Мы видим стандартную блокировку, которая создается для
каждого соединения с базой данных. Никакой дополнительной блокировки
установлено не было.
Другим способом проверки того, что блокировка
снимается сразу после извлечения данных, является использование трассировки.
Попробуйте выполнить следующую команду:
|
dbcc
traceon(3604,1200)
select
* from test
dbcc
traceoff(3604,1200)
|
Флаг трассировки 3604 заставляет сервер передавать
отладочную информацию в текущее соединение непосредственно клиенту, а 1200 –
выводить информацию о блокировках. В результате мы получим следующее:
|
Process
54 acquiring S lock on DB: 8 (class bit0 ref1) result: OK
Process
54 acquiring IS lock on TAB: 8:1993058136 [] (class bit0 ref1) result: OK
Process
54 acquiring IS lock on PAG: 8:1:31 (class bit0 ref1) result: OK
i n
-----------
--------------------
1 alex
2 rosa
3 dima
(3
row(s) affected)
Process
54 releasing lock on PAG: 8:1:31
Process
54 releasing lock on TAB: 8:1993058136 []
|
Хорошо. В первой сессии зафиксируйте транзакцию:
|
--print
@@spid
--begin
tran select * from test
commit
|
Повторный вызов sp_lock приводит к тем же результатам.
Это подтверждает, что предыдущим запросом никаких блокировок не
устанавливалось. Теперь попробуем наложить блокировку обновления. Делается это
с помощью хинта updlock (хинты подробно будут рассмотрены далее):
|
begin
tran select * from test with (updlock)
|
Теперь вызов sp_lock 54 дает более интересный
результат (таблица 4):
Главная