問題タブ [database-deadlocks]

マスターデータベースでこのクエリを実行した後、すべてのデータベースで実行中のすべてのプロセスが表示されます。データベースで実行中のすべてのプロセスを強制終了するクエリはありますか。

MySQL+InnoDB で、単一のテーブルと、"SELECT ... FOR UPDATE" を実行する 2 つのスレッドがあるとします。両方の SELECT ステートメントが複数の行を選択することになるとします。たとえば、両方とも行 R42 と R99 を選択することになります。これがデッドロックになる可能性はありますか？

私はこの状況を考えています。最初のスレッドは R42 をロックしてから R99 をロックしようとし、2 番目のスレッドは R99 をロックしてから R42 をロックしようとします。運が悪いと、2 つのスレッドがデッドロックしてしまいます。

「デッドロック」のMySQL用語集を読みました

トランザクションが (UPDATE または SELECT ... FOR UPDATE などのステートメントを使用して) 複数のテーブルの行をロックすると、デッドロックが発生する可能性がありますが、その順序は逆です。...

デッドロックの可能性を減らすには、 ... SELECT ... FOR UPDATE および UPDATE ... WHERE ステートメントで使用される列にインデックスを作成します。

これは、私の状況 (単一のテーブル) ではデッドロックしないことを示唆しています。これは、MySQL が主キーの順序で行を自動的にロックしようとするためかもしれませんが、確実にしたいのですが、何が起こっているかを正確に教えてくれるドキュメント。

Informix IDS 11.50 でデッドロックを強制する方法を探しています。ソリューションは、次の条件を満たす必要があります。

• 関係するテーブルは 1 つだけで、
• 分離レベル: COMMITTED READ、
• ROWレベルロック、
• 2 つのスレッドですが、他のスレッドによって変更された行にアクセスできるのは 1 つだけです。

最後の条件を除くすべての条件を満たすソリューションを思いつきました。

テーブルt1は次のように作成され、入力されます。

2 つの別々の dbaccess コンソール (ロック モードを 15 秒間待機するように設定) で、次のコマンドを実行します。

これらのスレッドは、他のスレッドがコミットするのを SELECT が待機しているため、デッドロックになっています。この解決策は、4 番目の条件に違反する他のスレッドによって更新された行を両方のスレッドが選択するため、適切ではありません。このソリューションを改善したり、すべての基準を満たす他のソリューションを提供したりする方法を考えられる人はいますか?

「SHOW ENGINE INNODB STATUS;」の応答の数行を次に示します。

この「Transaction transId, not started」の意味を知りたいですか? 実行に失敗したクエリはありますか?

私はinnodbを使用しています。また、手動でトランザクションを開始していません。大量のデータを持つテーブルに対して更新クエリを発行しているため、自動トランザクションを検討しています。そして、この単一のテーブルに対して 5 ～ 10 分で何百もの mysql 更新クエリが取得されます。

「トランザクションが開始されていません」の正確な意味を教えてください。失敗したクエリまたは通常のログを示していますか?

前もって感謝します！

同じテーブルでの同時クライアント処理中に MySQL によって検出されたデッドロックを理解しようとしています。これは、「SHOW InnoDB STATUS」コマンドの興味深い部分です。

このログから私が理解しているのは、トランザクション (1) がINodeparent_basenametable のインデックスで共有ロックを取得するのを待っているということtestsuiteです。INode. 現在、トランザクション (2) は、この同じインデックスに対して排他ロックを持っています。しかし奇妙なのは、トランザクション (2) も指定されたテーブルに対する X ロックを待機していることです。何故ですか？トランザクション (2) が既にロックを取得している場合、なぜそれを待つのでしょうか?

(一般に、status コマンドの出力を読み取る方法を正確に説明しているドキュメントは見つかりませんでした。誰かがそれを指摘してくれたら興味深いでしょう)

上記は、顧客がサイトから私に送信したデッドロック トレースのサニタイズされたインスタンスです。私が理解しているように、2 つのコミットが同じテーブルに順不同でアクセスしようとすると、デッドロックが発生します。

ただし、この例では、テーブルは 1 つしかなく、これらの SQL ステートメントを実行するコードは、それらをキューから取り出して順番に実行しています。

なぜこのデッドロックになるのでしょうか?

NHibernateをデータ アクセス レイヤーとして使用し、SQL Server コンパクトを使用して、ac# デスクトップ アプリケーションに取り組んでい ます。アプリケーションは複数のスレッドを使用して、データの選択と更新を実行します。

通常は正常に動作していますが、デッドロック状態が発生することがあります。

15:28:16,750 55 警告: System.Data.SqlServerCe.SqlCeLockTimeoutException (0x80004005): タイムアウト ..... [ セッション ID = 28、スレッド ID = 14576、プロセス ID = 12960、テーブル名 = PatientOrder、競合タイプ = xロック (x ブロック)、リソース = PAG (idx): 1035]

2 つのトランザクションが同じ行を更新しようとすると、デッドロックの問題を理解できます。ただし、この場合、両方のトランザクションが異なる行で動作しています。デッドロックは、インデックス ( ) のページ ロックResource = PAG (idx): 1035が原因のようです。

だから私の質問は、これらのデッドロックを防ぐために何ができるでしょうか?

私はすでに次のオプションを調べました：

• インデックスのページ ロックを無効にします。これは「フル」SQL サーバーでは可能ですが、コンパクト エディションではサポートされていないようです。

• with(rowlock)（うまくいけば）問題を防ぐSQLステートメントを生成するようにhibernateを構成します

• session.lock(...)すべてのトランザクションに対して同じ順序でリソース アクセスを強制するために使用しようとしています。ただし、デッドロックのトランザクションが別の行で動作しているため、これは役に立たないようです。

• 一度に 1 つだけがアクティブになるように、すべてのデータベース トランザクションをシリアル化します。これは機能しますが、パフォーマンスに大きな影響を与えます。

SQL Server 2008 のデッドロック グラフを使用して、SQL サーバーのデッドロックの問題を診断しました。

問題は私のインデックスに関係しています。2 つのクエリがあります。ベース テーブルの 2 つの異なる日付に従ってデータを取得する多数の結合とサブクエリを含む長期実行レポートと、そのベース テーブルの同じ日付を更新するクイック更新クエリです。2 つのインデックスがあり、レポートは両方に共有 KEY ロックを必要としますが、更新クエリはそれらの両方に排他的 KEY ロックを必要とし、どういうわけか各クエリはキーの 1 つしか取得できないため、どちらも続行できません。

これを修正するにはどうすればよいですか?

ここに私の状況に関するすべての詳細があります：

私のベーステーブルは次のようになります。

私のインデックスは次のようになります。

最後に、私の更新は次のようになります。

また、このレポートはあらゆる種類の統計を日付別にカウントしているため、ここには含めません。idx_createDate と idx_upDate は、そのレポートで頻繁に使用されているため、dataField1 を「カバー」または含めるように意図的に設計しました。

レポートは、インデックスの 1 つで共有ロックを取得し、サブクエリにヒットして、2 番目のインデックスでロックを要求していると思います。一方、更新クエリは、upDate と含まれる dataField1 の両方を更新するために、両方のインデックスを排他的にロックする必要があります。

皆さんはどう思いますか？

編集: 要求された XML デッドロック グラフは次のとおりです。

単純な質問ですが、明確な解決策を見つけて数日を無駄にしました.

私は春の jdbc テンプレートを DAO レイヤーとして使用し、mssql サーバー 2005 をデータベースとして使用しており、注文入力システムがあります。現在、システムに 5 人以上の人がいると、非常に多くのデッド ロック シナリオが発生します。他の人が既存の注文を更新している間に新しい注文を作成しようとすると、ロックが発生するようです。同じテーブルに対する挿入ステートメントと更新ステートメントの間で競合が発生しているようです。

私はこれを修正するためにいくつかのことをしましたが、どれもうまくいきませんでした。そこで、Java.util.semaphore または Lock を導入してスレッドの同時アクセスを制御するか、同期化されたメソッドまたはブロックを使用することを考えています。

これについてどう思いますか？データベースサーバーでこれを処理するより良い方法はありますか?

ありがとう。

jOOQデータベース抽象化レイヤーを使用して MySql データベースと通信しています。

次のエラーが発生し続けます。

これは、テーブルへの約 500 行の一括挿入中です。これらの一括挿入の複数が異なるスレッドから一度に試行される可能性があります。

デッドロックの原因は何ですか?どうすれば回避できますか?