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

Синтаксис конструкции, позволяюш;ей применить подсказку, является довольно простым; достаточно лишь ввести подсказку после имени таблицы {или после псевдонима, если таковой используется):

FROM <table name> [AS <alias>][[WITH](<hint>)]

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

select * FROM Sales.SalesOrderHeader as ord WITH (tablockx) select * FROM Sales.SalesOrderHeader as ord (tablockx) select * FROM Sales.SalesOrderHeader WITH (tablockx) select * FROM Sales.SalesOrderHeader (tablockx)

Теперь рассмотрим, как складывается ситуация, если блокировки устанавливаются одновременно на нескольких таблицах. С точки зрения применения блокировок в следуюш;их запросах выполняются такие же действия, как и в приведенных выше, - в них принудительно устанавливается исключительная блокировка таблицы на таблице SalesOrderHeader. Но следует учитывать, что в этих запросах не устанавливаются какие-либо специальные блокировки на таблице SalesOrderDetail, поскольку полный контроль над таблицей все еще сохраняет за собой диспетчер блокировок SQL Server. select *

FROM Sales.SalesOrderHeader AS ord WITH (TABLOCKX) JOIN Sales.SalesOrderDetail AS od

ON ord.SalesOrderlD = od.SalesOrderlD select *

FROM Sales.SalesOrderHeader AS ord (TABLOCKX) JOIN Sales.SalesOrderDetail AS od

ON ord.SalesOrderlD = od.SalesOrderlD

select *

FROM Sales.SalesOrderHeader WITH (TABLOCKX) JOIN Sales.SalesOrderDetail AS od

ON Sales.SalesOrderHeader.SalesOrderlD = od.SalesOrderlD select *

FROM Sales.SalesOrderHeader (TABLOCKX) JOIN Sales.SalesOrderDetail AS od

ON Sales.SalesOrderHeader.SalesOrderlD = od.SalesOrderlD

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

Определение блокировок с использованием программы Management Studio

По-видимому, наиболее удобный способ ознакомления с блокировками состоит в применении программы Management Studio. В программе Management Studio предусмотрена возможность просматривать с помощью окна Activity Monitor блокировки, отсортированные по двум разным признакам - по идентификатору процесса или по объектам.

Чтобы воспользоваться указанным окном программы Management Studio с отображением блокировок, перейдите к узлу Management Activity Monitor, связанному с обозначением используемого сервера. Затем щелкните на указанном узле правой кнопкой мыши и выберите требуемый тип информации. После этого откроется новое окно, которое показано на рис. 12.3.

J Ptocess Info

Locks by Procjess Ucks by Object

Server: SCHWEIT2EF Conrtectton! MyLoin jjViecQnntionPro

Puc. 12.3. Окно Activity Monitor

Для просмотра различных блокировок в этом окне достаточно развернуть интересующий вас узел (либо Locks by Process, либо Locks by Object).

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

Настройка уровня изоляции

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

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

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

Опция read committed (значение, применяемое по умолчанию).

Опция read uncommitted.

Опция repeatable read.

Опция serializable.

Для выбора конкретного уровня изоляции применяется довольно простой синтаксис:

set transaction isolation level <read committedread uncommitted Irepeatable readserializable>

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

Рассмотрим более подробно, какая ситуация возникает при использовании уровня изоляции, заданного по умолчанию (опция read committed).

Опция READ COMMITTED

При использовании опции read committed все созданные разделяемые блокировки автоматически освобождаются после завершения вьшолнения оператора, в котором они были созданы. Иными словами, в том случае, если начинается определенная транзакция, выполняется несколько операторов, после этого вызывается на вьшолнение оператор select, а затем выполняется еще несколько операторов, то блокировки, связанные с оператором select, освобождаются сразу после завершения его вьшолнения, т.е. СУБД SQL Server не ожидает завершения транзакции.

При выполнении запросов, которые оказывают воздействие на данные (с операторами update, delete или insert), возникает немного иная ситуация. Если в транзакции выполняется запрос, в котором модифицируются данные, то соответствующие блокировки сохраняются на время выполнения всей транзакции (на тот случай, если необходимо будет произвести откат).

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