昨年末に多くのシステムデータの移行を行いましたが、ほとんどのシステムはプラットフォームとバージョンの理由により論理的に移行され、一部のシステムは物理的に移行されましたが、いくつかの経験と経験があるので、皆さんと共有したいと思います。
まず、移行プロセスについて説明します。移行する前に、適切な計画、特に実装計画の手順を作成し、完全なテストを実施します。移行時、テストを通じて計画とプロセスを改善するために、一部のシステムは 4 ～ 5 回テストされました。
物理移行、つまり RMAN バックアップによるリストアとアーカイブの適用 (DD によるコールド移行についてはここでは説明しません) の場合は、ロギングを強制するようにデータベースを設定し、完全バックアップに RMAN を使用することが重要です。その前に、必ず次の操作を実行してください。
そうしないと不良ブロックが発生する可能性があります。
論理移行の場合、job_processes が 0 を超える値に設定される前に、ジョブの次回実行時間とジョブが属するユーザーに注意してください。たとえば、ジョブ定義が以前にインポートされていたが、そのジョブが移行中にすでに実行されていた場合、移行が完了した後も、次回のジョブの時刻は依然として元の時刻のままとなり、ジョブが繰り返し実行される可能性があります。 。さらに、ジョブが IMP 経由でインポートされた後、ジョブが属するユーザーはインポートされたユーザーの名前になります。明らかに、ジョブの元のユーザーはジョブを管理できません。次の SQL を通じて変更できます。
移行前に、テーブル構造、インデックス、ストアド プロシージャ パッケージなどのシステムの構造の変更とリリースを禁止する必要があります。
ストアド プロシージャを含むオブジェクトが exp/imp を使用してインポートされる場合、オブジェクトが元の運用ライブラリと一貫性があるかどうかを確認する必要があります。たとえば、dblink が原因で、ストアド プロシージャは imp の後に作成できず、一部のデータが失われます。これらのストアド プロシージャは使用できませんが、
移行を迅速化するためのヒントをいくつか紹介します。
dblink では、append insert メソッドを使用し、並列処理を使用します。このメソッドは exp/imp よりも高速です。
LONG 型の列の場合、insert..select メソッドは明らかに不可能です。exp/imp を使用できますが、このメソッドは非常に時間がかかります。その理由は、imp 中にテーブルが行ごとに挿入されるためです。sqlplus copy コマンドという別の方法もあります。
ただし、sqlpus copy コマンドは、タイムスタンプおよび LOB 列タイプを持つテーブルをサポートしません。タイムスタンプ型のテーブルがある場合は、exp中にROWID条件を追加することでテーブルを複数に分割し、同時に操作することができます。LOB型のテーブルでも同様です（挿入...選択モードでは、 lob 型の列の場合も行ごとに挿入されます)。このメソッドでは、ダイレクトメソッド exp/imp は使用できないことに注意してください。
表を複数の部分に分割し、同時に操作します。ROWIDを使用するだけでなく、表上の列も使用できます。たとえば、表にはcreated_date列があり、データは増分的に挿入されることが保証されています。この場合、このフィールドを使用してテーブルを異なる範囲に分割し、エクスポートとインポートを同時に行うこともできます。ただし、通常は ROWID を使用した方が効率的です。
もちろん、lob 列を含むテーブルの場合は、exp/imp を使用せずに、複数の挿入メソッドに分割し、上記の方法に従って同時に挿入することができます。
·特に大規模なパーティションテーブルの場合、並列処理を使用すると速度が向上しますが、単一のプロセスに制限されます(DB LINKを介して並列トランザクションを実行することはできません。並列クエリ、つまりinsert..selectのみが並列化されます)。 SELECT 部分) このように処理能力は依然として制限されています。複数の中間テーブルに並行してデータを挿入し、検証なしで交換パーティションを介してパーティションを交換することで、速度が大幅に向上します。
·なぜ並列でパーティションテーブルに直接挿入しないのかと疑問に思う人もいるかもしれません。 もちろん、非ダイレクトパス (追加) メソッドであれば問題ありませんが、この挿入メソッドはパフォーマンスが低くなります。ダイレクト パス方式ではテーブル上にモード=6 (相互排他) の TM ロックが保持され、複数のセッションを同時に挿入することはできません。(更新: 挿入するときにこのステートメントを使用します: insert into tablename Partition (partname) select * from tablename where ....。これはよりシンプルで効率的です。)
·移行中、データは 2 つの部分に分割されます。1 つの部分は履歴テーブルで、2 番目の部分は動的に変化するテーブルです。移行前に、履歴テーブルをインポートし、履歴テーブルにインデックスを構築します。これにより、間違いなく大幅なコスト削減が行われます。移行中の業務 システム中断時間
·移行する前に、不要なデータを消去することを検討してください。
·移行するときは、テーブルにインデックス、制約 (NOT NULL を除く)、トリガーがないことを確認してください。インデックスは、データのインポートが完了した後に再構築する必要があります。インデックスを構築する場合も同様で、複数のプロセスを使用してスクリプトを同時に実行します。インデックスが正常に作成されたら、インデックスの PARALLEL 属性を削除する必要があります。
·制約を作成するときは、最初にCHECK制約、主キー、一意キーを作成し、次に外部キー制約をこの順序で作成する必要があります。制約ステータスは ENABLE NOVALIDATE になり、制約の作成時間が大幅に短縮されます。移行が完了したら、ENABLE VALIDATE に戻すことを検討してください。
· dbms_stats.export_schame_stats および dbms_stats.import_schame_stats を使用して、使用する統計を再収集することなく、元のデータベースに統計情報をインポートします。
友人なら、上記はすべて 9i 用であることがわかりますが、実際、10g 環境や 11g 環境でも依然として多くの参照重要性を持っています。もちろん、これらの手法はデータベースの完全な移行に使用されるだけでなく、個々のテーブルを他のデータベースにコピーする場合にも適用できます。
ここで言及されていないのは、マテリアライズド ビューや高度なレプリケーションとトリガーなどのテクノロジの使用ですが、これらのテクノロジは結局、運用ライブラリを変更する必要があり、運用ライブラリの操作に比較的大きな影響を与えるためです。ダウンタイム要件が特に厳しい場合にのみ使用され、この時間内に移行を完了できない場合にのみ考慮する必要があります。
移行の経験から、完全なプロセスと完全なテストのみが成功を保証できます。ここではいくつかのヒントを紹介します。移行プロセス全体に興味がある場合は、このトピックについてさらに詳しく話し合うことができます。