Trace Flag 1222 non funziona?

Ho un sito di clienti con due server SQL 2008r2 similmente configurati "A" e "C". Su entrambi i server i flag di traccia 1204 e 1222 sono abilitati e DBCC tracestatusmostrano quanto segue su entrambi i server:

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

Su A i flag di traccia funzionano come previsto, quando si verifica un deadlock, nei registri errori vengono visualizzati sia i report deadlock 1204 che 1222. Tuttavia, su C, viene visualizzato solo il rapporto 1204, non otteniamo mai il rapporto 1222.

Per la mia vita non vedo alcun motivo per questa differenza. Ho entrambi cercato su Google ampiamente, e letto (e riletto) il documento MS su questi flag di traccia, e non riesco a trovare alcun rapporto di comportamento come questo, né alcun suggerimento su cosa potrebbe causarlo. L'unica cosa che si avvicina è l'affermazione occasionale che nessuna traccia di traccia funzionava, ma tutti si sono rivelati casi in cui avevano errori di battitura nei comandi di abilitazione. So che questo non è il caso qui perché ho usato DBCC TRACESTATUS per confermarlo.

Quindi, qualsiasi intuizioni in quello che potrebbe essere la causa solo il flag di traccia 1222 di non lavoro e / o come risolvere il problema sarebbe molto apprezzato.

Bene, ecco uno sviluppo interessante. Ogni volta che genera un deadlock (utilizzando questo codice: /programming/7813321/how-to-deliberately-cause-a-deadlock ), ottengo entrambi i rapporti di traccia nei log degli errori. Sono solo i deadlock "naturali" che si verificano ogni paio di giorni dalle applicazioni che sembrano attivare solo uno dei report deadlock. Non sono sicuro che ciò possa aiutare, c'è qualche motivo per credere che la traccia 1222 non riferisca su tutte le stesse condizioni di deadlock che 1204 farebbe?

— RBarryYoung
fonte

Certo, possibile, ma tutti i loro server sono già configurati in questo modo, non voglio cambiarli tutti, se riesco a far funzionare correttamente solo questo. Per quanto riguarda il non utilizzo di entrambi, anche possibile, ma in questo momento, il 1204 è l'unico modo in cui sapevo che si è verificato un deadlock su C e il 1222 non lo ha segnalato.

— RBarryYoung,

Non vedo un motivo per abilitare i flag di traccia per deadlock a partire da sql 2008 in su, come xml_deadlock_report già fa parte di system_health session. Controlla questo post per maggiori dettagli. Controlla che per vedere se riesci a vedere i deadlock.

— Kin Shah,

@Kin Una grande rovina del report di deadlock incorporato in system_health è che sql_text non è incluso, quindi può essere difficile risolvere i problemi relativi alle query / agli oggetti coinvolti.

— Aaron Bertrand

@AaronBertrand Ho provato su 2008R2 RTM e fornisce sia il testo sql che il nome dell'oggetto

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

; mode="X" associatedObjectId="72057594039107584". Mi sto perdendo qualcosa ? Ho usato

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 il

@kin Ho visto l'interruzione della query usando system_health. È un dolore

Ho avuto un problema simile, non sono sicuro che risolverà il tuo.

Prova questo:

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

Anche se stava registrando nel registro eventi tramite il flag di traccia, è necessario impostare anche questo per attivare le e-mail. Puoi vedere la tabella qui:

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

Puoi avere maggiori dettagli qui

— Marcello Miorelli
fonte