Главная » SQL, Базы данных » СРЕДСТВА блокировки ЯЗЫКА SQL

0

В стандарте SQL не предусмотрены какие-либо явно заданные средства блокировки; фактически в нем вообще не упоминается блокировка как таковая12.  Но этот стандарт требует, чтобы в его реализации были предусмотрены обычные  гарантии, касающиеся взаимного вмешательства (или, скорее, его отсутствия) между одновременно выполняемыми транзакциями. Что еще более важно, в этом стандарте требуется, чтобы обновления, внесенные любой конкретной транзакцией Т1, не становились бы доступными для любой другой транзакции Т2  до тех пор (или только после того), пока не произойдет фиксация транзакции Т1.

Примечание. Для соблюдения изложенных выше требований необходимо, чтобы все транзакции выполнялись на уровне изоляции READ COMMITTED, REPEATABLE READ или SERIALIZABLE (см. следующий абзац). К транзакциям, выполняемым на уровне

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

Глава 16. Параллельность     631

READ UNCOMMITTED, предъявляются особые требования, поскольку им, во-первых, разрешено выполнять грязное чтение, но, во-вторых, они обязательно должны относиться к типу READ ONLY (поскольку если бы было разрешено применять в этом случае транзакции типа READ WRITE, то восстанавливаемость больше нельзя было бы гарантировать). Теперь напомним, что уровни изолированности  SQL  определяются в операторе START TRANSACTION (как было сказано в главе 15). Для этого предусмотрены четыре ВОЗМОЖНОСТИ13—                                         SERIALIZABLE,                                         REPEATABLE                                         READ,                                         READ COMMITTED   И   READ   UNCOMMITTED.   По   умолчанию  применяется  значение SERIALIZABLE; если определена любая из трех других возможностей, то в конкретной реализации разрешено  назначать некоторый более высокий уровень, где понятие более

высокий определено в терминах упорядочения SERIALIZABLE > REPEATABLE READ > READ COMMITTED > READ UNCOMMITTED.

Если    все    транзакции   выполняются   на    уровне   изоляции     SERIALIZABLE (применяемом  по   умолчанию),  то   гарантирована    упорядочиваемость процедуры чередующегося выполнения любого множества  параллельных транзакций. Но  если любая транзакция выполняется на  более   низком уровне изоляции, то  нарушение упорядочиваемости  может произойти  по  самым различным причинам. В  стандарте определено три  вида нарушений:  грязное чтение, неповторяемое чтение и  фантомы (первые два из них описаны  в  разделе 16.2, а третий — в разделе 16.8), а различные уровни изоляции  определены в терминах нарушений, которые в  них допускаются’4. Итоговые сведения об этих нарушениях приведены в табл. 16.1 (здесь "Y" обозначает, что нарушение может возникнуть, a"N" — нет).

Таблица 16.1. Уровни изоляции SQL

В завершение этого раздела напомним, что ключевое слово REPEATABLE READ, которое определено в стандарте SQL, и опция повторяемого чтения (Repeatable Read — RR), определенная в СУБД DB2, не являются одинаковыми. В действительности, опция RR В СУБД DB2 аналогична ключевому слову SERIALIZABLE этого стандарта.

16.6.    РЕЗЮМЕ

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

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

14 Однако см. [16.2] и [16.14].

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

Наиболее распространенным методом разрешения указанных проблем  является  использование механизма блокировки. Существует два основных типа блокировок: разделяемая (блокировка S) и исключительная (блокировка X). Если транзакция устанавливает блокировку S для некоторого объекта, то другие  транзакции также смогут установить блокировку S для этого же объекта, однако установить для него блокировку X им не удастся. Если одна транзакция устанавливает блокировку X для некоторого объекта, то никакая другая транзакция не сможет установить для этого объекта никакой другой блокировки.  Специальный  протокол  использования  этих  блокировок  позволяет  устранить упомянутую выше проблему потерянного обновления и другие возможные проблемы. В соответствии с данным протоколом, блокировка S устанавливается для всех считываемых объектов, а блокировка X — для всех обновляемых объектов, причем все установленные блокировки сохраняются до окончания  выполнения транзакции. С помощью этого протокола можно обеспечить упорядочиваемость графика выполнения транзакций.

Описанный протокол является строгой формой протокола двухфазной блокировки.

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

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

если используемый график — не полностью упорядочиваемый. Однако в некоторых системах для повышения производительности и пропускной способности  предусмотрена возможность чередующегося выполнения нескольких транзакций с некоторым установленным уровнем изоляции, что на самом деле является не совсем безопасным решением. В этой главе был описан один такой небезопасный уровень, т.е. уровень стабильности курсора (с применением терминологии, принятой в СУБД DB2, хотя в стандарте языка SQL аналогичный уровень называется READ COMMITTED).

Далее  вкратце  было  рассмотрено  понятие  степени  детализации   блокировок  и связанная с ним идея намеченной блокировки. Предполагается,  что перед установкой транзакцией блокировки  определенного  типа  для  некоторого  объекта,  например  для кортежа   базы   данных,   ей   следует    установить   соответствующую   намеченную блокировку,  по  меньшей  мере, для  родительского объекта (в случае кортежа — для переменной  отношения,  в   которой  содержится  кортеж).  На  практике  намеченные блокировки обычно  устанавливаются неявно таким же образом, как блокировки S и X кортежей.   Однако  рекомендуется  предусмотреть  оператор  типа  LOCK  для  явной установки (в случае необходимости) блокировок,

более сильных, чем те, которые устанавливаются системой неявно (хотя в стандарте SQL

такой механизм не предусмотрен).

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

REPEATABLE   READ, READ   COMMITTED, READ   UNCOMMITTED),

которые в СУБД обычно

реализуются неявно заданными средствами блокировки.

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

По теме:

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