Лабораторные работы по курсу «Базы данных»

рассматриваются два возможных вида аппаратных сбоев: так называемые 
мягкие сбои, которые можно трактовать как внезапную остановку работы 
компьютера (например, аварийное выключение питания), и жесткие сбои, 
характеризуемые потерей информации на носителях внешней памяти. 
Примерами программных сбоев могут быть: аварийное завершение работы 
СУБД (по причине ошибки в программе или в результате некоторого 
аппаратного сбоя) или аварийное завершение пользовательской программы, в 
результате чего некоторая транзакция остается незавершенной. Первую 
ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; 
при возникновении последней требуется ликвидировать последствия только 
одной транзакции. 
Понятно, что в любом случае для восстановления БД нужно располагать 
некоторой дополнительной информацией. Другими словами, поддержание 
надежности хранения данных в БД требует избыточности хранения данных. 
Наиболее распространенным методом поддержания такой избыточной 
информации является ведение журнала изменений БД. 
Журнал – это особая часть БД, недоступная пользователям СУБД, в 
которую поступают записи обо всех изменениях основной части БД. В 
разных СУБД изменения БД журнализуются на разных уровнях: иногда 
запись в журнале соответствует некоторой логической операции изменения 
БД (например, операции удаления строки из таблицы реляционной БД), 
иногда - минимальной внутренней операции модификации страницы 
внешней памяти; в некоторых системах одновременно используются оба 
подхода. 
Во всех случаях придерживаются стратегии "упреждающей" записи в 
журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, 
эта стратегия заключается в том, что запись об изменении любого объекта БД 
должна попасть во внешнюю память журнала раньше, чем измененный 
объект попадет во внешнюю память основной части БД. Известно, что если в 
СУБД корректно соблюдается протокол WAL, то с помощью журнала можно 
решить все проблемы восстановления БД после любого сбоя. 
Самая простая ситуация восстановления - индивидуальный откат 
транзакции. Строго говоря, для этого не требуется общесистемный журнал 
изменений БД. Достаточно для каждой транзакции поддерживать локальный 
журнал операций модификации БД, выполненных в этой транзакции, и 
производить откат транзакции путем выполнения обратных операций, следуя 
от конца локального журнала. В некоторых СУБД так и делают, но в 
большинстве 
систем 
локальные 
журналы 
не 
поддерживают, 
а 
индивидуальный откат транзакции выполняют по общесистемному журналу, 
для чего все записи от одной транзакции связывают обратным списком (от 
конца к началу).
При мягком сбое во внешней памяти основной части БД могут 
находиться объекты, модифицированные транзакциями, не закончившимися 
к моменту сбоя, и могут отсутствовать объекты, модифицированные 
транзакциями, которые к моменту сбоя успешно завершились (по причине 

использования буферов оперативной памяти, содержимое которых при 
мягком сбое пропадает). При соблюдении протокола WAL во внешней 
памяти журнала должны гарантированно находиться записи, относящиеся к 
операциям модификации обоих видов объектов. Целью процесса 
восстановления после мягкого сбоя является состояние внешней памяти 
основной части БД, которое возникло бы при фиксации во внешней памяти 
изменений всех завершившихся транзакций и которое не содержало бы 
никаких следов незаконченных транзакций. Для того чтобы этого добиться, 
сначала производят откат незавершенных транзакций (undo), а потом 
повторно воспроизводят (redo) те операции завершенных транзакций, 
результаты которых не отображены во внешней памяти. 
Для восстановления БД после жесткого сбоя используют журнал и 
архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к 
моменту начала заполнения журнала (имеется много вариантов более гибкой 
трактовки смысла архивной копии). Конечно, для нормального 
восстановления БД после жесткого сбоя необходимо, чтобы журнал не 
пропал. 

жүктеу/скачать 0,79 Mb.

Достарыңызбен бөлісу: