問題タブ [database-deadlocks]

$this->db->trans_start();のみに適用され$this->db->query();ますか?

ユーザー ガイドのすべての CI の例で使用されているので、知りたいだけです。$this->db->query();

これに当てはまりますか？例：

どんな反応でも大歓迎です。ありがとう！

MSSQLサーバー2008を使用しており、アプリケーションにはSQLクエリがあり、行とページのレベルでDBをロックしています。ロックのため、CPU ヒット率は 100% であると言われています。この問題をさらに絞り込むことができるように、MSSQL サーバーのどのインスタンスがどれだけの CPU を消費しているかを調べる手順または方法はありますか?

私はマルチスレッドコンソールアプリケーションを使用しています.各スレッドは基本的に、特定の基準が満たされたTOP 1の「ファイル」行を取得しようとし、それをロックします.(これが発生すると入力されるLockID列があり、次のスレッド次に利用可能な「ロック解除された」「ファイル」行を選択します)

SQL Server DB にモニターを配置し、2 つのクエリでデッドロックが発生するたびに。

と

最初のクエリは、新しいスレッドが作成されたときに実行され、新しい「ファイル」行を取得しようとします。

2 番目のクエリは、スレッド (以前に作成されたものである可能性があります) が「ファイル」レコードの処理をほぼ完了したときに実行されます。このクエリで使用されたトランザクション。分離レベルは「ReadCommitted」でした。2 つのスレッドが同じ「FileID」を後で処理することはないため、両方のクエリが同じ「FileID」にアクセスしようとしていないことは確かです。この問題をどのように診断できるかについて、私はひどく混乱しています。これら 2 つのクエリ間のデッドロックの原因は何ですか? 誰かが私を正しい方向に導くことができれば、本当に感謝しています。事前にどうもありがとう:)

私は 2 つの SPID をトランザクションとして実行しています。以下は、それぞれがとりわけ行うことです。

SPID A -

1. テーブル 1 の行 1 ～ 10 を更新します
2. .......

SPID B -

1. テーブル 1 の行 5 を更新します
2. テーブル 1 から行 4、5、および 6 を選択し、テーブル 2 の行を更新します。
3. ……
4. ……

SPID A が行 4 を更新し、クラスター化インデックスの X ロックを待って行 5 を更新し、SPID B が手順 2 で、X にある行 4 のクラスター化インデックスの S ロックを待機しているデッドロック シナリオに直面しています。 SPID A によるロック。テーブル 1 にも非クラスター化インデックスがありますが、選択クエリをカバーしていないため、クラスター化インデックスを検索します。私はそれをカバリング インデックスにしても、SPID A は非クラスター化インデックスのロックを保持し、SPID B を待機させると想定しています。SPID Bが行5への更新をすでに開始している場合、多かれ少なかれテーブル全体を更新しているSPID Aがロックを取得するのを待たなければならないように、分離レベルをシリアライゼーションにエスカレートすることを検討しています。また、SPID Bを防ぎますSPID A が既に開始されている場合は、x ロックを取得できません。

この行き詰まりを解消するために、他に何か提案はありますか? ありがとう。

データを表示するために、MySQL DB で PHP スクリプトを実行するように依頼されたのですが、その設計が奇妙であることに気付きました。彼らは、ユーザーごとに最大 2000 レコードを収集する必要がある調査を実行したいと考えており、登録するユーザーごとに新しいテーブルを自動的に作成しています。この段階ではパイロット スタディなので、約 30 のテーブルがありますが、実際のスタディでは 3000 人のユーザーが必要です。

それらをすべて 1 つのテーブルにまとめることを提案したかったのですが、調査期間中にそのデータベースに対して 1 分あたり約 1500 回の INSERT が発生する可能性があるため、最初にここで質問したいと思いました。これにより、MySQL でテーブル ロックが発生しますか? つまり、1 分あたり 1500 回の INSERT で最大サイズが 6,000,000 レコードの 1 つのテーブルか、1 分あたり 30 回の INSERT で最大サイズが 2000 レコードの 3000 テーブルか。最初のオプションを提案したいと思いますが、問題が発生しないことを確認したいと思います. InnoDB には行レベルのロックがあると読みました。では、1 つのテーブル オプションと組み合わせると、パフォーマンスが向上しますか?

読み取りコミット分離レベルのトランザクション内で、一連の行で更新を行い、次に同じ行のセットで選択を行う場合、SQL Server は次の更新を行うときにインデックスで取得した x ロックを再利用しません。選択するか、インデックスで新しいロックのセットを取得しようとします。2 つのプロセスが、ロックされている 2 つのリソースの 1 つであるインデックス キー ロックをめぐって争っているデッドロック シナリオがあります。これは、プロセスの 1 つが既に更新を行ってから、同じ行を選択した場合に発生します。私の質問は、前のステップで同じ行の x ロックを既に取得しているのに、そのプロセスがインデックスのキー ロックを取得するのをどのように待機するのかということです。

私は調査を行っていますが、関連する情報を見つけるのは困難です。私はこの問題に遭遇しました：

次のトランザクション シナリオの待機グラフを生成し、デッドロックが存在するかどうかを判断します。

取引：

トランザクションによってロックされたデータ項目:

トランザクションが待機中のデータ項目:

さて、私がトランザクション管理について見た限りでは、これは非常に難しいことでした。誰かがこの種の問題を解決する方法の説明への参照を提供したり、とにかく助けたりできますか?

まず、Hibernate のことは忘れましょう。A と B の 2 つのテーブルがあるとします。2 つのトランザクションがこれら 2 つのテーブルの同じレコードを更新していますが、txn 1 は B を更新してから A を更新し、txn 2 は A を更新してから B を更新します。これは典型的なデッドロックの例です。これを回避する最も一般的な方法は、リソースを取得する順序を事前に定義することです。たとえば、テーブル A を更新してから B を更新する必要があります。

ハイバネートに戻ります。1 つのセッションで多数のエンティティを更新する場合、セッションをフラッシュすると、さまざまなエンティティの変更により、対応する挿入/更新/削除ステートメントが DB に生成されます。Hibernate には、エンティティ間の更新順序を決定するアルゴリズムがありますか? そうでない場合、最初の段落で説明されているデッドロックの状況を防ぐために Hibernate が使用した方法は何ですか?

Hibernate が順序を維持している場合、どうすれば順序を確認または制御できますか? DB での明示的な更新が Hibernate と競合し、デッドロックが発生することは望ましくありません。

アプリケーション内で再現可能なOracleデッドロックが発生しました。コードの最初の調査では明らかな原因は明らかにされていないため、実行中のSQLと、最も重要なこととして、SQLが実行されているトランザクションをログに記録しながら状況を再現したいと思います。

独自のデバッグステートメントを追加し始めましたが、これは車輪の再発明を行っているようで、すでにエラーが発生しやすいことが証明されています（EJBメソッドの1つが「RequiresNew」として定義されていることを最初は見逃していました）

これを行うツールはありますか？私が見た：

• log4jdbcですが、個別のトランザクションをログに記録することをドキュメントから確認できません。さらに、データソースをサポートしていないため、これを回避する必要があります。

• jdbcslog-トランザクションをログに記録するかどうかも明確ではありません

それとも、これを行うためのより明白な方法が欠けていますか？

最初のプロセス:

2 番目のプロセス:

リソース リスト:

表「UserPlanOption には複合 PK (UserId と PlanOptionId) があります。削除するとページ ロックが発生するのはなぜですか?何が起こっているのか理解するのを手伝ってもらえますか?同じクライアントからクエリを送信しますが、それは不可能です.これらは、同じ Web ページにアクセスする異なるクライアントである必要があります.

実際、最初の質問に対する答えはわかっていると思います。範囲を削除するにはページ ロックが必要です。しかし、どうすればこれを回避できますか？

インデックス クエリの結果:

updateとdeleteの実行計画。