Журнализация (Элемент протоколирования)

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

Аппаратные сбои обычно подразделяются на два вида:

– мягкие сбои связаны с внезапной остановкой работы компьютера. Обычно явля­ются следствием внезапного выключения питания или «зависания» операцион­ной системы (что особенно характерно для операционных Систем Windows);

– жесткие сбои характеризуются потерей информации на носителях внешней памяти.

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

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

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

В разных СУБД изменения базы данных журнализируются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции измене­ния базы данных, иногда – минимальной внутренней операции модификации стра­ницы внешней памяти. Могут также использоваться одновременно оба подхода.

Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log – WAL). Несколько утрированно можно сказать, что эта стратегия заключается в том, что запись об изменении любого объек­та базы данных должна быть занесена в журнал до того, как будет выполнено и зафиксировано изменение этого объекта. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановле­ния базы данных после любого сбоя.

Самая простая ситуация восстановления – индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений базы данных. Достаточно для каждой транзакции поддерживать локальный журнал опе­раций модификации базы данных, выполненных в этой транзакции, и произво­дить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции вы­полняют по общесистемному журналу, для чего все записи, относящиеся к одной транзакции, связывают обратным списком (от конца к началу).

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

Для восстановления базы данных после жесткого сбоя используют журнал и архивную копию базы данных. Архивная копия – это полная копия базы данных к моменту начала заполнения журнала (хотя имеется много вариантов трактовки смыс­ла архивной копии). Для нормального восстановления базы данных после жестко­го сбоя, естественно, необходимо, чтобы журнал не пропал. Тогда восстановление базы данных состоит в том, что, исходя из архивной копии, по журналу воспроиз­водится работа всех транзакций, которые закончились к моменту сбоя. В принци­пе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обыч­но не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.