問題タブ [database-locking]

ユーザー名がデータベースに存在するかどうかを検索し、そのユーザー名を新しい行としてデータベースに挿入できることを保証するにはどうすればよいSELECTですINSERTか?

あたかも存在しない行をロックしているかのようです。ユーザー名"Foo"で存在しない行をロックしたいので、データベースに存在するかどうかを確認し、存在しない場合は中断することなくデータベースに挿入できます。

私は使用LOCK IN SHARE MODEしてFOR UPDATE存在することを知っていますが、私が知る限り、それはすでに存在する行でのみ機能します。この状況で何をすべきかわかりません。

生産者と消費者のメカニズムがあり、生産されたアイテムをデータベースに保存する必要があります。これは要件です。また、いくつかのプロデューサーといくつかのコンシューマーがあり、プロデューサーとコンシューマーのスレッドはいくつかのデータベース テーブルのレコードにアクセスします。ProcessID 列は、どのスレッドがどのレコードにアクセスしているかを判断します。

スレッドは、Windows サービスを介して機能します。

ProcessID が作成される理由は 3 つあります。

• 1- スレッドが異常終了した場合、処理の再開を避けるために processID が使用されます。

• 2- スレッドはデータベースのロックによって同期されます。行ロックのみが取得されることを願っています。すべてのスレッドが ProcessID でマークされたいくつかのレコードにアクセスするため、ブロックされたスレッドが短時間だけ発生する可能性があります。

• 3-エラーをデータベースに記録しているため、どのスレッドがいつ何をしたかを追跡したかった。コンシューマーはアイテムを Web サービスに送信することに注意してください。

インメモリ配列をキューとして使用した場合、パフォーマンスが向上するとは思えません。次の欠点があります。

• コンシューマーがアイテムをデキューするときは、データベース内のレコードをプロセス ID で更新する必要があります。

• プロデューサーはアイテムをデータベースに挿入し、Output stp パラメータを使用してその ID を取得します。次に、アイテムをその ID とともにキューに入れ、データベースからの再読み取りを回避します。これがインメモリ キューの唯一の利点であり、回避します。データベースからアイテムを再読み込みします。レコードが DB に挿入されると、コンシューマー以外は何も更新されないことに注意してください。

• もう1つの問題は、オペレーターが特定のアイテムをデータベースから削除することで消費を停止できると想定していることです。メモリキューで使用すると、この未来が失われます。

• Queue クラスはプライベート オブジェクトをロックする必要があります。キュー メソッドへのアクセスは同期する必要があります。スレッドが枯渇する可能性を複製しているように感じます。スレッドがブロックされて待機する時間を複製しているように感じます。

2 つの質問

1- このデザインに欠けているものはありますか? うまくいくと思いますか？

2- インメモリ キューを使用しないのは良い考えですか?

データベーステーブルに何かを挿入/更新しようとすると、Oracle はテーブル全体をロックしますか、それとも挿入/更新される行のみをロックしますか?

これは、外部構成によって制御できるものですか?

私のアプリは、テーブルを結合する複雑な SQL クエリの結果である 1,000 万行をバッチ処理する必要があります。
結果セットを反復し、反復ごとに 100 を読み取る予定です。
ビジー状態の OLTP 本番 DB でこれを実行し、ロックを回避するには、 READ UNCOMMITTED 分離レベルでクエリを実行することにしました。
DB書き込みの邪魔にならないようにクエリを取得しますか? 行/テーブルのロックを回避しますか?

私の主な懸念は、クエリが他の DB アクティビティをブロックしていることです。その逆についてはあまり関心がありません。

補足:
1. 履歴データを読み取るため、コミットされていないデータに遭遇する可能性は低いです。私なら大丈夫です。
2. 反復プロセスには数時間かかる場合があります。DB 接続は、このプロセスを通じて開いたままになります。
3. このような同時バッチ インスタンスは最大で 2 つです。
4. 行の重複を許容できます。（コミットされていない読み取りの製品による）。
5. ターゲット DB は DB2 ですが、他の DB ベンダーにも適合するソリューションが必要です。
6. スナップショット分離レベルは、サーバー メモリのクリアに役立ちますか?

私はこの問題を抱えており、まだ解決策を見つけていません:

複数のテーブルを持つアプリケーションがあります (ほとんどのアプリケーションと同様)。

2 つのテーブルは次のとおりです。

はTB_POLICY、そのフィールドの一部のハッシュによって分割され、リレーションのTB_REDEMPTION参照によって分割されます。fk_policy

テーブルTB_POLICYには約 50,000 レコードが含まれ、テーブルTB_REDEMPTIONには約 25,000,000 レコードが含まれます。

アプリケーションが1 つのトランザクションで 1 つTB_POLICYのレコードと多数のレコード (約 200 ～ 300 レコード) を挿入するユース ケースがあります。TB_REDEMPTION

TB_REDEMPTIONコードでブレークポイントをマークすると、(両方のテーブルで) すべての挿入の後、トランザクションをコミットする前に、別のデータベース接続から (SQL*Plus から直接でも)別のレコードを挿入する方法がありません。ただ待って！

多くのことを分析した結果、PK_REDEMPTION( の主キー インデックスTB_REDEMPTION) でロックが発生していることがわかりました。

このロックを防ぐにはどうすればよいですか? Web を検索しましたが、挿入中のインデックス ロックに関する情報は見つかりませんでした。

このアプリケーションは Web ベースであり、同じユース ケースを使用する同時ユーザーが多数存在し、ユーザーが主キー インデックスをロックすると、他のユーザーのジョブが妨げられ、アプリケーションのパフォーマンスが非常に低下します。

もう1点、アプリケーションはSpring/Hibernateで開発されているので、トランザクション管理はSpringで行い、DML文はHibernateで作成します。また、Oracle 11g を使用しています。

長い間、以下の選択クエリを使用しています。しかし、今日、データベースに多くのロックがかかっています。

選択クエリによるロックを解決する方法を教えてください。

テーブルのサイズは 300kb と非常に小さいです。

テーブルを最適化しましたが、うまくいきませんでした

以下からクエリ情報とテーブル構造。

プランの説明:

Rails では複数のサーバーで同時実行の問題が発生する可能性があることに気付き、モデルを常にロックさせたいと考えています。データの整合性を強制する一意の制約と同様に、これはRailsで可能ですか? それとも、注意深いプログラミングが必要なだけですか?

ターミナル 1

第二ターミナル、寝てる間に

DB 開始

実行後

ターミナル 1

ターミナル 2

DBエンド

その他の例

http://rhnh.net/2010/06/30/acts-as-list-will-break-in-production