SQL Server 2008 har flere måder at identificere processer og forespørgsler, der er involveret i dødvande.
-
Hvis deadlocks er nemme at genskabe, er frekvensen højere, og du kan profilere SQL-serveren (du har adgangs- og ydeevneomkostningerne på serveren, når profiler er aktiveret) ved at bruge SQL Profiler vil du få en flot grafisk visning af deadlock. Denne side har alle de oplysninger, du skal bruge deadlock-graferhttp://sqlmag.com/ database-performance-tuning/gathering-deadlock-information-deadlock-graph
-
De fleste gange er det svært at reproducere deadlocks, eller også sker de i produktionsmiljøer, hvor vi ikke ønsker at knytte Profiler til det og påvirke ydeevnen.
Jeg ville bruge denne forespørgsel til at få dødvande til at ske:
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
Jeg ville IKKE gå i retning af at bruge (NOLOCK) til at rette deadlocks. Det er en glidebane og skjuler det oprindelige problem.