Section 3 — 応用編：高度な移行戦略と異種DB変換
🔧 対象: 中堅以上 ゴール: 異種移行・DDL変換・複雑な制約条件下での移行戦略を選定できる。
1. 異種DB移行のディープダイブ
Oracle → PostgreSQL/AlloyDB の典型課題
| 課題 | 対応 |
|---|---|
| データ型の差 | NUMBER → NUMERIC, DATE → TIMESTAMP, CLOB → TEXT |
| ストアドプロシージャ | PL/SQL → PL/pgSQL 変換、または Lambda アーキへ移行 |
| シーケンス | Oracle SEQUENCE → PostgreSQL SEQUENCE（互換性高） |
| DBMS_* 関数 | 代替関数で書き換え |
| マテリアライズドビュー | PostgreSQL のMV へ書き換え（更新仕様差に注意） |
| パーティショニング | Range/List パーティショニングの構文差 |
| ROWID | 概念なし → 別主キーで代替 |
主な変換ツール
| ツール | 用途 | 特徴 |
|---|---|---|
| DMS Migration Assistant | スキーマ変換・データ移行 | Google 公式、対応拡大中 |
| Ora2Pg | Oracle → PostgreSQL | OSS、長年の実績、スクリプト多数 |
| Striim | リアルタイム CDC、異種 | 商用、複雑な変換対応 |
| Database Migration Assessment (DMA) | 移行前評価 | Google 公式、変換難易度を自動評価 |
SQL Server → PostgreSQL の典型課題
| 課題 | 対応 |
|---|---|
| T-SQL → PL/pgSQL | ストアド書き換え、特に DECLARE / CURSOR 構文差 |
| IDENTITY → SERIAL/GENERATED | 自動採番列の構文差 |
| NVARCHAR → TEXT/VARCHAR | 文字列型の整理 |
| Linked Server | PostgreSQL FDW (Foreign Data Wrapper) で代替 |
2. DDL/DML の差異とリスク評価
DDL 変換の自動化レベル
| 変換ツール | レベル | 何ができる |
|---|---|---|
| DMS Assistant | 高 | 大半のテーブル・インデックス自動変換 |
| Ora2Pg | 高 | スキーマ・データ・PL/SQL の多くを変換 |
| 手動 | - | カスタムドメイン型・複雑なトリガーは手動 |
自動変換不可な要素 → 必ず手動対応
- カスタムドメイン型
- 複雑なストアドプロシージャ
- DBMS パッケージ依存処理
- DB リンク（Linked Server）
3. ゼロダウンタイム移行の完全フロー
Step-by-Step（業務クリティカル想定）
Phase 0: 準備
├ ソース DB のバックアップ
├ ターゲット DB の構築（HA構成）
├ ネットワーク確立（VPN/Interconnect）
├ DMS ジョブ準備（Continuous モード）
└ アプリ側で「読み取り用接続」「書き込み用接続」を分離
Phase 1: 初期移行
├ DMS スナップショット取得（数時間〜）
├ CDC 開始（バイナリログ／WAL から継続適用）
└ レプリ遅延を継続監視（< 5秒目標）
Phase 2: テスト
├ ステージング環境でカットオーバー リハーサル
├ 整合性チェック（行数、サンプル、ハッシュ）
└ アプリの読み取りを新DBに向けてテスト
Phase 3: カットオーバー（実行）
├ アプリの書き込みを一時停止（数秒）
├ 残りのバイナリログが適用完了まで待機
├ 新DBを Primary に昇格 (DMS Promote)
├ アプリの接続先を新DBへ切替
└ 書き込み再開
Phase 4: 後処理
├ リバースレプリケーション開始（新 → 旧）
├ 監視強化（CPU/接続/エラー）
├ 数日〜数週間の様子見
└ 問題なければ旧DB廃止
カットオーバー時のチェックリスト
- レプリ遅延 < 5秒
- アプリの書き込みフラグを停止モードに
- DMS が「ready to promote」状態
- DNS / 接続文字列の変更準備完了
- ロールバック手順を関係者で共有
- 監視・アラート画面をリアルタイム表示
4. ダウンタイム別の移行手段
ダウンタイム別の判断
| 許容ダウンタイム | 推奨手段 | 注意点 |
|---|---|---|
| ゼロ | DMS Continuous + リバースレプリ | 最も複雑、リスク高、コスト高 |
| 数秒〜数分 | DMS Continuous（リバースなし） | 標準、業務クリティカル |
| 30分〜数時間 | DMS One-time または mysqldump/pg_dump | 夜間メンテで実施可 |
| 数日許容 | Transfer Appliance | PB級・帯域不足の場合 |
コストと複雑度のトレードオフ
高
コスト ↑
複雑度 │ DMS Continuous + リバースレプリ
│ ↘
│ DMS Continuous
│ ↘
│ DMS One-time
│ ↘
│ mysqldump + リストア
│ ↘
低 ────────────────────────→
高 ダウンタイム許容度 低
5. リバースレプリケーションのパターン
パターン A: 同種 DB の場合（DMS で逆方向）
新 Primary → DMS Continuous → 旧 DB（リードレプリカ的）
- DMS のジョブを 逆向き に作る
- 数日〜数週間運用後、問題なければ停止
パターン B: 異種 DB の場合（CDC ツール経由）
新 PostgreSQL → Datastream → BigQuery → 旧 Oracle ← Striim
- Striim や手動の CDC で実現
- 複雑度高、テスト必須
リバースレプリケーションが不要なケース
- ダウンタイムが許容される
- ロールバックの代替（バックアップからの復旧）で十分
- 旧 DB を残し続けるコストが許容できない
6. 複雑なシナリオの判断
シナリオ 1: 「Oracle Exadata から AlloyDB へ。ダウンタイムは 1 時間以内」
- ステップ1: DMA で評価 → 変換難易度確認
- ステップ2: Ora2Pg or DMS Migration Assistant で スキーマ変換
- ステップ3: DMS（異種モード） で初期 + CDC
- ステップ4: カットオーバー（夜間 1時間枠）
- ステップ5: 監視 + 旧 DB を 30 日保持
シナリオ 2: 「MongoDB → Firestore (MongoDB-compatible)」
- ステップ1: ターゲット Firestore 構築
- ステップ2:
mongodump→ Cloud Storage →mongorestore - ステップ3: アプリの接続先を Firestore へ
- ステップ4: 整合性確認
シナリオ 3: 「マルチクラウド: AWS RDS MySQL → Cloud SQL MySQL」
- ステップ1: AWS RDS でバイナリログ有効化
- ステップ2: VPN または Cloud Interconnect 接続
- ステップ3: DMS Continuous で移行
- ステップ4: カットオーバー + 監視
シナリオ 4: 「Oracle on-prem → Bare Metal Solution」
- ステップ1: BMS 物理サーバープロビジョニング
- ステップ2: 専用線（Cloud Interconnect Partner Edition）構築
- ステップ3: Oracle Data Pump で論理移行 or RMAN で物理移行
- ステップ4: アプリ接続先切替
7. DMS の高度な機能
Migration Job のフィルタリング
- 特定テーブルだけ移行（CDC 含む）
- スキーマフィルタリング
DMS の連続レプリケーション監視
- 遅延（lag） メトリクス監視
- 遅延が一定以上で アラート 設定
- ソース DB の binary log 保持期間が遅延より長いことを保証
DMS の制約と回避策
| 制約 | 回避策 |
|---|---|
| 一部の DDL は CDC で同期されない | カットオーバー前に DDL 凍結 |
| 大型 BLOB の遅延が大きい | LOB を別経路で同期 |
| ストアドプロシージャ非対応 | カットオーバー前に手動移行 |
| トリガー非対応 | 手動移行 |
8. 移行後の検証
整合性検証の階層
行数チェック （最も基本）
SELECT COUNT(*) FROM table; -- 旧 vs 新ハッシュチェック （より厳密）
SELECT MD5(STRING_AGG(column1::text, '' ORDER BY id)) FROM table;サンプリングチェック
- ランダム n 行を抽出して比較
- データ型の差（NULL/空文字）に注意
アプリ E2E テスト
- 主要な業務フローを実行
- 性能劣化の確認
性能検証
- Query Insights で旧 vs 新の top SQL の応答時間比較
- 必要なら インデックス追加 / マシンサイズ調整
9. 移行プロジェクトの組織体制
試験では直接問われないが、シナリオ問題で「失敗要因」「成功要因」が出る。
推奨体制
- プロジェクトマネージャ: スケジュール・ステークホルダー調整
- DB エンジニア: 移行ツール操作、整合性確認
- アプリエンジニア: 接続先変更、テスト、ロールバック
- インフラエンジニア: ネットワーク、IAM、監視
- QA: 整合性・E2E テスト
試験で問われる「失敗要因」
- 事前テスト不足 → リハーサルなし
- ロールバック計画なし
- アプリ側の互換性確認不足
- 関係者の連絡体制が曖昧
- 監視・アラート不足
10. このセクションのチェックリスト
- Oracle → PostgreSQL の典型課題を 5 つ挙げられる
- DMS Migration Assistant / Ora2Pg / Striim の使い分けができる
- ゼロダウンタイム移行の 4 フェーズを言える
- カットオーバー時のチェックリストが頭に入っている
- ダウンタイム別の移行手段を即答できる
- リバースレプリケーションのパターンを 2 つ説明できる
- BMS への Oracle 移行手順を言える
- DMS の連続レプリケーション監視ポイントを言える
- 整合性検証の 4 階層を説明できる
- 移行プロジェクトの典型的な失敗要因を言える