移行ウィザード (データ / スキーマの移行)

データ / スキーマを移行する。同種か異種か、ダウンタイムの許容度はどれくらいか? 評価 → 移行 → 検証の順に段階的に計画する。まずここで切り替えのリハーサルを行う。

移行元と移行先は何ですか?

同種: 同じデータベースエンジン (例: Oracle 19 → Oracle 23、または PostgreSQL から別のサーバーへ)。異種: 異なるエンジン (例: Oracle → PostgreSQL、MySQL → SQL Server)。異種移行では、はるかに多くの互換性対応 (データ型、関数、PL/SQL) が必要となる。

• 同じエンジン、新しいサーバー/バージョン (同種)
• 異なるエンジンへ (異種)
• 計画段階なので、どう進めるべきか知りたい

ダウンタイムの許容度はどれくらいか?

これにより移行方法が決まる。メンテナンス時間帯がある場合、最も簡単な方法はダンプ / リストアである。ほぼゼロのダウンタイムが求められる場合は、初期データをロードし、継続的なレプリケーション (CDC) で同期を保ち、短時間で切り替える。

• メンテナンス時間帯がある (ダウンタイムは許容できる)
• ほぼゼロのダウンタイムが求められる

スキーマと型の互換性を評価したか?

異種間の移行では、本当の作業はデータのコピーではなく差異の解消である: データ型 (VARCHAR2↔TEXT)、関数 (NVL↔COALESCE)、自動採番の値、PL/SQL ↔ PL/pgSQL、削除された / 異なる機能。

• スキーマ / 型の差異を対応付けた
• まだ評価していない

まず互換性を評価する

移行の前に、ソースとターゲットの差異を対応付ける。この手順を省くと、移行は途中で行き詰まる。

オフライン移行 (ダンプ / リストア)

最も簡単で信頼性の高い同種間の方法: 一貫性のあるバックアップを取得し、ターゲットにロードし、検証し、切り替える。

最小限のダウンタイム (CDC / レプリケーション)

初期データをロードした後、継続的なレプリケーションでターゲットをソースと同期させる。ダウンタイムは短い切り替えの間だけ発生する。

異種間の移行 (別のエンジンへ)

スキーマを変換し、データを移動し、ロジックを適合させ、検証する。段階的に進め、すべてを一度に移行しない。