Развитие идей и приложений реляционной СУБД System R


Журнализация и восстановление в System R - часть 2


В общем случае процесс восстановления после жесткого сбоя существенно более накладен, чем после мягкого сбоя.

Как отмечает Дейт [34], любое восстановление состояния базы данных должно основываться на наличии некоторой дополнительной, избыточной информации. Из общих соображений очевидно, что для восстановления базы данных необходима информация, которая не теряется при сбоях, вызывающих потребность в восстановлении. Тем самым, задача любой СУБД и System R, в частности, состоит в выборе некоторого базового механизма поддержки такой избыточной информации, который удовлетворял бы потребностям всех используемых типов восстановлений.

Алгоритмы восстановления System R основаны на двух базовых средствах - ведении журнала и поддержке теневых состояний сегментов. Рассмотрим сначала механизм журнализации. Мы уже упоминали о наличии журнала в предыдущих подразделах. Журнал это отдельный файл внешней памяти, для которого для надежности обычно поддерживаются две копии и в который помещается информация по поводу всех операций изменения состояния базы данных. В предыдущем подразделе мы упоминали об использовании журнала для отката транзакции по явной операции RESTORE или при неявных откатах при разрушении тупиков. Та же схема употребляется и при откатах индивидуальных транзакций при сбоях.

Механизм индивидуального отката основан на обратном выполнении всех изменений, произведенных данной транзакции (undo). При этом из журнала в обратном хронологическому порядке выбираются все записи об изменении базы данных, произведенные от имени данной транзакции. Для этого необходима идентификация всех записей в журнале. В System R все записи одной транзакции связываются в один список в порядке обратном хронологическому. Ссылка в списке представляет собой адрес записи в файле-журнале. Поскольку схема индивидуального отката едина для всех ситуаций индивидуальных сбоев, в частности для ситуации разрушения тупиков, то обратное выполнение операций сопровождается снятием установленных при прямой работе транзакции синхронизационных захватов с объектов базы данных.


Начало  Назад  Вперед