Trace Flag 1222 Không hoạt động?

Tôi có một trang web khách hàng với hai Máy chủ SQL 2008r2 được cấu hình tương tự "A" và "C". Trên cả hai máy chủ, cờ theo dõi 1204 và 1222 được bật và DBCC tracestatushiển thị như sau trên cả hai máy chủ:

TraceFlag   Status  Global  Session
1204        1       1      0
1222        1       1      0
3605        1       1      0

Trên A cờ theo dõi hoạt động như mong đợi, khi xảy ra bế tắc, chúng tôi nhận được cả báo cáo bế tắc 1204 và 1222 trong nhật ký lỗi. Tuy nhiên, trên C, chỉ có báo cáo 1204 xuất hiện, chúng tôi không bao giờ nhận được báo cáo 1222.

Đối với cuộc sống của tôi, tôi không thể thấy bất kỳ lý do cho sự khác biệt này. Tôi đã mở rộng cả hai điều này và đọc (và đọc lại) tài liệu MS trên các cờ theo dõi này và tôi không thể tìm thấy bất kỳ báo cáo nào về hành vi như thế này, cũng như bất kỳ gợi ý nào về những gì có thể gây ra nó. Điều duy nhất đến gần là thỉnh thoảng tuyên bố rằng không có cờ theo dõi nào hoạt động, nhưng tất cả những điều này hóa ra là trường hợp chúng có lỗi chính tả trong các lệnh kích hoạt. Tôi biết rằng đây không phải là trường hợp ở đây vì tôi đã sử dụng DBCC TRACESTATUS để xác nhận nó.

Vì vậy, bất kỳ cái nhìn sâu vào những gì có thể gây ra chỉ dấu vết cờ 1222 để không làm việc và / hoặc làm thế nào để sửa chữa nó sẽ được đánh giá rất nhiều.

Vâng, đây là một sự phát triển thú vị. Bất cứ khi nào tôi tự tạo bế tắc (sử dụng mã này: /programming/7813321/how-to-deliberingly-cause-a-deadlock ), sau đó tôi nhận được cả báo cáo theo dõi trong nhật ký lỗi. Đó chỉ là những bế tắc "tự nhiên" xảy ra cứ sau vài ngày từ các ứng dụng dường như chỉ kích hoạt một trong những báo cáo bế tắc. Không chắc chắn nếu điều này có ích, có lý do nào để tin rằng dấu vết 1222 sẽ không báo cáo về tất cả các điều kiện bế tắc tương tự mà 1204 sẽ không?

— RBarryYoung
nguồn

Chắc chắn là có thể, nhưng tất cả các máy chủ của họ đã được thiết lập theo cách này, tôi không muốn phải thay đổi tất cả, nếu tôi có thể làm cho máy chủ này hoạt động chính xác. Đối với việc không sử dụng cả hai, cũng có thể, nhưng ngay bây giờ, 1204 là cách duy nhất tôi biết rằng sự bế tắc xảy ra trên C và 1222 đã không báo cáo.

— RBarryYoung

Tôi không thấy lý do cho phép cờ theo dõi cho bế tắc trên sql 2008 trở lên như xml_deadlock_report đã là một phần của system_health session. Kiểm tra bài này để biết thêm chi tiết. Kiểm tra xem để xem bạn có thể thấy những bế tắc không.

— Kin Shah

@Kin Một nhược điểm lớn của báo cáo bế tắc tích hợp trong system_health là sql lòng không được bao gồm, do đó có thể khó khắc phục các truy vấn / đối tượng liên quan.

— Aaron Bertrand

@AaronBertrand Tôi đã thử trên 2008R2 RTM và nó cung cấp văn bản sql cũng như tên đối tượng

&lt;inputbuf&gt; BEGIN TRAN UPDATE dbo.DeadLockTest2 SET col1 = 1 UPDATE dbo.DeadLockTest SET col1 = 1   &lt;/inputbuf&gt;

; mode="X" associatedObjectId="72057594039107584". Tui bỏ lỡ điều gì vậy ? Tôi đã sử dụng

SELECT CAST(xet.target_data AS XML) AS XMLDATA FROM sys.dm_xe_session_targets xet JOIN sys.dm_xe_sessions xe ON (xe.address = xet.event_session_address) WHERE xe.name = 'system_health'

— Kin Shah

@kin Tôi đã thấy cắt bỏ truy vấn bằng system_health. Đó là một nỗi đau.

Tôi đã có một vấn đề tương tự, không chắc nó sẽ sắp xếp của bạn.

Thử cái này:

EXEC master..sp_altermessage 1205, 'WITH_LOG', TRUE;
GO

Mặc dù nó đã đăng nhập vào nhật ký sự kiện thông qua cờ theo dõi, nhưng điều này cũng cần được đặt để kích hoạt các email. Bạn có thể xem bảng ở đây:

select * from master.sys.messages
where text like '%deadlock%'

Bạn có thể có thêm chi tiết ở đây

— Marcello Miorelli
nguồn