2014-10-02 3 views
0

Итак, я изучал больше инструментов управления SQL-серверами, используя несколько из них, и я был поражен тем, что обнаружил, что простые блокировки блокируют себя и вызывают взаимоблокировки. Я провел небольшое исследование, но я действительно удивлен, что это может произойти. Может ли кто-нибудь уточнить или, может быть, решить, почему это происходит?Базовый выбор самих взаимоблокировок

Я говорю про простой выбор.

SELECT 
    ID 
FROM 
    MainTable 
WHERE 
    Name Like 'John Smith' 

Использование Microsoft SQL Server Managment Studios, если это имеет значение.

+7

Откуда вы знаете, что это блокировки? Можете ли вы описать, что вы на самом деле видите? – Blorgbeard

+3

Это не приведет к возникновению взаимоблокировки. –

+0

Если вы вставляете в базу данных одновременно с тем, что вы выбираете эти данные, ваш запрос может быть выбран как жертва взаимоблокировки. Если вам не нужны данные, которые только что были вставлены, вы можете добавить 'с nolock' после имени вашей таблицы, и он сделает« грязное »чтение и не будет тупика. – paqogomez

ответ

0

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

latch waits reported as blocking

Это, безусловно, возможно для ЗЕЬЕСТ, чтобы вызвать затор, потому что разделяемые блокировки приобретаются при выборе данных, но также должны быть еще один процесс, который пытается обновить данные.

+0

Фактически общая блокировка (если мы не находимся в транзакции с REPEATABLE READ Isolation Level - или хуже -) будет удерживаться всего лишь на долю времени, а затем внезапно будет выпущена, по крайней мере, на отдельные строки или ключи. – Antonio

0

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

Если вы используете SQL 2008 или более позднюю версию, информация о блокировке по умолчанию отслеживается трассировкой расширенного события system_helath. Ниже приведен запрос на извлечение последней информации о блокировке из кольцевого буфера. Это устранит некоторые догадки.

SELECT 
     xed.value('@timestamp', 'datetime') as Creation_Date, 
     xed.query('.') AS Extend_Event 
FROM 
(
     SELECT CAST([target_data] AS XML) AS Target_Data 
     FROM sys.dm_xe_session_targets AS xt 
     INNER JOIN sys.dm_xe_sessions AS xs 
     ON xs.address = xt.event_session_address 
     WHERE xs.name = N'system_health' 
     AND xt.target_name = N'ring_buffer' 
) AS XML_Data 
CROSS APPLY Target_Data.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(xed) 
ORDER BY Creation_Date DESC; 
0

Этот простой выбор не может затормозить сам, единственная возможная причина - это что-то еще, что обновляет/удаляет строки во время чтения. Попробуйте запустить SQL Server Profiler и использовать:

  • тупикового
  • тупиковой цепь
  • deadloch граф

событие в шаблоне. Граф Deadlock, в частности, поможет вам определить, какие два процесса вызывают взаимоблокировку, и тот, который выбран как тупик.