Главная » SQL, Базы данных » ДАЛЬНЕЙШЕЕ ОПИСАНИЕ ПРОБЛЕМЫ ВОССТАНОВЛЕНИЯ

0

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

На время предположим, что не применяется никакой протокол блокировки (как и в разделе 16.2) и поэтому, в частности, что транзакции не должны никогда ожидать для

того, чтобы приобрести блокировку. Теперь рассмотрим рис. 16.11, который представляет собой модифицированную версию рис. 16.2 (различие между ними состоит в том, что теперь транзакция А выполняет фиксацию до того, как произойдет откат транзакции в).

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

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

Рис. 16.11. Пример невосстановимого графика

Ниже приведено условие достаточности того, чтобы график был восстановимым [15.2].

Если в транзакции А используются какие-либо из обновлений транзакции в, то фиксация А не должна осуществляться до завершения работы в.

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

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

Далее рассмотрим рис. 16.12, который представляет собой модифицированную версию рис. 16.11 (различия между ними состоят в том, что в данном случае в транзакции А не выполняется фиксация до завершения транзакции В, но транзакция в освобождает свою блокировку кортежа t преждевременно). Как показано на рис. 16.11, для того, чтобы выполнить запрос транзакции в на  выполнение операции ROLLBACK И вернуться к такой ситуации, как если бы в  никогда не выполнялась, необходимо произвести также откат транзакции А, поскольку в ней использовалось одно из обновлений транзакции В. Более того, может быть осуществлен и откат транзакции А, поскольку А еще не была зафиксирована. Но почти наверняка применение каскадных откатов, осуществляемых таким образом, является нежелательным; в частности, вполне очевидно, что если допускается каскадное распространение отката одной транзакции, которое влечет за собой откат другой транзакции, то можно быть готовым к тому, что придется столкнуться с цепочками каскадных откатов произвольной длины. Иными  словами, недостаток графика, показанного на этом рисунке, состоит в том, что он не гарантирует отсутствия каскадных откатов.

Рис. 16.12. Пример графика, который может стать причиной каскадного отката

Ниже приведено условие достаточности того, чтобы график гарантировал отсутствие каскадных откатов [15.2].

Если в транзакции А используются какие-либо обновления транзакции В, то транзакция А не должна использовать эти данные до завершения транзакции В.

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

5  Фактически строгий протокол двухфазной блокировки в определенной степени является слишком  строгим, поскольку на практике нет необходимости удерживать блокировки S до конца транзакции, при  условии, что сама транзакция продолжает оставаться двухфазной.

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

По теме:

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