Глава 15

Параллельность

15.1. Введение

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

Данная глава имеет следующую структуру.

Как уже говорилось, в разделе 15.2 рассматриваются проблемы, которые могут иметь место при отсутствии должного механизма управления параллельностью.

В разделе 15.3 предлагается стандартный метод разрешения таких проблем, получивший название метод блокировки.

Замечание. Блокировка не является единственно возможным подходом к решению проблемы управления параллельностью, однако именно этот метод чаще всего используется на практике. Некоторые другие подходы описаны в комментариях, приведенных в списке литературы [15.1], [15.3], [15.6], [15.7], [15.14], [15.15].

В разделе 15.4 поясняется, как можно использовать механизм блокировки для решения проблем, обсуждавшихся в разделе 15.2.

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

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

В разделах 15.7 и 15.8 продолжается рассмотрение некоторых важных дополнений к основной идее блокировки, а именно - концепций уровней изоляции и механизма блокировки намерения.

В разделе 15.9 описываются соответствующие средства языка SQL.

В разделе 15.10 дается краткое резюме и несколько заключительных замечаний к материалу данной главы.

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

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

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

15.2. Три пробле]чы параллельности

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

Потеря результатов обновления

Зависимость от незафиксированных результатов

Несогласованная обработка данных

Проблема потери результатов обновления

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

Замечание. Здесь и далее в этой главе вновь делается допущение, что имеет смысл говорить об обновлении кортежа .

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

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

ния этой транзакции еще не были зафиксированы. Если некоторое обновление не зафиксировано, всегда существует определенная вероятность, что оно не будет зафиксировано никогда из-за отката данной транзакции. В этом случае первая транзакция будет обрабатывать данные, которые уже не существуют (и, в сущности, никогда не существовали). Данная ситуация представлена на рис. 15.2 и 15.3.

Рис. 15.3. Транзакция А обновляет незафиксированное изменение в момент t2, но результаты этого обновления утрачиваются в момент ЬЗ

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