14.4. Восстановление системы

Система должна быть готова к восстановлению не только после локальных отказов, подобных возникновению условия переполнения при выполнении операции в пределах определенной транзакции, но и после глобальных нарушений, подобных отключению питания. Локальное нарушение по определению влияет только на ту транзакцию, в кото- рой оно, собственно говоря, и произошло. Подобные нарушения уже обсуждались выше, в разделах 14.2 и 14.3. Глобальное нарушение воздействует сразу на все транзакции, вы- полнявшиеся в момент его возникновения, и, следовательно, приводит к более значи- тельным для системы последствиям. Ниже кратко описывается, какие действия необхо- димо выполнить в процессе восстановления после глобального отказа системы. Сущест- вует две обширные категории глобальных нарушений.

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

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

В этом разделе будут рассмотрены отказы системы, а в разделе 14.5 — отказы носителей.

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

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

Возникает очевидный вопрос: "Как в процессе перезагрузки система узнает, какую транзакцию следует отменить, а какую выполнить повторно?". Ответ заключается в том, что система автоматически создает контрольные точки с некоторым наперед заданным интервалом (обычно, когда в журнале накапливается определенное число записей). Соз- дание контрольной точки означает: а) физическую перезапись ("принудительная разгруз- ка") содержимого рабочих буферов базы данных непосредственно в базу данных и б) фи- зическое помещение в файл журнала специальной записи контрольной точки. На рис. 14.3 представлен пример выполнения транзакций до аварийного сбоя системы (время возрастает слева направо).

Время tc tf

\

1

_{I Tl\}

a

н T2 \ з

a _T3 к

Ч T4 и

^и TS

Контрольная точка Отказ системы II

(время tc) ( время tf) II

Рис. 14.3. Пять возможных вариантов выполнения транзакций К этому можно добавить следующие комментарии.

• Отказ системы произошел в момент tf.

• Ближайшая к моменту tf контрольная точка была создана в момент tc.

• Транзакция Т1 успешно завершена до момента tc.

• Транзакция Т2 начата до момента tc и успешно завершена после момента tc, но до момента tf.

• Транзакция ТЗ также начата до момента tc, но не завершена к моменту tf.

• Транзакция Т4 начата после момента tc и успешно завершена до момента tf.

• Транзакция Т5 также начата после момента tc, но не завершена к моменту tf.

Очевидно, что при перезагрузке системы транзакции типа ТЗ и Т5 должны быть отме- нены, а транзакции типа Т2 и Т4 — выполнены повторно. Заметьте, что транзакции типа Tl вообще не участвуют в процессе перезагрузки, так как выполненные ими обновления были принудительно занесены в физическую базу данных в момент tc как часть проце- дуры создании этой контрольной точки. Обратите внимание также на то, что транзакции, завершившиеся неудачно (т.е. для них был выполнен откат) до момента tf, также не бу- дут принимать участия в процессе перезагрузки (подумайте, почему).

Следовательно, во время перезагрузки система прежде всего идентифицирует все транзакции типа Т2-Т5. При этом осуществляются следующие действия.

1. Создается два списка транзакций; назовем их UNDO (отменить) и REDO (выполнить повторно). В список UNDO заносятся все транзакции, упомянутые в последней из существующих записей контрольной точки, а список REDO пока остается пустым.

1. В журнале регистрации поиск организуется с записи последней контрольной точки.

2. Если в журнале регистрации обнаружена запись BEGIN TRANSACTION с указанием о на- чале выполнения некоторой транзакции Т, то эта транзакция добавляется в список UNDO.

3. Если в журнале регистрации обнаружена запись COMMIT, свидетельствующая об оконча- нии выполнения некоторой транзакции Т, эта транзакция добавляется в список REDO.

4. По достижении конца файла журнала регистрации списки UNDO и REDO анализиру- ются для выявления транзакций типа Т2 и Т4, помещенных в список REDO, и тран- закций типа ТЗ и Т5, оставшихся в списке UNDO.

После этого система просматривает журнал регистрации в обратном направлении, выполняя откат транзакций из списка UNDO, а затем вновь просматривает журнал в пря- мом направлении, повторно выполняя транзакции из списка REDO².

Замечание. Восстановление согласованного состояния базы данных посредством от- мены выполненных операций иногда называется обратным восстановлением. Анало- гично восстановление согласованного состояния базы данных за счет повторного выпол- нения уже выполненных действий называется прямым восстановлением.

И наконец, когда такая восстановительная работа будет завершена, тогда (и только тогда) система будет готова к дальнейшей работе.