大手金融機関が、オンプレミスのOracle 19c本番データベース（容量12TB、うち約30%がLOB（Large Object：画像・PDF・音声などの大容量バイナリまたはテキストデータ型）データ）をAmazon Aurora PostgreSQLへ移行している。本番システムは24時間365日稼働しており、承認されたカットオーバーウィンドウは週末の30分間のみである。AWS SCT（Schema Conversion Tool）によるスキーマ変換は完了しているが、Oracle固有の機能を利用する100個のストアドプロシージャは自動変換できず残存している。DMSレプリケーションインスタンスにはc5.4xlargeを使用し、フルロードおよびCDC（Change Data Capture：ソースDBの更新操作をリアルタイムに捕捉してターゲットへ転送するレプリケーション技術）を組み合わせたDMSタスクを設定した。本番2週間前のテスト移行では、フルロードフェーズに36時間を要し、CDCフェーズではレプリケーションラグが最大3時間に達した。このままでは30分のカットオーバーウィンドウを大幅に超過する可能性がある。30分以内にカットオーバーを完了させるために実施すべき2つの対策はどれか。
正解： B. DMSレプリケーションインスタンスをr5.4xlargeなどのメモリ最適化インスタンスタイプに変更し、DMSタスク設定のMax Full Load SubtasksおよびLoad Max File Sizeパラメータを最適化してフルロードの並列処理スループットを向上させる。 D. カットオーバー手順を以下のように定義する：カットオーバーウィンドウ開始時にソースOracleデータベースへの書き込みを停止してread-onlyに設定し、DMSのCDCレプリケーションラグがゼロになるまで待機した後、アプリケーションの接続先をAurora PostgreSQLに切り替えてDNS変更または接続文字列変更でカットオーバーを完了させる。 【インスタンス変更が正解の理由】c5系はコンピューティング最適化型であり大容量LOBデータ処理時にメモリが不足しやすい。r5系メモリ最適化インスタンスへの変更とMax Full Load Subtasks増加により、フルロード時間の短縮とCDCラグの低減が期待できます。 【カットオーバー手順が正解の理由】ソースをread-only化することでCDCラグが確実にゼロへ収束し、ラグゼロ確認後に切り替えることで30分ウィンドウを遵守できます。 選択肢Aは、full LOBモードはDMSがLOBカラムを行単位でメモリに展開するためフルロードがさらに低速化します。 選択肢Cは、100個のストアドプロシージャをAurora PostgreSQL向けに手動書き換えすることは移行完了の前提条件ですが、フルロード時間やCDCレプリケーションラグを削減する対策ではありません。 選択肢Eは、Oracle Data PumpはOracle独自のバイナリ形式であり、Aurora PostgreSQLへの直接インポートはフォーマット非互換のため不可能です。