翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ステップ 3. AWS SCT レポートの実行
このステップでは、[AWS SCT マルチサーバーアセッサー](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_AssessmentReport.Multiserver.html)を実行するための入力として、[ステップ 2](pl-sql.md) の出力 (CSV ファイル形式) を使用します。マルチサーバーアセッサーへの入力として提供する前に、ログイン認証情報 (ユーザー ID とパスワード）、データベース名、およびデータベースの説明を AWS SCT CSV ファイルに追加する必要があります。 AWS ドキュメント[の例](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_AssessmentReport.Multiserver.html#CHAP_AssessmentReport.Multiserver.Input)に記載されている AWS SCT 形式に従います。
マルチサーバーアセッサーは、CSV ファイルに記載されている各データベーススキーマ AWS SCT に対して実行されます。これにより、各スキーマの変換の複雑さを反映する詳細なレポートが生成されます。この計算は、 が自動的に変換 AWS SCT できるコードオブジェクト、ストレージオブジェクト、構文要素の割合と、移行中に手動で修正する必要があるコードに基づいています。複雑さの値の範囲は 1 (最も複雑でない) から 10 (最も複雑) です。
![\[AWS SCT レポートに基づいてデータベースをフィルタリングするための条件\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/database-refactor-prioritization/images/filter-by-complexity.png)
AWS SCT は、コード変換と移行の労力に基づいて変換の複雑さレベルを指定します。数字の 1 は最低レベルの複雑さを表し、10 は最高レベルの複雑さを表します。変換の複雑さレベルでソートし、2 未満の値をフィルタリングすると、ターゲットデータベースエンジンに移行する候補となるデータベースのリストが生成されます。次の例で説明するように、データベースサイズやオブジェクトの合計数などの他のプロパティを含めて、候補のリストを微調整できます。
## マルチサーバーアセッサーの例
次の例では、 AWS SCT マルチサーバーアセッサーを使用して Oracle および SQL Server データベーススキーマを評価します。評価は、ターゲットデータベースエンジンとして PostgreSQL と MySQL に対して実行されます。
AWS SCT マルチサーバー評価者は、各移行ターゲットの推定複雑さを示す集計レポートを生成します。このレポートは、Amazon Relational Database Service (Amazon RDS) for PostgreSQL または Amazon RDS for MySQL ターゲットエンジンの*列変換の複雑さ*列でソートできます。これにより、コード変換要件、ストレージの複雑さ、構文の複雑さに基づいて、最小限の労力で、またはまったく労力をかけずに、PostgreSQL や MySQL などのオープンソースデータベースエンジンに簡単に移行できるデータベースのリストが提供されます。
次の表は、PostgreSQL や MySQL などのオープンソースデータベースエンジンに移行する初期候補となる SQL Server データベースのサンプルリストを示しています。このテーブルには、[ステップ 2](pl-sql.md) の出力からの*合計オブジェクト*数と*サイズが GB *列で含まれています。
![\[オープンソースデータベースエンジンに移行する早期候補となる SQL Server データベースのサンプル AWS SCT レポート\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/database-refactor-prioritization/images/sql-sct-report.png)
データは*変換の複雑さ*列 (Amazon RDS for PostgreSQL または MySQL の場合) で昇順にソートされます。また、要件に基づいてテーブルを *GB 単位のサイズ*と*合計オブジェクト*で昇順にさらにソートすることもできます。これにより、サイズが小さく、オブジェクトが少なく、変換の複雑さが最も少ないデータベーススキーマのリストが得られます。この表は、Amazon RDS for PostgreSQL と Amazon RDS for MySQL の変換の複雑さが 1 (最小の複雑さ) の SQL Server データベーススキーマのリストを示しています。これらの結果は、これらのスキーマをオープンソースのデータベースエンジンに移行するのに最小限の労力がかかることを示しています AWS。
次の表は、オープンソースの PostgreSQL データベースと MySQL データベースに移行する初期候補となる Oracle データベースの同様のリストを示しています。
![\[オープンソースデータベースエンジンに移行する早期候補となる Oracle データベースのサンプル AWS SCT レポート\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/database-refactor-prioritization/images/oracle-sct-report.png)
Oracle テーブルと SQL Server テーブルには、スキーマ名、データベースバージョン、オブジェクトの合計数、スキーマのサイズ、変換の複雑さなどの重要な情報も表示されます。このデータを使用して、要件に基づいて移行を確認および計画できます。