SQL Server 2008 heeft meerdere manieren om processen en query's te identificeren die betrokken zijn bij een impasse.
-
Als deadlocks gemakkelijk te reproduceren zijn, is de frequentie hoger en kunt u SQL-server profileren (u hebt de toegang en prestatiekosten op de server wanneer profiler is ingeschakeld) met behulp van SQL Profiler krijgt u een mooie grafische weergave van deadlock. Deze pagina heeft alle informatie die u nodig heeft moet deadlock-grafieken gebruikenhttp://sqlmag.com/ database-performance-tuning/gathering-deadlock-information-deadlock-graph
-
Meestal is het reproduceren van deadlocks moeilijk, of ze gebeuren in een productieomgeving waar we geen Profiler aan willen koppelen en de prestaties beïnvloeden.
Ik zou deze query gebruiken om deadlocks te voorkomen:
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
Ik zou NIET in de richting gaan van het gebruik van (NOLOCK) om impasses op te lossen. Dat is een hellend vlak en verbergt het oorspronkelijke probleem.