テーブルエラーを変更する原因と解決策は何ですか？

変換テーブルエラーは、設計上の欠陥または問題のあるクエリによって引き起こされることを理解しています。

最近、古いクエリが実稼働環境に導入され、変更テーブルエラーがスローされました。DBAが問題を解決しましたが、方法はわかりません。

変換テーブルエラーの正確な原因は何ですか？DBAはどのように問題を修正しましたか？

変換テーブルエラーの最も可能性の高い原因は、トリガーの誤用です。典型的な例を次に示します。

1. テーブルAに行を挿入します
2. テーブルAのトリガー（行ごと）がテーブルAでクエリを実行します。たとえば、サマリー列を計算します。
3. OracleがORA-04091をスローします。テーブルAが変化しています。トリガー/関数がそれを認識しない場合があります

これは予想される正常な動作です。Oracleは次のことを保証するため、ユーザーを保護します。

• （i）各ステートメントはアトミックである（つまり、失敗するか完全に成功する）
• （ii）各ステートメントがデータの一貫したビューを見る

ほとんどの場合、この種のトリガーを作成すると、クエリ（2）で（1）に挿入された行が表示されることが予想されます。更新はまだ終了していないため、上記の両方の点と矛盾します（挿入する行がさらにある可能性があります）。

Oracle は、ステートメントの開始直前の時点と一致する結果を返すことができますが、このロジックを実装しようとするほとんどの例から、人々は複数行のステートメントを一連の連続したステップと見なし、ステートメント[2]で、前のステップで行われた変更を確認します。Oracleは期待される結果を返すことができないため、エラーをスローします。

詳細については、Ask Tomの「mutating table」を参照してください。

私が疑うように、変化するテーブルエラーの原因がトリガーである場合、エラーを回避する1つの方法は、トリガーからプロシージャにロジックを移動することです。

変異の表では、文が火災とそのトリガー参照トリガーを発生させたテーブルにトリガが発生したときに発生します。このような問題を回避する最善の方法は、トリガーを使用しないことですが、DBAはそのために時間をかけなかったと思われます。彼は次のいずれかを行うことができました。

• トリガーを後トリガーに変更しました。
• 行レベルトリガーからステートメントレベルトリガーに変更しました。
• 複合トリガーに変換します。
• 行と文レベルのトリガーの組み合わせを使用するようにトリガーの構造を変更しました。
• トリガーをコミットで自律化しました。