Как проверить блокирующие запросы в SQL Server

Question

У меня есть один сервер хранилища, который получил данные/синхронизацию из унаследованной системы 24/7, я заметил, что некоторые из моих отчетов/работы с sql-заданиями являются неопределенными, и большую часть времени я слышал от команды DBA что мой запрос блокирует другому процессу синхронизации.

Из команды DBA я познакомился с командой i.e. EXEC SP_WHO2, с помощью которой я могу идентифицировать spid запроса, которые вызывают блокировку, просматривая столбцы BlkBy.

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

Answer 1

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

Он будет решать проблему блокировки в SP, но он не будет работать в функции таблицы, в случае функции таблицы вам нужно писать с (nolock) во всех таблицах функции.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; 

Answer 2

Помимо sp_who2 вы можете использовать следующий запрос для идентификации блокировки в вас SQL.

SELECT 
db.name DBName, 
tl.request_session_id, 
wt.blocking_session_id, 
OBJECT_NAME(p.OBJECT_ID) BlockedObjectName, 
tl.resource_type, 
h1.TEXT AS RequestingText, 
h2.TEXT AS BlockingTest, 
tl.request_mode 
FROM sys.dm_tran_locks AS tl 
INNER JOIN sys.databases db ON db.database_id = tl.resource_database_id 
INNER JOIN sys.dm_os_waiting_tasks AS wt ON tl.lock_owner_address = wt.resource_address 
INNER JOIN sys.partitions AS p ON p.hobt_id = tl.resource_associated_entity_id 
INNER JOIN sys.dm_exec_connections ec1 ON ec1.session_id = tl.request_session_id 
INNER JOIN sys.dm_exec_connections ec2 ON ec2.session_id = wt.blocking_session_id 
CROSS APPLY sys.dm_exec_sql_text(ec1.most_recent_sql_handle) AS h1 
CROSS APPLY sys.dm_exec_sql_text(ec2.most_recent_sql_handle) AS h2 
GO 

Также можно проверить детали конкретного SPID, используя следующую команду.

DBCC INPUTBUFFER(56) — Will give you the Event Info. 

KILL 56 -- Will kill the session of this id. 

Answer 3

This - очень подробное руководство. Некоторые основные принципы, хотя:

• Избегайте SELECT ... INTO #temp картины и вместо того, чтобы создать таблицу первого и использовать INSERT INTO #Temp SELECT...
• Использование WITH (NOLOCK) на запросах, где вы можете терпеть dirty reads
• Обеспечить proper indexes существуют
• Использование sargable предикаты в вашем WHERE статьи
• Обратитесь к вашему администратору базы данных о возможном включении READ_COMMITTED_SNAPSHOT уровень изоляции