3

デッドロックの問題が発生し、異なるスレッド (2 つは Web サービスと呼ばれる) によって呼び出される 2 つのストアド プロシージャが原因であることがわかりました。

  1. X テーブルにデータを挿入するspを挿入します。
  2. X テーブルのデータを削除するspを削除します。

さらに、Xテーブルの非一意かつ非クラスター化インデックスでデッドロックが発生したことを示す結果が得られました。この問題を解決するためのアイデアはありますか?

アップデート

Read/Write deadlockから、次のステートメントのためにエラーだと思います。

  • insert ステートメントでは、id(クラスター化インデックス) を取得してから、非クラスター化インデックスを取得します。
  • delete ステートメントでは、id の前に非クラスター化インデックスを取得します。

したがって、次のステートメントのように、delete ステートメントの id を選択する必要があります。

SELECT id FROM X WITH(NOLOCK) WHERE [condition]

PS。両方のストアド プロシージャがトランザクションで呼び出されます。

ありがとう、

4

5 に答える 5

4

ある種のコードを見る必要があります...トランザクションについて言及しました。それはどの分離レベルですか？(UPDLOCK)行を検索する (または存在を確認する) ために使用する任意のクエリにヒントを追加することをお試しください。そのため、最初から (読み取りロックではなく) 書き込みロックを取得します。

競合すると、デッドロックではなく (非常に短い) ブロックが発生するはずです。

于 2009-07-24T04:52:10.677 に答える
0

デッドロック情報がない場合は、適切な答えよりも推測になります...読み取り/書き込みデッドロックと同様のインデックスアクセス順序の問題である可能性があります。

于 2009-07-24T04:30:50.410 に答える
0

selectクエリが実際の問題である可能性があります。特に、両方のストアドプロシージャで同じテーブルであるが、順序が異なる場合はそうです。テーブルから読み取ると（共有）ロックが作成されることを覚えておくことが重要です。ロックの種類を確認することをお勧めします。

Remusが投稿したように、同じことがインデックスレベルでも発生する可能性があります。彼がリンクした記事は良い説明を提供しますが、残念ながら、それぞれの場合に最適な解決策は1つもないため、誰も不思議な解決策を見つけることはできません。

私自身はこの分野の専門家ではありませんが、ロックヒントを使用すると、同じリソースが同じ順序でロックされ、デッドロックを防ぐことができる場合があります。ただし、これを効果的に解決するには、テスターからのより多くの情報が必要になる可能性があります。

于 2009-07-24T04:34:11.137 に答える
0

ストアド プロシージャは何かを変更しますか、それとも単に読み取りを行いますか? 何かを変更する場合、更新に関する句が十分に細かく設定されていますか? より小さいバッチで行を更新しようとすることができれば、SQL Server はインデックス全体ではなく少量のインデックスのみをロックするため、デッドロックの可能性は低くなります。

可能であれば、デッドロックしているコードをここに投稿できますか? ストアド プロシージャが長すぎる場合、その中に問題のあるステートメントを投稿できますか (どれがどれかわかっている場合)。

于 2009-07-24T04:13:58.337 に答える