OCI Database Migration

解決する課題

• オンプレや別環境の Oracle DB を OCI へ移したいが、手作業の移行（エクスポート/インポートの手順管理）が煩雑でミスが起きやすい → 移行を一連のジョブとしてマネージドに管理したい
• 業務を止められないので、移行に伴うダウンタイムを最小化したい → 初期データのコピー後も継続的にレプリケーションして切り替え直前まで差分を追従したい
• 移行前に互換性や前提条件を確認したい → 事前の検証（チェック）で問題を洗い出してから本移行したい
• AWS でいう AWS Database Migration Service（AWS DMS） に相当する、移行専用のマネージド基盤を OCI 側でも使いたい

主要概念と用語

• 移行（Migration）リソース: 1 つの移行作業を表す設定単位。ソース・ターゲット・移行方式などをまとめて保持する
• ソースデータベース接続 / ターゲットデータベース接続: 移行元・移行先の Oracle DB への接続情報を表す登録リソース。接続情報はサービスから参照される
• オンライン移行（Online Migration）: 初期ロードに加えて継続的レプリケーションを行い、切り替え時のダウンタイムを最小化する方式
• オフライン移行（Offline Migration）: 一括コピーのみで継続レプリケーションを伴わない方式。停止可能な範囲が広い場合に用いる
• 初期ロード（Initial Load）: ソースの既存データをターゲットへ最初に転送する工程
• 継続レプリケーション（Change Data Capture, CDC）: 初期ロード後にソースで発生した変更（差分）をターゲットへ追従させる工程。AWS DMS の CDC に相当する
• 検証（Validation / Evaluation）: 本移行の前に前提条件・互換性・接続性を点検する事前チェック
• 切り替え（Switchover / Cutover）: ターゲットがソースに追いついた状態でアプリの接続先を切り替える最終工程
• 移行ジョブ（Job）: 検証や移行の実行単位。フェーズごとに進捗とログを確認できる

仕様・制限・クォータ

• 主たる用途は Oracle Database の OCI への移行で、ターゲットには Autonomous Database や Base Database / Exadata などの OCI 上の Oracle DB を選べる
• 方式は**オフライン（一括）とオンライン（初期ロード＋継続レプリケーション）**があり、許容できるダウンタイムと要件で選ぶ
• 対応するソースのバージョンや構成・前提条件はサービスのサポート範囲に依存する。具体的な対応バージョンや制限は変動するため、利用前に公式ドキュメントで確認すること
• オンライン移行では、ソース側で**継続レプリケーションに必要な設定（補助ログ等の有効化）**が前提となる場合がある
• ソース・ターゲット間のネットワーク到達性が必要で、プライベート接続や中継ホストが要件になることがある
• テナンシ/リージョンごとに**サービス制限（リミット）**があり、必要に応じて引き上げを申請できる

内部の仕組み

• 移行は**フェーズ（段階）**として進行する。一般に「検証（事前チェック）→ 初期ロード → 継続レプリケーション → 切り替え」という流れをとる
• 検証フェーズでソース/ターゲットの接続性・前提条件・互換性を点検し、問題があれば本移行前に把握できる
• 初期ロードで既存データをターゲットへ転送する。データ量に応じて並列度などが内部的に調整される
• オンライン移行では初期ロード完了後も、ソースで発生した変更を**継続レプリケーション（CDC）**でターゲットへ反映し続ける。これにより切り替え直前までソースとターゲットの差を小さく保てる
• ソースとターゲットの差が十分に小さくなった時点で切り替えを行い、アプリの接続先をターゲットへ向ける
• 各フェーズの状態とログはサービス側で管理され、進捗の確認や失敗時の調査に利用できる

設計パターン / ベストプラクティス

• まず検証（事前チェック）を必ず実行し、前提条件と互換性の問題を本移行前に解消する
• 本番移行の前に、ステージング/検証環境で一度通し、所要時間と手順を把握する
• ダウンタイムを抑えたい本番系はオンライン移行を選び、継続レプリケーションで追従させてから切り替える
• ソース・ターゲット間は**プライベートな経路（VCN/プライベートエンドポイントや専用接続）**で結び、移行トラフィックを公開経路に出さない
• 接続に使う資格情報は**OCI Vault（Secrets）**で管理し、平文で扱わない
• 切り替えは業務影響の小さい時間帯に計画し、切り戻し（ロールバック）手順とエンドポイント変更手順を事前に用意する
• 切り替え後はデータ件数・整合性・アプリ動作を検証してから旧環境を停止する

運用・監視

• 移行ジョブのフェーズごとの進捗とログをサービス上で確認し、失敗時は該当フェーズのログから原因を切り分ける
• 接続エラー時は、ソース/ターゲット接続情報・ネットワーク到達性・セキュリティリスト/NSG・資格情報を順に確認する
• オンライン移行中は**継続レプリケーションの追従状況（差分の大きさ）**を確認し、切り替え可能なタイミングを見極める
• イベントや通知と連携し、移行の完了・失敗を検知して運用フローに組み込む
• 切り替え後は旧環境をすぐ削除せず、一定期間は切り戻し可能な状態で保持する

コスト

• 主なコストはターゲット DB の稼働費用と、オンライン移行でソースとターゲットを並走させる期間に左右される
• 並走を長引かせるとその分のコストがかさむため、切り替えを計画的に進める

セキュリティ

• ソース/ターゲットへの接続資格情報は**OCI Vault（Secrets）**で管理し、平文で保持しない
• 移行トラフィックはプライベートな経路を通し、公開経路に出さない設計とする
• 操作権限は IAM ポリシー（グループ/動的グループ＋ポリシー）で最小権限に設計し、移行リソースや接続情報へのアクセスを限定する
• ターゲット DB 側の保存時暗号化・転送時の TLS を有効にし、移行後も暗号化された状態を維持する
• 接続元は**セキュリティリスト / ネットワークセキュリティグループ（NSG）**で必要最小限に絞る

Well-Architected の観点

• 運用（Operational Excellence）: 移行をフェーズ管理されたジョブとして扱い、検証・ログ・通知連携で手順を標準化・自動化する。手作業のエクスポート/インポート運用に比べて再現性と可観測性が高い
• 信頼性（Reliability）: 継続レプリケーションで切り替え直前まで差分を追従し、ダウンタイムを最小化する。切り戻し手順と切り替え後検証を用意することで、移行失敗時の影響を抑えられる

試験で問われるポイント

関連サービス・比較

• ターゲット DB は Autonomous Database や Base Database / Exadata が選択肢になる。スキーマ変換や異種 DB 間の変換が必要な場面では、別途の変換ツールを併用する
• AWS DMS が多様なエンジン間の移行を広くカバーするのに対し、本サービスは Oracle DB の OCI 移行に特化している点が特徴

ハンズオン / CLI例

# ソースデータベースの接続を登録（資格情報は Vault Secret を参照）
oci database-migration connection create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name source-oracle \
  --connection-type ORACLE \
  --database-id "$SOURCE_DB_OCID" \
  --password-secret-id "$VAULT_SECRET_OCID"

# 移行リソースを作成（オンライン移行＝継続レプリケーションあり）
oci database-migration migration create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name oracle-to-adb \
  --source-database-connection-id "$SOURCE_CONNECTION_OCID" \
  --target-database-connection-id "$TARGET_CONNECTION_OCID" \
  --type ONLINE

# 事前検証（前提条件チェック）を実行
oci database-migration migration validate \
  --migration-id "$MIGRATION_OCID"

# 本移行を開始し、ジョブの状態を確認
oci database-migration migration start \
  --migration-id "$MIGRATION_OCID"

oci database-migration job get \
  --job-id "$JOB_OCID"