Базы Данных - Сибилев, 2007

81

−время начала операции,

−идентификатор обрабатываемого элемента данных,

−тип операции,

−копия элемента данных до операции (для операций обновления значения

иудаления),

−копия элемента данных после операции (для операций обновления значе-

нияи вставки).

Имея эту информацию, можно выполнить откат. Для этого нужно

− выбрать из журнала все записи об операциях откатываемой тран-

закции;

−расположить их в порядке, обратном хронологическому;

−последовательно просматривая обратный список операций, вы-

полнять над текущим состоянием рабочего буфера операции, обратные по смыслу.

Кроме того, каждой транзакции, завершившейся штатно (т.е. опера-

торами COMMIT или ROLLBACK), сопоставляется запись об окончании транзакции.

Но в случае мягкого сбоя этого мало, так как мягкий сбой приводит к потере содержимого рабочих буферов БД. Нужно ещё располагать состоя-

нием БД на какой-то момент времени t0 и знать, какие транзакции в этот момент существовали в системе. Тогда, если в момент tf > t0 произойдёт мягкий сбой, то для восстановления системы достаточно будет загрузить в оперативную память зафиксированное в момент t0 состояние рабочих бу-

феров БД, проанализировать записи журнала транзакций, сделанные в ин-

тервале [t0, tf], и восстановить (выполнить повторно) успешно завершённые или откатить незавершённые транзакции.

Итак, для обеспечения возможности восстановления системы после мягкого сбоя состояние рабочих буферов БД должно периодически фик-

82

сироваться во внешней памяти, и каждая запись журнала транзакций должна иметь временнỳю метку.

Однако и этого недостаточно. Нужно ещё, чтобы все записи журнала от транзакций, завершённых до момента сбоя, находились во внешней па-

мяти.

Обычно поддерживается следующая дисциплина обмена между внешней памятью и ОЗУ. С целью минимизации обращений к устройствам внешней памяти программы формируют записи файлов в своих рабочих буферах ОЗУ. Сброс записей во внешнюю память происходит автоматиче-

ски, когда буфер заполняется. Незаполненный буфер можно вытолкнуть принудительно.

Буфер журнала имеет размер, достаточный для размещения записей от многих транзакций. Велика вероятность того, что к моменту мягкого сбоя он не будет сброшен во внешнюю память автоматически, и часть за-

писей журнала будет утеряна.

Буфер журнала должен принудительно выталкиваться во внешнюю память при завершении транзакции. Только после этого транзакция счи-

тается закончившейся. Обновления, совершённые транзакцией, не могут попасть во внешнюю память раньше, чем соответствующие ей записи журнала.

Это правило составляет суть протокола предварительной записи в журнал (протокол WAL – Write Ahead Log).

Посмотрим теперь, как можно восстанавливать состояние базы дан-

ных, если в системе поддерживается журнал транзакций и протокол пред-

варительной записи.

4.10.3 Индивидуальный откат транзакции

Индивидуальный откат транзакции производится либо по явно за-

данному оператору ROLLBACK, либо вследствие локального сбоя.

83

Для осуществления отката создаётся список записей журнала от дан-

ной транзакции. Элементы списка размещены в порядке, обратном хроно-

логическому. Список последовательно просматривается и для каждой за-

писи выполняется противоположная по смыслу операция, восстанавли-

вающая предыдущее состояние объекта базы данных. Начальным состоя-

нием для процедуры отката является состояние буферов БД в момент пре-

кращения транзакции.

С точки зрения системы процедура отката является транзакцией. По-

этому обратные операции также регистрируются в журнале. Это «пере-

страховка» на случай мягкого сбоя системы в процессе отката. Имея эти записи, система сможет «дооткатить» транзакцию, откат которой был пре-

рван.

4.10.4 Восстановление после мягкого сбоя

Рабочие буферы базы данных, в отличие от буфера журнала, не вы-

талкиваются во внешнюю память при каждом успешном завершении тран-

закции. Реально исполнение оператора COMMIT сводится к тому, что ста-

новится невозможной отмена проделанных транзакцией изменений. Сам же изменённый объект может ещё долго существовать только в рабочем буфере БД. Может случиться так, что в системе произойдёт сбой после ус-

пешного выполнения COMMIT, но до того, как обновлённый транзакцией объект попадёт во внешнюю память. В соответствии с принципом долго-

вечности транзакции система должна при перезагрузке сохранить эти об-

новления в ФБД, несмотря на то, что их уже нет в буфере оперативной па-

мяти.

Кроме того, система может временно помещать во внешнюю память промежуточные результаты транзакций, если необходимо освободить ме-

сто в буферах. При нормальной работе эти несогласованные изменения по завершении внесшей их транзакции отвергаются. Поскольку мягкий сбой прерывает все транзакции, промежуточные результаты оказываются «за-

фиксированными».

84

При перезагрузке система должна откатить все прерванные тран-

закции и выполнить повторно все успешно завершившиеся, но не зафик-

сированные в ФБД.

Текущее состояние ФБД в момент сбоя не может быть использовано как опорное для восстановления, поскольку неизвестно, к какому моменту времени оно относится. Для того чтобы иметь такое опорное состояние БД,

система принимает контрольную точку.

В некотором интервале времени она дожидается завершения очеред-

ных операций обновления во всех транзакциях и не допускает запуска но-

вых операций. Исполнение действующих транзакций приостанавливается.

В момент принятия контрольной точки, когда все транзакции приостанов-

лены, в журнале создаётся специальная запись контрольной точки, содер-

жащая список всех транзакций, существующих в системе. Затем во внеш-

нюю память принудительно выталкивается содержимое буфера журнала и рабочих буферов СУБД. По завершении этого процесса исполнение приос-

тановленных транзакций продолжается.

Пусть последняя контрольная точка принята в момент tc, а в момент tf произошёл мягкий сбой. К моменту мягкого сбоя возможны состояния транзакций, показанные на рис.4.9.

При перезагрузке системы после мягкого сбоя для транзакций типа

T1, завершившихся до момента принятия контрольной точки, никаких действий производить не требуется, т.к. их результаты отражены в ФБД.

Транзакции типа T2 и Т4 нужно выполнить повторно, а Т3 и Т5 – отка-

тить.

85

ТТ1

Рис. 4.9 Типичные состояния транзакций на момент мягкого сбоя

Замечание. Транзакции, прерванные или завершившиеся оператором

ROLLBACK до мягкого сбоя, в процессе восстановления не участвуют.

Впроцессе восстановления выполняются следующие действия.

•Создаётся два списка транзакций: отменяемых (UNDO) и испол-

няемых повторно (REDO). В список UNDO включаются все транзакции,

указанные в записи контрольной точки. Список REDO остаётся пустым.

• Выполняется анализ записей журнала регистрации, начиная с запи-

си контрольной точки.

•Если обнаружена запись о начале транзакции Т, то эта транзакция добавляется в список UNDO.

•Если обнаружена запись о завершении транзакции Т оператором

COMMIT, то эта транзакция добавляется в список REDO.

• По достижении конца файла журнала списки анализируются с це-

лью различения транзакций типа Т2 – Т4 и Т3 – Т5. Из списка UNDO ис-

ключаются транзакции, попавшие в список REDO.

• Системный журнал просматривается от конца до записи контроль-

ной точки, и отменяются транзакции из списка UNDO.

• Системный журнал просматривается от записи контрольной точки до конца, и выполняются повторно транзакции из списка REDO.

По окончании этой процедуры система готова к работе.

86

4.10.5 Восстановление после жесткого сбоя

При жёстком сбое физическая база данных оказывается разрушен-

ной. Поэтому для восстановления необходимо иметь её резервную копию.

Обычно резервное копирование ФБД выполняется по факту переполнения системного журнала. Для этого в файле журнала устанавливается так на-

зываемая «жёлтая зона», по достижении которой запуск новых транзак-

ций не производится. Система дожидается окончания всех существующих транзакций. После этого рабочие буферы журнала и базы данных выталки-

ваются во внешнюю память. Созданное таким образом состояние ФБД ко-

пируется на резервный носитель, а файл журнала очищается. Может быть также создана резервная копия журнала.

При восстановлении после жёсткого сбоя восстанавливается состоя-

ние ФБД на момент последнего копирования, а затем по текущему журна-

лу регистрации повторно исполняются все транзакции, успешно завер-

шившиеся до момента сбоя.

Поскольку жёсткий сбой не сопровождается потерей буферов, после восстановления можно даже продолжить исполнение не завершившихся к моменту сбоя транзакций. Однако обычно все незавершённые транзакции откатываются.

4.11 Функции СУБД

В качестве резюме сказанного в настоящем разделе перечислим требо-

вания к функциям и службам, которые должна поддерживать полномасштаб-

ная СУБД. Эти требования сформулированы в 1982 году Э. Коддом и извест-

ны как «восемь сервисов Кодда».

1. СУБД должна предоставлять пользователям возможность сохра-

нять, извлекать и обновлять данные в базе данных.

Это самая главная функция СУБД. Способ реализации этой функции должен обеспечивать сокрытие от пользователя деталей физической реа-

лизации системы.

87

2. СУБД должна поддерживать доступный пользователям каталог, в

котором хранятся описания элементов и структур данных.

Системный каталог обеспечивает следующие возможности.

− Централизованное накопление и сохранение информации о ресур-

сах данных. Благодаря этому оказывается возможным управление данны-

ми как ресурсом организации.

−Сохранение точных определений смысла элементов и структур данных. Благодаря этому пользователи могут понять их предназначение.

−Обнаружение избыточности и противоречивости описания отдель-

ных элементов данных.

− Протоколирование изменений организации базы данных, в частно-

сти, схем всех уровней.

−Определение последствий любых изменений в организации БД ещё до их внесения.

−Организацию поддержки целостности данных.

−Сохранение сведений о владельцах и пользователях данных и об их привилегиях. Благодаря этому система может обнаруживать и пресекать попытки несанкционированного использования данных.

3. СУБД должна иметь механизм, гарантирующий выполнение либо всех операций транзакции, либо ни одной из них.

Эта служба обеспечивает атомарность и (совместно со службами 5

и 8) согласованность транзакции.

4. СУБД должна иметь механизм, гарантирующий корректное об-

новление базы данных при параллельном выполнении операций обновле-

ния многими пользователями.

Эта служба обеспечивает изолированность транзакций.

5. СУБД должна предоставлять средства восстановления базы дан-

ных в случае какого-либо её повреждения или разрушения.

Эта служба обеспечивает долговечность транзакций.

88

6. СУБД должна иметь механизм, гарантирующий доступ к данным только санкционированных пользователей.

Этот механизм обеспечивает безопасность данных, уменьшает воз-

можности их некомпетентного или злонамеренного использования.

7. СУБД должна иметь механизмы взаимодействия с различными коммуникационными программными средствами.

Современные системы баз данных реализуются в технологии «кли-

ент-сервер». Приложение, размещённое на клиентском узле сети, обраща-

ется к серверу БД и получает сообщения от него через сеть, управляемую менеджером обмена данными (МОД). МОД не является частью СУБД, но жизнеспособная СУБД должна быть способна к интеграции с различными МОД.

8. СУБД должна иметь средства контроля данных на соответствие заданным правилам целостности.

Эта служба обеспечивает предотвращение ошибок пользователей при обновлении данных, а также поддержание делового регламента орга-

низации в рамках известных системе правил.

Кроме этих основных служб полномасштабная СУБД должна пре-

доставлять некоторый набор вспомогательных служб (утилит), поддержи-

вающих функции Администратора баз данных.

89

5 Реляционная модель данных

5.1 Общая характеристика модели

Реляционная база данных (РБД) на концептуальном уровне

ANSI/SPARC выглядит как совокупность взаимосвязанных простых таб-

лиц. РБД управляется реляционной СУБД (РСУБД). Реляционные СУБД появились на рынке программных продуктов в конце 70-х годов ХХ века и быстро вытеснили господствовавшие там иерархические и сетевые СУБД.

И это несмотря на то, что они существенно уступали (по крайней мере,

вначале) своим конкурентам в производительности.

РСУБД и РБД базируются на реляционной модели данных (РМД).

РМД предложена в 1970 году американским математиком Эдгаром Ф.

Коддом. В это время фирма IBM работала над проектом, известным под названием System/R. Проект был направлен на создание СУБД нового по-

коления и обобщал накопленный опыт эксплуатации систем с базами дан-

ных. По замыслу разработчиков новая СУБД должна была иметь входной язык, доступный пользователю-непрограммисту. Все СУБД, представлен-

ные к тому времени на рынке программного обеспечения, имели только интерфейс прикладного программиста. Конечный пользователь обращался к СУБД исключительно через посредство приложения. Приложения вы-

полняли обработку предопределённых запросов. Любой новый запрос тре-

бовал модификации приложения, как правило, разработки новой приклад-

ной программы. Пользователь вынужден был обращаться к программистам с любой «мелочью». СУБД, предоставляющая конечному пользователю доступ к БД, минуя программиста, сильно укрепила бы позиции фирмы

IBM на рынке. Оказалось, что РМД является хорошей основой для входно-

го языка такой СУБД. Экспериментальная РСУБД System/R была создана в начале 70-х годов ХХ века. Она не избавила пользователя от программи-

ста, но зато существенно облегчила задачи создания приложений. Многие

90

решения, найденные в ходе разработки System/R, до сих пор служат ори-

ентиром для проектировщиков СУБД.

Первая промышленная РСУБД DB2 также создана фирмой IBM. Она появилась на рынке в конце 70-х годов и до настоящего времени успешно эксплуатируется во многих организациях. Входной язык DB2, известный ныне под названием SQL (Structured Query Language), стандартизован и поддерживается всеми современными РСУБД.

Причиной популярности РСУБД среди разработчиков СБД является простота входного языка этих систем. Входной язык РСУБД содержит

−язык определения данных (ЯОД) — средства определения объектов РБД на логическом уровне и

−язык манипулирования данными (ЯМД) —непроцедурные средства описания операций выборки/обновления данных.

Структуры данных РБД — таблицы — просты для понимания. Каж-

дая таблица представляет какой-то объект предметной области. Связи объ-

ектов в концептуальной схеме РБД определяются явно. Поэтому схема БД понятна конечному пользователю на интуитивном уровне. Операторы ма-

нипулирования данными (выборка/обновление) являются, по сути, описа-

ниями свойств требуемых наборов значений данных и не содержат каких-

либо указаний на то, как эти значения извлечь из БД или поместить на хранение.

Например, запрос на выборку сведений о студентах может выглядеть

(в неформальной записи) так:

«Получить значения полей Фамилия, Имя, Отчество, Номер-

Студбилета из тех строк таблицы СТУДЕНТ, в которых значение поля

НомерГруппы = 10801».

Формальная запись этого запроса ничуть не сложнее:

SELECT Фамилия, Имя, Отчество, НомерСтудбилета

FROM СТУДЕНТ

WHERE НомерГруппы = ‘10801’;