Дополнительные структуры данных
Первой такой структурой является таблица транзакций (transaction table). Эта таблица содержит информацию обо всех незавершенных транзакциях, которые существуют в данный момент в системе. Таблица транзакций также используется при установке контрольных точек и восстановлении. Элемент таблицы содержит поля TransID (идентификатор транзакции) и LastLSN - LSN последней записи, помещенной в журнал этой транзакцией.
Кроме того, элемент таблицы транзакций содержит поля State и UndoNxtLSN. В первом поле хранится статус транзакции - prepared или unprepared. Рассматривается общий случай, когда данная транзакция может являться участницей некоей распределенной транзакции. Тогда то, что транзакция находится в состоянии prepared, означает, что она готова зафиксировать все требуемые изменения и ждет подтверждения от инициатора распределенной транзакции (составной частью которой она являлась), чтобы завершить работу. В тоже время такая транзакция должна сохранять ряд блокировок, чтобы быть в состоянии быстро откатиться в случае неудачного завершения распределенной транзакции. Статус unprepared характеризует то состояние, когда транзакция находится в процессе работы и еще не готова к завершению.
Как можно использовать такую информацию? Дело в том, что в случае сбоя транзакцию, находившуюся в этот момент в состоянии unprepared, скорее всего во время восстановления придется откатить. Но если транзакция находилась в момент сбоя в состоянии prepared, то может оказаться так, что она должна быть восстановлена и завершена. Это происходит в том случае, если инициатор транзакции все еще ждет от нашей БД завершения ее части распределенной транзакции.
Теперь вернемся к полю UndoNxtLSN. В этом поле элемента таблицы транзакций содержится LSN следующей записи журнала, которую необходимо обработать при откате. В случае, когда последняя запись не является CLR-записью, это значение совпадает с LastLSN. Если же последняя журнальная запись транзакции компенсационная, то это значение будет браться из одноименного поля CLR-записи.
Еще одним важным преимуществом ARIES является то, что алгоритм не накладывает фактически никаких ограничений на политику, используемую менеджером буферизации (кроме требования поддержки упреждающей журнализации). Вся необходимая для восстановления информация собирается на основе данных журнала. Но если конкретная политика буферизации неизвестна, во время восстановления потребуется некоторая дополнительная информация о состоянии страниц БД. Эта информация содержится в таблице "грязных" страниц (dirty pages table). Уточним, что имеется в виду. Страница буферного пула называется "грязной", если она содержит какие-либо изменения, еще не внесенные в тот вариант этой страницы, который располагается во внешней памяти. Чтобы отслеживать такие страницы, менеджер буферизации и поддерживает таблицу грязных страниц.
Каждый элемент этой таблицы содержит пару значений: PageID и RecLSN. PageID - это идентификатор страницы, а RecLSN - LSN, используемый при восстановлении. Зная это значение, мы можем установить, с какого LSN нужно просматривать журнал, чтобы восстановить страницу с данным PageID. В конкретной реализации таблица грязных страниц может быть организована с использованием хеширования.
