Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Posibnik.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
5.62 Mб
Скачать

Создание контрольных точек

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

Контрольная точка – момент синхронизации между базой данных и журналом регистрации транзакций.

В этот момент все буфера системы принудительно записываются во вторичную память системы.

Контрольные точки организуются через установленный интервал времени и предусматривают выполнение следующих действий.

  • Перенос всех имеющихся в оперативной памяти записей журнала во вторичную память.

  • Запись всех модифицированных блоков в буферах базы данных во вторичную память.

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

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

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

Пример выполнения операций отката и наката при наличии контрольной точки.

Обратимся к примеру выполнения операций отката и наката. Если предположить, что в момент времени tс была создана контрольная точка, то это позволит установить, что результаты выполнения транзакций Т2 и Т3, уже внесены во вторичную память. Поэтому диспетчеру восстановления не потребуется выполнять накат этих транзакций.

Однако выполнение наката потребуется для транзакций Т4 и Т5, результаты которых были зафиксированы после создания контрольной точки. Кроме того, потребуется выполнить откат транзакций Т1 и Т6, которые все еще были активны в момент возникновения аварии. Обычно создание контрольных точек представляет собой относительно недорогую операцию, поэтому часто оказывается возможным создать три или даже четыре контрольные точки в час. В результате при сбое потребу восстановить работу, выполненную всего лишь за последние 15-20 минут.

Методы восстановления

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

Рассмотрим два варианта.

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]