デッドロックの問題を解決するために長時間実行されているトランザクションを見つけるためのクエリがあります-
SELECT spid, cmd, status, loginame, open_tran, datediff(s, last_batch, getdate ()) AS [WaitTime(s)]
FROM master..sysprocesses p
WHERE open_tran > 0
AND spid > 50
AND datediff (s, last_batch, getdate ()) > 30
ANd EXISTS (SELECT * FROM master..syslockinfo l
WHERE req_spid = p.spid AND rsc_type <> 2)
しかし、それは rcord を返さず、アプリケーションでまだデッドロックの問題が発生しています。何が理由でしょうか？
DBCC TRACEON(1222,-1)-フラグのトレースを有効にするには、デッドロック情報がログファイルに記録されますDBCC TRACESTATUS (1222, -1)-トレースフラグのステータスを確認しますDBCC TRACEOFF (1222,-1)-トレースフラグを無効にしますこれはいくつかの点で明確化を求めていることを理解していますが、それが答えに属することは十分に重要です。
デッドロックは、2 つのプロセスが同じリソースを待機している非常に特殊な発生であり、待機によって解決できない catch-22 状況にあります。よく読んでください SQL Server 2000 と書かれていますが、非常に簡単な説明があります。それを再現するには、この素晴らしいスクリプトも参照してください。おそらく、デッドロックについて理解する上で最も重要なことは、通常、デッドロックは非常に高速であるということです。デッドロック状態に陥った場合、SQL Server はそれを認識してプロセスの 1 つを強制終了するほどスマートです。
したがって、まだデッドロックが発生していると思われる場合は、ポスターが正しいため、回答 #1 を聞いてください。人々が「デッドロック」という用語をより大まかに使用していると思われる場合は、プロセスがリソースを拘束し、他のすべてのプロセスが待機する必要がある場所をロックおよびブロックします。SQL Server プロファイラーを実行し、問題のプロセスにゆっくりと焦点を合わせることで、これらのトラブルシューティングを行います。
元のポスターではないにしても、これが将来の読者のために明確にするのに役立つことを願っています. あなたが実際に研究しているものを知っていることを確認してください！
DBCC TRACEON (1204) で試すことができます