翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 移行プロジェクトのスキーマ変換設定の指定
<a name="schema-conversion-settings"></a>

移行プロジェクトを作成した後、DMS Schema Conversion でコンバージョン設定を指定できます。スキーマ変換設定を設定すると、変換済みのコードのパフォーマンスが向上します。

**コンバージョン設定を編集するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。

1. **[移行プロジェクト]** を選択します。**[移行プロジェクト]** ページが開きます。

1. 移行プロジェクトを選択します。**[スキーマ変換]** 選択して、**[スキーマ変換を起動]** をクリックします。

1. **[設定]** を選択します。**[設定]** ページが開きます。

1. **[変換]** セクションで、設定を変更します。

1. **[適用]**、**[スキーマ変換]** の順に選択します。

すべての変換ペアについて、アクション項目を含め、変換済みのコードのコメント数を制限できます。変換済みのコード内のコメント数を制限するには、移行プロジェクトのコンバージョン設定を開きます。

**[Comments in converted SQL code]** で、アクション項目の重大度レベルを選択します。DMS Schema Conversion は、選択した重大度以上のアクション項目について、変換済みのコードにコメントを追加します。例えば、変換済みのコード内のコメント数を最小限に抑えるには、**[エラーのみ]** を選択します。

変換済みのコードにすべてのアクション項目のコメントを含めるには、**[すべてのメッセージ]** を選択します。

その他のコンバージョン設定は、ソースデータベースとターゲットデータベースのペアにより異なります。

**Topics**
+ [Oracle から MySQL への変換設定を理解する](schema-conversion-oracle-mysql.md)
+ [Oracle から PostgreSQL への変換設定を理解する](schema-conversion-oracle-postgresql.md)
+ [SQL Server から MySQL への変換設定を理解する](schema-conversion-sql-server-mysql.md)
+ [SQL Server から PostgreSQL への変換設定を理解する](schema-conversion-sql-server-postgresql.md)
+ [PostgreSQL から MySQL への変換設定を理解する](schema-conversion-postgresql-mysql.md)
+ [IBM Db2 for LUW から Amazon RDS for PostgreSQL への変換設定について](schema-conversion-db2-luw-postgresql.md)
+ [IBM Db2 for z/OS から Amazon RDS for Db2 への変換設定について](schema-conversion-db2-zos-db2.md)
+ [IBM Db2 for z/OS から Amazon RDS for PostgreSQL への変換設定について](schema-conversion-db2-zos-postgresql.md)
+ [SAP ASE (Sybase ASE) から PostgreSQL への変換設定について](schema-conversion--sybase-ASE.md)

# Oracle から MySQL への変換設定を理解する
<a name="schema-conversion-oracle-mysql"></a>

DMS Schema Conversion の Oracle から MySQL へのコンバージョン設定は、次のとおりです。
+ ソースの Oracle データベースでは、`ROWID` 疑似列を使用できるが、MySQL は同様の機能をサポートしていない。DMS Schema Conversion は、変換したコードで `ROWID` 疑似列をエミュレートできる。このためには、**[行 ID を生成]** オプションをオンにする。

  ソースの Oracle コードが `ROWID` 疑似列を使用していない場合は、**[行 ID を生成]** オプションをオフにする。この場合、変換したコードの処理が迅速化する。
+ ソースの Oracle のコードには、MySQL ではサポートされないパラメータを使用する `TO_CHAR` 関数、`TO_DATE` 関数、`TO_NUMBER` 関数が使用されている場合がある。デフォルトでは、DMS Schema Conversion は変換したコード内のこのようなパラメータの使用をエミュレートする。

  ソースの Oracle コードに MySQL でサポートされないパラメータがない場合は、MySQL のネイティブの `TO_CHAR` 関数、`TO_DATE` 関数、`TO_NUMBER` 関数を使用できる。この場合、変換したコードの処理が迅速化する。これには、次の値を選択する。
  + **Use a native MySQL TO\$1CHAR function**
  + **Use a native MySQL TO\$1DATE function**
  + **Use a native MySQL TO\$1NUMBER function**
+ データベースとアプリケーションは別々のタイムゾーンで実行できる。デフォルトでは、DMS Schema Conversion は変換したコードのタイムゾーンをエミュレートする。ただし、データベースとアプリケーションが同じタイムゾーンを使用している場合は、このエミュレーションは必要ない。この場合、**[Improve the performance of the converted code where the database and applications use the same time zone]** を選択する。

# Oracle から PostgreSQL への変換設定を理解する
<a name="schema-conversion-oracle-postgresql"></a>

DMS Schema Conversion の Oracle から PostgreSQL へのコンバージョン設定は、次のとおりです。
+ 生成 AI を使用して該当するデータベースオブジェクトを変換するには、**[生成 AI]** 設定を有効にする。生成 AI を使用して正常に変換されたオブジェクトは、変換でデータ内のパターンに基づいて予測を生成する機械学習モデルが使用されることを示す**アクション項目 5444** で明確に識別できる。詳細については、「[生成 AI を使用したデータベースオブジェクトの変換](schema-conversion-convert.databaseobjects.md)」を参照してください。
  + 最新バージョンだけでなく、サポートされているさまざまなバージョンのターゲットデータベースのスキーマを変換できる。バージョンを指定するには、**[ターゲットエンジンバージョン]** 設定を使用する。使用可能な変換オプションは、選択したエンジンバージョンによって異なる。現在、PostgreSQL バージョン 14 および 15 がサポートされている (設定は同じ)。この設定で指定されたバージョンとは異なるターゲットエンジンバージョンをスキーマ変換中に使用すると、ターゲットへの適用オペレーションの実行時に互換性の問題やエラーが発生する可能性がある。
+ AWS DMS は、Oracle マテリアライズドビューを PostgreSQL のテーブルまたはマテリアライズドビューに変換できます。**[マテリアライズドビュー]** で、ソースのマテリアライズドビューの変換方法を選択する。
+ ソースの Oracle データベースでは、`ROWID` 疑似列を使用できるが、PostgreSQL は同様の機能をサポートしていない。DMS Schema Conversion は、`bigint` または `character varying` データ型を使用して、変換したコードで `ROWID` 疑似列をエミュレートできる。このためには、**[行 ID]** で **[Use the bigint data type to emulate the ROWID pseudocolumn]** または **[Use the character varying data type to emulate the ROWID pseudocolumn]** を選択する。
  + NUMBER データ型を最適な数値データ型に変換するには、精度とスケールに応じて、NUMBER データ型の列に [Use the optimized data type mapping] を選択する。
+ ソースの Oracle コードが `ROWID` 疑似列を使用していない場合は、**[Don't generate]** を選択する。この場合、変換したコードの処理が迅速化する。
+ ソースの Oracle のコードには、PostgreSQL ではサポートされないパラメータを使用する `TO_CHAR` 関数、`TO_DATE` 関数、`TO_NUMBER` 関数が使用されている場合がある。デフォルトでは、DMS Schema Conversion は変換したコード内のこのようなパラメータの使用をエミュレートする。

  ソースの Oracle コードに PostgreSQL でサポートされないパラメータがない場合は、PostgreSQL のネイティブの `TO_CHAR` 関数、`TO_DATE` 関数、`TO_NUMBER` 関数を使用できる。この場合、変換したコードの処理が迅速化する。これには、次の値を選択する。
  + **Use a native PostgreSQL TO\$1CHAR function**
  + **Use a native PostgreSQL TO\$1DATE function**
  + **Use a native PostgreSQL TO\$1NUMBER function**
+ データベースとアプリケーションは別々のタイムゾーンで実行できる。デフォルトでは、DMS Schema Conversion は変換したコードのタイムゾーンをエミュレートする。ただし、データベースとアプリケーションが同じタイムゾーンを使用している場合は、このエミュレーションは必要ない。この場合、**[Improve the performance of the converted code where the database and applications use the same time zone]** を選択する。
+ 変換したコードで引き続きシーケンスを使用するには、**[Populate converted sequences with the last value generated on the source side]** を選択する。
+ 場合によっては、ソース Oracle で、`NUMBER` データ型のプライマリキー列または外部キー列に整数値のみを格納していることがある。このような場合、 AWS DMS はこれらの列を `BIGINT` データ型に変換できます。このアプローチを採用すると、変換したコードのパフォーマンスが向上する。これを行うには、**[Convert primary and foreign key columns of the NUMBER data type to the BIGINT data type]** を選択する。データの損失を避けるため、ソースのこれらの列に浮動小数点値が含まれていないことを確認する。
+ ソースコード内の非アクティブ化されたトリガーと制約をスキップするには、**[アクティブなトリガーと制約のみを変換]** を選択する。
+ DMS Schema Conversion を使用すると、動的 SQL として呼び出される文字列変数を変換できる。このような文字列変数の値は、データベースコードで変更できる。が AWS DMS 常にこの文字列変数の最新の値を変換するようにするには、**「呼び出されたルーチンで作成された動的 SQL コードを変換する**」を選択します。
+ PostgreSQL バージョン 10 以前のバージョンでは、プロシージャをサポートしていない。PostgreSQL でのプロシージャの使用に慣れていない場合は、Oracle プロシージャを PostgreSQL 関数に変換 AWS DMS できます。このためには、**[プロシージャを関数に変換]** を選択する。
+ 発生したアクション項目に関する追加情報を確認するには、拡張パックに特定の関数を追加する。このためには、**[Add extension pack functions that raise user-defined exceptions]** を選択する。次に、ユーザー定義の例外を発生させる重大度レベルを選択する。ソースデータベースオブジェクトを変換した後は、必ず拡張パックスキーマを適用する。拡張パックの詳細については、「[拡張パックの使用](extension-pack.md)」を参照する。
+ ソースの Oracle データベースでは、自動的に生成された名前を使用した制約が使用されている場合がある。ソースコードでこのような名前を使用している場合は、必ず **[Keep the names of system generated constraints]** を選択する。ソースコードでこのような制約が使用されていても、名前は使用されていない場合は、このオプションをオフにすると変換速度が向上する。
+ ソースデータベースとターゲットデータベースが別々のタイムゾーンで実行されている場合、Oracle の `SYSDATE` 組み込み関数をエミュレートする関数がソース関数とは異なる値を返す。ソース関数とターゲット関数が同じ値を返すようにするには、**[ソースデータベースのタイムゾーンを設定]** を選択する。
+ 変換したコードでは、orafce 拡張機能の関数を使用できる。このためには、**[Oracle 組み込みルーチン]** で使用する関数を選択する。orafce についての詳細は、GitHub で「[orafce](https://github.com/orafce/orafce)」を参照してください。

# SQL Server から MySQL への変換設定を理解する
<a name="schema-conversion-sql-server-mysql"></a>

DMS Schema Conversion の SQL Server から MySQL へのコンバージョン設定は、次のとおりです。
+ ソースの SQL Server データベースは、`EXEC` の出力をテーブルに保存できる。DMS Schema Conversion は、一時テーブルと、この機能をエミュレートする追加のプロシージャが作成する。このエミュレーションを使用するには、 **[Create additional routines to handle open datasets]** を選択する。

# SQL Server から PostgreSQL への変換設定を理解する
<a name="schema-conversion-sql-server-postgresql"></a>

DMS Schema Conversion の SQL Server から PostgreSQL へのコンバージョン設定は、次のとおりです。
+ 生成 AI を使用して該当するデータベースオブジェクトを変換するには、**[生成 AI]** 設定を有効にする。生成 AI を使用して正常に変換されたオブジェクトは、変換でデータ内のパターンに基づいて予測を生成する機械学習モデルが使用されることを示す**アクション項目 7744** で明確に識別できる。詳細については、「[生成 AI を使用したデータベースオブジェクトの変換](schema-conversion-convert.databaseobjects.md)」を参照してください。
+ SQL Server では、複数のテーブルで同じインデックス名を使用できるが、PostgreSQL では、スキーマで使用するインデックス名がすべて一意である必要がある。DMS Schema Conversion がすべてのインデックスのために固有の名前を生成するようにするには、**[インデックスの一意の名前を生成]** を選択する。
+ PostgreSQL バージョン 10 以前のバージョンでは、プロシージャをサポートしていない。PostgreSQL でのプロシージャの使用に慣れていない場合は、SQL Server プロシージャを PostgreSQL 関数に変換 AWS DMS できます。このためには、**[プロシージャを関数に変換]** を選択する。
+ ソースの SQL Server データベースは、`EXEC` の出力をテーブルに保存できる。DMS Schema Conversion は、一時テーブルと、この機能をエミュレートする追加のプロシージャが作成する。このエミュレーションを使用するには、 **[Create additional routines to handle open datasets]** を選択する。
+ 変換されるコード内のスキーマ名に使用するテンプレートを定義できる。**[スキーマ名]** で、次のオプションのいずれかを選択する。
  + **DB** – SQL Server のデータベース名を PostgreSQL のスキーマ名として使用する。
  + **SCHEMA** – SQL Server のスキーマ名を PostgreSQL のスキーマ名として使用する。
  + **DB\$1SCHEMA** – SQL Server データベースとスキーマ名の組み合わせを PostgreSQL のスキーマ名として使用する。
+ ソースオペランドの名前の大文字と小文字は維持できる。オペランド名が小文字に変換されないようにするには、**[大文字と小文字を区別する操作では小文字へのキャストを避ける]** を選択する。このオプションは、ソースデータベースで大文字と小文字の区別機能が有効になっている場合にのみ利用できる。
+ ソースデータベースのパラメータ名は維持できる。DMS Schema Conversion は、変換されるコードのパラメータ名に二重引用符を追加できる。このためには、**[元のパラメータ名を保持]** を選択する。
+ ソースデータベースのルーチンパラメータの長さを保持できます。DMS スキーマ変換はドメインを作成し、このドメインを使用してルーチンパラメータの長さを指定します。そのためには、**[パラメータの長さを保持]** を選択します。
+ サポートされていないビルトインオブジェクトをスタブオブジェクトに変換するには、**[Convert unsupported built-in objects to stub objects]** 設定を有効にします。
  +  有効にすると、DMS SC はサポートされていないビルトインオブジェクトをターゲットデータベース内の対応するスタブオブジェクトに置き換えます。この機能は、通常は移行の問題 7811 または 7904 で囲まれるコードセクションを変換します。プロシージャについてはソースビルトインオブジェクト `PROCEDURE`、ビューまたはテーブルについては `VIEW` のタイプに基づいてスタブオブジェクトを作成します。

    サポートされていないオブジェクトの呼び出しでソースデータベースオブジェクトを変換すると、スタブオブジェクトの呼び出しと移行の問題 7822 が発生します。

    **[Create stub objects in a separate schema]** オプションを有効にすると、別のスキーマでスタブオブジェクトを作成できます。このオプションを選択すると、スタブオブジェクトはターゲットデータベースの `aws_sqlserver_stub` という特別なスキーマで作成されます。選択しない場合、スタブオブジェクトは呼び出し元のオブジェクトと同じスキーマで作成されます。
  + スタブルーチン名は、元のビルトインの完全修飾名に基づいて決定されます。スタブビューの場合、命名規則にはシステムスキーマ名 `system_schema_name$builtin_view_name` が含まれます。

    再変換中、DMS SC はターゲットデータベース内の既存のスタブルーチンをチェックします。名前と入力パラメータが同じであるルーチンが既に存在する場合、そのルーチンは上書きされません。

    変換後、必要に応じてスタブルーチンのカスタムコードを確認して実装します。
+ DMS Schema Conversion のすべての文字列データ型に対する `CITEXT` データ型の設定には、以下が含まれます。
  + SQL Server から PostgreSQL への変換時に大文字と小文字を区別しない文字列オペレーションに `CITEXT` データ型を使用するには、**[Use CITEXT for all string datatypes]** 設定を有効にします。このオプションは、大文字と小文字を区別しない SQL Server から大文字と小文字を区別する PostgreSQL 環境に移行する場合に、動作の一貫性を維持するのに役立ちます。
  + このオプションを有効にすると、DMS SC は関連するすべての文字列データ型をソース SQL Server データベースから PostgreSQL の `CITEXT` に変換します。これにより、条件で明示的な LOWER () 関数呼び出しが不要になり、条件付きオペレーションの文字列式が `CITEXT` に自動的にキャストされます。
  + SQL Server インスタンスで大文字と小文字が区別されるかどうかを確認するには、次のクエリを実行します。

    ```
    SELECT SERVERPROPERTY('COLLATION');
    ```

    結果に「CI」が含まれる場合は大文字と小文字が区別されず、「CS」が含まれる場合は大文字と小文字が区別されます。
  + `CITEXT` 変換は、大文字と小文字を区別する明示的な照合設定がサーバー、データベース、または列レベルで使用されるシナリオでは適用されない場合があります。

    この機能を使用するには、`CITEXT` モジュールがターゲット PostgreSQL データベースにインストールされ、使用可能であることを確認してください。
  + `CITEXT` データ型変換を使用する場合は、以下のベストプラクティスを考慮してください。
    + 大文字と小文字を区別しない SQL Server から移行する場合、PostgreSQL で動作の一貫性を維持するためにこの機能を有効にします。
    + アプリケーションコードを確認して、大文字と小文字を区別する文字列オペレーションに依存していないことを確認します。
    + 移行後にアプリケーションを徹底的にテストし、大文字と小文字を区別しない動作が想定どおりに維持されていることを確認します。

# PostgreSQL から MySQL への変換設定を理解する
<a name="schema-conversion-postgresql-mysql"></a>

DMS Schema Conversion の PostgreSQL から MySQL へのコンバージョン設定は、次のとおりです。
+ **変換後の SQL コードのコメント**: この設定には、変換後のコード内の選択した重大度以上のアクション項目に関するコメントが含まれます。この設定では、以下の値がサポートされます。
  + エラーのみ
  + エラーおよび警告
  + すべてのメッセージ

# IBM Db2 for LUW から Amazon RDS for PostgreSQL への変換設定について
<a name="schema-conversion-db2-luw-postgresql"></a>

**注記**  
 AWS マネジメントコンソールは、ソースデータプロバイダーとして IBM Db2 for LUW を使用し、ターゲットデータプロバイダーとして Amazon RDS for PostgreSQL を使用する DMS Schema Conversion での移行プロジェクトの作成をサポートしていません。代わりに AWS CLI または DMS Schema Conversion API を使用します。

DMS Schema Conversion の IBM Db2 for Linux、UNIX、Windows から Amazon RDS for PostgreSQL への変換設定は次のとおりです。
+  **変換後の SQL コードのコメント**: この設定には、変換後のコード内の選択した重大度以上のアクション項目に関するコメントが含まれます。この設定では、以下の値がサポートされます。
  + エラーのみ
  + エラーおよび警告
  + すべてのメッセージ

# IBM Db2 for z/OS から Amazon RDS for Db2 への変換設定について
<a name="schema-conversion-db2-zos-db2"></a>

DMS Schema Conversion での IBM for z/OS から Amazon RDS for DB2 への変換設定には、以下が含まれます。
+ **変換後の SQL コードのコメント**: この設定には、変換後のコード内の選択した重大度以上のアクション項目に関するコメントが含まれます。この設定では、以下の値がサポートされます。
  + エラーのみ
  + エラーおよび警告
  + すべてのメッセージ

# IBM Db2 for z/OS から Amazon RDS for PostgreSQL への変換設定について
<a name="schema-conversion-db2-zos-postgresql"></a>

**注記**  
 AWS マネジメントコンソールは、ソースデータプロバイダーとして IBM Db2 for z/OS を使用し、ターゲットデータプロバイダーとして Amazon RDS for PostgreSQL を使用する DMS Schema Conversion での移行プロジェクトの作成をサポートしていません。代わりに AWS CLI または DMS Schema Conversion API を使用します。

DMS Schema Conversion の IBM Db2 for z/OS から Amazon RDS for PostgreSQL への変換設定は次のとおりです。
+  **変換後の SQL コードのコメント**: この設定には、変換後のコード内の選択した重大度以上のアクション項目に関するコメントが含まれます。この設定では、以下の値がサポートされます。
  + エラーのみ
  + エラーおよび警告
  + すべてのメッセージ

# SAP ASE (Sybase ASE) から PostgreSQL への変換設定について
<a name="schema-conversion--sybase-ASE"></a>

DMS Schema Conversion の SAP ASE (Sybase ASE) から PostgreSQL への変換設定は次のとおりです。
+ 生成 AI を使用して該当するデータベースオブジェクトを変換するには、**[生成 AI]** 設定を有効にする。生成 AI を使用して正常に変換されたオブジェクトは、「この変換では、データのパターンに基づいて予測を生成する機械学習モデルを使用します」と記述された**アクション項目 3077** で明確に識別されます。詳細については、「[生成 AI を使用したデータベースオブジェクトの変換](schema-conversion-convert.databaseobjects.md)」を参照してください。
+ **変換後の SQL コードのコメント**: この設定には、変換後のコード内の選択した重大度以上のアクション項目に関するコメントが含まれます。この設定では、以下の値がサポートされます。
  + エラーのみ
  + エラーおよび警告
  + すべてのメッセージ
+ 変換されるコード内のスキーマ名に使用するテンプレートを定義できる。**[スキーマ名]** で、次のオプションのいずれかを選択する。
  + **DB** – PostgreSQL のスキーマ名として SAP ASE (Sybase ASE) データベース名を使用します。
  + **SCHEMA** – PostgreSQL のスキーマ名として SAP ASE (Sybase ASE) スキーマ名を使用します。
  + **DB\$1SCHEMA** – SAP ASE (Sybase ASE) データベースとスキーマ名の組み合わせをスキーマ名として使用します。
+ ソースデータベースからオブジェクト名の正確な大文字と小文字を保持できます。これを行うには、ソースデータベースオブジェクト名を大文字と小文字を区別して扱うを選択します。このオプションをオフにすると、すべてのデータベースオブジェクト名が小文字に変換されます。
+ 大文字と小文字を区別しないオペレーションでは、オペランドを小文字にキャストしないようにできます。DMS Schema Conversion は、変換されたコードのオペランドに LOWER 関数を適用しません。これを行うには、**大文字と小文字を区別しないオペレーションでオペランドを小文字にキャストしない**を選択します。このオプションが選択されていない場合 (デフォルト）、DMS Schema Conversion は LOWER 関数を自動的に適用してオペランドを小文字に変換してから、大文字と小文字を区別しない比較を実行します。
+ SAP ASE (Sybase ASE) では、異なるテーブル間で同じ名前のインデックスを作成できます。PostgreSQL では、スキーマ内のすべてのインデックス名が一意である必要があります。 AWS Schema Conversion が移行中に一意のインデックス名を作成するようにするには、**インデックスの一意の名前を生成する**を選択します。このオプションは、ターゲット PostgreSQL データベースの命名競合を防ぐために、インデックス名にプレフィックスを自動的に追加します。