何十億もの行をschema1.table1から新しいschema2.table2に移動したいと思います。table2はtable1からリファクタリングされたものです。したがって、それらのテーブル構造は異なります。table1とtable2の両方がパーティション化されていますが、table2は空です。これらのスキーマは両方とも同じOracle DBにあります。このデータ移行を実行するためのパフォーマンス効率の良い方法は何ですか？最後にのみコミットを実行しますか、それとも増分コミットを選択しますか？つまり、数時間かかったジョブの99％を完了した後にデータの移行が失敗したとしましょう。今ロールバックしますか？増分コミットを行う場合、どのように失敗を処理しますか？
回答:
これを並行INSERT APPENDしNOLOGGINGて行うのがこの方法です。すべてのNOLOGGING操作と同様に、完了時にすぐにバックアップを取ります。最初にインデックスを使用不可としてマークし、制約を無効にし、テーブルを変更し、操作を実行してから、制約を再度有効にします。
Appendを使用すると、Oracleは常に現在の最高水準点より上の空き領域を取得するため、セグメント内の領域を再利用するのは効率的ではありませんが、フリーリストやUNDOオーバーヘッドをいじる必要はありません。なんらかの理由で再開する必要がある場合はTRUNCATE、しないでくださいDELETE。
増分コミットに関しては、データのセグメント化方法によって異なりますが、一度に1か月分を移動することは簡単に言えますか（たとえば、パーティションスキームはソースとターゲットで同じですか）。何らかの述語を満たす必要がある場合、明らかに速度が低下することを忘れないでください。操作が論理的に失敗しないことを確認して（たとえば、ソースとターゲットで互換性のないデータ型）、十分なリソースを割り当てて、1つのトランザクションでそれを実行します。幸運を！
パーティションスキームが同じである場合（表1のパーティションaのデータがテーブル2のパーティションaに移動するなど）、複数のセッションに移動し、各セッションに「自分の」パーティションのデータを追加させます。これにより、多くのロックが防止され、速度が最高になります。ハードウェアによっては、HBAカードを首まで埋めることができます。すべてのパーティションのコミット-各パーティションに数行以上を想定している-は問題になりませんし、私は間違いなくそうします。移行中にアプリケーションがダウンしていると仮定すると、フォールバックは単純です。少なくとも2回目の実行が行われる前に、アプリがデータを変更した部分については、アプリを変更せずにtable2のパーティションを切り捨てないでください。
これが役に立てば幸い