大手製造業企業がOracle Database 19c（容量8TB）からAmazon Aurora PostgreSQLへの移行を進めています。AWS Schema Conversion Tool（SCT）による評価の結果、以下の課題が判明しました。 【SCT評価結果】 ・ストアドプロシージャ800本のうち480本（60%）は自動変換可能 ・残り320本（40%）はOracle固有機能のため手動対応が必要： - CONNECT BY句（階層クエリ）を使用：150本 → PostgreSQLのWITH RECURSIVE CTEへの書き換えが必要 - DBMS_SCHEDULER（Oracleジョブスケジューラ）を使用：80本 → 代替手段の検討が必要 - UTL_FILE（ファイルI/O操作パッケージ）を使用：50本 → S3統合への変更が必要 - BULK COLLECT / FORALL（バルク処理構文）を使用：40本 → SET-ベースSQLへの書き直しが必要 【追加の複雑性と制約】 ・一部のプロシージャはアプリケーション層から直接呼び出されており、インターフェース（プロシージャ名・引数）の変更は不可 ・カットオーバー前に本番データとの並行稼働による整合性確認が必要 ・許容ダウンタイムは最大4時間（月1回の深夜メンテナンス窓のみ） ・移行期間は6ヶ月（交渉の余地なし） 6ヶ月の期限内でリスクを最小化しながら移行を完了する最も適切なアプローチはどれですか？
正解： SCTの自動変換（60%）をまず開発環境のAurora PostgreSQLに適用する。SCT評価レポートの複雑度スコアと業務影響度に基づき320本を優先順位付けし、CONNECT BY→WITH RECURSIVE CTE、DBMS_SCHEDULER→Amazon EventBridge+Lambda、UTL_FILE→AWS SDK for S3呼び出しへの変換を並行チームで実施する。AWS DMS継続的レプリケーション（CDC：Change Data Capture）でOracle本番データをAuroraへリアルタイム同期し、並行稼働で整合性を確認した後、4時間の窓でカットオーバーする。 SCTの自動変換を先行適用して作業量を60%削減し、評価レポートの複雑度スコアで優先順位付けをすることで、6ヶ月の制約内で効率的に変換を進められます。AWS DMS CDCは本番Oracleの変更をリアルタイムでAuroraに反映するため、カットオーバーまで両環境を並行稼働させながら整合性を確認できます。CONNECT BY→WITH RECURSIVE CTE、DBMS_SCHEDULER→EventBridge+Lambdaへの代替はAWSのデータベース移行ベストプラクティスです。インターフェース（名前・引数）を維持しながら実装のみ変換することも可能です。【Bが誤りの理由】800本ものストアドプロシージャのビジネスロジックを6ヶ月でアプリケーション層に移行することは現実的ではありません。アプリケーション層の大規模書き直しはリスクが高く、テスト工数も膨大になります。【Cが誤りの理由】DBLinkによるクロスデータベース参照はネットワークレイテンシ・セキュリティリスク・パフォーマンス劣化の問題があります。「後続フェーズで段階的に変換」という計画は6ヶ月期限内での完了要件を満たしません。【Dが誤りの理由】RDS for OracleはBYOL（Bring Your Own License）またはライセンス込みモデルでOracleライセンスコストが継続発生します。また「将来の別プロジェクト」という先送りは、Aurora PostgreSQL移行という本来の要件を達成しません。