Ни один элемент данных не может быть заблокирован, пока не будет освобожден представляющий его узел.
Ни один из узлов не может быть освобожден, ока его родительский узел не будет освобожден от блокировки намерения.
Ни один узел не может быть освобожден, пока не будут освобождены все его потомки.
В этом случае блокировка устанавливается, начиная с корня иерархии вниз, с использованием блокировок намерения вплоть до достижения узла, представляющего элемент данных, блокируемый для записи или для чтения. Освобождение блоков выполняется снизу-вверх.
6.5. Восстановление данных
Восстановление данных – это процесс возвращения базы данных в корректное состояние, утраченное в результате сбоя или отказа.
Концепцию восстановления данных можно представить, как службу СУБД, гарантирующую надежное сохранение БД в согласованном состоянии даже при наличии в системе отказов. Как подобная служба может быть организована?
Для хранения данных в общем случае может быть использовано четыре различных типа носителей: оперативная память, магнитный диск, магнитная лента, оптический диск.
Существует множество различных типов отказов, которые могут влиять не только на содержимое ОЗУ, но и вторичной памяти:
Аварийное прекращение работы, вызванное ошибкой оборудования или программного обеспечения, приведшей к разрушению содержимого ОЗУ;
Отказ носителей информации;
Ошибка прикладных программ;
196
Стихийные бедствия – пожары, отказы в сети электропитания;
Небрежное или легкомысленное обращение
персонала;
Диверсии и преднамеренное разрушение или уничтожение данных, оборудования или ПО.
Какова бы ни была причина отказа, может быть два принципиально разных следствия – утрата содержимого ОЗУ и утрата копии БД на дисках.
Менеджер восстановления должен гарантировать, что при восстановлении после сбоя для каждой отдельной транзакции в БД будут постоянно фиксироваться либо все внесенные ею изменения, либо ни одного из них. Ситуация осложняется тем фактом, что запись в БД не представляет собой атомарного действия (выполняемого за один шаг), и поэтому существует вероятность, что, когда выполнение транзакции будет завершено, внесенные ею изменения не будут реально отражены в БД по той причине, что еще не достигли файлов БД.
Буфера СУБД занимают определенную часть оперативной памяти и используются для обмена информацией данными со вторичной памятью. Только после того как соответствующий буфер выгружен во вторичную память, можно считать, что выполненные операции обновления приобрели постоянный характер.
Если отказ системы произойдет между записью данных в буфер и выгрузкой буфера во вторичную память, менеджер восстановления должен уточнить состояние транзакции, выполнявшей запись в момент аварии. Если транзакция уже выдала команду завершения (выгрузки во вторичную память), то менеджер восстановления должен повторно ее выполнить.
Если на момент отказа системы транзакция еще не была завершена, менеджер восстановления должен отменить любые е результаты (откатить). Если требуется откатить только одну транзакцию, то это – частичный откат. Кроме того, транзакция может отменяться по внутренним причинам – по
197
требованию пользователя или в результате возникновения исключительной ситуации в прикладной программе. Если требуется выполнить откат всех активных транзакций, то это –
глобальный откат.
Функции восстановления
Типичная СУБД должна предоставлять такие функции восстановления как:
механизм резервного копирования, предназначенного для периодического создания копий БД;
средства ведения журнала, в котором фиксируются текущее состояние транзакций и вносимые в БД изменения;
функции создания контрольных точек, обеспечивающих перенос выполняемых в БД изменений во вторичную память с целью сделать их постоянными;
менеджер восстановления, обеспечивающий восстановление согласованного состояния БД, нарушенного в результате отказа.
-тип записи журнала (начало транзакции, операции вставки, обновления или удаления, отмены или фиксации транзакции);
-идентификатор элемента данных, вовлеченного в операцию обработки БД,
-копию элемента данных до операции;
-копию элемента данных после операции;
-служебную информацию файла журнала, включающую указатели на предыдущую и последующую записи журнала для этой транзакции;
записи контрольных точек.
Часто журнал используется и для других целей, отличных от целей восстановления. В этом случае он может содержать дополнительную информацию (например, сведения о пользователях, об операциях, о завершении сеанса пользователя).
По причине его важности журнал может создаваться в двух и даже в трех экземплярах, которые автоматически поддерживаются системой.
Один из подходов к автономной обработке файла журнала состоит в разделении оперативного файла на две независимые части, организованные в виде файлов с произвольным доступом. Записи журнала помещаются в первый файл до тех пор, пока он не оказывается заполненным до установленного уровня (например, на 70%). Затем открывается второй файл и все записи журнала для новых транзакций помещаются уже в него. Сведения о старых транзакциях помещаются в первый файл до тех пор, пока обработка всех старых транзакций не будет завершена. В этот момент первый файл закрывается и переводится в автономное состояние. Подобный подход упрощает восстановление отдельных транзакций, т.к. записи о каждой транзакции всегда содержатся в одном фрагменте файла журнала – либо в оперативном, либо в автономном. Следует отметить, что файл журнала потенциально является узким местом с точки зрения производительности любых систем, поэтому скорость записи
199
информации в файл журнала может оказаться одним из важнейших факторов, определяющих общую производительность системы с БД.
Создание контрольных точек Контрольная точка – это момент синхронизации между
базой данных и журналом регистрации транзакций. Все буфера системы принудительно записываются во вторичную память системы.
Контрольные точки организуются через установленный интервал времени и включают выполнение следующих действий.
Запись всех имеющихся в ОЗУ записей журнала во вторичную память;
Запись всех модифицированных блоков в буфера БД во вторичную память;
Помещение в файл журнала записи контрольной точки. Эта запись содержит идентификаторы всех транзакций, которые были активны в момент создания этой контрольной точки.
Если произошел отказ, то просматриваются все транзакции, выполнявшиеся после последней контрольной точки. Транзакция, которая выполнялась в момент отказа должна быть отменена, а остальные повторены.
Методы восстановления
Тип процедуры, которая будет использоваться для восстановления БД, зависит от размера повреждений, которые были нанесены этой базе в результате отказа. Рассмотрим два варианта:
Если базе данных нанесены обширные повреждения (например, разрушилась магнитная головка диска), то потребуется восстановить ее последнюю резервную копию, после чего повторить в ней все выполненные транзакции, сведения о которых присутствуют в журнале регистрации. Безусловно, предполагается, что файл журнала поврежден не
200