Oracle 10gをホストするAIXサーバー上でNohupとして並行して実行される一連のスクリプトがあります。これらのスクリプトは他の誰かによって作成され、同時に実行されることを意図しています。すべてのスクリプトがテーブルの更新を実行しています。エラーが発生しています
ORA-00060:リソースの待機中にデッドロックが検出されました
私がこれをグーグルで探したとき、私は見つけました http://www.dba-Oracle.com/t_deadly_perpetual_embrace_locks.htm
スクリプトは同じテーブルで同時に更新を実行しますが、WHERE
句によって決定されるテーブルの異なるレコードで更新を実行し、それらの間でレコードが重複することはありません。
だから、これはエラーを引き起こしたでしょうか?.
このエラーは、テーブルで更新が実行される場所に関係なく発生しますか?.
テーブルの同時更新を常に避けるべきですか?.
奇妙なことに、私はNohup.outログにもPL/SQL successfully completed
上記の引用されたエラーの後。
これは、Oracleがデッドロックから回復し、更新を正常に完了したことを意味しますか、またはこれらのスクリプトを連続して再実行する必要がありますか?どんな助けも歓迎します。
前もって感謝します。
行ロックだけでなく、デッドロックを取得することもできます。 this を参照してください。スクリプトは、インデックスブロックなどの他のリソースと競合する場合があります。
私はこれまで、並列処理を設計して、互いに近いブロックに影響を与える可能性が低いワークロードの部分で異なるインスタンスが動作するようにしています。たとえば、大きなテーブルの更新では、MOD(n,10)
のようなものを使用してパラレルスレーブをセットアップする代わりに、TRUNC(n/10)
を使用します。つまり、各スレーブは連続したセットで動作しますデータの。
もちろん、並列処理のためにジョブを分割するより良い方法があります。 DBMS_PARALLEL_EXECUTE 。
「PL/SQLが正常に完了した」理由がわからない、おそらくスクリプトが例外を処理しているのでしょうか?
私は最近、同様の問題に苦労していました。データベースには外部キーのインデックスが欠落していることが判明しました。これにより、Oracleは必要以上に多くのレコードをロックし、高い同時実行性の間にすぐにデッドロックを引き起こしました。
デッドロックの修正方法に関する多くの詳細、提案、および詳細を含む優れた記事を次に示します。 http://www.oratechinfo.co.uk/deadlocks.html#unindex_fk
私もこの問題に遭遇しました。私は実際に何が起こっていたの技術的な詳細を知りません。ただし、 私の状況では 、根本的な原因は、Oracleデータベースにカスケード削除セットアップがあり、JPA/Hibernateコードもカスケード削除呼び出しを実行しようとしていたことです。したがって、私のアドバイスは、何が起きているのかを正確に把握することです。
IF-ELSE
ブロック内に複数のUPDATE
ステートメントがある関数をテストしていました。
考えられるすべてのパスをテストしていたため、関数を再度実行する前に、毎回 'manual' UPDATE
ステートメントを使用してテーブルを以前の値にリセットしました。
これらのUPDATE
ステートメントの直後に問題が発生することに気付きました。
テーブルのリセットに使用したUPDATE
ステートメントの後にCOMMIT;
を追加し、問題を解決しました。
そのため、問題は関数自体ではありませんでした...