DB移行ツールの選び方 — AWS DMS・SCT・Data Pump・GoldenGateをどう使い分けるか

Oracle移行の相談で「DMSでできますよね？」と聞かれるたび、「何を運びたいかによります」と返しています。AWS DMSは強力ですが、名前から誤解されがちなツールでもあります。DMS・SCT・Data Pump・GoldenGate・ZDM——それぞれ守備範囲が違うので、組み合わせを正しく選ぶことが移行計画の要になります。

01まず役割を分ける — DMSは「データ」、SCTは「スキーマ」

AWSの移行ツールは2枚看板です。ここを混同すると計画が狂います。

• AWS SCT（Schema Conversion Tool） — スキーマ・ストアド・ビュー等の「構造とコード」を変換する。異種DB間（Oracle→PostgreSQL等）で主役。事前アセスメントで変換率も出す
• AWS DMS（Database Migration Service） — テーブルの「データ（行）」を移す。同種・異種どちらも対応。CDC（変更データキャプチャ）で無停止に近い切替ができる

02DMS最大の罠 — 索引もFKもシーケンスもSPも運ばない

これがDMSで最も多い誤解です。DMSはレプリケーションに必要な最小限（テーブルと主キー）しか移しません。セカンダリインデックス、外部キー、シーケンス、トリガー、ストアドプロシージャは、デフォルトでは移行対象外です。

「DMSで移したのにアプリが動かない／激遅」の正体はたいていこれで、スキーマ側は別途SCTやネイティブ手段で作る必要があります。しかも移行中は性能のために外部キーや一部インデックスをあえて外し、データ投入後に作り直すのが定石。この「スキーマは別、DMSはデータだけ」を理解していないと、工程の見積もりを丸ごと外します。

03使い分けの早見

• 同種・同程度バージョン・停止時間に余裕 → Oracle Data Pump（古いOracleの記事で詳述）。論理移行の王道
• 同種・停止時間を極小化 → 物理手段（Data Guard/RMAN）や、DMSのCDCで差分を流し続けて短時間カットオーバー
• 異種（Oracle→PostgreSQL等） → SCTでスキーマ・コード変換＋DMSでデータ移行。ただしSCTの変換残りは人手（ストアド移行の記事）
• 異種＋無停止に近い要件・大規模 → SCT＋DMSのCDC、あるいはGoldenGate
• Oracle→Oracleを別環境へ最小停止で → Oracleの移行ツール（ZDM等）も選択肢。内部でData Guard/GoldenGateを使う

04CDCによる「止めない切替」の型

DMSやGoldenGateのCDCは、移行を止めずに進めるための鍵です。流れはこうです。

• ① フルロード — 現行DBの全データを移行先へ一括コピー
• ② 継続レプリケーション（CDC）— コピー中および以後の変更を、移行先へ流し続ける
• ③ カットオーバー — 業務を短時間止め、最後の差分を同期してから切替。停止時間を分〜時間単位に抑えられる

この型はサーバ移行のMGNと発想が同じで、「並走させて、最後だけ止める」ものです。停止許容時間から逆算する考え方は移行の5決定を参照してください。

05ツールは手段、検証が目的

どのツールを選んでも、移行の合否は「移行先で正しく同じデータが、正しく同じ挙動で動くか」の検証で決まります。DMSのデータ検証、件数・チェックサムの突合、そして異種移行ならロジックの再テスト。ツール選定に時間をかけすぎ、検証設計を後回しにするのが典型的な失敗です。ツールは荷物を運ぶだけで、着いた荷物が無事かは別途確かめる必要があります。