Лекция. Поддержание механизма транзакций. Проблемы параллелизма транзакций

Лекция. Поддержание механизма транзакций. Проблемы параллелизма транзакций

1 Понятие транзакции. Свойства транзакций

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

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

Допустим, выделим работу по вводу данных о поступивших новых книгах в библиотеку. Эту операцию можно разбить на две последовательные: сначала ввод данных о книге — это новая строка в таблице BOOKS, а потом ввод данных обо всех экземплярах новой книги — это ввод набора новой строки в таблицу EXEMPLAR. Если эта последовательность работ будет прервана, то база данных не будет соответствовать реальному объекту, поэтому желательно выполнять ее как единую работу над базой данных.

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

Традиционные плоские транзакции обладают четырьмя свойствами, известными как ACID: атомарность (Atomicity), согласованность (Consistency), изолированность (Isolation), долговечность (Durability). Традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее:

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

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

Свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.

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

Под управлением транзакциями понимается способность управлять различными операциями над данными, которые выполняются внутри реляционной СУБД. Прежде всего, имеется в виду выполнение операторов INSERT, UPDATE и DELETE. После успешного выполнения команд, заключенных в тело одной транзакции, немедленного изменения данных не происходит. Для окончательного завершения транзакции существуют так называемые команды управления транзакциями, с помощью которых можно либо сохранить в базе данных все изменения, произошедшие в ходе ее выполнения, либо полностью их отменить.

Существует два способа (две команды) завершения транзакций: фиксация (COMMIT) и откат (ROLLBACK).

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

Откат транзакции  — это   действие, аннулирующее все изменения данных, которые были выполнены операторами SQL в теле текущей незавершенной транзакции.

Следующая схема демонстрирует принцип использования транзакций.

Рисунок 7.1 - Принцип использования транзакций

Новая транзакция начинается с начала каждого сеанса работы с базой данных. Далее все выполняемые SQL-операторы будут входить в одну транзакцию до тех пор, пока не будет выполнен оператор COMMIT WORK или ROLLBACK WORK.

Оператор COMMIT WORK завершает текущую транзакцию, выполняя фиксацию сделанных изменений в базе данных. Иногда говорят, что оператор COMMIT WORK фиксирует транзакцию.

Оператор ROLLBACK WORK выполняет откат транзакции, отменяя действие всех SQL-операторов, выполненных в текущей транзакции.

Логически транзакция должна объединять только выполнение взаимосвязанных операций. Однако, если делать транзакции "очень большими", состоящими из последовательности не связанных между собой операторов, то любой сбой, автоматически выполняющий откат транзакции, повлияет на отмену действий, которые могли бы быть успешно завершены при более "коротких" транзакциях.

7.2 Модели транзакции

В стандарте ANSI SQL определены модель транзакций и функции операторов COMMIT и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем или содержащегося в программе, изменяющей текущее состояние базы данных. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных путей:

1.  оператор COMMIT означает успешное завершение транзакции; его использование делает постоянными изменения, внесенные в базу данных в рамках текущей транзакции;

2.  оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в базе данных в рамках этой транзакции; новая транзакция начинается непосредственно после использования ROLLBACK;

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

4.  ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).

Большинство коммерческих СУБД позволяет устанавливать режим автоматической фиксации изменений - автокоммит.

В модели стандарта ANSI SQL каждый оператор, который изменяет состояние БД, рассматривается как транзакция, поэтому при успешном завершении этого оператора БД переходит в новое устойчивое состояние.

Рисунок 7.2 - Модель транзакций ANSI/ISO

В дальнейшем в коммерческих СУБД была реализована расширенная модель транзакций. В этой модели используются следующие четыре оператора:

-     оператор BEGIN TRANSACTION сообщает о начале транзакции;

-     оператор COMMIT TRANSACTION сообщает об успешном завершении транзакции;

-     оператор SAVE TRANSACTION создает внутри транзакции точку сохранения, которая соответствует промежуточному состоянию БД, сохраненному на момент выполнения этого оператора;

-     оператор ROLLBACK имеет две модификации. Если этот оператор используется без дополнительного параметра, то он интерпретируется как оператор отката всей транзакции. Если же оператор отката имеет параметр и записан в виде ROLLBACK В, то он интерпретируется как оператор частичного отката транзакции в точку сохранения В.

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

Принципы выполнения транзакций в расширенной модели транзакций представлены на рисунке 7.3.

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

Транзакция начинается явным оператором начала транзакции, который имеет в нашей схеме номер 1.

Далее идет оператор 2, который является оператором поиска и не меняет текущее состояние БД.

Следующие за ним операторы 3 и 4 переводят базу данных уже в новое состояние.

Оператор 5 сохраняет это новое промежуточное состояние БД и помечает его как промежуточное состояние в точке А.

Далее следуют операторы 6 и 7, которые переводят базу данных в новое состояние.

Оператор 8 сохраняет это состояние как промежуточное состояние в точке В.

Оператор 9 выполняет ввод новых данных.

Оператор 10 проводит некоторую проверку условия 1;

Если условие 1 выполнено, то выполняется оператор 11, который проводит откат транзакции в промежуточное состояние В. Это означает, что последствия действий оператора 9 как бы стираются и база данных снова возвращается в промежуточное состояние В, хотя после выполнения оператора 9 она уже находилась в новом состоянии. И после отката транзакции вместо оператора 9, который выполнялся раньше из состояния В БД, выполняется оператор 13 ввода новых данных, и далее управление передается оператору 14.

Рисунок 7.3 - Пример выполнения транзакций в расширенной модели

Оператор 14 снова проверяет условие, но уже некоторое новое условие 2;

Если условие выполнено, то управление передается оператору 15, который выполняет откат транзакции в промежуточное состояние А, то есть все операторы, которые изменяли БД, начиная с 6 и заканчивая 13, считаются невыполненными, то есть результаты их выполнения исчезли и мы снова находимся в состоянии А, как после выполнения оператора 4. Далее управление передается оператору 17, который обновляет содержимое БД, после этого управление передается оператору 18, который связан с проверкой условия 3.

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

Расширенная модель транзакции поддерживает гораздо более гибкий механизм выполнения транзакций по сравнению с моделью стандарта ANSI SQL. Целесообразно использовать точки сохранения в длинных и сложных транзакциях, чтобы обеспечить возможность отмены изменения для определенных операторов. Однако это обусловливает дополнительные затраты ресурсов системы — оператор выполняет работу, а изменения затем отменяются.

7.3 Журнализация изменений БД

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

Общей целью журнализации изменений баз данных является обеспечение возможности восстановления согласованного состояния базы данных после любого сбоя. Общими принципами восстановления являются следующие:

-       результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;

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

Возможны два основных варианта ведения журнальной информации.

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

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

Журнал обычно представляет собой последовательный файл с записями переменного размера, которые можно просматривать в прямом или обратном порядке. В грамотно организованных СУБД структура  журнальных записей известна только компонентам, ответственным за журнализацию и восстановление данных. Поскольку содержимое журнала является критичным при восстановлении базы данных после сбоев, к ведению файла журнала предъявляются особые требования по части надежности. В частности, обычно стремятся поддерживать две идентичные копии журнала на разных устройствах внешней памяти.   

Все транзакции в журнале имеют свои внутренние номера.

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

Рисунок 7.4 - Журнал транзакций

Имеются два альтернативных варианта ведения журнала транзакций: протокол с отложенными обновлениями и протокол с немедленными обновлениями.

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

1.  Когда транзакция Т1 начинается, в протокол заносится запись <Т1 Begin transaction>.

2.  На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение: <T1, ID_RECORO. атрибут, новое значение ... >. Здесь ID_RECORD — уникальный номер записи.

3.  Если все действия, из которых состоит транзакция Т1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится <Т1 СОММIТ>.

4.  После того как транзакция зафиксирована, записи протокола, относящиеся к Т1, используются для внесения соответствующих изменений в БД.

5.  Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать.

Альтернативный механизм с немедленным выполнением предусматривает внесение изменений сразу в БД, а в протокол заносятся не только новые, но и все старые значения изменяемых атрибутов, поэтому каждая запись выглядит <Т1, ID_RECORD, атрибут новое значение старое значение ...>. При этом запись в журнал предшествует непосредственному выполнению операции над БД. Когда транзакция фиксируется, то есть встречается команда <Т1 СОММIТ> и она выполняется, то все изменения оказываются уже внесенными в БД и не требуется никаких дальнейших действий по отношению к этой транзакции.

При откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу начиная с команды BEGIN TRANSACTION.

7.4 Журнал как средство восстановления состояния БД

Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных по журналу:

1)     явное завершение ТРАНЗАКЦИИ оператором ROLLBACK - откат транзакции инициируется системой (примерами могут быть возникновение исключительной ситуации в прикладной программе (например, деление на ноль) или выбор транзакции в качестве жертвы при обнаружении синхронизационного тупика). Для восстановления согласованного состояния базы данных нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции. В этом случае выполняется индивидуальный откат транзакции;

2)     восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть при аварийном выключении электрического питания, при возникновении неустранимого сбоя процессора, ОЗУ и т.д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти;

3)     восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее, СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.

Журнализация и буферизация. Журнализация изменений тесно связана с буферизацией страниц базы данных в оперативной памяти. По причинам объективно существующей разницы в скорости работы процессоров, оперативной памяти и устройств внешней памяти,  буферизация страниц базы данных в оперативной памяти - это единственный реальный способ достижения удовлетворительной эффективности СУБД. Если бы запись об изменении базы данных, которая должна поступить в журнал при выполнении любой операции модификации базы данных, реально немедленно записывалась бы во внешнюю память, это привело бы к существенному замедлению работы системы. Поэтому записи в журнал тоже буферизуются: при нормальной работе очередная страница выталкивается во внешнюю память журнала только при полном заполнении записями.

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

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

Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) - "пиши сначала в журнал", и состоит в том, что если требуется вытолкнуть во внешнюю память измененный объект базы данных, то перед этим нужно гарантировать выталкивание во внешнюю память журнала записи о его изменении.

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

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

Рассмотрим теперь, как можно выполнять операции восстановления базы данных в различных ситуациях, если в системе поддерживается общий для всех транзакций журнал с общей буферизацией записей, поддерживаемый в соответствии с протоколом WAL.

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

Итак, индивидуальный откат транзакции выполняется следующим образом:

-        выбирается очередная запись из списка данной транзакции;

-        выполняется противоположная по смыслу операция: вместо операции INSERT выполняется соответствующая операция DELETE, вместо операции DELETE выполняется INSERT, и вместо прямой операции UPDATE обратная операция UPDATE, восстанавливающая предыдущее состояние объекта базы данных;

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

-        при успешном завершении отката в журнал заносится запись о конце транзакции. С точки зрения журнала такая транзакция является зафиксированной.

Восстановление после мягкого сбоя. К числу основных проблем восстановление после мягкого сбоя относится то, что одна логическая операция изменения базы данных может изменять несколько физических блоков базы данных, например, страницу данных и несколько страниц индексов. Страницы базы данных буферизуются в оперативной памяти и выталкиваются независимо от страниц журнала. Несмотря на применение протокола WAL (Write Ahead Log), после мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, т.е. часть страниц внешней памяти соответствует объекту до изменения, часть - после изменения.

Состояние внешней памяти базы данных называется физически согласованным, если наборы страниц всех объектов согласованы, т.е. соответствуют состоянию объекта либо после его изменения, либо до изменения.

Будем считать, что в журнале отмечаются точки физической согласованности базы данных - моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились, а буфер журнала вытолкнут во внешнюю память. Назовем такие точки tpc (time of physical consistency). Сервер устанавливает точки физической согласованности базы данных tpc - моменты времени, соответствующие согласованному состоянию БД (все операции завершены, буфер журнала вытолкнут во внешнюю память). Существует пять вариантов состояния транзакций на момент мягкого сбоя (рисунок 7.5):

1)  транзакция Т₁ успешно завершена, получено подтверждение ее выполнения во внешней памяти;

2)  транзакция Т₂ успешно завершена, но для некоторых операций Т₂ не получено подтверждение их выполнения во внешней памяти;

3)  транзакция Т₃ начата до момента tpc и не завершена в результате сбоя;

4)  транзакция Т₄ начата после tpc и успешно завершена до сбоя;

5)  транзакция Т₅ начата после tpc и не завершена в результате сбоя.

Рисунок 7.5 - Варианты состояния транзакций на момент мягкого сбоя

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

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

Общая идея теневого механизма показана на рисунке 7.6.

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

Восстановление к tpc происходит мгновенно: текущая таблица отображения заменяется на теневую (при восстановлении просто считывается теневая таблица отображения). Все проблемы восстановления решаются, но за счет слишком большого перерасхода внешней памяти. В пределе может потребоваться вдвое больше внешней памяти, чем реально нужно для хранения базы данных. Теневой механизм — это надежное, но слишком грубое средство. Обеспечивается согласованное состояние внешней памяти в один общий для всех объектов момент времени. На самом деле достаточно иметь совокупность согласованных наборов страниц, каждому из которых может соответствовать свои временные отсчеты.

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

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

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

Рисунок 7.6 - Использование теневых таблиц отображения информации

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

-      для транзакции Т1 никаких действий производить не требуется. Она закончилась до момента tpc, и все ее результаты отражены во внешней памяти базы данных;

-      для транзакции Т2 нужно повторно выполнить оставшуюся часть операций (redo). Действительно, во внешней памяти полностью отсутствуют следы операций, которые выполнялись в транзакции Т2 после момента tpc. Следовательно, повторная прямая интерпретация операций Т2 корректна и приведет к логически согласованному состоянию базы данных (поскольку транзакция Т2 успешно завершилась до момента мягкого сбоя, в журнале содержатся записи обо всех изменениях, произведенных этой транзакцией);

-      для транзакции ТЗ нужно выполнить в обратном направлении первую часть операций (undo). Действительно, во внешней памяти базы данных полностью отсутствуют результаты операций ТЗ, которые были выполнены после момента tpc. С другой стороны, во внешней памяти гарантированно присутствуют результаты операций ТЗ, которые были выполнены до момента tpc. Следовательно, обратная интерпретация операций ТЗ корректна и приведет к согласованному состоянию базы данных (поскольку транзакция ТЗ не завершилась к моменту мягкого сбоя, при восстановлении необходимо усхранить все последствия ее выполнения);

-      для транзакции Т4, которая успела начаться после момента tpc и закончиться до момента мягкого сбоя, нужно выполнить полную повторную прямую интерпретацию операций (redo);

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

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

Восстановление начинается с обратного копирования базы данных из архивной копии. Затем для всех закончившихся транзакций выполняется redo, т.е. операции повторно выполняются в прямом смысле.

Более точно, происходит следующее:

-    по журналу в прямом направлении выполняются все операции;

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

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

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

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

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

Скачано с www.znanio.ru