Indicateur de trace 1222 ne fonctionne pas?

J'ai un site client avec deux serveurs SQL 2008r2 de configuration similaire "A" et "C". Sur les deux serveurs, les indicateurs de trace 1204 et 1222 sont activés et DBCC tracestatusaffichent ce qui suit sur les deux serveurs:

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

Sur A, les indicateurs de trace fonctionnent comme prévu, lorsqu'un blocage se produit, nous obtenons les rapports de blocage 1204 et 1222 dans les journaux d'erreurs. Cependant, sur C, seul le rapport 1204 apparaît, nous n'avons jamais le rapport 1222.

Pour ma vie, je ne vois aucune raison à cette différence. J'ai à la fois googlé cela sur Google, et lu (et relu) le doc MS sur ces indicateurs de trace, et je ne trouve aucun rapport de comportement comme celui-ci, ni aucune indication sur ce qui pourrait le provoquer. La seule chose qui se rapproche est l'affirmation occasionnelle qu'aucun des indicateurs de trace ne fonctionnait, mais tous ces cas se sont avérés être des fautes de frappe dans les commandes d'activation. Je sais que ce n'est pas le cas ici parce que j'ai utilisé DBCC TRACESTATUS pour le confirmer.

Par conséquent, tout aperçu de ce qui pourrait entraîner le non-fonctionnement du seul indicateur de trace 1222 et / ou de la façon de le corriger serait grandement apprécié.

Eh bien, voici une évolution intéressante. Chaque fois que je génère moi-même un blocage (en utilisant ce code: /programming/7813321/how-to-deliberately-cause-a-deadlock ), j'obtiens les deux rapports de trace dans les journaux d'erreurs. Seuls les blocages «naturels» qui surviennent tous les deux jours à partir des applications semblent déclencher l'un des rapports de blocage uniquement. Je ne sais pas si cela aide, y a-t-il une raison de croire que la trace 1222 ne rendrait pas compte des mêmes conditions de blocage que 1204?

— RBarryYoung
source

Bien sûr, possible, mais tous leurs serveurs sont déjà configurés de cette façon, je ne veux pas avoir à les changer tous, si je peux faire fonctionner celui-ci correctement. Quant à ne pas utiliser les deux, c'est également possible, mais pour le moment, le 1204 est le seul moyen pour moi de savoir qu'un blocage s'est produit sur C et le 1222 ne l'a pas signalé.

— RBarryYoung

Je ne vois pas de raison d'activer les indicateurs de trace pour les blocages sur sql 2008 comme cela xml_deadlock_report fait déjà partie de la system_health session. Consultez cet article pour plus de détails. Vérifiez cela pour voir si vous pouvez voir les blocages.

— Kin Shah

@Kin Un gros inconvénient du rapport de blocage intégré dans system_health est que sql_text n'est pas inclus, il peut donc être difficile de dépanner les requêtes / objets impliqués.

— Aaron Bertrand

@AaronBertrand J'ai essayé sur 2008R2 RTM et il donne le texte sql ainsi que le nom de l'objet

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

; mode="X" associatedObjectId="72057594039107584". Suis-je en train de manquer quelque chose? J'ai utilisé

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 J'ai vu la coupure de requête en utilisant le system_health. C'est une douleur.

J'ai eu un problème similaire, je ne suis pas sûr qu'il résoudra le vôtre.

Essaye ça:

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

Même s'il se connectait au journal des événements via l'indicateur de trace, cela doit également être défini afin de déclencher les e-mails. Vous pouvez voir le tableau ici:

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

Vous pouvez avoir plus de détails ici

— Marcello Miorelli
source