6.6. Журнализация и восстановление после сбоев.

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

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

Во всех случаях придерживаются стратегии “упреждающей” записи в журнал (так называемого протокола Write Ahead Log – WAL). Эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

Для восстановления БД после жесткого сбоя используют не только журнал, но и архивную копию БД. Архивная копия – это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Восстановление БД состоит в том, что исходя из архивной копии по журналу, воспроизводится работа всех транзакций, которые закончились к моменту сбоя. Более подробно этот вопрос будет рассмотрен далее.

7. Управление транзакциями.

7.1. Свойства транзакций. Проблемы параллельного выполнения.

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

Любая транзакция всегда должна переводить базу данных из одного согласованного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции. Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (COMMIT) в базе данных, и последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции. Этот процесс называется откатом (ROLLBACK) транзакции. Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакций обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая журналом транзакций. Зафиксированная транзакция не может быть отменена.

В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду COMMIT при нормальном завершении этой программы. Аналогично, в случае ее аварийного завершения в базе данных автоматически будет выполнена команда ROLLBACK.

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

Атомарность. Это свойство типа “все или ничего”. Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вовсе.

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

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

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

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

Рассмотрим три примера потенциальных проблем, которые могут иметь место при параллельном выполнении транзакций, – проблему потерянного обновления, проблему зависимости от нефиксированных результатов и проблему несогласованной обработки. Если обозначить операции чтения, записи новых значений и откат транзакции над базой данных соответственно как R, W, O, то для первой транзакции это могут быть операции R1, W1, O1, а для параллельно выполняющейся второй транзакции операции – R2, W2, O2.

Проблема потерянного обновления возникает, когда результаты вполне успешно завершенной операции обновления одной транзакции могут быть перекрыты результатами выполнения другой транзакции. Эта ситуация может возникнуть в следующей ситуации: R1, R2, W2, W1.

Проблема зависимости от нефиксированных результатов возникает в том случае, если одна из транзакций получит доступ к промежуточным результатам выполнения другой транзакции до того, как они будут зафиксированы в базе данных. Эта ситуация может возникнуть в следующей ситуации: R1, W1, R2, О1, W2.

В обоих приведенных выше примерах речь шла о транзакциях, выполняющих обновление данных в базе, наличие взаимовлияния между которыми и вызывало разрушение базы. Однако транзакции, которые только считывают информацию из базы данных, также могут давать неверные результаты, если им будут доступны для чтения промежуточные результаты одновременно выполняющихся и еще не завершенных транзакций, обновляющих информацию в базе. В некоторых случаях эту проблему называют чтением мусора или не повторяемостью чтения. Проблема несогласованности обработки возникает в тех случаях, когда транзакция считывает несколько значений из базы данных, после чего вторая транзакция обновляет некоторые из этих значений непосредственно во время выполнения первой транзакции. Эта ситуация может возникнуть в следующей ситуации: R1, R2, W1, R2. В данной ситуации второе R2 означает считывание следующей порции данных.

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

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

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