ЖУРНАЛИЗАЦИЯ ИЗМЕНЕНИЙ БД
Одним из основных требований к развитым СУБД является надежность хранения данных, т. е. возможность восстановления согласованного состояния БД после любого рода аппаратных и программных сбоев. Очевидно, что для выполнения восстановлений необходима некоторая дополнительная информация. В подавляющем большинстве современных реляционных СУБД такая избыточная дополнительная информация поддерживается в виде журнала изменений БД.
Итак, общей целью журнализации изменений БД является обеспечение возможности восстановления согласованного состояния БД после любого сбоя. Поскольку основой поддержания целостного состояния БД является механизм транзакций, журнализация и восстановление тесно связаны с этим понятием. Общими принципами восстановления являются следующие: — результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии БД;
- результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии БД.
Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние БД.
Возможны следующие ситуации, при которых требуется производить восстановление состояния БД:
- 1. Индивидуальный откат транзакции. Простой ситуацией отката транзакции является ее явное завершение оператором ROLLBACK. Возможны также случаи, когда откат инициируется системой. Примерами могут быть возникновение исключительной ситуации в прикладной программе (например, деление на ноль) или выбор транзакции в качестве жертвы при обнаружении синхронизационного тупика. Для восстановления согласованного состояния БД при индивидуальном откате нужно устранить последствия операторов модификации БД, которые выполнялись в этой транзакции.
- 2. Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть при аварийном выключении электрического питания, сбое процессора (например, срабатывании контроллера оперативной памяти) и т. д. Теряется та часть БД, которая к моменту сбоя содержалась в буфере оперативной памяти.
- 3. Восстановление после поломки основного внешнего носителя БД (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее, СУБД должна быть в состоянии восстановить БД даже и в этом случае. Основой восстановления является архивная копия и журнал изменений БД.
Во всех трех случаях основой восстановления является избыточное хранение данных в журнале, содержащем последовательность записей об изменении БД.
Возможны два основных варианта ведения журнальной информации.
В первом варианте для каждой транзакции поддерживается отдельный локальный журнал изменений БД этой транзакцией. Эти журналы используются для индивидуальных откатов транзакций и могут поддерживаться в оперативной
(правильнее сказать, в виртуальной) памяти. Кроме того, поддерживается общий журнал изменений, используемый для восстановления состояния БД после мягких и жестких сбоев.
Этот подход позволяет быстро выполнять индивидуальные откаты транзакций, но приводит к дублированию информации в локальных и общем журналах. Поэтому чаще применяется второй вариант — поддержание только общего журнала изменений БД, который используется и при выполнении индивидуальных откатов. Далее рассмотрим именно этот вариант.
