Главная » SQL, Базы данных » ВОССТАНОВЛЕНИЕ ТРАНЗАКЦИИ

0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но на практике (как правило) ни одно из этих требований не соблюдается. Во-первых, буфера могут просто оказаться недостаточно большими, а это означает, что потребуется записывать на диск обновления транзакции А еще до того, как  произойдет фиксация транзакции А с помощью оператора COMMIT. Такая  необходимость может, например, возникнуть в связи с тем, что потребуется освободить место для обновлений транзакции в (в подобных ситуациях принято говорить, что транзакция в вытесняет транзакцию А из буферного пространства). Во-вторых, физическая (или принудительная) запись обновлений на диск во время выполнения оператора COMMIT может оказаться очень неэффективной; например, если все 100 последовательных транзакций обновляют один и тот же объект, то принудительная запись означает, что должно быть выполнено 100 физических операций записи, когда вполне достаточно одной. По этим причинам в применяемых на практике диспетчерах транзакций обычно предусмотрено так называемое правило конфискации и отказа от принудительной записи  (steal/no-force), а это, вполне очевидно, весьма значительно усложняет реализацию. Дополнительные сведения об этом выходят за рамки данной книги.

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

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

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

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

5  В некоторых системах предусмотрен принудительный вывод записи журнала с оператором COMMIT на диск сразу после получения запроса на выполнение оператора COMMIT, а в других системах происходит ожидание до тех пор (например), пока буфер не заполнится, и только после этого выполняется принудительный вывод этой записи на диск. Последний из этих  методов называется групповой фиксацией (group commit) на том основании, что его применение  обычно влечет за собой одновременную фиксацию  нескольких  транзакций; при  использовании  такого  метода  количество  операций  ввода—вывода сокращается, но продолжительность выполнения некоторых транзакций увеличивается.

Свойства ACID транзакций

Как и в [15.14], можно подытожить материал этого и предыдущего разделов, сделав заключение,  что  транзакции  обладают  (или  должны  обладать!)  четырьмя  важными свойствами:  неразрывностью  (atomicity),  правильностью6   (correctness),  изолированностью (isolation) и устойчивостью (durability). Этот набор свойств принято называть свойствами ACID (по первым буквам их английских названий).

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии