Known issues, limitations, and notes
====================================

これらは、次の既知の問題、制限、および注意事項です。

- :ref:`Migration Portal 4.0.0 release notes <Migration Portal 4.0.0 release notes>`  - :ref:`Extracting schemas using the EDB DDL Extractor <Extracting schemas using the EDB DDL Extractor>`  - :ref:`Extracting schemas using Oracle Data Pump utilities <Extracting schemas using Oracle Data Pump utilities>` 

Migration Portal
----------------

ラップされたオブジェクト
^^^^^^^^^^^^^^^^^^^^^^^^

移行ポータルは、ラップされたオブジェクトを評価できません。抽出されたDDLにそれらを含める場合、それらは移行ポータルにロードされず、評価されるオブジェクトの数に含まれません。ラップされたオブジェクトを評価し、
EDB Postgres Advanced
Serverに移行する場合は、移行ポータルにアップロードするDDLファイルにオブジェクトのラップされていないバージョンを含めます。これを行うことをお勧めします。スキーマ抽出を実行する前に、Oracleデータベース内のラップされたバージョンをクリアテキストバージョンに置き換えることです。スキーマ抽出を実行した後、オブジェクトをラップされたバージョンに置き換えることができます。

削除されたオブジェクト
^^^^^^^^^^^^^^^^^^^^^^

一部のサポートされていないOracleオブジェクトは、移行ポータルがソースDDLファイルを評価するときに削除されます。これらの削除されたオブジェクトは変換手順から除外され、移行ポータル評価で削除されたとしてフラグが立てられません。

次のオブジェクトは、スキーマ評価中に削除されます。

- ``MATERIALIZED VIEWS`` に関連するオブジェクトたとえば、\ ``MVIEW``
  をサポートするように作成されたバックエンド\ ``TABLE``
  または\ ``INDEX`` ステートメント

- ``Queues`` 関連オブジェクト

- ``Nested Tables`` 関連オブジェクト

- ``XMLType Tables`` 関連オブジェクト

- ``SYSTEM Schemas`` に依存する型

- ``PRIMARY KEY`` および\ ``UNIQUE``
  コンストレインに関連するインデックス

- サポートされていないシステム\ ``GRANT`` 特権

EDBは、 ``CREATE DATABASE LINK`` 、\ ``CREATE PUBLIC DATABASE LINK``
、\ ``DROP PUBLIC DATABASE LINK`` 、および\ ``EXEMPT ACCESS POLICY``
システム権限の付与のみをサポートしています。他の\ ``GRANT``
ステートメントはサポートされておらず、 DDLファイルから削除されます。

ファイルエンコード
^^^^^^^^^^^^^^^^^^

移行ポータルは、 ``.SQL``
出力ファイルをUTF-8エンコード形式にすることをお勧めします。非UTF-8エンコードを使用して\ ``.SQL``
ファイルをアップロードする場合、
UTF-8と互換性のないすべての文字は、出力DDLで置換文字 \`�
に変換されます。

..  Tip::
   Linuxではiconvユーティリティ、またはWindowsではLibIconvユーティリティを使用して、抽出したファイルをUTF-8形式に手動で変換できます。たとえば、データベースキャラクタセットがLatin-1 ISO-8859-1である場合、次のように、抽出したファイルをUTF-8形式に変換できます。`iconv -f iso-8859-1 -t UTF-8 sample.sql > sample_utf8.sql` 

ホワイトラベルエラー
^^^^^^^^^^^^^^^^^^^^

移行ポータルの新しいバージョンがリリースされると、移行ポータルを開くことができない問題が発生する場合があります。
``White label Error Page``
またはその他のエラーのようなエラーにより、移行ポータルを使用できません。ブラウザーに保存されているキャッシュデータがこのエラーの原因となります。これが発生した場合は、ブラウザ履歴からキャッシュデータをクリアするか、シークレット/プライベートウィンドウを使用して移行ポータルにアクセスします。

ALTERステートメント
^^^^^^^^^^^^^^^^^^^

``ALTER PROFILE DEFAULT`` 、\ ``ALTER TABLE``
、および\ ``ALTER TRIGGER`` を除き、移行ポータルはDDL内の他の\ ``ALTER``
ステートメントを処理しません。

ユーザー、ロール、プロファイル、および付与
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

付与
^^^^

移行ポータルは、抽出およびアップロードされたスキーマのOracleユーザーの評価と移行をサポートするようになりました。プロジェクトに関連付けられているスキーマのすべてのユーザー、ロール、およびプロファイルは、移行ポータルビューの\ ``GLOBAL_OBJECTS``
擬似スキーマの下にグループ化されます。現在、システム特権、オブジェクト特権、およびロールの付与は、ユーザーオブジェクトのDDLに含まれています。同様に、ロールへのシステム特権およびオブジェクト特権の付与は、ロールオブジェクトのDDLに含まれます。

付与は現在ユーザーとロールオブジェクトにアタッチされているため、ユーザーに権限が付与されている1つ以上のオブジェクトに障害が発生すると、ユーザーオブジェクト自分自身は評価に不合格になります。この問題を解決するには、個々のステートメントのSQL単一行コメント\ ``--``
または連続するgrantステートメントのSQL複数行コメント\ ``/ ** /``
を使用して、障害が発生したオブジェクトのgrantステートメントをコメントアウトし、オブジェクトの再評価ができます。実行されます。失敗したgrantステートメントに対応する障害のあるオブジェクトが修復された後、以前に失敗したgrantステートメントのコメントを外し、ユーザーオブジェクトを再評価できます。

RESOURCEロールの付与は、被付与者と同じ名前を共有するスキーマのCREATEおよびUSAGE特権を付与することと同じです。
RESOURCEロールを付与する場合は、最初にユーザーまたはロールと同じ名前でスキーマを作成する必要があります。それ以外の場合、「スキーマは存在しません」エラーが発生します。

特権
^^^^

スキーマをターゲットEDB Postgres Advanced
Serverデータベースに移行するには、移行の実行に使用されるターゲットデータベースユーザーに次の特権が必要です。

- ``SUPERUSER`` プロファイルを移行する

- ユーザーとロールを移行するための\ ``SUPERUSER``
  または\ ``CREATE ROLE``

パスワード
^^^^^^^^^^

ユーザーを移行する際、移行ポータルはユーザーのパスワードを移行しません。ユーザーは、パスワードなしでターゲットEDB
Postgres Advanced
Serverデータベースに作成されます。ユーザーをパスワードで構成することが望ましいまたは必要な場合、これはユーザーが移行された後、ターゲットデータベースで手動で行うことができます。

プロファイル
^^^^^^^^^^^^

移行ポータルは、スキーマユーザーに割り当てられた非\ ``DEFAULT``
プロファイルを移行します。
Oracleプロファイルには、パスワードとリソース制限の両方が含まれます。 EDB
Postgres Advanced
Serverは、Oracleパスワード関連の制限のみをサポートしています。リソース制限はプロファイルで抽出されますが、移行ポータルはパスワード制限のみをアップロード、評価、および移行します。また、\ ``DEFAULT``
プロファイルは、Oracleデータベースで新しい制限値でオーバーライドされる場合があります。
EDB DDLエクストラクタは、
Oracleデータベースでオーバーライドされる\ ``DEFAULT``
プロファイルの\ ``ALTER PROFILE``
ステートメントを抽出し、移行ポータルはこれらのステートメントをターゲットEDB
Postgres Advanced
Serverデータベースに適用しようとします。スキーマを既存のユーザーとデータベースを含むEDB
Postgres Advanced Serverインスタンスに移行する場合、
DDLをターゲットデータベースに移行する前に、必要に応じて\ ``ALTER PROFILE DEFAULT``
ステートメントの設定を検証および更新することをお勧めします。

..  Note::
   バージョン4.3.0以降、移行ポータルは、ユーザー、ロール、プロファイル、および付与の評価をサポートしています。ただし、移行ポータルの4.3.0より前のバージョンを使用して作成されたプロジェクトの場合、この機能はサポートされていません。ユーザー、ロール、プロファイル、および付与を評価するには、最新バージョンのEDB DDLエクストラクタを使用し、新しいプロジェクトを作成します。

Oracleのデフォルトの場合を使用する
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Oracleのデフォルトの大文字小文字機能を使用するオプションは、OracleデータベースからEDB
Postgres Advanced
Serverデータベースにスキーマを移行するときに、すべてのデータベースオブジェクトのOracleのデフォルトの大文字命名規則を保持します。

EDB DDLエクストラクタおよびOracle Data Pumpユーティリティは、 PL/
SQLの本文内で参照されているオブジェクト名を除き、Oracleのデフォルトの大文字小文字つまりオブジェクト名の大文字または大文字と小文字が区別されるオブジェクト名のそれぞれの大文字と小文字ですべてのDDLを抽出しますDDLの作成時にユーザーが明示的に二重引用符で囲まれない限り、オブジェクト。

したがって、移行ポータルは、この機能のソーススキーマファイルからすべての二重引用符を保持し、さらに、移行ポータルは以下に二重引用符を適用します。

- ビューおよびマテリアライズドビューの\ ``SELECT``
  ステートメント内の列名。

- チェック制約内のカラム名。

- トリガーヘッダー内のテーブル名と列名。

Oracle大文字小文字を使用するオプションが選択されていない場合、移行ポータルのデフォルト動作は、すべてのオブジェクトが小文字EDB
Postgres Advanced
Serverのデフォルトの大文字または引用符で囲まれた大文字と小文字の混合を使用してオブジェクト名が指定されている場合は大文字と小文字が混合で作成されることですソースDDLで
。

useOraCase機能を使用して、以下のソースDDLとターゲットDDLを見つけます。

.. code:: sql

   - - Source DDL
   CREATE TABLE "RHS_SANITY"."DEPT"
      (    "DEPTNO" NUMBER(2,0),
       "DNAME" VARCHAR2(14),
       "LOC" VARCHAR2(14),
        CONSTRAINT "DEPTDEPTNO_PK" PRIMARY KEY ("DEPTNO")
     USING INDEX  ENABLE,
        CONSTRAINT "DEPTDNAME_UK" UNIQUE ("DNAME")
     USING INDEX  ENABLE
      ) ;

   - - Target DDL
   CREATE TABLE "RHS_SANITY"."DEPT"
      (    "DEPTNO" NUMBER(2,0),
       "DNAME" VARCHAR2(14),
       "LOC" VARCHAR2(14),
        CONSTRAINT "DEPTDEPTNO_PK" PRIMARY KEY ("DEPTNO")
     USING INDEX  ENABLE,
        CONSTRAINT "DEPTDNAME_UK" UNIQUE ("DNAME")
     USING INDEX  ENABLE
      ) ;

Oracleのデフォルトのケースを使用している間、他のプロジェクトと比べて互換性率が低下する場合があります。次に、この互換性率の低下の原因と考えられる理由を示します。

- 最も一般的な理由は、オブジェクト/リレーションが存在しないことです。このシナリオは、テーブル/オブジェクトがOracleの大文字と小文字を保持するために二重引用符で囲まれている大文字であるのに対し、障害が発生したオブジェクトでは二重引用符なしで参照されるという事実によって発生します。例

.. code:: sql

      CREATE TABLE "HR"."EMP"
         (   "EMPNO" NUMBER(4,0),
               "ENAME" VARCHAR2(10),
               "JOB" CLOB,
               "MGR" NUMBER(4,0),
               "HIREDATE" DATE,
               "SAL" NUMBER(7,2),
               "COMM" NUMBER(7,2),
               "DEPTNO" NUMBER(2,0),
             CONSTRAINT "PK_EMP" PRIMARY KEY ("EMPNO")
        USING INDEX  ENABLE
         ) ;

      CREATE OR REPLACE  PROCEDURE "HR"."PROC"
      IS
       CURSOR emp_cur IS SELECT hiredate, CAST(hiredate AS timestamp(6)) AS timestamped FROM emp;
       REC emp_cur%rowtype;
      BEGIN
         OPEN emp_cur;
         LOOP
         FETCH emp_cur INTO rec;
             EXIT WHEN emp_cur%NOTFOUND ;
                     DBMS_OUTPUT.PUT_LINE(rec.hiredate ||  ||rec.timestamped);
               END LOOP;
          CLOSE EMP_CUR;
         END ;

エラーは次のように表示されます。

.. code:: sql

      relation "emp" does not exist

上記の例では、テーブル名とその列名は\ ``CREATE TABLE``
ステートメントで引用符で囲まれた大文字の名前で指定されています。ただし、
``CREATE OR REPLACE PROCEDURE``
ステートメントでは、テーブルとその列は、引用符で囲まれていない小文字の識別子を使用して参照されます。

- ``%type`` を使用して定義された変数は、前述の\ ``table.column-name``
  が\ ``employees.employee_id%type``
  のように小文字であるのに対し、実際のテーブルのテーブル名と列名は二重引用符で囲まれた大文字であるため、コードオブジェクトで失敗します。例

.. code:: sql

      CREATE TABLE "HR"."EMPLOYEES"
         (    "EMPLOYEE_ID" NUMBER(6,0),
                "FIRST_NAME" VARCHAR2(20),
                "LAST_NAME" VARCHAR2(25) CONSTRAINT "EMP_LAST_NAME_NN" NOT NULL ENABLE,
                "EMAIL" VARCHAR2(25) CONSTRAINT "EMP_EMAIL_NN" NOT NULL ENABLE,
                "PHONE_NUMBER" VARCHAR2(20),
                "HIRE_DATE" DATE CONSTRAINT "EMP_HIRE_DATE_NN" NOT NULL ENABLE,
                "JOB_ID" VARCHAR2(10) CONSTRAINT "EMP_JOB_NN" NOT NULL ENABLE,
                "SALARY" NUMBER(8,2),
                "COMMISSION_PCT" NUMBER(2,2),
                "MANAGER_ID" NUMBER(6,0),
                "DEPARTMENT_ID" NUMBER(4,0),
                 CONSTRAINT "EMP_SALARY_MIN" CHECK ("SALARY" > 0) ENABLE,
                 CONSTRAINT "EMP_EMP_ID_PK" PRIMARY KEY ("EMPLOYEE_ID")
        USING INDEX  ENABLE,
                 CONSTRAINT "EMP_EMAIL_UK" UNIQUE ("EMAIL")
        USING INDEX  ENABLE
         ) ;
      CREATE OR REPLACE  PROCEDURE "HR"."PKG" AS
      -- declare variables for data fetched from cursor
        empid       employees.employee_id%TYPE; -- variable for employee_id
        hiredate    employees.hire_date%TYPE;   -- variable for hire_date
        firstname   employees.first_name%TYPE;  -- variable for first_name
        lastname    employees.last_name%TYPE;   -- variable for last_name
        rowcount    NUMBER;
        bonusamount NUMBER;
        yearsworked NUMBER;
      -- declare the cursor with a parameter
        CURSOR cursor1 (thismonth NUMBER)IS
          SELECT employee_id, first_name, last_name, hire_date FROM employees
             WHERE EXTRACT(MONTH FROM hire_date) = thismonth;
      BEGIN
        null;
      END;

エラーは次のように表示されます。

.. code:: sql

      syntax error at or near "%" (line 3, char 37)

- テーブルの列データ型にTYPE参照がある場合、大文字と小文字の違いが原因で失敗します。例

.. code:: sql

      CREATE OR REPLACE TYPE "HR"."USER_TYPE" IS OBJECT(
          "ID" NUMBER,
          "NAME" VARCHAR2(256)
      );

      CREATE TABLE "HR"."MY_TABLE"
      (
          "ID" NUMBER,
          "MY_NAME" user_type
      );

エラーは次のように表示されます。

.. code:: sql

      type "user_type" does not exist
      LINE 4:     "MY_NAME" user_type
                    ^
      SQL state: 42704
      Character: 58

不完全なオブジェクト定義
^^^^^^^^^^^^^^^^^^^^^^^^

移行ポータルでソーススキーマを評価しているときに、まれに、ソースDDLに予約語が含まれている場合、変換されたオブジェクト定義が不完全です。

オブジェクト定義の一部が欠落しているか、ステートメントの実際の最後に到達する前に定義が終了する問題が発生した場合は、
EDB Postgres Advanced
Serverによって予約されているキーワードを使用している可能性があります。たとえば、\ ``TABLE``
定義で列名として\ ``CONSTRAINT`` を使用し、\ ``VIEW`` または\ ``MVIEW``
定義で参照すると、移行ポータルはそのDDLステートメントを突然終了し、正常に評価または変換せずに次の定義にスキップする場合があります。

この問題をワークアラウンドには、次のいずれかのことができます。

- Oracleデータベースの列名を変更し、
  DDLを再抽出して移行ポータルにアップロードします。

- 抽出したDDLファイルの列名を変更し、移行ポータルにアップロードします。

EDB DDLエクストラクタ
---------------------

一般的な制限事項
^^^^^^^^^^^^^^^^

- EDB DDLエクストラクタスクリプトは、 ``Flashback``
  を使用して復元されたオブジェクトで、
  ``BIN$b54+4XlEYwPgUAB/AQBWwA==$0``
  のような名前が残っているオブジェクトを抽出しません。これらのオブジェクトを抽出する場合は、オブジェクトの名前を変更し、抽出プロセスを再実行する必要があります。

- EDB DDLエクストラクタは、\ ``nologging``
  テーブルを通常のテーブルとして抽出します。これらのテーブルがEDB
  Postgres Advanced
  Serverに移行されると、WALログファイルが作成されます。

- EDB DDLエクストラクタは、\ ``VALID``
  ステータスでのみオブジェクトを抽出します。移行ポータルで評価する\ ``INVALID``
  ステータスを持つオブジェクトについては、最初に\ ``VALID``
  に更新します。

- EDB DDLエクストラクタは、
  Oracleのラップ機能を使用して難読化されたオブジェクトを抽出しません。そのため、これらのオブジェクトは、移行ポータルによって評価されるDDLのセットには含まれません。これらのオブジェクトを評価し、
  EDB Postgres Advanced
  Serverに移行する場合は、オブジェクトのラップされたバージョンを非ラップバージョンに置き換えます。詳細については、
  :ref:`ラップされたオブジェクト <ラップされたオブジェクト>` を参照してください。

- EDB
  DDLエクストラクタは、グローバル一時テーブルを作成して、スキーマ名とその依存関係情報を保存します。これらのテーブルは、抽出が成功した最後に削除されます。

- PostgreSQLがサポートしていないため、EDB
  DDLエクストラクタスクリプトは、名前が\ ``PG_``
  で始まるスキーマを抽出しません。これらのスキーマを抽出する場合は、抽出前にスキーマの名前を変更する必要があります。

- EDB
  DDLエクストラクタは、プロファイル、ロール、および付与の情報を自動的に抽出します。

- EDB DDLエクストラクタは、現在Oracle 11gからの\ ``ROLES``
  、\ ``SYSTEM GRANTS ON ROLES`` 、\ ``OBJECT GRANTS ON ROLES``
  、および\ ``ROLE GRANTS``
  の抽出をサポートしていません。この動作により、エラーメッセージがこれらのオブジェクトタイプに対応するセクションの抽出されたファイルに書き込まれます。これらのエラーは、移行ポータルによるこれらのファイルの評価において問題を発生させることはありません。

- EDB
  DDLエクストラクタスクリプトは、抽出されたファイルの依存オブジェクトセクションに\ ``object "OBJECT_NAME" of type SYNONYM not found in schema "PUBLIC"``
  エラーをログに記録する場合があります。これは、OracleデータベースがコンテナデータベースであるOracleマルチテナント環境から依存オブジェクトを抽出するオプションをユーザーが選択した場合にのみ発生します。

「スナップショットが古すぎます」エラー
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

EDB
DDLエクストラクタは、データベースサーバーがUNDOテーブルスペースで適切に処理できない大量のトランザクションを生成すると、実行時にエラー「ORA-01555:
snapshot too old」を表示します。

データベースサーバーが高いレートでUNDOトランザクションを生成すると、サーバーがUNDOデータを保存するための領域が不足する場合があります。
UNDOテーブルスペースは循環バッファとして実装されているため、古いUNDOデータブロックの上書きを開始します。このエラーを解決し、EDB
DDLエクストラクタを再実行して、エラーなしでDDLを抽出します。

このエラーをワークアラウンドには、 ``UNDO_RETENTION``
パラメーターの割り当て領域を増やします。

最初に、元に戻す操作用に現在割り当てられている合計領域と現在の空き領域を確認します。

1. ``UNDO_RETENTION`` パラメーターの既存の値を確認します。

.. code:: sql

       SELECT value FROM v$parameter WHERE name = undo_retention;

1. 次の2つのクエリーの結果を加算して、UNDOテーブルスペースの使用可能な合計領域を確認します。

.. code:: sql

       SELECT SUM(bytes)/1024/1024 free_mb FROM dba_undo_extents WHERE status=EXPIRED;

.. code:: sql

       SELECT dfs.tablespace_name, SUM(dfs.bytes) / 1024 / 1024 AS free_mb FROM 
       dba_free_space dfs 
       JOIN dba_tablespaces dt ON dfs.tablespace_name = dt.tablespace_name 
       WHERE dt.contents = UNDO GROUP BY dfs.tablespace_name; 2 3 4

次に、環境が必要なMB数を決定し、割り当てられた記憶領域を増やします。

1. 使用ピーク時間にトランザクションによって生成されたUNDOデータの量を監視します。

.. code:: sql

       SELECT SUM(undoblks * 8192)/1024/1024 AS undo_mbs FROM v$undostat;

!!!note この値は、10分間隔で消費されたUNDOブロックの数を反映していますMBに変換されます。 .. ::
   1. 環境がUNDO表領域に必要とする合計MB数を計算します。たとえば、トランザクションボリュームが1分ごとにX MBのUNDOデータを生成し、要件がY分間データを保持することである場合

UNDO領域MB = X MB/分×Y (分)

1. 必要なMB単位の領域に応じて、\ ``UNDO_RETENTION``
   パラメーターを更新します。この例では、記憶領域を2400 MBに増加します。

.. code:: sql

       ALTER SYSTEM SET UNDO_RETENTION = 2400;
       __OUTPUT__
       System altered.

Oracle Data Pumpユーティリティ
------------------------------

- Oracleの引用演算子\ ``IDENTIFIED BY VALUES q'[:1]'``
  などと\ ``IDENTIFIED BY``
  句を使用してデータベースリンクを作成する場合、移行ポータルはSQLファイルの解析に失敗する場合があります。ファイルを正常に解析するには、実際のパスワード、たとえば、\ ``IDENTIFIED BY my_password``
  を使用してみてください。

- Oracle Data
  Pumpユーティリティによって生成されたDDLには、移行ポータルによって処理されない\ ``ALTER FUNCTION``
  、\ ``ALTER PACKAGE`` 、\ ``ALTER TYPE`` などの\ ``ALTER STATEMENTS``
  が含まれる場合があります。

- Oracle Data Pumpがスキーマモードで実行される場合、つまり、 ``expdp``
  コマンドの実行時に\ ``SCHEMAS``
  パラメーターが使用される場合、プロファイルとロールは抽出されません。エクスポートされるスキーマユーザーにプロファイルが割り当てられている場合、プロファイルはエクスポートされた\ ``impdp``
  ファイルの一部ではないため、移行ポータルでのスキーマユーザーオブジェクトの評価は失敗します。この問題を修正するには、ユーザーオブジェクトターゲットDDLのプロファイルの割り当てを削除し、ユーザー作成オブジェクトを再評価します。

- スキーマモードで\ ``impdp`` または\ ``expdp`` を使用してOracle
  11gから\ ``ROLES`` 、\ ``SYSTEM GRANTS ON ROLES``
  、\ ``OBJECT GRANTS ON ROLES`` 、および\ ``ROLE GRANTS``
  を抽出しようとしているときに、いくつかのエラーが表示される場合があります。回避策は、
  ``full=y``
  オプションを使用することです。これは、エラーなしですべてのスキーマとこれらのオブジェクトタイプを抽出します。

AIコパイロット
--------------

AI
Copilotは、DDLの移行中に発生する問題を支援するように設計されたツールです。
このツールは問題の解決に非常に役立ちますが、生成AIテクノロジーは不正確または無関係な応答を生成する場合があることを理解することが重要です。
推奨されるソリューションの精度と品質は、
:ref:`How to create good prompts <How to create good prompts>` に大きく影響されます。

提案されたソリューションを運用環境に適用する前に、制御されたテスト環境でソリューションをテストして、提案された修正が特定の移行要件と一致することを確認することを強くお勧めします。

この最初のリリースでは、AIコパイロットの応答時間が予想よりも遅くなる場合があります。
