Структура записей журнала
Поскольку в ARIES на журнал возлагается вся ответственность за восстановление данных, записи журнала являются достаточно сложными и содержат массу информации. Эти записи имеют различную структуру в зависимости от журнализуемого действия. Например, запись, помещаемая при обычной работе транзакции, несколько отличается от записи, помещаемой в случае ее частичного или полного отката. Для обозначения записей последнего типа будем использовать термин CLR (Compensation Log Record). Ниже перечисляются некоторые поля записи журнала, которые используются далее при описании ARIES. Конечно, приводимая структура записи не является единственно возможной. Она максимально упрощена для удобства изложения основных идей алгоритма.
Поле LSN (Log Sequence Number) содержит номер записи журнала. Для простоты изложения будем считать, что это значение постоянно увеличивается (т.е. номера не используются повторно). Будем также полагать, что сам журнал представляет собой бесконечно увеличивающийся файл, хотя, конечно, на практике обычно используется группа файлов. В качестве LSN часто используется адрес первого байта записи журнала. Из этого следует, что хранить LSN в виде отдельного поля не обязательно.
Содержимое поля Type определяет тип того действия, которое описывает запись журнала. В этом поле могут встретиться такие значения, как "compensation" (для записи, соответствующей откату некоторого шага транзакции), "update" или "commit". Тип действия может быть и не связан с работой транзакций (например, записи могут относиться к работе менеджера буферизации)
Поле TransID содержит идентификатор транзакции, к которой относится запись журнала.
В поле PrevLSN хранится номер предыдущей записи, добавленной в журнал журнализуемой транзакцией. В первой записи, созданной транзакцией, это значение полагается равным нулю. Таким образом, все записи, которые описывают изменения, вносимые данной транзакцией, оказываются связанными в список. Это позволяет при необходимости отката пройти от конца транзакции к началу, пошаговым образом отменяя все действия, совершенные транзакцией.
Поле PageID присутствует только в записях, описывающих действия по изменению данных, таких как update или compensation. Поле содержит идентификатор изменяемой страницы данных.
Поле UndoNxtLSN присутствует только в CLR-записях (тех записях, которые журнализуют откаты транзакций). Оно содержит LSN следующей записи журнала, которую надо будет обработать при откате.
По этому поводу требуется некоторый комментарий. Существенной особенностью ARIES является то, что компенсационные записи (CLR), фиксирующие откаты транзакций, сами не допускают отката. В оригинальной работе про ARIES они называются redo-only records. Именно по этой причине такие записи содержат поле UndoNxtLSN. Это поле позволяет при откате обойти CLR, проследовав к той записи, на которую оно указывает. Обычно UndoNxtLSN содержит LSN записи, которая расположена в списке записей, описывающем действия данной транзакции, перед той записью, откат которой фиксирует CLR. Поскольку обычно требуется отменить не собственно откат (CLR) а несколько действий транзакции (может быть даже все), то таким образом устраняется потребность в лишней работе. В самом деле, зачем отменять откат (т.е. восстанавливать некоторое действие) если тут же будет отменено и само это действие, что вернет нас на исходные позиции. Однако поле UndoNxtLSN CLR-записи не всегда используется именно таким образом. Забегая вперед, заметим, что исключением является случай, который возникает при реализации аппарата Nested Top Actions (NTA).
Последнее поле, котором следует упомянуть, это поле Data. В зависимости от типа записи оно содержит информацию, необходимую при восстановлении или откате. Обычно это самое длинное поле записи журнала, содержащие информацию непосредственно из базы данных (например, это может быть образ объекта до и после его изменения).
После обсуждения структуры записей журнала, мы можем объяснить то, как в ARIES отслеживаются состояния страниц базы данных. Когда мы говорим о состоянии страницы БД, нас интересует, главным образом, попали ли в нее изменения, описанные в журнале.Чтобы обеспечить возможность выяснить это, в каждую страница помещается LSN (будем называть его page_LSN) записи, которая описывает последнее изменение, внесенное в эту страницу. Сравнивая page_LSN со значениями LSN записей журнала можно выяснить, были ли внесены изменения, описываемые данной записью журнала, в страницу или же нет.
Вся эта информация необходима во время восстановления после сбоя. Вообще говоря, ARIES довольно детально описывает процесс восстановления. Возможно, именно эффективный способ восстановления стал главным фактором популярности ARIES. Поэтому обратимся к устройству системы восстановления. Но перед этим нам нужно рассмотреть еще несколько структур данных, поддерживаемых во время работы СУБД по алгоритму ARIES.
