問題タブ [database-deadlocks]

トリガーを追加した後、デッドロックが発生しています。UserBalanceHistoryトランザクションごとに 1 つの行と 1 つの列を持つテーブルがありますAmount。列を合計しAmount、結果を関連Userテーブル列に配置するトリガーが追加されましたBalance。

私もオンにしましたREAD_COMMITTED_SNAPSHOT：

エントリを作成している並列プロセスを実行していUserBalanceHistoryますが、明らかに同時に同じ作業をしている場合User、デッドロックが発生します。提案？

ASP.NET-Applicationによってスローされた例外をログに記録しました。

メッセージ：トランザクション（プロセスID 56）がロックでデッドロックされました| 別のプロセスとの通信バッファリソースであり、デッドロックの犠牲者として選択されています。トランザクションを再実行します。

selectsその理由は、アプリケーションで同時にクエリされたテーブルでSSMSで直接実行していたためだと確信しています。

だから今私の質問は：

• SQL-Serverが「デッドロックの犠牲者」を選択する優先順位を変更できますか？ASP.NETではなく「myself」（SSMS）をデッドロックの犠牲者として選択したいと思います。これはタイムクリティカルなアプリケーションであり、ユーザーがエラーを受け入れるよりも手動クエリを再実行する方が簡単だからです。

前もって感謝します。

ここで何が起こっているのかを正確に理解しようとしています。選択/更新の組み合わせがデッドロックを引き起こす可能性があることを認識しています-この場合、長い待ち時間です。

シナリオは次のとおりです。クエリ A は、3 つのインデックスを使用する選択ステートメントです (非常に単純化されています)。

インデックスはすべて非クラスタ化されています:

1. Plan_Id
2. Date_Entered
3. Plan_Id、nabp

すべてに ProblemTable.Unique_Id の「出力」があります

クエリ B は、2 つのインデックスを使用する更新ステートメントです。

インデックスは次のとおりです。

1. クラスター化されていない Date_Entered ASC、Source ASC、DataStartOffset ASC
2. インデックス 1 のインデックス検索の結果で使用される Unique_Id のクラスター化インデックス。

更新クエリ:

私は知っています.. dateaddは間抜けです。私はこれを書いていません:)

したがって、これはクエリ A とは別のインデックスをスキャンしますが、Date_Entered も使用します。このような状況のため、長い待ち時間が発生し続けます。デッドロックは発生していないように見えますが、各クエリが通常数秒で実行される場合、5 分以上の待機時間が発生する可能性があります。

これは、INSERT into ProblemTable でも発生することに注意してください。

したがって、SELECT stmt は、NC インデックス検索に基づいて最終的に選択することを決定した行のロックを取得し、更新ステートメントは、NC インデックスでの検索から返された行のロックを取得しようとすると推測しています。しかし、デッドロックが発生していないのに、なぜ長い時間がかかるのでしょうか?

質問は基本的に次のとおりです。

1 デッドロックではなく長い待機時間はなぜですか? 2. 何が原因ですか?

ここで利用できる十分な情報はありますか？

EDIT 1両方のクエリはかなり高速で、どちらもこれほど長くかかりません。長い時間は、ここでの「何らかの」未知のロックの問題の結果です。進行中の他の明示的なトランザクションはありません。

次の場合にトランザクションを再起動する方法 (少なくとも 1 回は実行されるようにするため):

( com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException:ロックを取得しようとしたときにデッドロックが見つかりました; トランザクションを再起動してください) または (トランザクションがタイムアウトしました) ?

MySQL（innoDB ENGINE）とJavaを使用しています。役立つリソースやコードをリンクしてください。

同時に実行されることがある2つのプロセスがあります。

最初の 1 つは一括挿入です

2 つ目は、ストアド プロシージャからの一括更新です。

-- ストアド プロシージャのコードの一部 --

最初のプロセスは少しの間実行され (着信レコードのロードによって異なります)、2 番目のプロセスは常にデッドロックの犠牲になります。

SqlBulkCopyOptions.TableLockリソースが解放されるまで 2 番目のプロセスが待機するように設定する必要がありますか。

私はmysql 5.0.92を使用しています。最近、比較的高速に行が挿入 (および更新または削除) される 1 つのテーブルへの挿入のデッドロックが多数発生しています。問題を理解せずに、ここで StackOverflow、mysql のドキュメント、およびフォーラムで質問を調査しました。私を困惑させることの 1 つは、テーブルの 1 つが innodb ステータスに従ってリソースをロックしていないという事実です。

の出力は次のSHOW INNODB STATUSとおりです。

テーブルは次のように定義されます。

助けていただければ幸いです。

私は次の表を持っています

そして、次のデッドロックの問題：

このデッドロックのメカニズムを理解するのを手伝っていただけませんか。

これらの2つのクエリは、異なるスレッドから発行されます。各スレッドには、クエリ内に独自のnode_idがあります。2つのクエリが同じnode_idを持つことはありません。

フィールド（node_id、status）に複合インデックスを作成することで状況を解決できると思いますが、これは良い解決策ではないと思います。問題の性質を理解する必要があります。

同じクエリでのこれらのデッドロックは、1回または2回ではなく、定期的に発生します。

影響を受けるクエリのEXPLAINは、興味深い結果をもたらします。

MySQLのバージョンは5.5です。

また、デッドロックの時点では、影響を受けるクエリの条件に一致する行がテーブルに含まれていません（たとえば、更新のために.. from .where（。.=95および..='EXECUTING'）を選択すると、行はまったく生成されません）usr_sl3。taskidusr_sl3taskusr_sl3tasknode_idusr_sl3taskstatus

前もって感謝します。

誰かがこのデッドロック グラフを読んだり理解したりするのを手伝ってくれませんか?

プロセス 75 が、彼がすでにロックしているオブジェクトのロックを要求している理由がわかりません。

ライブアプリでデッドロックエラーが発生し、（SQL Server Profilerの「デッドロックグラフ」を使用after insertして）テーブルで定義されたトリガーまで追跡しました。

基本的にシナリオはそうです-特定のテーブルに挿入されたレコードを時間枠ごとにグループ化して追跡したいと思います。（つまり、12：00〜12：10の間に、7つのレコードがに挿入されましたUsers）。
私が実装した方法はafter insert、これらのテーブルにトリガーを作成することでした。そのため、レコードが挿入されると、統計テーブルの適切なレコードを更新します。（下記参照）。

私が言ったように、これはデッドロック状態を生み出すようです。何が起こるかというと（私はそれについて確信する方法を見つけていないと思います）、各トランザクションがコミットする前にいくつかのテーブルにいくつかのレコードを挿入/更新する可能性があります。
したがって、トランザクション1が実行され、統計テーブルの特定のレコードが更新され（したがってロックされ）、次にテーブルBのレコードが更新されます。
一方、トランザクション2はレコードをテーブルBに挿入し（したがってロックし）、次のことを試みます。統計テーブルのレコードを更新すると、デッドロックが発生します。

（もちろん、これは起こり得ることの非常に単純化されたバージョンです。実際には、私はまだ100％確実ではありません）。

さて、私の最初の考えは、コミット後にトリガーを実行して、トランザクションがロックを保持しないようにすることが可能かどうかを確認することでした。
しかし、私が理解できる限り、そのような選択肢はありません。

別の解決策は、トリガーを完全に排除し、代わりにある種のバッチジョブを使用することです。

望ましい解決策についての他のアイデア/考えは大歓迎です。

トリガーコード：

FK制約のバックアップに使用できる可能性のあるインデックスが複数ある場合について説明しているものは何も見つかりません。

以下のテストから、FKの作成時に、FKは特定のインデックスにバインドされ、新しいより良いインデックスが後で追加されるかどうかに関係なく、これは常にFK制約を検証するために使用されるようです。

これを確認または否定するリソースを誰かが指摘できますか？