Схема восстановления
Процесс восстановления в разных системах выглядит похожим образом. Сначала проходит стадия анализа, во время которой на основе журнальной информации собираются сведения, необходимые для восстановления. В основном эта работа связана с определением тех транзакций, действия которых необходимо повторить, и тех, действия которых нужно отменить. После этого следуют стадии повторения и отмены. Обычно во время повторения в базу данных вносятся все изменения, которые были внесены в нее транзакциями, успевшими к моменту сбоя завершиться, а отмена соответственно заключается в том, чтобы отменить действия, совершенные транзакциями, нуждающимися в откате. В ARIES имеется некоторое отличие от этой схемы, а именно то, что на стадии повторения ARIES повторяет все действия, которые были отражены в журнале к моменту сбоя. То есть после этой стадии база данных находится в том же состоянии, в каком она была во время сбоя. После этого уже происходит откат всех незавершенных транзакций.
Опишем схему восстановления ARIES более детально. Для этого приведем псевдокод, описывающий процесс восстановления в виде процедуры.
restart (masteraddr)
{
restartanalysis (masteraddr, transtable, dirtypages, redoLSN);
restartredo (redoLSN, transtable, dirtypages);
Инициализировать системную таблицу грязных страниц данными из таблицы dirtypages, созданной на двух первых этапах;
Удалить из этой таблицы все записи, соответствующие тем страницам, которые были сброшены на диск;
restartundo (transtable);
Восстановить блокировки для транзакций, находившихся в состоянии prepared;
checkpoint ();
}
Сначала следует стадия анализа. На этой стадии, на основе записей последней контрольной точки воссоздаются таблицы транзакций и грязных страниц. Еще одно значение, получаемое на этой стадии, - redoLSN. Это номер записи журнала, начиная с которой будут повторяться действия над базой данных во время следующего этапа восстановления. Единственный тип записей, которые добавляются в журнал во время стадии анализа, - это записи о завершении откатов транзакций, которые уже завершили откат к моменту сбоя, но не успели зафиксировать этот факт в журнале.
Далее на стадии повторения просматривается журнал, и в таблицы, загруженные из записей контрольной точки, вносятся изменения. В конце этой стадии таблица транзакций и таблица грязных страниц фактически приходят в то состояние, в котором они находились на момент сбоя. После этого redoLSN вычисляется как минимум из RecLNS, содержащихся в таблице грязных страниц.
Вообще говоря, не обязательно требуется оформлять стадию анализа в качестве отдельного прохода. Поскольку в ARIES на стадии повторения в любом случае вносятся все недостающие изменения вне зависимости от того, придется ли их потом откатывать или нет, информация, собранная во время анализа, может потребоваться лишь на этапе отмены (undo). Таким образом, стадии повторения и анализа можно совместить.
После завершения этих двух этапов системная таблица грязных страниц мы инициализируется тем вариантом таблицы, который получился в результате проделанной работы. Далее из нее удаляются записи о тех страницах, которые уже попали во внешнюю память. Начиная с этого момента, таблица грязных страниц поддерживается менеджером буферизации в автоматическом режиме. И лишь после этого происходит стадия отката.
На этой стадии откатываются те транзакции, которые в существенной степени не успели завершиться к моменту сбоя. Откат всех таких транзакций происходит за один просмотр журнала. LSN следующей записи журнала, подлежащей откату, вычисляется как максимум из всех номеров записей, которые были созданы откатываемыми транзакциями. То есть откат действий этих транзакций происходит в обратном хронологическом порядке.
Выше была описана обычная схема восстановления. В ней восстановление происходит в режиме offline. Это означает, что пользователям СУБД придется дожидаться окончания процесса восстановления, прежде чем они смогут продолжить работу с базой данных. Поэтому вполне естественно стремление сократить промежуток времени после сбоя, в течение которого система недоступна. Для этого можно разделить все объекты базы данных на два класса в соответствии с их важностью.Объекты первого класса восстанавливаются в первую очередь, чтобы позволить СУБД инициировать новые транзакции для работы над ними как можно скорее. Восстановление же объектов второго класса можно несколько отложить во времени, поскольку они менее важны. Это свойство поддерживается во многих алгоритмах восстановления. ARIES также допускает модификацию, позволяющую реализовать такую схему восстановления. Более подробно этот вопрос освещен в [4].
