Другие способы восстановления базы данных

Эта глава описывает иные возможные пути восстановления баз данных OpenEdge и транзакций, в случаях системных или дисковых сбоев.

Введение в механизм восстановления

OpenEdge RDBMS имеет три механизма восстановления:

 

· Crash recovery - использует данные BI

· Roll-forward recovery – использует резервные копии и After-image для восстановления после дисковых сбоев

· Two-phase commit – гарантирует завершении транзакция между несколькими базами данных

В зависимости от ваших требований, можно использовать не все три механизма. Рисунок 6-1 показывает приоритеты этих механизмов. Crash recover использует BI лог (primary recovery log), и не требует вмешательства со стороны. Roll-forward recovery требует работы After-Imaging (AI). Two-phase commit требует использования лога транзакций (transaction log – TL). При использовании Two-phase commit необходимо также использование After-imaging.

Рисунок 6-1 Механизм восстановления OpenEdge

Каждый механизм использует описание изменений, для записи в файл и последующей записи в базу данных. Для примера, была сделана одна запись, изменившая один блок в базе данных. Движок базы данных автоматически записывает описание изменения в BI файл. Если after-imaging активирован, он также записывает описание изменения в AI файл (after-image log). Если активирован Two-phase commit, также записываются транзакции и описания изменений в TL файл (transaction log).

Crash recover

Этот механизм работает в автоматическом режиме. Он использует информацию из primary recovery log (BI), для восстановления после системных сбоев. BI файл является активной частью базы данных. Он рассматривается как неотъемлемая часть базы данных. Когда происходит копирование и восстановление базы данных, вместе с базой копируется и восстанавливается BI файл. Никогда не удаляйте файлы BI в ручную.

Когда база данных работает, информация о транзакциях базы хранится в трех местах:

 

· В базе данных на диске

· В буфере памяти

· В BI файлах на диске

 

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

Перед изменением базы данных, движок базы делает копию текущих данных и записывает ее в файл BI. Это происходит по завершению операции изменения. Если происходит системный сбой во время транзакции, движок базы восстанавливает из BI файла базу данных в предшествующее состояние. Движок использует информацию BI файла, также, и при нормальной работе, для отката транзакций.

Например, допустим, выполняется следующая программа на языке ABL (Advanced Business Language):

 

FOR EACH customer:

UPDATE name max-credit.

END.

                    

Мы изменили записи о клиенте 1 и 2, и пока меняли данные о клиенте 3, произошел системный сбой. При перезагрузке базы данных (.lg), в логе базы данных появятся следующие сообщения:

 

11:13:54 Single-user session begin for marshall on /dev/pts/25 (451)
11:13:54 Begin Physical Redo Phase at 256. (5326)
11:13:56 Physical Redo Phase Completed at blk 800 of 8165 and 31829 (7161)
11:13:56 Begin Physical Undo 1 transactions at blk 800 offset 8189 (7163)
11:14:38 Physical Undo Phase Completed at 1020. (5331)
11:14:38 Begin Logical Undo Phase, 1 incomplete transactions are being backed out. (7162)
11:14:38 Logical Undo Phase Complete. (5329)
11:14:46 Single-user session end. (334)

 

В сообщении указаны фазы crash recovery, которые выполняет движок базы данных для приведения базы в состояние до системного сбоя. Движок выполняет crash recovery каждый раз, когда вы открываете базу данных, но не все фазы восстановления отображаются в логе базы. Например, движок выполняет и, безусловно регистрирует в логе фазу Physical Redo, но фазы Physical Undo и Logical Undo выполняет и регистрирует в логе только в случае обнаружения незавершенных транзакций.

Если после этого перезапустить программу, то мы обнаружим, что клиенты 1 и 2 были изменены, а клиент 3 остался без изменений, так как на основании BI файла движок вернул его информацию в первоначальное состояние.

Crash recovery защищает базу от системных сбоев, но не сможет защитить ее от ошибок носителей. В случае ошибок носителя или его полной потери, восстановление базы возможно только из резервной копии, при этом необходимо вручную провести все транзакции заново до момента сбоя, либо использовать механизм roll-forward recovery, если он был активирован на базе до сбоя.

 

Roll-forward recovery

Roll-forward recovery совместно использует after-imaging и резервную копию базы, позволяя восстанавливать ее после ошибок или после потери носителя. Используйте последнюю резервную копию, а затем roll-forward recovery для восстановления базы в состояние до возникновения ошибки или до потери носителя. Этот механизм использует информацию из AI файлов для последовательного наката транзакций, совершенных после формирования последней резервной копии, до возникновения сбоя.

Для использования механизма roll-forward recovery, необходимо:

· Постоянно выполнять резервные копии, т.к. они являются основой для работы механизма.

· Активировать на базе данных механизм After-imaging

· Постоянно делать резервные копии сформированных AI - файлов.

· Храните AI-файлы на другом диске, отличном от того на котором находятся база данных и BI-файлы.