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