ある企業が AWS への移行を進めており、移行後にアプリケーションのパフォーマンスを最適化したいと考えています。現在、オンプレミスのアプリケーションは Oracle 19c データベース（100TB）で稼働しており、移行先として Amazon Aurora PostgreSQL を検討しています。Oracle 固有の機能（パッケージ、シノニム、CONNECT BY 句）を多用しており、自動変換できないコードがどの程度あるかを事前に把握したいと考えています。最も適切なアプローチはどれですか？
- A. PostgreSQL の互換性リストを確認し、使用している Oracle 機能が対応しているかを手動でチェックする
- B. Aurora PostgreSQL の評価版を作成し、実際に Oracle からデータを移行してエラーを確認する
- C. AWS Schema Conversion Tool（SCT）を Oracle 19c データベースに接続し、スキーマとコードの変換評価レポートを生成する。SCT は自動変換可能なオブジェクトと手動変換が必要なオブジェクト（ストアドプロシージャ、パッケージ、トリガー等）を識別し、難易度スコアと変換工数の推定を提供する
- D. 開発チームが Oracle のコードを手動で PostgreSQL に変換し、変換工数を見積もる
解答と解説を見る
正解: C
AWS SCT は移行前の評価フェーズに設計されており、ソースデータベースのスキーマとコードをスキャンして、ターゲットエンジン（Aurora PostgreSQL）への変換可能性を詳細にレポートします。自動変換率、手動変換が必要なオブジェクトのリスト、変換複雑度のスコアを生成し、プロジェクト計画の精度を大幅に向上させます。Oracle 固有の構文（CONNECT BY、パッケージ等）の評価も含まれます。 D: 手動評価は時間がかかり、網羅性と精度がツールに劣ります。100TB の大規模データベースでの手動評価は非現実的です。 B: 実際に移行を試みてエラーを確認する方法は、移行プロジェクトのリスクを高め、コストも発生します。評価フェーズでは SCT のような非破壊的なアセスメントが適切です。 A: PostgreSQL の互換性リストの手動確認は概要の把握には有用ですが、実際のコードの変換可能性の詳細評価には不十分です。