大手金融機関がオンプレミスで稼働するOracle Database 19c（8TB、RAC（Real Application Clusters）構成）をAmazon Aurora PostgreSQL Compatible Editionへ移行する計画を立てています。このデータベースには数百のPL/SQLストアドプロシージャ・パッケージ・シーケンス・マテリアライズドビューが含まれ、一部はOracle固有機能（DBMS_SCHEDULER、Oracle Spatial）を使用しています。 ビジネス要件： ・本番カットオーバー時のダウンタイムは最大2時間以内 ・移行期間中も夜間バッチ処理（3時間）は継続する必要がある ・移行完了後6ヶ月間のロールバック手順維持（規制要件） 追加制約： ・ソースDBへのDDL変更権限なし ・Supplemental Loggingの有効化は可能 ・DBA担当者は2名のみ ・サードパーティツールのインストールは禁止 このシナリオで最も適切な移行アプローチはどれですか？
AWS SCTで変換レポートを生成し、変換不可のOracle固有オブジェクト（DBMS_SCHEDULER、Oracle Spatial等）を事前にリスト化する。変換可能なオブジェクトはSCTで自動変換し、変換不可のオブジェクトはAWSプロフェッショナルサービスと協力して手動で書き換える計画を立てた上で、DMS Full Load + CDCで移行を実施する。バッチ処理時間帯を避けてCDCラグを最小化し、カットオーバー前にAurora PostgreSQLで負荷テストを実施する。 SCT+DMS(CDC)が基本方針ですが、Oracle固有機能（DBMS_SCHEDULER、Oracle Spatial）はSCTで自動変換できないため、事前に変換レポートで変換不可オブジェクトを特定し手動書き換え計画を立てることが必須です。 選択肢A:事前特定プロセスを省略しており、移行中に変換不可オブジェクトが発覚した場合のリスクが高くなります。 選択肢B:Oracle Data Pumpによる全データエクスポートと手動インポートでは、最大2時間のダウンタイム制約に対して8TBのデータ転送と差分手動適用は現実的ではありません。 選択肢C:RDS for OracleへのリフトアンドシフトはOracle固有機能を維持できますが、Aurora PostgreSQLへの移行が別フェーズとなりコスト・工数・リスクが増大します。