7.1. Модели транзакций

Рассмотрим две модели транзакций, используемые в большинстве коммерческих СУБД: модель автоматического выполнения транзак­ций и модель управляемого выполнения транзакций, обе основан­ные на инструкциях языка SQL — COMMIT и ROLLBACK.

Автоматическое выполнение транзакций.

В стандарте ANSI/ISO зафиксировано, что транзакция автоматиче­ски начинается с выполнения пользователем или программой пер­вой инструкции SQL. Далее происходит последовательное выполне­ние инструкций до тех пор, пока транзакция не завершается одним из двух способом (рис. 7.2):

• инструкцией COMMIT, которая выполняет завершение тран­закции: изменения, внесенные в БД, становятся постоянны­ми, а новая транзакция начинается сразу после инструкции COMMIT;

• инструкцией ROLLBACK, которая отменяет выполнение те­кущей транзакции и возвращает БД к состоянию начала тран­закции, новая транзакция начинается сразу после инструкции ROLLBACK.

Такая модель создана на основе модели, принятой в СУБД DB2.

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

Отличная от модели ANSI/ISO модель транзакций используется в СУБД Sybase, где применяется диалект Transact-SQL, в котором для обработки транзакций служат четыре инструкции (см. рис. 7.3):

• инструкция BEGIN TRANSACTION сообщает о начале тран­закции, т. е. начало транзакции задается явно;

• инструкция COMMIT TRANSACTION сообщает об успешном выполнении транзакции, но при этом новая транзакция не начинается автоматически;

• инструкция SAVЕ TRANSACTION позволяет создать внутри транзакции точку сохранения и присвоить сохраненному со­стоянию имя точки сохранения, указанное в инструкции;

• инструкция ROLLBACK отменяет выполнение текущей тран­закции и возвращает БД к состоянию, где была выполнена инструкция SAVE TRANSACTION (если в инструкции указа­на точка сохранения — ROLLBACK TO имя точки сохране­ния), или к состоянию начала транзакции.

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

Рис. 7.3. Модель управляемого выполнения транзакций

7.2. Журнал транзакций

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

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

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

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

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

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

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

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

В заключение сформулируем общие требования к системе восстановления данных в составе СУБД.

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

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

3. При выполнении процедур автоматизированного восстанов­ления пользователь не должен анализировать состав данных и вы­бирать сами процедуры.

Для восстановления базы данных СУБД имеют в своем составе сервисные программные средства:

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

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

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

Программы отката ликвидируют последствия выполнения оп­ределенной транзакции в БД.

Программы записи контрольных точек и повторного исполнения позволяют ускорить восстановление.