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

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

コンバージョンに関する問題のグループとカテゴリが表示されているコンバージョン ワークスペースの概要画面。
図 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 メッセージでのみロギングされる場合）、PostgreSQL コードで SQLSTATE を安全に使用できます。

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

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

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. パイプライン関数の rowtype を定義するソース Oracle オブジェクトまたはレコード型から変換された PostgreSQL 型（UDT）を参照します。次に、特定のケースに応じて、PostgreSQL 関数の戻り句を 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 では、さまざまな方法で UNPIVOT 転置を作成できます。これにより、一連の列から Key-Value ペアが作成されます。

  • 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 オペレーション、インライン ビューの DML（INSERT INTO (SELECT ... FROM ...)）、ラテラルビューなどがあります。
考えられる緩和策

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

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

コードを変更して、機能的に同等の 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 構文を使用します。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 コードを調整します。これらの修正を行うには、参照される属性、変数、列を理解している必要があります。

比較の問題

考えられる根本原因

データベース移行サービスでは、データ比較式を変換する際に、メタデータやデータ型に関する情報が不足している可能性があります。たとえば、ユーザー定義型（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 に同等のものがあるため、変換されたコードに意味的または機能的な違いはありません。ただし、一部の形式モデルには完全一致がない場合や、動作が若干異なる場合があります。
考えられる対応策

形式モデル変換を使用して式を確認して検証し、変換されたコードが想定どおりに機能することを確認します。

例外コードを確認する

考えられる根本原因

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

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

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

考えられる根本原因

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

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

Oracle 組み込み関数のエミュレーションを確認する

考えられる根本原因

Database Migration Service のコードとスキーマの変換は、PostgreSQL の同等の機能で Oracle の関数動作を提供することを目的としていますが、結果がシナリオに必ずしも適しているとは限りません。そのため、変換ワークスペースでは、確認が必要になる可能性がある関数変換に関する警告が常に表示されます。
考えられる対応策

変換ワークスペースが 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 パッケージは、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 ソース オブジェクトで内部エラーが発生することがあります。その場合は、サポートチームにお問い合わせください。

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

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

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