Trace Flag 1222 ¿No funciona?

Tengo un sitio de cliente con dos servidores SQL 2008r2 configurados de forma similar "A" y "C". En ambos servidores, los indicadores de traza 1204 y 1222 están habilitados y DBCC tracestatusmuestran lo siguiente en ambos servidores:

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

En A, las marcas de seguimiento funcionan como se esperaba, cuando se produce un punto muerto, obtenemos los informes de punto muerto 1204 y 1222 en los registros de errores. Sin embargo, en C, solo aparece el informe 1204, nunca recibimos el informe 1222.

Por mi vida no puedo ver ninguna razón para esta diferencia. He buscado en Google esto extensamente y leí (y volví a leer) el documento de MS en estos indicadores de seguimiento, y no puedo encontrar ningún informe de comportamiento como este, ni ninguna pista sobre lo que podría causarlo. Lo único que se acerca es la afirmación ocasional de que ninguno de los marcadores de seguimiento funcionaba, pero todos estos resultaron ser casos en los que tenían errores tipográficos en los comandos de habilitación. Sé que este no es el caso aquí porque he usado DBCC TRACESTATUS para confirmarlo.

Por lo tanto, cualquier idea sobre lo que podría estar causando que solo el indicador de traza 1222 no funcione y / o cómo solucionarlo sería muy apreciado.

Bueno, aquí hay un desarrollo interesante. Cada vez que genero un punto muerto (usando este código: /programming/7813321/how-to-deliberately-cause-a-deadlock ), obtengo ambos informes de seguimiento en los registros de errores. Son solo los puntos muertos "naturales" que ocurren cada dos días desde las aplicaciones que parecen desencadenar solo uno de los informes de punto muerto. No estoy seguro de si esto ayuda, ¿hay alguna razón para creer que el rastro 1222 no informaría sobre las mismas condiciones de bloqueo que 1204 lo haría?

— RBarryYoung
fuente

Claro, es posible, pero todos sus servidores ya están configurados de esta manera, no quiero tener que cambiarlos a todos, si puedo hacer que este funcione correctamente. En cuanto a no usar ambos, también es posible, pero en este momento, el 1204 es la única forma en que sabía que se produjo un punto muerto en C y el 1222 no lo informó.

— RBarryYoung

No veo una razón para habilitar marcas de seguimiento para puntos muertos en sql 2008 como xml_deadlock_report ya es parte de system_health session. Mira esta publicación para más detalles. Comprueba eso para ver si puedes ver los puntos muertos.

— Kin Shah

@Kin Una gran desventaja del informe de punto muerto integrado en system_health es que sql_text no está incluido, por lo que puede ser difícil solucionar las consultas / objetos involucrados.

— Aaron Bertrand

@AaronBertrand Probé en 2008R2 RTM y da el texto sql, así como el nombre del objeto

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

; mode="X" associatedObjectId="72057594039107584". Me estoy perdiendo de algo ? Yo solía

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 He visto el corte de la consulta usando system_health. Es un dolor

Tuve un problema similar, no estoy seguro de que solucionará el tuyo.

Prueba esto:

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

A pesar de que estaba iniciando sesión en el registro de eventos a través del indicador de seguimiento, esto también debe configurarse para activar los correos electrónicos. Puedes ver la tabla aquí:

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

Puedes tener más detalles aquí

— Marcello Miorelli
fuente