跟踪标志1222不起作用？

我有一个客户站点，其中有两个配置类似的2008r2 SQL Server“ A”和“ C”。在两台服务器上，启用了跟踪标志1204和1222，并DBCC tracestatus在两台服务器上显示以下内容：

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

在A上，跟踪标志按预期工作，当发生死锁时，我们在错误日志中同时获取1204和1222死锁报告。但是，在C上，仅显示1204报告，而我们从未获得1222报告。

对于我的一生，我看不出有什么区别。我已经在Google上进行了广泛的搜索，并阅读（并重新阅读了）这些跟踪标志上的MS文档，但找不到任何此类行为的报告，也没有任何提示可能导致这种情况的提示。唯一接近的是偶尔声称没有跟踪标记起作用的情况，但是事实证明，如果它们在启用命令中有错别字。我知道这里不是这种情况，因为我已经使用DBCC TRACESTATUS进行了确认。

因此，对于可能导致仅跟踪标记1222不工作和/或如何修复跟踪标记的任何见解，将不胜感激。

好吧，这是一个有趣的发展。每当我自己生成一个死锁（使用此代码：https : //stackoverflow.com/questions/7813321/how-to-deliberately-cause-a-deadlock）时，我都会在错误日志中获得两个跟踪报告。从应用程序开始每两天就会发生“自然”死锁，似乎只触发其中一个死锁报告。不确定是否有帮助，是否有任何理由相信跟踪1222不会报告与1204相同的所有死锁条件？

— RBarryYoung
source

当然可以，但是他们的所有服务器都已经以这种方式设置，如果我能使这台服务器正常工作，我就不必更改所有服务器。至于不同时使用这两种方法，也是可行的，但是现在，1204是我知道C发生死锁而1222没有报告死锁的唯一方法。

— RBarryYoung 2014年

我没有看到在sql 2008上启用死锁跟踪标志的原因，因为xml_deadlock_report 它已经是的一部分system_health session。检查此帖子以获取更多详细信息。检查是否可以看到死锁。

— Kin Shah

@Kin system_health中内置死锁报告的一大缺点是不包含sql_text，因此很难对所涉及的查询/对象进行故障排除。

— 亚伦·伯特兰

我在2008R2 RTM上尝试过@AaronBertrand，它确实提供了sql文本以及对象名称

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

； mode="X" associatedObjectId="72057594039107584"。我想念什么吗？我用过

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 2014年

@kin我已经看到使用system_health的查询截止。真痛苦

我遇到了类似的问题，不确定是否会对您的问题进行排序。

尝试这个：

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

即使它是通过跟踪标志登录到事件日志中的，也需要进行设置以触发电子邮件。您可以在此处查看表格：

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

您可以在此处获得更多详细信息

— 马切洛·米奥雷利（Marcello Miorelli）
source