Выясните, какие блокировки получены в запросе на SQL Server?

Question

У меня есть оператор SQL из моего приложения. Я хотел бы знать, какие блокировки получает это утверждение; Как я могу сделать это с сервером SQL? Заявление зашло в тупик, который я пытаюсь проанализировать; Я не могу воспроизвести тупик. Я работаю на MS SQL Server 2005.

Answer 1

Вы можете запустить оператор в транзакции, но не зафиксировать транзакцию. Поскольку блокировки будут удерживаться до совершения транзакции, это дает вам время для проверки блокировок. (Не бесконечно, но по умолчанию 5 минут.)

Как:

BEGIN TRANSACTION
select * from table

Затем откройте Management Studio и проверьте блокировки. Они находятся в разделе Управление -> Монитор активности -> Блокировки по объекту или Блокировки по процессу. После того, как вы закончите, запустите:

COMMIT TRANSACTION

чтобы освободить замки.

Answer 2

Вот запрос, который покажет вам все активные блокировки, кто их получил и на каком объекте они находятся. Я вытащил это из статьи в Technet или что-то много лет назад. Он работает на SQL 2000 и 2005 (замените sysobjects на sys.objects для 2005.) Раскомментируйте предложение WHERE, если вы хотите ограничить его только этой базой данных, и только "EXCLUSIVE" блокирует.

select 'Locks' as Locks,
    spid, nt_username, name, hostname, loginame, waittime, open_tran,
    convert(varchar ,getdate() - last_batch, 114) as TimeSinceLastCommand,
    case req_mode
    when  0 then 'Not granted'
    when  1 then 'Schema stability'
    when  2 then 'Schema modification'
    when  3 then 'Intent shared'
    when  4 then 'Shared intent update'
    when  5 then 'Intent shared shared'
    when  6 then 'Intent exclusive'
    when  7 then 'Shared Intent Exclusive'
    when  8 then 'Shared'
    when  9 then 'Update'
    when 10 then 'Intent insert NULL'
    when 11 then 'Intent shared exclusive'
    when 12 then 'Intent update'
    when 13 then 'Intent shared-update'
    when 14 then 'Exclusive'
    when 15 then 'Bulk operation'
    else str(req_mode) end as LockMode
from master..syslockinfo
    left join sysobjects so on so.id = rsc_objid
    left join master..sysprocesses sp on sp.spid = req_spid
--where rsc_dbid = (select db_id()) and ltrim(req_mode) in (6,7,11,14) 

Answer 3

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

Таким образом, сведения о событии будут записываться в журнал ошибок SQL Server.

Просмотрите следующую справочную систему Books Online для получения подробной информации о различных флагах трассировки. Вам нужно использовать 1204 и / или 1222

http://msdn.microsoft.com/en-us/library/ms188396(SQL.90).aspx

Обязательно включите флаги трассировки с областью сервера, а не только с текущим сеансом. Например, используйте:

DBCC TRACEON(1222,-1)

Answer 4

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

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

Answer 5

Устранение неисправностей тупиков:

http://blogs.msdn.com/bartd/archive/2006/09/09/747119.aspx http://blogs.msdn.com/bartd/archive/2006/09/13/751343.aspx

Воспроизведение тупиков:

http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/01/01/reproducing-deadlocks-involving-only-one-table.aspx

Answer 6

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

Под какой изоляцией вы работаете? Какие типы запросов являются взаимоблокирующими? Используете ли вы явные транзакции, которые охватывают несколько обновлений, или они блокируют отдельные операторы?

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

Сообщите нам, к какому типу запросов они относятся, существуют разные общие проблемы для разных типов транзакций.