変換に関する問題とパターンのリファレンス

コンバージョン ワークスペースでは、すべてのコンバージョンの問題がグループとカテゴリに集約され、コンバージョンのエラーと警告を修正する計画を立てることができます。各カテゴリは、問題を修正するために必要な作業の種類（確認、リファクタリング、データ型の調整）を表します。グループは、下位レベルの特定のケースを区別するため、さらに集計を行います。

コンバージョン ワークスペースの概要画面。コンバージョンの問題のグループとカテゴリが表示されます。
図 1. コンバージョンの問題のグループとカテゴリが表示されたコンバージョン ワークスペースの概要画面。
コンバージョン ワークスペースの概要画面。コンバージョンの問題のグループとカテゴリが表示されます。

次の表に、スキーマ変換中に発生する可能性のある変換の問題グループをすべて示します。

問題グループ ID 説明

無効なソースコード

考えられる根本原因

このグループのエラーは、Database Migration Service で不明な構文が検出された場合や、Oracle ソースコードが無効な場合（ストアド プロシージャに END; キーワードがない場合など）に発生します。
考えられる対応策

移行元の Oracle データベースで無効なオブジェクトを修正します。次に、Database Migration Service でソーススキーマのスナップショットを更新し、スキーマ変換プロセスを再試行します。または、移行からオブジェクトを除外することもできます。

参照先のオブジェクトが見つかりません

考えられる根本原因

Database Migration Service は、ソースツリー内のオブジェクトのメタデータを使用して、依存オブジェクトのコード変換品質を向上させます。コードがソーススキーマに含まれていないオブジェクトを参照している場合、Database Migration Service は、参照されている列、属性、オブジェクトの構造やデータ型を特定できないため、変換の問題が発生する可能性があります。

このグループで発生する可能性のあるエラーには、ユーザー定義型（UDT）のデータ型が正しくない、列、パラメータ、変数のデフォルトの VARCHAR データ型が正しくないなどがあります。
考えられる緩和策

参照されているすべてのオブジェクトが Database Migration Service のソースツリーに追加されていることを確認するか、欠落している依存関係のソースデータ モデルに関する知識に基づいて PostgreSQL コードを手動で調整します。

主キーのないテーブル

考えられる根本原因

Database Migration Service では、すべてのテーブルに主キーが必要です。主キーのないテーブルの場合、Database Migration Service は、rowid という名前の NUMERIC 列をターゲットの PostgreSQL テーブルに追加します。この列には、ソース Oracle ROWID 疑似列の対応する数値が入力されます。移行後に INSERT ステートメントが失敗しないように、Database Migration Service はシーケンスを作成し、それを使用して rowid 列を自動インクリメントします。
考えられる対応策

移行後に rowid 列を保持するか、削除するかを選択できます。

サポートされていない Oracle 組み込み機能

考えられる根本原因

サポートされていない組み込みの Oracle 機能を使用している可能性があります。
考えられる対応策

PostgreSQL で同様の機能を見つけて、変換されたコードを適宜変更します。場合によっては、Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL の両方の移行で使用できる Orafce 拡張機能によって、不足している機能が提供されることがあります。

SQLCODE はサポートされていません

考えられる根本原因

Oracle の SQLCODE 関数は変換でサポートされていません。SQLCODE は INTEGER を返しますが、PostgreSQL で最も近いのは TEXT 値を返す SQLSTATE 関数です。
考えられる対応策

ソースコードが SQLCODE を返す整数に依存していない場合（たとえば、SQLCODE が VARCHAR2 列または DBMS_OUTPUT メッセージにのみ記録されている場合）、SQLSTATE は PostgreSQL コードで安全に使用できます。

ソースコードが整数を返す SQLCODE に依存している場合（たとえば、NUMBER 変数または INTEGER 変数で使用している場合や、SQLCODE の戻り値をパラメータまたは列として保存している場合）、変換されたコードをリファクタリングする必要があります。

Oracle SQL 関数はサポートされていません

考えられる根本原因

一部の Oracle 組み込み関数は、Database Migration Service での変換でサポートされていません。

一部の関数には、PostgreSQL に対応する関数（ASCII など）が存在する場合があります。また、同じ名前を共有していても仕様が異なる関数（REGEXP% 関数など）もあります。一部の関数はまったく存在しない可能性があります。

考えられる対応策

エラーを発生させた Oracle 関数を調べます。

  • PostgreSQL で同じ動作の関数が存在する場合は、変換されたコードが移行後も同じように動作するため、エラー メッセージを無視できます。

  • 関数の名前が同じでも動作が異なる場合や、PostgreSQL に存在しない場合は、変換されたコードを修正してみてください。

Oracle 組み込みパッケージは完全にはサポートされていません

考えられる根本原因

Database Migration Service は特定の Oracle 組み込みパッケージをサポートしていますが、DBMS_STATS、DBMS_UTILITY、DBMS_SQL など、多くのパッケージは完全な変換をサポートしていません。
考えられる対応策

サポートされていないパッケージを使用する場合は、次の操作が必要になることがあります。

  • コードを変更します。たとえば、DBMS_STATS.GATHER_TABLE_STATS を使用する代わりに、ANALYZE などのよりシンプルなコマンドを使用できます。

    UTL_FILE や DBMS_AQ などのパッケージは、PostgreSQL で簡単に複製できないため、リファクタリングが必要になる場合があります。

  • 一部の Oracle データベースの関数または機能は、 Orafce などの拡張機能で複製できます。移行先データベースでサポートされている拡張機能の詳細については、 サポートされているデータベース拡張機能をご覧ください。

変換でサポートされていない Oracle のデータ型

考えられる根本原因

一部の Oracle データ型は、現在、変換またはデータ移動でサポートされていません。
考えられる対応策

ほとんどの場合、PostgreSQL には同等のデータ型があります。 変換マッピング ファイルを使用して変換ロジックをカスタマイズし、サポートされていない Oracle データ型を必要な PostgreSQL データ型に変換できます。

データ型のサポートの詳細については、 コンバージョン ワークスペース - 概要とサポートされているオブジェクトをご覧ください。

命名の競合

考えられる根本原因

このグループは、複数のデータベース オブジェクト（テーブル、マテリアライズド ビューなど）が、移行先データベースで同じ名前を使用するように変換される問題をキャプチャします。たとえば、名前が大文字と小文字の違いのみであるソース オブジェクトがある場合に、この問題が発生することがあります。Oracle のオブジェクト名では大文字と小文字が区別されませんが、PostgreSQL では区別されるため、オブジェクト名は同じ文字列を使用するように変換されます。
考えられる対応策

競合するオブジェクトの名前を、ソース データベースで直接変更するか、変換ワークスペース エディタで変換されたスキーマで変更します。 RENAME_* ディレクティブを含むコンバージョン マッピング ファイルを使用することもできます。

ソース機能はサポートされていません
考えられる根本原因

このグループには、変換でサポートされていない Oracle 機能に関連する一般的な問題がすべて含まれます。このグループの問題は、他のより具体的な問題グループには該当しません。
考えられる対応策

スキーマ オブジェクト タイプはサポートされていません

考えられる根本原因

PostgreSQL には適切な同等のオブジェクトがないため、Database Migration Service はコード変換で特定の Oracle スキーマ オブジェクト タイプをサポートしていません。たとえば、索引構成表（IOT）、テキスト検索インデックス、ユーザー定義型（UDT）の本文などです。
考えられる対応策

Database Migration Service は、サポートされていないオブジェクトを最も近い PostgreSQL の同等オブジェクトに変換します。たとえば、IOT は主キー制約を持つ通常のテーブルになり、テキスト検索インデックスは B ツリー インデックスに変換されます。これらの変換により、元のオブジェクト タイプに固有の機能が失われる可能性があります。

PL/SQL 機能はサポートされていません
考えられる根本原因

このグループには、変換でサポートされていない PL/SQL 機能に関連する一般的な問題がすべて含まれます。このグループの問題は、他のより具体的な問題グループには該当しません。
考えられる対応策

一括バインディングはサポートされていません

考えられる根本原因

Database Migration Service のコード変換は、現在、BULK COLLECT、FORALL、SAVE EXCEPTIONS などの Oracle 一括バインディング機能をサポートしていません。
考えられる対応策

この問題を解決するには、一括バインド機能を使用するコードを変更する必要があります。PostgreSQL と Oracle のアーキテクチャの違いと、ユースケースで PostgreSQL で配列処理が必要かどうかを検討することをおすすめします。

PostgreSQL で Oracle の一括バインド オペレーションにアプローチするには、いくつかの戦略があります。これらの使用方法は、特定のシナリオによって異なります。そのため、特定のニーズに対応するには、 Gemini を活用した変換アシスタンスを使用することをおすすめします。以下に、参考になるおすすめの例をいくつか紹介します。

  • 完全な BULK COLLECT（LIMIT なし）の場合は、ARRAY_AGG 関数を使用してみてください。
  • LIMIT を含む BULK COLLECT の場合は、CURSOR FOR LOOP を使用して、配列内の行のバッチを読み込んで処理できます。ただし、機能の変更が可能な場合は、CURSOR FOR LOOP を使用して（配列に読み込むのではなく）1 行ずつ処理する方が簡単な場合があります。
  • FORALL オペレーションの場合、配列処理を使用する場合は、UNNEST でセットベースの DML を試すことができます。
  • SAVE EXCEPTIONS の場合、PostgreSQL には同等の句がないため、行ベースの CURSOR FOR LOOP 内に例外ハンドラを記述する必要があります。

コレクションはサポートされていません

考えられる根本原因

Database Migration Service のコード変換は、Oracle コレクションを部分的にサポートしています。
考えられる対応策

変換された PostgreSQL コードを適宜変更する必要があります。コレクションに関する問題を解決する際は、PostgreSQL 配列がスパースになることはないことに注意してください。要素をまばらに割り当てると、PostgreSQL 配列は Oracle 配列とは異なる結果とカーディナリティ数を返す可能性があります。

PostgreSQL は文字列インデックス配列をサポートしていないため、データの性質によっては、JSON/JSONB または hstore 拡張機能が適している場合があります。

パイプライン関数はサポートされていません

考えられる根本原因

パイプライン関数は、Database Migration Service ではサポートされていません。
考えられる対応策

Oracle のパイプライン関数は、PostgreSQL のセットを返す関数に置き換えることができます。ユースケースに関連する方法でコードを調整することをおすすめします。以下に、参考となる例をいくつかご紹介します。

  1. パイプライン関数の行タイプを定義するソース Oracle オブジェクトまたはレコードタイプから変換された PostgreSQL タイプ（UDT）を参照します。次に、特定のケースに応じて、PostgreSQL 関数の return 句を RETURNS SETOF <type name> または RETURNS TABLE に変更します。

  2. 変換された PIPE ROW コードの戻り値を RETURN NEXT <row or record variable> に置き換えます。

Oracle 関数の RETURN 句で使用されるソース パイプライン関数のコレクション タイプは、PostgreSQL では必要ありません。

動的 SQL はサポートされていません

考えられる根本原因

Database Migration Service は、動的 SQL の変換を部分的にサポートしています。Oracle の EXECUTE IMMEDIATE、OPEN FOR、USING / INTO キーワードは、対応する PostgreSQL に正しく変換されますが、実際の動的 SQL、DML、DDL 文字列は変換されません。
考えられる対応策

変換されたコードを要件に合わせて変更する必要があります。動的 SQL を処理するには、 Gemini を活用した変換アシスタンスを使用することを強くおすすめします。

CONNECT BY オプションはサポートされていません

考えられる根本原因

ほとんどの CONNECT BY 演算子、関数、疑似列は Database Migration Service でサポートされており、PostgreSQL の再帰的な共通テーブル式（CTE）に変換されます。ただし、注意が必要な例外もあります。たとえば、ORDER SIBLINGS BY 句は昇順でのみサポートされています。
考えられる対応策

降順の ORDER SIBLINGS BY 句を簡単に複製することはできないため、昇順で動作するようにコードを再構成する必要がある場合があります。

CONNECT BY 演算子で報告された問題を確認し、必要に応じてコードを調整します。このような修正を迅速に行うには、Gemini を活用した自動変換機能を使用することをおすすめします。詳細については、 Gemini アシスタンスを使用して Oracle のコードとスキーマを変換するをご覧ください。

JSON はサポートされていません

考えられる根本原因

Database Migration Service がデータ移動とコード変換で JSON をサポートする方法には、いくつかの制限があります。

  • JSONB はデータ移動ではサポートされていません。
  • コード変換では、Oracle の JSON クエリ関数または演算子（JSON_TABLE、JSON_QUERY、JSON_OBJECT[AGG]、JSON_ARRAYAGG、JSON_PATCH など）はサポートされていません。
  • 21c より前の Oracle バージョンでは、JSON データを VARCHAR2、CLOB、または BLOB 列に保存し、IS JSON 条件で検証できます。Database Migration Service は、この条件の変換をサポートしていません。
考えられる対応策

  • VARCHAR2、CLOB、BLOB 列に保存されている JSON データを PostgreSQL に移動するには、MODIFY_TYPE ディレクティブを使用して変換マッピング ファイルを作成する必要があります。

    次に例を示します。

    MODIFY_TYPE SOURCE_TABLE_NAME:BLOB_COLUMN_NAME_WITH_JSON_DATA:JSON

    コンバージョン マッピング ファイルの詳細については、 コンバージョン マッピング ファイルをご覧ください。

  • Oracle の JSON 関数と演算子を PostgreSQL に変換するには、JSONB_ARRAY_ELEMENTS、JSON_AGG などの PostgreSQL 関数を使用します。詳細については、PostgreSQL ドキュメントの JSON 関数と演算子をご覧ください。

ロックとトランザクションに関する問題

考えられる根本原因

Database Migration Service のコード変換は、LOCK ステートメントまたは SAVEPOINT ステートメントをサポートしていません。PostgreSQL は SAVEPOINT をサポートしていません。
考えられる対応策
  • Oracle の SAVEPOINT ブロックを、ROLLBACK ステートメントを使用する PostgreSQL の個別のトランザクション ブロックに分割します。
  • DBMS_LOCK を実装するには、PostgreSQL の pg_dbms_lock 拡張機能を使用します。この拡張機能は、Oracle DBMS_LOCK パッケージの機能をエミュレートすることで、Oracle ユーザー定義ロックの PostgreSQL への移行を簡素化します。

XML はサポートされていません

考えられる根本原因

Database Migration Service は、Oracle XMLTYPE または関連する XML 関数と演算子をサポートしていません。
考えられる対応策

Database Migration Service は XMLTYPE を直接サポートしていませんが、データ移動のために BLOB、CLOB、NVARCHAR2、VARCHAR2 列を XML にカスタマイズできます。PostgreSQL は XML 機能をサポートしています。

XML データを移行する手順は次のとおりです。

  1. XML データの MODIFY_TYPE ディレクティブを使用して、変換マッピング ファイルを作成します。次に例を示します。

    MODIFY_TYPE SOURCE_TABLE_NAME:BLOB_COLUMN_NAME_WITH_XML_DATA:XML

    コンバージョン マッピング ファイルの詳細については、 コンバージョン マッピング ファイルをご覧ください。

  2. 移行ジョブを開始します。このプロセスでは、XMLTYPE 型の列のデータを除き、すべてのデータが Oracle から PostgreSQL に移行されます。これらの列には、PostgreSQL の NULL 値が入力されます。
  3. Oracle から XMLTYPE 列のみを選択して、PostgreSQL に外部テーブルを作成します。ソーステーブルの主キー列を含めます。
  4. 外部テーブルの XML データを元の PostgreSQL テーブルにマージします。

PostgreSQL が XMLTYPE と連携する方法の詳細については、PostgreSQL ドキュメントの XML 関数をご覧ください。

PIVOT はサポートされていません

考えられる根本原因

Database Migration Service は、コード変換の PIVOT 転置演算子と UNPIVOT 転置演算子をサポートしていません。
考えられる対応策

PostgreSQL で PIVOT 転置を実現するには、tablefunc 拡張機能を使用するか、ソースの PIVOT 式を条件付き集計に書き換えます。次に例を示します。

  • SUM(CASE WHEN <condition> THEN <value> ELSE 0 END)
  • COUNT(CASE WHEN <condition> THEN 1 END)

PostgreSQL では、一連の列から Key-Value ペアを作成する UNPIVOT 転置をさまざまな方法で作成できます。

  • LATERAL 結合と VALUES のセットを組み合わせる。次に例を示します。 SELECT ... FROM <table> CROSS JOIN LATERAL (VALUES ('<column1-name>', <column1>), ('<column2-name>', <column2>) AS u(column_name, column_value))
  • ARRAY で UNNEST を使用する。次に例を示します。 SELECT ..., UNNEST(ARRAY['<column1-name>', '<column2-name>']) AS column_name, UNNEST(ARRAY[column1, column2]) AS column_value FROM <table>

ALTER ステートメント オプションはサポートされていません

考えられる根本原因

Database Migration Service は、変換のために ALTER ステートメント（動的 SQL でよく実行される）を実行しません。
考えられる対応策

Oracle の ALTER ステートメントを PostgreSQL の SET コマンドに置き換えます。このような修正を迅速に行うには、Gemini を活用した自動変換機能を使用することをおすすめします。詳細については、 Gemini アシスタンスを使用して Oracle のコードとスキーマを変換するをご覧ください。

SQL 機能はサポートされていません
考えられる根本原因

このグループには、変換でサポートされていない SQL 機能に関連する一般的な問題がすべて含まれます。このグループの問題は、他のより具体的な問題グループには該当しません。たとえば、データベース イベント トリガー、GRANT ステートメント、マルチテーブル INSERT オペレーション、インライン ビュー（INSERT INTO (SELECT ... FROM ...)）の DML、ラテラルビューなどがあります。
考えられる対応策

サポートされていない構文
考えられる根本原因

このグループには、サポートされていない Oracle SQL または PL/SQL 構文に関連するすべての一般的な問題が含まれます。このグループの問題は、他のより具体的な問題グループには該当しません。
考えられる対応策

PostgreSQL と機能的に同等の PostgreSQL 構文を使用するようにコードを変更します。Gemini を活用した自動変換機能を試して、コードを調整することをおすすめします。詳細については、 Gemini アシスタンスを使用して Oracle のコードとスキーマを変換するをご覧ください。
サポートされていない SQL 構文

考えられる根本原因

ソースコードで、Database Migration Service でサポートされていない SQL 構文または要素が使用されている。たとえば、Oracle TO_DATE 関数の NLS_LANG パラメータはサポートされていません。
考えられる対応策
対応していない PL/SQL 構文

考えられる根本原因

ソースコードで、Database Migration Service でサポートされていない PL/SQL 構文または要素が使用されている。たとえば、レコードベースの INSERT ステートメント（INSERT INTO table VALUES r_variable など）と PRAGMA RESTRICT_REFERENCES はサポートされていません。
考えられる対応策

PostgreSQL と機能的に同等の PostgreSQL 構文を使用するようにコードを変更します。Gemini を活用した自動変換機能を試して、コードを調整することをおすすめします。詳細については、 Gemini アシスタンスを使用して Oracle のコードとスキーマを変換するをご覧ください。

サポートされていない日付とタイムスタンプの構文

考えられる根本原因

Database Migration Service では、サポートされていない日付またはタイムスタンプの構文、オペレーション、式に対してエラーまたは警告が発生することがあります。このような問題の例としては、一致しないデータ型間の比較や、タイムスタンプでの TZH:TZM 形式モデルの使用などがあります。サポートされているオブジェクトとデータ型の詳細については、 コンバージョン ワークスペースについてをご覧ください。
考えられる対応策

ほとんどの日付とタイムスタンプの式は、PostgreSQL の同等の式を使用して再作成できます。このような修正を迅速に行うには、Gemini を活用した自動変換機能を使用することをおすすめします。詳細については、 Gemini アシスタンスを使用して Oracle のコードとスキーマを変換するをご覧ください。

Oracle の例外処理構文のサポートされていない要素

考えられる根本原因

Database Migration Service のコード変換では、次の Oracle PL/SQL 例外構文要素はサポートされていません。

  • リテラル -20nnn コードではなく、変数エラーコードを指定した RAISE_APPLICATION_ERROR の使用。
  • エラーコード引数を指定した SQLERRM の使用。この構文は PostgreSQL でサポートされていません。
考えられる対応策

これらの問題は、変換されたコードで手動で解決する必要があります。このような修正を迅速に行うには、Gemini を活用した自動変換機能を使用することをおすすめします。詳細については、 Gemini アシスタンスを使用して Oracle のコードとスキーマを変換するをご覧ください。

データ型と変換に関する問題

考えられる根本原因

Database Migration Service は、コンテキスト（ 型比較式で発生する変換の問題など）に基づいて変換の問題をグループ化できます。CW_OP0500 グループは、他の問題グループに該当しない一般的なデータ型変換の問題をすべてキャプチャします。
考えられる対応策

ほとんどの場合、Database Migration Service は、変換された PostgreSQL コードで ERROR_UNIMPLEMENTED または ERROR_TYPE メッセージを出力します。関連するデータ型に関する知識に基づいて、このエラーを解決します。

日付形式モデルに関する問題

考えられる根本原因

フォーマット モデルに基づいて日付またはタイムスタンプ式を文字列に変換する場合、または文字列から変換する場合に、警告や問題が発生することがあります。Oracle ソースコードのキャストで明示的な日付またはタイムスタンプ形式モデルが除外されている場合、Database Migration Service はデフォルト モデル（現在は DD-MON-RR）を使用します。

暗黙的なキャストに対して出力された形式モデルが、同じ式内の明示的な形式モデルと競合する場合、変換されたコードで問題が発生することがあります。この問題は、 Oracle の RR 形式と PostgreSQL の YY 形式の違いによってデータが影響を受ける可能性がある場合にも発生することがあります。
考えられる対応策

コンバージョン ワークスペースで、変換された PostgreSQL 式を確認して検証します。

数値形式モデルに関する問題

考えられる根本原因

Database Migration Service は、すべての Oracle 形式モデルをサポートしているわけではありません。たとえば、'L' や 'X' はサポートされていません。Oracle 形式モデルに基づいて文字列を数値に変換するコードで、問題や警告が発生することがあります。
考えられる対応策

PostgreSQL に同等のものがない Oracle 形式モデルの場合は、式または形式モデルのリファクタリングが必要になることがあります。このような修正を迅速に行うには、Gemini を活用した自動変換機能を使用することをおすすめします。詳細については、 Gemini アシスタンスを使用して Oracle のコードとスキーマを変換するをご覧ください。

データ型キャストの問題

考えられる根本原因

サポートされていないデータ型キャストや不正確なデータ型キャストが原因で、エラーが発生することがあります。Database Migration Service は通常、ERROR_UNIMPLEMENTED を出力します。これは通常、メタデータが不足しているか不完全であることが原因です。 Database Migration Service には、関数の引数やプロシージャのパラメータなど、型をキャストするのに十分な情報がない可能性があります。
考えられる対応策

PostgreSQL コードを調整して、データ型が正しく変換されるようにします。これらの修正を行うには、参照される属性、変数、列に精通している必要があります。

比較の問題

考えられる根本原因

Database Migration Service には、データ比較式を変換する際に、データ型に関する十分なメタデータや情報がない場合があります。たとえば、ユーザー定義型（UDT）が NULL と比較される場合に発生することがあります。
考えられる対応策

変換された PostgreSQL 式を確認し、問題を解決します。このような修正を迅速に行うには、Gemini を活用した自動変換機能を使用することをおすすめします。詳細については、 Gemini アシスタンスを使用して Oracle のコードとスキーマを変換するをご覧ください。

このカテゴリの問題は、Oracle ソースコードが最も近い PostgreSQL の同等物に正しく変換されているものの、結果のコードに軽微なセマンティックまたは機能的な違いがあり、確認が必要な場合を表します。これは、Oracle と PostgreSQL でデータ型、形式、オブジェクトの処理方法が異なるために発生します。

一見すると、このカテゴリは データ型と変換（CW_05）カテゴリの問題と重複しているように見えるかもしれませんが、これらは異なる問題を表しています。CW_05 には、Database Migration Service が Oracle コードを PostgreSQL 相当のコードに変換できない既知の問題が含まれています。

日付形式モデルを確認してください

考えられる根本原因

ほとんどの Oracle の日付とタイムスタンプの形式モデルには、PostgreSQL に適切な同等のモデルがあるため、変換されたコードに意味的または機能的な違いはありません。一部のモデルには完全一致がなく、動作が異なります。 たとえば、 Oracle の RR 形式は、 PostgreSQL の YY 形式に変換されます。
考えられる対応策

フォーマット モデル変換を使用した式を確認して検証し、変換されたコードが想定どおりに動作することを確認します。

数値形式モデルを確認してください

考えられる根本原因

ほとんどのソース数値形式モデルには PostgreSQL に同等のモデルがあるため、変換されたコードにセマンティックや機能の違いはありません。ただし、一部のフォーマット モデルは、完全に一致しない場合や、動作が若干異なる場合があります。
考えられる対応策

フォーマット モデル変換を使用した式を確認して検証し、変換されたコードが想定どおりに動作することを確認します。

例外コードを確認してください

考えられる根本原因

-20000～-20999 の範囲のエラーコードで RAISE_APPLICATION_ERROR を使用すると、Database Migration Service は、CW0000～CW999 の範囲の SQLSTATE を含む PostgreSQL RAISE EXCEPTION に変換します。変換では、ソースエラーコードの最後の 3 桁が保持され、先頭に CW が追加されます。
考えられる対応策

この動作を確認して、ニーズに適しているかどうかを判断してください。 この確認は、ソースエラー コードがアプリケーション、サポートチーム、ドキュメントにとって意味がある場合にのみ必要です。エラーコード値自体に意味がない場合は、この警告を無視できます。

例外メッセージを確認してください

考えられる根本原因

SQLERRM 関数は Oracle PL/SQL と PostgreSQL の両方に存在しますが、エンジンごとに異なるエラーテキストが返される場合があります。たとえば、Oracle でゼロ除算を行うと、エラーテキスト ORA-01476: divisor is equal to zero が返されますが、PostgreSQL では ERROR: division by zero が返されます。
考えられる対応策

アプリケーション、サポート インフラストラクチャ、ドキュメントがエラーテキストに依存している場合は、変換を確認してください。それ以外の場合は、この違いを無視できます。

Oracle 組み込み関数のエミュレーションを確認してください

考えられる根本原因

Database Migration Service のコードとスキーマの変換は、Oracle 関数の動作を PostgreSQL の同等の機能で提供することを目的としていますが、シナリオによっては結果が満足できない場合があります。そのため、コンバージョン ワークスペースでは、確認が必要な関数変換に関するアドバイスの警告が常に表示されます。
考えられる対応策

変換ワークスペースが CW_OP0605 問題グループで警告を出力するオブジェクトを確認することをおすすめします。

外部キー列のデータ型を確認してください

考えられる根本原因

Database Migration Service が、親オブジェクトと子オブジェクトの間で一致しないデータ型仕様を特定しました（たとえば、親列が NUMBER(4) で、子列が NUMBER(10) の場合）。
考えられる対応策

ほとんどの場合、データ型の不一致がわずかであれば、データベースの機能に問題は発生しません。ただし、変換されたデータモデルに不整合がないか確認することをおすすめします。
機能の確認を推奨
考えられる根本原因

このグループには、Oracle と PostgreSQL のコードの機能的な違いに関連する一般的な問題がすべて含まれます。このグループの問題は、他のより具体的な問題グループには該当しません。
考えられる対応策

Oracle 組み込み関数のエミュレーションを確認してください

考えられる根本原因

多くの Oracle 組み込み関数には、PostgreSQL に直接対応する関数がありません。移行時のこの問題を軽減するため、Database Migration Service は、異なる SQL 式を使用してコードを変換し、PostgreSQL で同等の機能動作を実現します。

変換された式が複雑になる場合があります。 Database Migration Service は、CW_OP0702 グループに警告を出力して、考えられる問題を強調表示し、関数が式でエミュレートされたことを通知します。
考えられる対応策

変換されたコードを確認して、変換された関数が PostgreSQL 環境で想定どおりに動作することを確認します。

自律型トランザクションのリファクタリングが必要です

考えられる根本原因

PostgreSQL は 自律型トランザクションをサポートしていません。
考えられる対応策

PostgreSQL で自律型トランザクションを実現するには、 dblink、 pg_background、または PL/Proxy 拡張機能を使用します。これらの拡張機能のいずれかを使用して行われたデータベース呼び出しは、別のセッションで実行されるため、自律型トランザクションが生成されます。

データベース リンクのリファクタリングが必要です

考えられる根本原因

Database Migration Service は、 Oracle データベース リンクをサポートしていません。リンクを使用するオブジェクトは、リファクタリングが必要です。
考えられる対応策

データベース リンクのターゲットに応じて、 dblink、 postgres_fdw、 oracle_fdw、 PL/Proxy などのデータベース拡張機能を使用して、PostgreSQL で同等の機能を実装できます。

高度なキュー リファクタリングが必要です

考えられる根本原因

Oracle Advanced Queuing パッケージ（DBMS_AQ、DBMS_AQADM）には PostgreSQL に相当するものがなく、リファクタリングが必要です。
考えられる対応策

次のオプションを検討してください。

  • キューイング機能をデータベースからアプリケーション層にリファクタリングします。
  • PostgreSQL のテーブル、アラート、トリガーを使用して、同等の動作を実装します。
  • さらにサポートが必要な場合は、テクニカル ソリューション チームの担当者にお問い合わせください。

データベースのメール リファクタリングが必要です

考えられる根本原因

AlloyDB for PostgreSQL は、データベースから直接メールを送信することをサポートしていません。この機能を有効にする拡張機能もサポートされていません。 そのため、Database Migration Service は UTL_SMTP パッケージの使用を変換しません。
考えられる対応策

データベースのメールコードをリファクタリングし、メール送信の責任をアプリケーション層に移動します。データベースを使用して、メールの送信が必要な条件をキャプチャすることもできます。

実装例としては、メールの詳細を専用のテーブルに書き込むことが考えられます。このテーブルは、Cloud Run functions 関数でポーリングして実際の SMTP 処理を行うメールキューとしても機能します。

ジョブとスケジューリングのリファクタリングが必要です

考えられる根本原因

DBMS_JOB と DBMS_SCHEDULER の Oracle パッケージは、Database Migration Service によって変換されません。これらのパッケージを参照するコードをリファクタリングする必要があります。
考えられる対応策

依存関係のない単純なジョブの場合は、 pg_cron 拡張機能を使用して、ターゲット PostgreSQL データベースにスケジュール設定されたジョブを手動で作成できます。

pg_cron でサポートされていない複雑なスケジュールの場合は、アプリケーション レベルまたはサードパーティのスケジューラを使用する必要があります。

ファイル I/O のリファクタリングが必要です

考えられる根本原因

Database Migration Service は、Oracle の UTL_FILE パッケージをサポートしていません。このパッケージを参照するコードをリファクタリングする必要があります。

Orafce 拡張機能には UTL_FILE エミュレーションが含まれていますが、ファイル I/O 機能が制限されているため、Google が管理する PostgreSQL 環境では動作しない可能性があります。
考えられる対応策
  • UTL_FILE への依存関係を削除するようにコードをリファクタリングします。

  • AlloyDB for PostgreSQL にはファイル I/O 機能に関する特定の制限があるため、この動作を移行先データベースに直接実装することはできません。

    別の方法として、VPC 内の Compute Engine VM に orafce 拡張機能を使用して PostgreSQL をインストールすることもできます。その後、移行先データベースで PL/Proxy 拡張機能を使用して、Compute Engine VM のデータベースで実行される PostgreSQL 互換の UTL_FILE バージョンを呼び出すことができます。

類義語

考えられる根本原因

PostgreSQL はシノニムをサポートしていません。コード オブジェクトの場合、Database Migration Service は、シノニム参照をソーススキーマとオブジェクト名に自動的に置き換えます。コード オブジェクトの外部で同義語を使用する場合（データベース アプリケーション ユーザーの読み取り専用スキーマなど）、手動で変換する必要があります。
考えられる対応策

コード オブジェクトの外部で同義語を使用する場合は、PostgreSQL の SEARCH_PATH パラメータを使用するか、クエリ オブジェクトにビューを使用するようにコードをリファクタリングします。

グローバル一時テーブルのリファクタリングが必要です

考えられる根本原因

この問題グループは、Database Migration Service が Oracle ソースコードでグローバル一時テーブルを検出したことを示す警告です。グローバル一時テーブルを移行するには、移行先のデータベースに pgtt PostgreSQL 拡張機能をインストールして作成する必要があります。
考えられる対応策

pgtt PostgreSQL 拡張機能がインストールされ、移行先データベースに作成されていることを確認することをおすすめします。

Gemini の提案を確認してください
考えられる根本原因:

この問題グループには、Gemini による拡張コード変換に関連する一般的なエラーと警告がすべて含まれます。

考えられる緩和策: ここで見つかった問題が、必ずしも実際の不具合を指しているとは限りませんが、Gemini 拡張コンバージョンをすべて確認して、期待どおりに動作していることを確認することを強くおすすめします。

AI 拡張コードを確認してください
考えられる根本原因: この DDL コードは Gemini の拡張機能を使用して変換されたため、正確性を確認する必要がある可能性があります。

考えられる緩和策 AI による拡張機能で変換されたコードを慎重に確認し、最終的な結果がソーススキーマの機能と一致していることを確認することをおすすめします。

引用
考えられる根本原因: Gemini で強化された提案には、複数のソースから引用されたコンテンツが含まれる場合があります。特定の引用には、ライセンス制限が適用される場合があります。変換されたコードに引用がないか確認することをおすすめします。

メタデータの変換に関する問題
考えられる根本原因:

このグループには、他のより具体的な問題グループに該当しないすべてのコンバージョンの問題が含まれます。

考えられる対応策

ソースデータ モデルの知識に基づいて変換されたコードを確認し、必要に応じてコードを調整することをおすすめします。

メタデータの変換に関する問題
考えられる根本原因:

このグループは、他のより具体的な問題グループに該当しない、すべてのメタデータ トラッキングの問題をキャプチャします。
考えられる対応策:

このグループの問題の例は、通常、変換された PostgreSQL のデータ型に問題を引き起こす可能性のあるコンパイル エラーまたは警告に関連しています。ソースデータ モデルの知識に基づいて変換されたコードを確認し、不適切な参照を調整することをおすすめします。

サポートチームにお問い合わせください

考えられる根本原因

特殊なエッジケースでは、有効な Oracle ソース オブジェクトで内部エラーが発生することがあります。その場合は、サポートチームにお問い合わせください。

変換に関する一般的な問題
考えられる根本原因

このグループには、他のより具体的な問題カテゴリまたはグループに該当しないすべての問題が含まれます。
考えられる対応策

ソースデータ モデルとコードに関する知識に基づいて、変換されたコードを確認し、必要に応じて調整することをおすすめします。