Trace Flag 1222 Não está funcionando?

8

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?

sql-server sql-server-2008-r2 deadlock dbcc error-log RBarryYoung
fonte
11
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
2
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
4
@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
4
@AaronBertrand Eu tentei no 2008R2 RTM e ele fornece o texto sql e o nome do objeto <inputbuf> BEGIN TRAN UPDATE dbo.DeadLockTest2 SET col1 = 1 UPDATE dbo.DeadLockTest SET col1 = 1 </inputbuf>; mode="X" associatedObjectId="72057594039107584". Estou esquecendo de algo ? Eu useiSELECT 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
11
@kin Vi o ponto de corte da consulta usando o system_health. É uma dor.

Respostas:

1

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