我有一个客户站点，其中包含两个类似配置的 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 报告。
对于我的生活，我看不出这种差异的任何原因。我已经广泛地搜索了这个，并阅读（并重新阅读）了关于这些跟踪标志的 MS 文档，我找不到任何关于此类行为的报告，也没有任何关于可能导致它的原因的提示。唯一接近的是偶尔声称这两个跟踪标志都不起作用，但这些都被证明是在启用命令中有拼写错误的情况。我知道这里不是这种情况，因为我已经使用 DBCC TRACESTATUS 进行了确认。
因此，对于可能导致仅跟踪标志 1222 不起作用和/或如何修复它的任何见解，将不胜感激。
嗯，这是一个有趣的发展。每当我自己生成死锁时（使用此代码：https : //stackoverflow.com/questions/7813321/how-to-deliberately-cause-a-deadlock），我都会在错误日志中得到两个跟踪报告。似乎只是触发死锁报告之一的应用程序每隔几天就会发生一次“自然”死锁。不确定这是否有帮助，是否有任何理由相信跟踪 1222 不会报告与 1204 相同的所有死锁情况？
我一直在处理死锁，特别是获取他们的信息，正如你在这篇文章中看到的。
在同一篇文章中，Shanky推荐了“您现在必须依靠扩展事件跟踪来捕获死锁信息”
我的问题是：
1) 使用扩展事件是否会增加 CPU？
2) 它使用了多少内存、磁盘空间和 I/O？
任何相关文档的链接都将是奖励。