Главная » SQL, Базы данных » ВОССТАНОВЛЕНИЕ СИСТЕМЫ

0

Система должна быть готова к восстановлению не только после локальных  отказов, подобных возникновению условия переполнения при выполнении операции в пределах определенной транзакции, но и после глобальных  нарушений, подобных отключению питания. Локальное нарушение по определению влияет только на ту транзакцию, в которой оно, собственно говоря, и произошло. Подобные нарушения уже обсуждались выше, в разделах 15.2 и 15.3. Глобальное нарушение воздействует сразу на все транзакции, выполнявшиеся в момент его возникновения, и поэтому приводит к более значительным для системы последствиям. В этом и следующем разделе кратко описано, какие действия необходимо выполнить в процессе восстановления после глобального  отказа системы. Такие отказы подразделяются на две основные категории, которые описаны ниже.

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

6  В литературе (в частности в [15.14]) чаще всего вместо термина "правильность" (correctness)  применяется термин "совместимость" (consistency), но в этой главе уже было сказано, по каким  причинам автор предпочитает именно первый термин.

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

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

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

любая такая транзакция будет отменена (т.е. будет выполнен ее откат).

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

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

слева направо).

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

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

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

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

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

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

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

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

Рис. 1S.3. Пять возможных вариантов выполнения транзакций

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

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

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

2.          В список UNDO заносятся все транзакции, упомянутые в последней из существую щих записей контрольной точки, a cписок REDO пока остается пустым.

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

4.          Если в журнале регистрации обнаружена запись BEGIN TRANSACTION с указани ем о начале выполнения некоторой транзакции т, то эта транзакция добавляется в СПИСОК UNDO.

5.          Если в журнале регистрации обнаружена запись COMMIT, свидетельствующая об окончании выполнения некоторой транзакции т, эта транзакция переносится из СПИСКа UNDO В СПИСОК REDO.

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

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

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

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

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

Алгоритм ARIES

Безусловно, приведенное выше описание процедуры восстановления системы  чрезмерно упрощено7. В частности, следует отметить, что в этой процедуре операции отмены внесенных обновлений (называемые также откатом)  выполняются перед операциями повторного внесения изменений (которые принято также называть накатом). На первых порах во многих системах восстановление было организовано именно таким образом, но для повышения эффективности в современных системах эти действия происходят в обратной  последовательности.  В  настоящее  время  в  большинстве  систем  фактически используется схема, называемая ARIES [15.20], или другая организация работы, весьма похожая на эту схему, в которой операции наката в действительности осуществляются в первую очередь. Выполнение процедур алгоритма ARIES подразделяется на описанные ниже три основных этапа.

1.  Анализ. Формирование списков REDO (накат) и UNDO (откат).

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

3.  Откат. Отмена результатов внесения изменений теми транзакциями, фиксация которых не была выполнена.

Следует отметить, что принцип "накат перед откатом" предусматривает  повторное внесение изменений, сделанных теми транзакциями, которые не были зафиксированы и для этих изменений в дальнейшем требуется снова выполнять  откат. Отчасти по этой причине этап наката в алгоритме ARIES часто называют повторением истории [15.21] (или повторением прежних ошибок). Заслуживает также внимания тот факт, что в алгоритме ARIES предусматривается запись в журнал всех операций, выполняемых на этапе отката, поэтому, если в ходе выполнения данной процедуры перезапуска снова произойдет аварийный останов системы (а это отнюдь нельзя исключить), то обновления, для которых уже был выполнен откат, не будут отменены повторно при следующем перезапуске.

Аббревиатура ARIES расшифровывается как "Algorithms for Recovery and  Isolation Exploiting Semantics" (Алгоритмы восстановления и изоляции на основе семантики).

7  Кроме всего прочего, в нем предполагается, что восстановление всегда возможно! Вполне очевидно, что если никакие транзакции не выполнялись параллельно в момент аварии, то все  они  могут быть восстановлены. Но если в базе данных предусмотрена возможность параллельного выполнения транзакций, то организация ее работы в значительной степени усложняется и приходится тщательно следить за тем, чтобы выполняемые в ней операции исключали  возможность  восстановления. Эта тема рассматривается более подробно в следующей главе.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии