Trace Flag 1222 Funktioniert nicht?

Ich habe einen Kundenstandort mit zwei ähnlich konfigurierten 2008r2-SQL-Servern "A" und "C". Auf beiden Servern sind die Ablaufverfolgungsflags 1204 und 1222 aktiviert und DBCC tracestatuszeigen auf beiden Servern Folgendes an:

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

Bei A funktionieren die Ablaufverfolgungsflags wie erwartet. Wenn ein Deadlock auftritt, werden sowohl die 1204- als auch die 1222-Deadlock-Berichte in den Fehlerprotokollen angezeigt. Auf C wird jedoch nur der 1204-Bericht angezeigt, wir erhalten nie den 1222-Bericht.

Für mein Leben kann ich keinen Grund für diesen Unterschied sehen. Ich habe dies beide ausgiebig gegoogelt und das MS-Dokument auf diesen Ablaufverfolgungsflags gelesen (und erneut gelesen), und ich kann keine Berichte über ein solches Verhalten oder Hinweise darauf finden, was es verursachen könnte. Das einzige, was nahe kommt, ist die gelegentliche Behauptung, dass keines der Trace-Flags funktioniert hat, aber es stellte sich heraus, dass dies alles Fälle waren, in denen Tippfehler in den Aktivierungsbefehlen vorhanden waren. Ich weiß, dass dies hier nicht der Fall ist, da ich DBCC TRACESTATUS verwendet habe, um dies zu bestätigen.

Daher wären alle Erkenntnisse darüber, was möglicherweise dazu führt, dass nur das Ablaufverfolgungsflag 1222 nicht funktioniert, und / oder wie es behoben werden kann, sehr willkommen.

Hier ist eine interessante Entwicklung. Immer wenn ich selbst einen Deadlock generiere (unter Verwendung dieses Codes: /programming/7813321/how-to-deliberately-cause-a-deadlock ), erhalte ich beide Ablaufverfolgungsberichte in den Fehlerprotokollen. Es sind nur die "natürlichen" Deadlocks, die alle paar Tage bei den Anwendungen auftreten und nur einen der Deadlock-Berichte auslösen. Sie sind sich nicht sicher, ob dies hilft. Gibt es einen Grund zu der Annahme, dass Trace 1222 nicht alle Deadlock-Bedingungen wie 1204 melden würde?

— RBarryYoung
quelle

Sicher, möglich, aber alle Server sind bereits auf diese Weise eingerichtet. Ich möchte nicht alle ändern müssen, wenn nur dieser ordnungsgemäß funktioniert. Es ist auch möglich, nicht beide zu verwenden, aber im Moment ist der 1204 der einzige Weg, von dem ich wusste, dass ein Deadlock auf C aufgetreten ist, und der 1222 hat ihn nicht gemeldet.

— RBarryYoung

Ich sehe keinen Grund, Trace-Flags für Deadlocks auf SQL 2008 zu aktivieren, da dies xml_deadlock_report bereits Teil von ist system_health session. Überprüfen Sie diesen Beitrag für weitere Details. Überprüfen Sie dies, um festzustellen, ob Sie die Deadlocks sehen können.

— Kin Shah

@Kin Ein großer Nachteil des in Dead_health integrierten Deadlock-Berichts ist, dass sql_text nicht enthalten ist, sodass es schwierig sein kann, die beteiligten Abfragen / Objekte zu beheben.

— Aaron Bertrand

@AaronBertrand Ich habe 2008R2 RTM ausprobiert und es gibt den SQL-Text sowie den Objektnamen an

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

. mode="X" associatedObjectId="72057594039107584". Vermisse ich etwas Ich habe

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 Ich habe den Abfrageschnitt mit system_health gesehen. Es ist ein Schmerz.

Ich hatte ein ähnliches Problem, nicht sicher, ob es Ihr Problem lösen wird.

Versuche dies:

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

Obwohl das Ereignisprotokoll über das Ablaufverfolgungsflag protokolliert wurde, muss dies auch festgelegt werden, um die E-Mails auszulösen. Sie können die Tabelle hier sehen:

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

Weitere Details finden Sie hier

— Marcello Miorelli
quelle