0

これはおそらく非常に基本的なものなので、ご容赦ください (一方で、おそらく素敵な光沢のあるカットアンドドライの答えがあるでしょう!)。

現在、デッドロックの問題を診断しています。実際、セッションの 1 つが別のセッションによってブロックされていることがわかります。(デッドロックのもう一方の端は、反対の順序で互いに待機している Java スレッドです。) Management Studio のプロセス エクスプローラーでプロセスの詳細を表示すると、ブロックされたセッションの SQL が表示されますが、ブロックされたセッションの SQLのみが表示されます。 「EXEC sp_unprepare 807」として。

これは準備されたステートメントに関連していることを理解したので、これ自体に動揺していません。ただし、実際の SQL が何であるかを知りたいので、コードベースのどこに疑わしい目を向けるべきかがわかります。では、この時点で、これをこのスレッドによって実行された実際の SQL に関連付ける最良の方法は何でしょうか? 準備済みステートメントの SQL へのマッピングを検索できるシステム テーブルはありますか? おそらく、呼び出しを保持することが期待されるセッションの最後のn SQL ステートメントを格納するテーブルでしょうか? prepareこのセッションでプリペアド ステートメントを完全に無効にするデータベース ドライバー接続に設定できるフラグはありますか?

この問題に対する代替アプローチがより良い方法である場合は、それを歓迎します (基本的に、テーブルを変更した後にコミットに失敗している Java コードがいくつかあると強く疑っています。そのための SQL を知りたいです)私はそれがどこにあるかを見つけます)。

4

2 に答える 2

1

これを試して

dbcc inputbuffer(spid)
于 2009-01-14T15:03:22.523 に答える
0

SQL プロファイラーを使用してサーバー上のアクティビティを追跡し、問題を再現します。サーバー側カーソルを使用する場合、SQL は数値をハンドルとして使用します。これらのハンドルをプロファイラーの出力から追跡して、そのハンドルを使用して他に何が実行されているかを確認できます。ハンドルと SPID の間でワークロードを追跡し、問題の原因を詳細に調べることができます。

于 2009-01-15T21:29:00.467 に答える