Почему Aries выполняет повтор перед отменой при восстановлении управления базой данных?

Потому что в буфере могут быть несброшенные страницы, даже если транзакция зафиксирована. ARIES использует no-force в диспетчере буферов. Повтор приводит таблицу транзакций и таблицу грязных страниц в состояние, которое было на момент сбоя. В результате успешные транзакции могут быть отражены в стабильном хранилище.

Короткий ответ:

Нам нужно повторить все сбои в истории на проходе повтора, чтобы обеспечить согласованность базы данных перед выполнением прохода отмены.

Длинный ответ:

алгоритм восстановления ARIES, чтобы обеспечить свойства атомарности и устойчивости СУБД, выполняет 3 проходит:

1. Проход анализа: чтобы увидеть, что нужно сделать (проигрывает журнал вперед)
2. Повторить проход: чтобы убедиться, что диск отражает все обновления, которые есть в журнале, но не на диске, включая те, которые относятся к транзакциям, которые в конечном итоге будут отменены. Таким образом, мы находимся в непротиворечивом состоянии, что позволяет выполнять логическую отмену.
3. Отменить проход: удалить действия любых проигрышных транзакций.

Журнал данных UNDO является логическим, а журнал данных REDO — физическим:

• Мы должны выполнить физический REDO, так как мы не можем гарантировать, что база данных находится в согласованном состоянии (поэтому, например, регистрация «INSERT VALUE X INTO TABLE Y» может быть плохой идеей, потому что X может быть отражено в индексе, но а не таблицу, или наоборот, если при вставке произойдет сбой)
• Мы можем выполнить логический UNDO, потому что после REDO мы знаем, что все непротиворечиво. На самом деле, мы должны выполнять логическую отмену, потому что мы отменяем только некоторые действия, а физическое ведение журналов отмен в форме, например, «разделить страницу x индекса y», может быть неправильным с точки зрения управления индексами или инвариантами. техническое обслуживание. Нам не нужно беспокоиться об этом во время повтора, потому что мы повторяем историю и воспроизводим все, что означает, что любые физические изменения, сделанные в базе данных в прошлый раз, по-прежнему будут правильными.

Источник

Не знаю, что такое aries, но если предположить, что это то же самое, что и другие базы данных:

Начиная с некоторых базовых журналов повторного выполнения резервных копий, применяются все операторы изменения данных, которые произошли после резервного копирования, но до сбоя. Без этого вы бы потеряли все, что произошло с момента последней резервной копии.

Когда это завершено, все незавершенные транзакции откатываются, потому что нет никого, кто мог бы взять эти транзакции для их завершения.

Вы хотите вернуться к состоянию на момент сбоя, чтобы точно определить, какие транзакции необходимо отменить. Одним из примеров, который приходит на ум, являются последовательные неудачи. Именно сбои при восстановлении после крашей. Во время восстановления вы записываете свои действия в журнал. Если вы потерпите неудачу во время процесса восстановления, вы ПОВТОРИТЕ все операции в журнале (даже операции ОТМЕНЫ, записанные во время последней попытки!!).

Он обеспечивает простой алгоритм, потому что вам не нужно обрабатывать особые случаи и особые случаи особых случаев. Есть гарантия, что после любого количества сбоев при восстановлении мы вернемся в то же состояние, как если бы сбоев при восстановлении не было.

если вы не поддерживаете блокировку на уровне записи, вы можете использовать выборочный повтор, который повторяет только транзакцию победителя. в противном случае лучше повторить историю (переделать все) перед отменой

Вы можете рассмотреть, что на самом деле делается во время повтора и отмены. Redo повторяет историю, согласно завершенным журналам. Отмена, напротив, создает новые записи журнала CLR. При сбое системы в журнале появляются записи о незафиксированных xacts. Если вы не отмените их, записей журнала CLR не будет, что приведет к несогласованности.

Одна из целей ARIES — простота. Хотя отмена после повтора может и не понадобиться, она делает правильность алгоритма более очевидной, чем более сложная схема, которая выполняет отмену перед повтором.

Помимо того, чтобы убедиться, что база данных непротиворечива, а диск точно такой же, как до сбоя (как ответил Франк Дернонкур), еще одно преимущество выполнения повтора перед отменой заключается в следующем:

Сбой может произойти во время восстановления. Повтор продвигает ход всего «инкрементного восстановления», а именно, если во время повтора или отмены произойдет сбой, следующее восстановление может взять то, что осталось от предыдущего восстановления (повторения), и продолжить, если повтор выполняется до отмены.

В крайнем случае, если отмена выполняется до повтора, а сбой происходит снова во время отката и снова, все откаты становятся напрасными.