Trace Flag 1222 Não está funcionando?

Eu tenho um site de cliente com dois SQL Server 2008r2 configurados de forma semelhante "A" e "C". Nos dois servidores, os sinalizadores de rastreamento 1204 e 1222 são ativados e DBCC tracestatusmostram o seguinte nos dois servidores:

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

Em A, os sinalizadores de rastreamento funcionam conforme o esperado, quando ocorre um conflito, obtemos os relatórios de conflito 1204 e 1222 nos logs de erros. No entanto, em C, apenas o relatório 1204 aparece, nunca recebemos o relatório 1222.

Pela minha vida, não vejo razão para essa diferença. Eu pesquisei isso extensivamente no Google e li (e reli) o documento MS sobre esses sinalizadores de rastreamento, e não consigo encontrar nenhum relatório de comportamento como esse, nem dicas sobre o que pode causar isso. A única coisa que se aproxima é a alegação ocasional de que nenhum sinalizador de rastreamento estava funcionando, mas todos acabaram sendo casos em que houve erros de digitação nos comandos de ativação. Sei que esse não é o caso aqui, porque usei o DBCC TRACESTATUS para confirmá-lo.

Portanto, qualquer percepção sobre o que pode estar fazendo com que apenas o sinalizador de rastreamento 1222 não funcione e / ou como corrigi-lo seria muito apreciada.

Bem, aqui está um desenvolvimento interessante. Sempre que eu mesmo gerar um deadlock (usando este código: /programming/7813321/how-to-deliberately-cause-a-deadlock ), recebo os dois relatórios de rastreamento nos logs de erros. São apenas os impasses "naturais" que ocorrem a cada dois dias nos aplicativos que parecem acionar apenas um dos relatórios de impasse. Não tenho certeza se isso ajuda, existe alguma razão para acreditar que o rastreio 1222 não reportaria todas as mesmas condições de impasse que 1204 faria?

— RBarryYoung
fonte

Claro, possível, mas todos os servidores já estão configurados dessa maneira, não quero alterá-los, se conseguir que apenas este funcione corretamente. Quanto a não usar os dois, também é possível, mas agora, o 1204 é a única maneira que eu sabia que ocorreu um impasse em C e o 1222 não o relatou.

— usar o seguinte código

Não vejo uma razão para ativar sinalizadores de rastreamento para conflitos no sql 2008, como xml_deadlock_report já faz parte do system_health session. Verifique esta postagem para mais detalhes. Verifique se você pode ver os impasses.

— Kin Shah

@Kin Uma grande queda do relatório de deadlock interno no system_health é que sql_text não está incluído, portanto pode ser difícil solucionar problemas nas consultas / objetos envolvidos.

— Aaron Bertrand

@AaronBertrand Eu tentei no 2008R2 RTM e ele fornece o texto sql e o nome do 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". Estou esquecendo de algo ? Eu usei

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 Vi o ponto de corte da consulta usando o system_health. É uma dor.

Eu tive um problema semelhante, não tenho certeza se ele resolverá o seu.

Tente o seguinte:

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

Mesmo que estivesse efetuando login no log de eventos por meio do sinalizador de rastreamento, isso também precisa ser configurado para acionar os emails. Você pode ver a tabela aqui:

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

Você pode ter mais detalhes aqui

— Marcello Miorelli
fonte