Восстановление посредством повторной обработки

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

Восстановление посредством повторной обработки возможно при работе с прилми, не отвечающими на прямой ввод пользователя. Но даже в этом случае повторная обработка не гарантирует возвращения к состоянию, существовавшему до сбоя. Например, при повторной обработке может измениться график тран-ий. Подобное изменение, вероятно, повлияет на тран-ии.

За исключением очень редких случаев, невозможно гарантировать свойство продолжительности посредством повторной обработки.

Восстановление посредством прокрутки вперед

Более подходящей стратегией восстановления, получившей название восстановление и прокрутка вперед, является восстановление БД в ее предыдущем корректном состоянии с последующим повторным применением всех изменений зафиксированных тран-ий в порядке их первоначальной фиксации. Таким образом БД может быть возвращена в состояние, в котором она находилась непосредственно перед катастрофой.

Для поддержки прокрутки вперед система должна поддерживать ведение хронологического списка всех зафиксированных изменений. Этот список называется журналом восстановления. Каждый раз при выполнении обновления в системе в журнале производится запись, содержащая новое значение измененного объекта.

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

Очевидно, что если журнал восстановления ведется на том же компьютере, что и БД, то катастрофический сбой, вероятно, разрушит как базу данных, так и журнал восстановления. Поэтому свойство продолжительности требует, чтобы физически журнал хранился отдельно от БД. В системах с высоким уровнем безопасности операция фиксации тран-ии не считается завершенной до тех пор, пока журнальная запись не сохранена на удаленном носителе. Используя Internet, можно организовать хранение журнала восстановления на удаленном узле. Когда выполняется операция фиксации, журнальная запись посылается удаленной системе. После получения подтверждения операция фиксации завершается.

Полного соблюдения продолжительности тран-ий можно достигнуть посредством использования физически удаленных резервных копий и журналов восстановления.

Восстановление посредством отката

Откат восстанавливает предыдущее состояние, удаляя результат тран-ий. Отказ 9 в списке типичных отказов происходит тогда, когда зафиксированные тран-ии повреждают базу данных. Восстановление в данной ситуации требует, чтобы БД была восстановлена до прежнего корректного состояния путем удаления результатов зафиксированных тран-ий.

Хотя зафиксированные тран-ии могут быть отменены посредством прокрутки вперед, часто более эффективно выполнить откат зафиксированных тран-ий. Система должна хранить журнал отмены (undo log), содержащий исходный образ каждого обновленного значения. Откат начинается с текущего состояния и отменяет все обновления в обратном порядке до достижения желаемого состояния.

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