3
行ロック競合のトレース、デバッグ、修正
遅くなって、私は多くの行ロックの競合に直面しました。競合するテーブルは特定のテーブルのようです。 これは一般的に何が起こるかです- 開発者1は、Oracle Formsのフロントエンド画面からトランザクションを開始します 開発者2は、同じ画面を使用して別のセッションから別のトランザクションを開始します 〜5分で、フロントエンドが応答しなくなったようです。セッションをチェックすると、行ロックの競合が示されます。誰もが投げる「解決策」は、セッションを終了することです:/ データベース開発者として 行ロックの競合を排除するために何ができますか? ストアドプロシージャのどの行がこれらの行ロックの競合を引き起こしているかを調べることは可能でしょうか このようなコーディングの問題を軽減/回避/排除するための一般的なガイドラインは何でしょうか? この質問が無制限で不十分な情報であると感じた場合は、気軽に編集してください。 問題のテーブルには多くの挿入と更新が行われています。最も忙しいテーブルの1つだと思います。SPはかなり複雑です-簡単にするために-さまざまなテーブルからデータをフェッチし、それを作業テーブルに取り込みます。作業テーブルで多くの算術演算が行われ、作業テーブルの結果が問題のテーブルに挿入/更新されます。 データベースのバージョンは、Oracle Database 10g Enterprise Editionリリース10.2.0.1.0-64ビットです。ロジックのフローは両方のセッションで同じ順序で実行され、トランザクションは長時間(または少なくともそうだと思われます)開いたままにならず、トランザクションのアクティブな実行中にロックが発生します。 更新:テーブルの行数は予想よりも大きく、約310万行です。また、セッションをトレースした後、このテーブルに対するいくつかの更新ステートメントがインデックスを使用していないことがわかりました。なぜそうなのか-よくわかりません。where句で参照される列にはインデックスが付けられます。現在、インデックスを再構築しています。