Oracle PL / SQL スクリプトがあります。約 5,100 万のレジスタを処理し、結果を 5 つの異なるテーブルに書き込みます。
問題は、昨夜プロセスを実行したままにしたことです。どうやら UNDO ログにオーバーフローがあったようです。
特に、このスクリプトのロールバックには関心がありません。失敗した場合は、再度実行できます。
元に戻す/やり直しログの使用を最適化する方法はありますか? それらを書くことを避けるか、それらの書き込みを最小限に抑えますか?
私が理解している限り、APPEND挿入を使用することに加えて、出力テーブルにNOLOGGING属性を設定すると役立ちます（ここで述べたように）。
5,100 万の登録を 1 つのバッチだけで処理しないでください。たとえば、数千の小さなチャンクに分割してみてください。小さなバッチごとに COMMIT を実行すると (ロールバックしないと言うのでとにかく実行します)、やり直し/元に戻すログの使用はコミットされていない部分に対してのみ行われ、オーバーフローを回避できます。
それは本当に問題であり、あなたがしている仕事の量を減らすことです.
システムは特定の範囲のブロックをセグメントから削除する必要があることを記録する必要があるだけなので、ダイレクト パス挿入のテーブル UNDO は常に小さくなります。ただし、インデックスは依然としてかなりの元に戻す必要があります。ダイレクト パス挿入でログを記録しないと、テーブルの REDO が最小限に抑えられます。
さらに、制約とインデックスを無効にすると、挿入が高速化される場合もあります。nologging でインデックスを再構築できます。
「特に、このスクリプトのロールバックには関心がありません。失敗した場合は、もう一度実行できます。」
1 つの質問は、スクリプトを再度実行するために、以前のバックアップに戻る必要があるか、またその準備ができているかということです。つまり、プロセスが 1,000 万行の後で失敗した場合、単純にスクリプトを再実行すると 6,100 万行が挿入されるか、1,000 万行がスキップ/無視されるか、1,000 万行が更新されて 4,100 万行が挿入されます。
また、NOLOGGING 挿入を行う場合は、ジョブの直後に新しいバックアップが必要になる可能性があります。スクリプトの実行中に特定の時点へのポイント イン タイム リカバリを実行すると問題が発生するため、スクリプトの実行中にデータベースで他のアクティビティが発生していることも考慮する必要があります。
PL/SQL スクリプトの記述方法によっては、行ごとの処理ではなく、大きな SQL を使用することで、元に戻す操作を減らすことができる場合があります (たとえば、処理されたブロックへの再アクセスを最小限に抑えることにより)。
UNDO の削減または UNDO の再利用を可能にするコミットの影響を本当に理解していない限り、私の最初の推奨事項は、単純に UNDO テーブルスペースのサイズを増やすことです。もちろん、undo のバケツ負荷を生成した場合、障害がロールバックするのに長い時間がかかるという欠点があります。
隠しパラメーター _disable_logging = true を使用してやり直しを減らすこともできますが、結果のインポートは回復不能になることに注意してください。