環境：
SQL Server 2008 r2
Windows764ビット
Windbg64ビット
私がすでに知っていること
サーバー側のプロファイラートレースを実行し、デッドロックが発生するとすぐに停止することで、このトランザクションでsqlstmtsを見つけることができます。次に、トレースファイルでトランザクションIDを検索します。ただし、これはブルートフォース方式であり、実稼働環境で常に実行できるとは限りません。
マイクロソフトにメモリダンプを送信して、それを分析する必要があることはわかっています。しかし、私的なシンボルなしでこれを解決する希望があれば、私は私たちを見つけたいと思います。
問題：
2つのトランザクションがデッドロックしたときにSQLサーバーで拡張イベントを使用してメモリダンプを作成します（lock_deadlockイベント）。
このデッドロックシナリオは、ManagementStudioを介して手動で作成しています。デッドロックされたxactionの1つに2つのSQLステートメントがあるとします。
begin tran
update tabl1 ... -- sql stmt 1
go
update tabl2 .. -- sql stmt 2
今、私は私のメモリダンプでこのスレッドを見つけました、そして私は私のsql stmt 2、すなわち「updatetabl2」だけを見つけることができます。
とにかく、スレッドがxactionで実行したすべてのSQL stmtを検索できますか？つまり、この場合は「updatetabl1 ..」ですか？
同じトランザクションでスレッドが以前に何を実行したかを知りたい。このxactionはダンプの時点ではまだコミットされていないため、値はスレッドメモリのどこかにあるはずです。
ここで意味がわからない場合はお知らせください。私はしばらくこの問題を抱えていましたが、これが可能かどうか知りたいです。
追加情報
背景：
パフォーマンステスト環境があり、12時間の負荷テストを実行します。翌朝、デッドロックを分析して見つけます。アプリケーションはトランザクションで7〜8個のdmlステートメントを実行します（hibernateを使用します）。sys.dm_exec_sql_textベースは、キャッシュ内にある場合にのみ結果を生成するため、翌日分析しているため、dmlステートメントのセット全体を取得しません（ps：問題が1後に報告されたとき、これを試していませんでした） day）
今日この問題をどのように解決しましたか：
1。サーバー側のトレースを設定します
2.デッドロック時にトリガーされるイベント通知を設定し、トレースを停止するspを呼び出します。
3.拡張イベントxmlレポートまたはプロファイラーから、トランザクションIDを見つけ、それに対応する過去のステートメントを検索します。
この問題を解決できると思った方法：
1.システムIDが含まれている拡張イベント「lock_deadlock」でメモリダンプをトリガーします。
2.どういうわけか、システムIDに対応するスレッドで履歴を見つけようとします。
なぜメモリダンプするのか：
本番環境で実行する必要がある場合、この設定による影響が最も少ないためです。