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

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

Ниже перечислены случаи установки точки фиксации.

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

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

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

Здесь п. 2 (исключая замечание о возможности сохранения некоторой адресуемости и, следовательно, соответствующей блокировки кортежей) также применим, когда транзакция завершена оператором ROLLBACK, а не COMMIT. К п. 1 это, конечно, не относится.

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

А сейчас вернемся к примеру из предыдущего раздела (см. рис. 14.1). В нем используется явный тест для определения ошибок, и при обнаружении любой из них оператор ROLLBACK выполняется явным образом. Однако не вызывает сомнения то, что работа системы не может быть построена на предположении, что в программах всегда будут использоваться явные тесты для выявления всех возможных типов ошибок. Следовательно, система будет выполнять оператор ROLLBACK неявно для любой программы, которая по какой-либо причине не была нормально завершена (на рис. 14.1 нормальное завершение означает явное выполнение оператора COMMIT или ROLLBACK).

-Транзакция 1

Начало программы

BEGIN

TRANSACTION

COMMIT Транзакция 2 (отменена) -

BEGIN

TRANSACTION

ROLLBACK

Транзакция 3

BEGIN

TRANSACTION

COMMIT

Завершение программы

Рис. 14.2. Выполнение типичной программы представляет собой последовательность из нескольких транзакций

Из всего сказанного выше следует, что транзакции - это не только логические единицы работы, но и единицы восстановления. При успешном завершении транзакции система гарантирует, что выполненные ею обновления будут сушествовать в базе данных постоянно, даже если система потерпит крах в следуюший момент. Вполне возможно, что в системе произойдет сбой после успешного выполнения оператора COMMIT, но перед тем, как обновления будут физически записаны в базу данных (они все еще могут оставаться в буфере оперативной памяти и, таким образом, могут быть утеряны в момент сбоя системы). Даже если подобное случится, процедура перезагрузки системы все равно должна повторно вносить эти обновления в базу данных на основе анализа соответствующих записей в журнале регистрации. (Из этого следует, что журнал регистрации должен быть физически записан перед завершением операции COMMIT. Это важное правило называется протоколом предварительной записи в журнал (write-ahead log rule).) Процедура перезагрузки позволяет восстановить любые успешно завершенные транзакции, обновления которых не были физически записаны во вторичную память до возникновения сбоя системы. Следовательно, как и указывалось ранее, транзакция действительно является единицей восстановления.

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

АСШ-свойства транзакций

Как и в [14.14], можно подытожить материал этого и предыдущего разделов, сделав заключение, что транзакции обладают четырьмя важными свойствами: атомарностью (atomicity), согласованностью (consistency), изолированностью (isolation) и долговечностью (durability). Этот набор свойств принято называть АСШ-свойствами (по первым буквам их английских названий).

Н Атомарность. Транзакции атомарны (выполняется все или ничего).

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

Н Изолированность. Транзакции изолированы одна от другой. Это означает, что, даже если будет запущено множество транзакций, работающих параллельно, результаты любых операций обновления, выполняемых отдельной транзакцией, будут скрыты от всех остальных транзакций до тех пор, пока эта транзакция не будет зафиксирована. Иначе говоря, для любых отдельных транзакций Т1 и Т2 справедливо следующее утверждение: Tl сможет увидеть результаты выполненных транзакцией Т2 обновлений только после завершения выполнения транзакции Т2, а транзакция Т2 сможет увидеть результаты выполненных транзакцией Т1 обновлений только после завершения выполнения транзакции Tl. Более подробно эта тема рассматривается в главе 15.

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

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

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

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

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

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

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

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