Known issues, limitations, and notes¶

このページには、次の既知の問題、制限事項、および注意事項がリストされています。

Using Migration Portal - EDB DDLエクストラクタを使用したスキーマの抽出 - Extracting schemas using Oracle Data Pump utilities

Migration Portal¶

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

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

ファイルのエンコード¶

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

Tip

Linux の iconv ユーティリティまたはWindowsの LibIconv ユーティリティを使用して、抽出されたファイルを UTF-8 形式に手動で変換できます。たとえば、データベースの文字セットが Latin-1 (ISO-8859-1) である場合、次のように、抽出されたファイルを UTF-8 形式に変換できます。

ALTER ステートメント¶

ALTER TABLE と ALTER TRIGGER を除き、Migration PortalはDDL内の他の ALTER ステートメントを処理しません。

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

付与¶

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

現在、権限はユーザーオブジェクトとロールオブジェクトに付加されているため、ユーザーに権限を付与されている 1 つ以上のオブジェクトが失敗すると、ユーザーオブジェクト自体の評価が失敗します。この問題を解決するには、失敗したオブジェクトの許可ステートメントを、個々のステートメントに対してSQL単一行コメント (-- ) を使用するか、連続する許可ステートメントに対してSQL複数行コメント (/ ** / ) を使用してコメントアウトしてから、オブジェクトを再評価します。実行される。失敗したグラントステートメントに対応する失敗したオブジェクトが修復された後、以前に失敗したグラントステートメントのコメントを解除して、ユーザーオブジェクトを再評価できます。

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

特権¶

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

プロファイルを移行するための SUPERUSER
ユーザーとロールを移行するための SUPERUSER または CREATE ROLE

パスワード¶

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

プロフィール¶

Migration Portalは、スキーマユーザーに割り当てられた非 DEFAULT プロファイルを移行します。 Oracle プロファイルには、パスワードとリソース制限の両方が含まれます。 EDB Postgres Advanced Server は、 Oracle パスワード関連の制限のみをサポートします。リソース制限はプロファイルで抽出されますが、パスワード制限のみがMigration Portalによってアップロード、評価、移行されます。また、Oracle データベースでは、DEFAULT プロファイルが新しい制限値で上書きされている可能性があります。 DEFAULT プロファイルは、Migration Portalによって移行されません。 Oracle DEFAULT プロファイルに適用されている制限オーバーライドを使用してEDB Postgres Advanced Serverの DEFAULT プロファイルを構成する場合は、ALTER PROFILE ステートメントを使用してターゲットのEDB Postgres Advanced Serverデータベースに制限オーバーライドを手動で適用する必要があります。

注釈

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

Oracle のデフォルトのケースを使用する¶

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

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

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

ビューおよびマテリアライズド・ビューの SELECT ステートメント内の列名。
チェック制約内の列名。
トリガーヘッダー内のテーブル名と列名。

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

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

- - 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 のケースを維持するためにテーブル/オブジェクトが二重引用符で囲まれた大文字になっているのに対し、障害が発生したオブジェクトでは二重引用符なしで参照されていることが原因で発生します。例えば：

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 ;

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

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

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

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;

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

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

テーブルの列データ型に TYPE 参照がある場合、大文字と小文字の違いにより失敗します。例えば：

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
);

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

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

EDB DDLエクストラクタ¶

EDB DDLエクストラクタスクリプトは、Flashback を使用して復元された、BIN$b54+4XlEYwPgUAB/AQBWwA==$0 のような名前がまだ残っているオブジェクトを抽出しません。これらのオブジェクトを抽出する場合は、オブジェクトの名前を変更し、抽出プロセスを再実行する必要があります。
EDB DDLエクストラクタは、 nologging テーブルを通常のテーブルとして抽出します。これらのテーブルがEDB Postgres Advanced Serverに移行されると、WAL ログファイルが作成されます。
EDB DDLエクストラクタは、 VALID ステータスのオブジェクトのみを抽出します。Migration Portalで評価する必要がある INVALID ステータスを持つオブジェクトについては、まずそれらを VALID に更新します。
EDB DDLエクストラクタは、 Oracle ラップ機能を使用して難読化されたオブジェクトを抽出しません。そのため、これらのオブジェクトは、Migration Portalによって評価されるDDLのセットには含まれません。これらのオブジェクトを評価してEDB Postgres Advanced Serverに移行する場合は、オブジェクトのラップされたバージョンをラップされていないバージョンに置き換えます。詳細については、ラップされたオブジェクトを参照してください。
EDB DDLエクストラクタは、スキーマ名とその依存関係情報を保存するグローバル一時テーブルを作成します。これらのテーブルは、抽出が成功すると削除されます。
EDB DDLエクストラクタスクリプトは、名前が PG_ で始まるスキーマを抽出しません。これは、PostgreSQL がサポートしていないためです。これらのスキーマを抽出する場合は、抽出前にスキーマの名前を変更する必要があります。
EDB DDLエクストラクタは、プロファイル、ロール、および付与の情報を自動的に抽出します。
EDB DDLエクストラクタは現在、Oracle 11g からの ROLES 、SYSTEM GRANTS ON ROLES 、OBJECT GRANTS ON ROLES 、および ROLE GRANTS の抽出をサポートしていません。この動作により、抽出されたファイルのこれらのオブジェクトタイプに対応するセクションにエラーメッセージが書き込まれます。これらのエラーは、Migration Portalによるこれらのファイルの評価に問題を引き起こすことはありません。

Oracle データポンプユーティリティ¶

Oracle の引用演算子 (IDENTIFIED BY VALUES q'[:1]' など) を含む IDENTIFIED BY 句を使用してデータベースリンクを作成する場合、Migration PortalはSQLファイルの解析に失敗する可能性があります。ファイルを正常に解析するには、IDENTIFIED BY my_password などの実際のパスワードを使用してみてください。
Oracle Data Pumpユーティリティによって生成されたDDLには、Migration Portalによって処理されないALTER FUNCTION 、ALTER PACKAGE およびALTER TYPE などのALTER STATEMENTS が含まれる場合があります。
Oracle Data Pumpがスキーマ・モードで実行される場合、つまり、expdp コマンドの実行時にSCHEMAS パラメータが使用される場合、プロファイルとロールは抽出されません。エクスポートされるスキーマユーザーにプロファイルが割り当てられている場合、そのプロファイルはエクスポートされた impdp ファイルの一部ではないため、Migration Portalでのスキーマユーザーオブジェクトの評価は失敗します。この問題を解決するには、ユーザーオブジェクトのターゲットDDLでプロファイルの割り当てを削除し、ユーザー作成オブジェクトを再評価します。
スキーマモードで impdp または expdp を使用して Oracle 11g から ROLES 、SYSTEM GRANTS ON ROLES 、OBJECT GRANTS ON ROLES 、および ROLE GRANTS を抽出しようとすると、エラーが発生する場合があります。回避策は、full=y オプションを使用することです。これにより、すべてのスキーマとこれらのオブジェクトタイプがエラーなく抽出されます。

Known issues, limitations, and notes¶

Migration Portal¶

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

ファイルのエンコード¶

ALTER ステートメント¶

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

付与¶

特権¶

パスワード¶

プロフィール¶

Oracle のデフォルトのケースを使用する¶

EDB DDLエクストラクタ¶

Oracle データポンプユーティリティ¶

前のトピックへ

目次

Known issues, limitations, and notes¶

Migration Portal¶

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

ファイルのエンコード¶

ALTER ステートメント¶

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

付与¶

特権¶

パスワード¶

プロフィール¶

Oracle のデフォルトのケースを使用する¶

EDB DDLエクストラクタ¶

Oracle データ ポンプ ユーティリティ¶

Oracle データポンプユーティリティ¶