web-dev-qa-db-ja.com

selectステートメントからのデッドロック

2つのselectステートメントからデッドロックが発生しています。その理由は何ですか？そして、どうすればこの問題を修正できますか？

enter image description here

Deadlocked processes:   11278 
Victim process: 5185
Lock type:  Index/(Key)

両方のクエリは同じです

オブジェクト：unicas_ux.dbo.Course、ロックモード：排他（X）、インデックス：NCIDX_Course_TermId

（@ P0 bigint）selectコース0_.TermIdをTermId17_130_1_として、コース0_.IdをId1_45_1_として、コース0_.IdをId1_45_0_として、コース0_.ConvertedGradeをConverte2_45_0 _...... courses0_.VerifiedCreditsとしてVerifie14_45_0。 dbo.Course courses0_からVerifie16_45_0_として。

sql-serversql-server-2008deadlock
2
sebeid

デッドロックは、1つのクエリがオブジェクト（行、データページ、エクステント、テーブルなど）のロックを取得し、他のリソースがそれにアクセスしようとしたときに発生します。 SQL Serverの最小単位はデータページであり、SQLは作業中にページをロックします。したがって、はい、2つのselectステートメントでデッドロックが発生する可能性があります。

ソリューション：

  1. WITH（NOLOCK）-データがダーティに読み取れる場合
  2. コミットされた読み取りスナップショットまたはスナップショット分離を使用する
  3. トランザクションを小さく、バッチに保つようにしてください
  4. bound connection を使用-2つの接続が同じトランザクションとロックを使用できるようにします

スクリーンショットには情報が含まれていないため、この回答は質問に基づいています。

3
Anuj Tripathi

これがデッドロックの簡単な定義です

  • クエリ1はテーブル1をロックし、テーブル2へのアクセスを望んでいます
  • クエリ2はテーブル2をロックし、テーブル1へのアクセスを望んでいます

これは解決できない状況を作り出します。各クエリは、クエリがキャンセルされるか、接続が強制終了されるか、インスタンスがシャットダウンするまで、他のテーブルにアクセスできるようになるまで待機します。 SQL Serverはこれに気づき、そのうちの1つをdeadlock victimとして強制終了します。 Table 1またはTable 2は、テーブルの一部であっても、同じテーブルの一部であってもかまいません。

解決策は、クエリを同時に実行しないか、より速く実行するか、ロックを保持する時間を短くするか、クエリを変更して他のテーブルを使用しないようにすることです。

実際のクエリがないと、より具体的なアドバイスを提供することはできません。

編集：上記で指定したクエリの一部に基づいています（途中に....があるため、これがクエリ全体ではないと思います）。他に何が起こっているのか知りたい。 selectステートメントに排他ロックを要求しています。クエリヒントがないと、これはかなり珍しいことです。このトランザクションの前に追加のクエリがあるトランザクションはありますか？テーブル/インデックスの構造を教えてください。

1
Kenneth Fisher