Главная » SQL, Базы данных » ТРИ ПРОБЛЕМЫ ОРГАНИЗАЦИИ ПАРАЛЛЕЛЬНОЙ РАБОТЫ

0

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

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

■     Проблема потерянного обновления.

■     Проблема зависимости от незафиксированных результатов.

■     Проблема анализа несовместимости.

Рассмотрим каждую из этих проблем по очереди.

Проблема потерянного обновления

Рассмотрим ситуацию, показанную на рис. 16.1. События, представленные на  этом рисунке, развиваются следующим образом: транзакция А выполняет выборку некоторого кортежа t в момент времени tl, транзакция в выполняет выборку того  же кортежа t в момент времени t2, транзакция А обновляет кортеж в момент времени t3 (с учетом тех значений, которые он имел во время tl), а транзакция в обновляет тот же кортеж в момент времени t4 (с учетом тех значений, которые он имел во время t2, которые оставались такими же, как и во время tl). В момент времени t4 происходит потеря обновления, внесенного транзакцией А,  поскольку транзакция в перезаписывает его, даже не проверяя.

Рис. 16.1. Пример того, как транзакция А теряет обновление в момент времени t4

Примечание. Здесь и далее в этой главе принято соглашение об использовании термина обновление кортежа вместо обновление значения переменной кортежа.

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

откат, и в этом случае первая транзакция будет работать с данными, которых больше не существует (и которые в определенном смысле и не существовали). Рассмотрим в качестве примеров рис. 16.2 и 16.3.

Рис. 16.2. Пример того, что транзакция A становится зависимой от незафиксированного обновления в момент времени t2

Рис. 16.3. Пример того, что транзакция А обновляет незафиксированное изменение в момент времени t2 и теряет это обновление в момент времени t3

В первом примере (рис. 16.2) транзакция А получает доступ к незафиксированному обновлению (называемому также незафиксированным изменением) в момент времени t2. Затем в момент времени t3 происходит отмена этого обновления. Таким образом, транзакция А действует на основании  ложной  предпосылки, что кортеж t имеет значение, которое было ею получено во время t2, тогда как этот кортеж фактически имеет то значение, которое он имел к моменту времени tl. В связи с этим транзакция А вполне может выработать неправильные результаты. Кстати, следует отметить, что откат транзакции в вполне может произойти не из-за ошибки в в; например, он может произойти из-за аварийного останова системы. (А если транзакция А к этому времени уже будет завершена, то такой останов не повлечет за собой выполнение отката также и для А.)

Во втором примере (рис. 16.3) события развиваются по еще более худшему сценарию. Транзакция А становится не только зависимой от  незафиксированного изменения в момент времени t2, но и фактически теряет  свое обновление во время t3, поскольку откат в момент времени t3 вызывает  восстановление кортежа t до того значения, которое он имел к моменту времени tl, т.е. это еще один вариант проблемы потерянного обновления.

Проблема анализа несовместимости

Рассмотрим рис. 16.4, где показаны две транзакции, А и в, оперирующие с кортежами некоторого счета (ACCount — АСС). Транзакция А подсчитывает  остатки на счетах, а транзакция В переводит сумму 10 со счета 3 на счет 1. Очевидно, что результат, выработанный транзакцией А, — 110, является неправильным; если бы в ходе своего дальнейшего выполнения транзакция А снова записала этот результат в базу данных, то фактически оставила бы базу данных в противоречивом состоянии1. По сути, транзакция А обнаружила несовместимое состояние базы данных и поэтому выполнила анализ несовместимости. Обратите внимание на различие между этим примером и предыдущим: в данном случае не возникает проблема зависимости транзакции А от незафиксированного изменения, поскольку в зафиксировала все свои обновления еще до того, как А  прочитала

значение АСС 3.

Примечание. Кстати, следует отметить, что вместо термина анализ несовместимости следовало бы применять анализ неправильности. Но мы по  традиции придерживаемся прежнего термина.

Более подробное описание рассматриваемых проблем ‘

Примечание. Этот подраздел при первом чтении можно пропустить.

В данном подразделе описанные выше проблемы рассматриваются немного  более подробно. Очевидно, что с точки зрения организации параллельной работы наибольший интерес представляют такие операции, как выборка информации из базы данных и обновление базы данных; иными словами, любая транзакция может рассматриваться как состоящая  из  последовательности только  указанных  операций  (безусловно, если не учитывать  такие  необходимые  операции,  как  BEGIN  TRANSACTION  И  COMMIT  ИЛИ ROLLBACK). В дальнейшем эти операции будут сокращенно обозначаться, соответственно, как R (чтение) и w (запись). В таком случае становится ясно, что если А и в — параллельно выполняемые транзакции, то проблемы могут возникнуть, если в ходе выполнения А и B требуется прочитать или записать один и тот же объект базы данных, например, кортеж t. При этом возникают четыре возможные конфликтные ситуации, которые описаны ниже.

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

■     Конфликт типа RW. В транзакции А выполняется чтение кортежа t, а затем в тран закции в возникает необходимость записать кортеж t. Если транзакции в будет разрешено выполнить эту запись, то (как показано на рис. 16.4) может возникнуть проблема анализа несовместимости, поэтому можно утверждать, что проблема анализа несовместимости вызвана конфликтами типа RW.

Примечание. Если транзакция В выполняет свою операцию записи, а затем транзакция А снова считывает значение t, то последняя обнаруживает значение, отличное

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

от того, что было прочитано раньше; такое стечение обстоятельств принято обозначать (не совсем точно) как неповторяемое чтение, поэтому проблема неповторяемого чтения также вызывается конфликтом типа RW.

■  Конфликт типа WR. В транзакции А выполняется запись кортежа t, а затем в транзакции в возникает необходимость прочитать t. Если транзакции в будет разрешено выполнить эту операцию чтения, то (как показано на  рис. 16.2, с учетом того, что транзакции А   И В  поменялись ролями) может возникнуть проблема зависимости от незафиксированных обновлений;  таким образом, можно утверждать, что проблема зависимости от  незафиксированных обновлений вызывается конфликтами типа WR.

Примечание. Чтение в транзакции в, если оно будет разрешено, называется грязным чтением (dirty read).

Рис. 16.4. Пример того, что транзакция А выполняет анализ несовместимости

■  Конфликт типа WW. В транзакции А выполняется запись кортежа t, а затем необходимость выполнить запись кортежа t возникает в транзакции в. Если транзакции В будет разрешено выполнить эту запись, то (как показано на рис. 16.1, а также на рис. 16.3) может возникнуть проблема потерянного  обновления; таким образом, можно утверждать, что проблема потерянного обновления вызвана конфликтами типа WW.

Примечание. Запись в транзакции в, если она будет разрешена, называется грязной записью (dirty write).

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

По теме:

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