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

14.2. Транзакции

Как уже указывалось в разделе 14.1, мы начнем с изучения фундаментального понятия транзакции. Транзакция - это логическая единица работы. Рассмотрим следующий пример. Предположим сначала, что переменная-отношение Р (переменная-отношение деталей) включает дополнительный атрибут TOTQTY, представляющий собой общий объем поставок для каждой детали. Другими словами, предполагается, что значение атрибута TOTQTY для любой конкретной детали равно сумме всех значений атрибута QTY для всех поставок данной детали (в терминах главы 8 это ограничение базы данных). На рис. 14.1 показан псевдокод процедуры вставки в базу данных сведений о новой поставке со значением 1000 для поставщика S5 и детали Р1 (команда INSERT добавляет сведения о новой поставке в отношение SP, а команда UPDATE обновляет значение атрибута TOTQTY для детали Р1 )

BEGIN TRANSACTION ;

INSERT INTO SP

RELATION { TUPLE { St St ( S5 ), Pt Pt ( Pl ), QTY QTY ( 1000 ) } } ;

IF <возникла ошибка> THEN GO TO UNDO ; END IF ;

UPDATE P WHERE Pt = Pt { Pl )

TOTQTY := TOTQTY + QTY { 1000 ) ; IF <возникла ошибка> THEN GO TO UNDO ; END IF ;

COMMIT ;

GO TO FINISH ;

UNDO :

ROLLBACK ;

FINISH : RETURN ;

Puc 14 I Пример транзакции (псевдокод)

в приведенном примере предполагается, что речь идет об одиночной, атомарной операции. На самом деле добавление сведений о новой поставке - это выполнение двух обновлений в базе данных: операции INSERT и операции UPDATE. Более того, в базе данных между этими двумя обновлениями временно нарушается требование, что значение атрибута TOTQTY для детали Р1 равно сумме всех значений атрибутов QTY для этой детали. Таким образом, логическая единица работы (т.е. транзакция) вовсе необязательно является простой одиночной операцией системы баз данных; чаше всего она представляет собой последовательность из нескольких таких операций. В обшем случае выполнение этой последовательности переводит базу данных из одного непротиворечивого состояния в другое, причем в промежуточных точках выполнения база данных может находиться в противоречивом состоянии.

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

Системный компонент, обеспечиваюший атомарность (или ее подобие), называется менеджером транзакций или диспетчером обработки транзакций (transaction processing monitor- TP-monitor), a ключевыми элементами в его выполнении служат операторы COMMIT и ROLLBACK.

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

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

Таким образом, в приведенном примере оператор COMMIT должен выполняться, если оба обновления прошли успешно, после чего выполненные в базе данных изменения станут постоянными. Если что-то не так, если обновление было прервано каким-либо условием ошибки, то выполняется оператор ROLLBACK и любые внесенные изменения отменяются.

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

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

Кстати, следует отметить, что реальные приложения могут не только модифицировать базу данных (или пытаться это сделать), но также отсылать пользователю некоторые сообшения о том, что произошло. В нашем примере можно отослать пользователю сообшение Сведения о поставке введены после выполнения операции COMMIT и сообщение Ошибка - сведения о поставке не введены в противном случае. Выдача сообщений, в свою очередь, имеет дополнительное значение для восстановления. Более подробно эти вопросы обсуждаются в [14.12].

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

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

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

14.3. Восстановление транзакции

Транзакция начинается в результате успешного выполнения оператора BEGIN TRANSACTION и заканчивается успешным выполнением оператора COMMIT или ROLLBACK. Оператор COMMIT устанавливает так называемую точку фиксации (которая в коммерческих продуктах иначе называется точкой синхронизации (syncpoint)). Точка фиксации соответствует концу логической единицы работы и, следовательно, точке, в которой база данных находится (или будет находиться) в состоянии непротиворечивости.