【发布时间】：2011-10-05 15:34:16
【问题描述】：
环境：
Sql server 2008 r2
Windows 7 64 位
Windbg 64位
我已经知道的
我可以通过运行服务器端分析器跟踪并在出现死锁时立即停止它来找到此事务中的 sql stmts。然后在跟踪文件中搜索事务 ID。但这是一种蛮力方法，不能总是在生产环境中完成。
我知道我应该将内存转储发送给微软，然后获取然后分析它。但是我想知道我们是否有希望在没有私有符号的情况下解决这个问题。
问题：
当 2 个事务死锁（lock_deadlock 事件）时，我使用 sql server 中的扩展事件创建内存转储。
我正在通过管理工作室手动创建这个死锁场景。 假设 1 个死锁的 xaction 中有 2 个 sql 语句。
begin tran
update tabl1 ... -- sql stmt 1
go
update tabl2 .. -- sql stmt 2
现在我在我的内存转储中找到了这个线程，我只能找到我的 sql stmt 2，即“更新 tabl2”。
无论如何我可以查找线程在 xaction 中执行的所有 sql stmts，即在我们的例子中是“update tabl1..”？
我想知道线程之前在同一个事务中执行了什么。由于在转储时尚未提交此 xaction，因此这些值应该位于线程内存中的某个位置。
如果我在这里没有意义，请告诉我。我一直在关注这个问题一段时间并且
我想知道这是否可能。
附加信息
背景：
我们有性能测试环境，我们在其中运行 12 小时的负载测试。第二天早上我们分析并找出一个死锁。应用程序在一个事务中执行 7-8 个 dml 语句（我们使用 hibernate）。由于基于 sys.dm_exec_sql_text 的结果只有在缓存中才会产生结果，因此我们在第二天分析它时没有得到整套 dml 语句（ps：我什至没有尝试过，当问题在 1 后报告给我时日）
我们今天是如何解决这个问题的：
1. 设置服务器端跟踪
2.设置在死锁时触发的事件通知并调用停止跟踪的sp。
3.从扩展事件xml报告或分析器中，我们找到事务id并查找对应的过去语句。
我怎么想我可以解决这个问题：
1. 在包含系统 ID 的扩展事件“lock_deadlock”上触发内存转储。
2. 不知怎的尝试在系统id对应的线程中查找历史。
为什么要转储内存：
因为如果我必须在生产中进行此设置，则影响最小。
【问题讨论】：
标签： sql-server sql-server-2008 debugging windbg memory-dump