Thực hiện truy vấn từ đây để kéo các sự kiện bế tắc ra khỏi phiên sự kiện mở rộng mặc định
SELECT CAST (
REPLACE (
REPLACE (
XEventData.XEvent.value ('(data/value)[1]', 'varchar(max)'),
'<victim-list>', '<deadlock><victim-list>'),
'<process-list>', '</victim-list><process-list>')
AS XML) AS DeadlockGraph
FROM (SELECT CAST (target_data AS XML) AS TargetData
FROM sys.dm_xe_session_targets st
JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address
WHERE [name] = 'system_health') AS Data
CROSS APPLY TargetData.nodes ('//RingBufferTarget/event') AS XEventData (XEvent)
WHERE XEventData.XEvent.value('@name', 'varchar(4000)') = 'xml_deadlock_report';mất khoảng 20 phút để hoàn thành trên máy của tôi. Số liệu thống kê được báo cáo là
Table 'Worktable'. Scan count 0, logical reads 68121, physical reads 0, read-ahead reads 0,
lob logical reads 25674576, lob physical reads 0, lob read-ahead reads 4332386.
SQL Server Execution Times:
CPU time = 1241269 ms, elapsed time = 1244082 ms.
Nếu tôi loại bỏ WHEREmệnh đề, nó sẽ hoàn thành trong chưa đầy một giây trả về 3.782 hàng.
Tương tự như vậy nếu tôi thêm OPTION (MAXDOP 1)vào truy vấn ban đầu, nó cũng tăng tốc mọi thứ với các số liệu thống kê hiện hiển thị số lần đọc lob ít hơn.
Table 'Worktable'. Scan count 0, logical reads 15, physical reads 0, read-ahead reads 0,
lob logical reads 6767, lob physical reads 0, lob read-ahead reads 6076.
SQL Server Execution Times:
CPU time = 639 ms, elapsed time = 693 ms.
Vì vậy, câu hỏi của tôi là
Bất cứ ai có thể giải thích những gì đang xảy ra? Tại sao kế hoạch ban đầu lại tồi tệ đến mức thảm khốc và có cách nào đáng tin cậy để tránh vấn đề này không?
Thêm vào:
Tôi cũng thấy rằng việc thay đổi truy vấn để INNER HASH JOINcải thiện mọi thứ ở một mức độ nào đó (nhưng vẫn mất> 3 phút) vì kết quả DMV rất nhỏ. Tôi nghi ngờ rằng chính loại Tham gia chịu trách nhiệm và cho rằng một thứ khác phải thay đổi. Số liệu thống kê cho điều đó
Table 'Worktable'. Scan count 0, logical reads 30294, physical reads 0, read-ahead reads 0,
lob logical reads 10741863, lob physical reads 0, lob read-ahead reads 4361042.
SQL Server Execution Times:
CPU time = 200914 ms, elapsed time = 203614 ms.Sau khi điền vào bộ đệm vòng sự kiện mở rộng ( DATALENGTHtrong số XML4,880,045 byte và nó chứa 1,448 sự kiện.) Và thử nghiệm phiên bản cắt giảm của truy vấn ban đầu có và không có MAXDOPgợi ý.
SELECT COUNT(*)
FROM (SELECT CAST (target_data AS XML) AS TargetData
FROM sys.dm_xe_session_targets st
JOIN sys.dm_xe_sessions s
ON s.address = st.event_session_address
WHERE [name] = 'system_health') AS Data
CROSS APPLY TargetData.nodes ('//RingBufferTarget/event') AS XEventData (XEvent)
WHERE XEventData.XEvent.value('@name', 'varchar(4000)') = 'xml_deadlock_report'
SELECT*
FROM sys.dm_db_task_space_usage
WHERE session_id = @@SPID Đã cho kết quả như sau
+-------------------------------------+------+----------+
| | Fast | Slow |
+-------------------------------------+------+----------+
| internal_objects_alloc_page_count | 616 | 1761272 |
| internal_objects_dealloc_page_count | 616 | 1761272 |
| elapsed time (ms) | 428 | 398481 |
| lob logical reads | 8390 | 12784196 |
+-------------------------------------+------+----------+Có một sự khác biệt rõ ràng trong phân bổ tempdb với các 616trang hiển thị nhanh hơn được phân bổ và phân bổ. Đây là cùng số lượng trang được sử dụng khi XML cũng được đặt vào một biến.
Đối với kế hoạch chậm, số lượng phân bổ trang này là hàng triệu. Bỏ phiếu dm_db_task_space_usagetrong khi truy vấn đang chạy cho thấy dường như liên tục phân bổ và phân bổ các trang ở tempdbbất kỳ nơi nào từ 1.800 đến 3.000 trang được phân bổ cùng một lúc.
WHEREmệnh đề vào biểu thức XQuery; logic không phải được loại bỏ để nó đi nhanh :TargetData.nodes ('RingBufferTarget[1]/event[@name = "xml_deadlock_report"]'). Điều đó nói rằng, tôi không biết nội bộ XML đủ tốt để trả lời câu hỏi bạn đã đặt ra.