以前のコンバージョン ワークスペースについて

以前のコンバージョン ワークスペースは、より制限の多い古いタイプのコンバージョン ワークスペースです。従来の変換ワークスペースは、Gemini 拡張変換機能やインタラクティブ SQL エディタをサポートしていません。これらのファイルは、Ora2Pg 移行ツールで移行元のスキーマを変換する場合にのみ使用できます。

移行にレガシー タイプのコンバージョン ワークスペースを使用することはおすすめしません。コンバージョン ワークフローに次のような制限が複数あります。

インタラクティブなコンバージョン ワークスペース以前のコンバージョン ワークスペース
スキーマとコード オブジェクトの変換は Database Migration Service で行われます。 スキーマとコード オブジェクトの変換は、Database Migration Service の外部で Ora2Pg 移行ツールを使用して行います。
変換されたソースは、Database Migration Service で移行先データベースに直接適用できます。 変換されたスキーマを AlloyDB for PostgreSQL の移行先クラスタの移行先データベースに適用するのはお客様の責任です。
下書きのスキーマとコードは、Database Migration Service で直接テストして、移行先クラスタに正常に適用できることを確認できます。 宛先クラスタに影響を与えることなく、下書きのスキーマとコードをテストすることはできません。
主キーと一意の制約がないテーブルに、不足している rowid 列が自動的に追加されます。 スキーマを適用した後、不足している主キーを宛先テーブルに追加する必要があります。
表 1: コンバージョン ワークスペースの機能の比較

以前のコンバージョン ワークスペースを使用する

シナリオで以前のコンバージョン ワークスペースを使用する必要がある場合は、次の操作で移行プロセスを変更します。

  1. Ora2Pg 構成ファイルを作成します。

    Ora2Pg 変換ツールの使用方法については、 Ora2Pg のドキュメントをご覧ください。Database Migration Service でサポートされているディレクティブの一覧については、次のセクションをご覧ください。

    Database Migration Service でサポートされている Ora2Pg 構成

    Database Migration Service は、Ora2Pg ファイルに次の構成を使用します。

    • BOOLEAN_VALUES
    • DATA_TYPE
    • DEFAULT_NUMERIC
    • ENABLE_MICROSECOND
    • EXPORT_SCHEMA
    • MODIFY_STRUCT
    • MODIFY_TYPE
    • PG_INTEGER_TYPE
    • PG_NUMERIC_TYPE
    • PG_SCHEMA
    • PRESERVE_CASE
    • REPLACE_AS_BOOLEAN
    • REPLACE_COLS
    • REPLACE_TABLES
    • REPLACE_ZERO_DATE
    • SCHEMA

    Database Migration Service は接続プロファイルを使用して接続の詳細を定義するため、Or2Pg 構成ファイルで次の情報を定義する必要はありません。

    • ORACLE_DSN
    • ORACLE_HOME
    • ORACLE_PWD
    • ORACLE_USER
    • PG_DSN
    • PG_PWD
    • PG_USER

    また、Database Migration Service は、WHERE 構成ディレクティブを使用して移行するレコードを制限しません。
  2. 以前のコンバージョン ワークスペースを作成し、スキーマを変換する。

  3. 変換されたスキーマを手動で移行先データベースに適用します。

    Ora2Pg 構成を作成してワークスペースを作成したら、生成されたコードを宛先データベースに直接適用する必要があります。

  4. 主キーのないテーブルを移行する。

    Database Migration Service は、主キーがあるテーブルのみを移行します。ソース データベースに主キーのないテーブルが含まれている場合は、変換されたスキーマを適用した後、宛先データベースの変換されたテーブルに主キーまたは一意の制約を手動で作成する必要があります。詳細については、次のセクションを開いてください。

    宛先データベースに主キーまたは一意の制約を追加します。

    主キーのない Oracle テーブルを移行する手順は次のとおりです。

    1. psql クライアントを使用して AlloyDB for PostgreSQL クラスタに接続します。
    2. テーブルに不足している主キー制約を作成します。主キーの詳細については、PostgreSQL ドキュメントの 主キーをご覧ください。

      以下のセクションを開いて、SQL コマンドの例を確認することもできます。

      既存の列を使用して主キーを作成する

      テーブルに、列または列の組み合わせに基づく論理主キーがすでに存在している場合があります。たとえば、一意の制約またはインデックスが構成されている列がある場合があります。これらの列を使用して、ソース データベース内のテーブルの新しい主キーを生成します。次に例を示します。

      ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME);

      すべての列を使用して主キーを作成する

      主キーとして機能する既存の制約がない場合は、テーブルのすべての列を使用して主キーを作成します。PostgreSQL クラスタで許可されている主キーの最大長を超えないようにしてください。次に例を示します。

      ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME_1, COLUMN_NAME_2, COLUMN_NAME_3, ...);

      このような複合主キーを作成する場合は、使用するすべての列名を明示的に指定する必要があります。この目的でステートメントを使用してすべての列名を取得することはできません。

      ROWID 疑似列を使用して一意の制約を作成する

      Oracle データベースでは、 ROWID 疑似列を使用して、テーブル内の各行の位置を保存します。主キーのない Oracle テーブルを移行するには、宛先の PostgreSQL データベースに ROWID 列を追加します。Database Migration Service は、移行元の Oracle ROWID 疑似列から対応する数値を列に入力します。

      列を追加して主キーとして設定するには、次のコマンドを実行します。

      ALTER TABLE TABLE_NAME ADD COLUMN rowid numeric(33,0) NOT NULL;
CREATE SEQUENCE TABLE_NAME_rowid_seq INCREMENT BY -1 START WITH -1 OWNED BY TABLE_NAME.rowid;
ALTER TABLE TABLE_NAME ALTER COLUMN rowid SET DEFAULT nextval('TABLE_NAME_rowid_seq');
ALTER TABLE TABLE_NAME ADD CONSTRAINT CONSTRAINT_DISPLAY_NAME PRIMARY KEY (rowid);

次のステップ

以前のワークスペースで変換ワークフローを実行したら、標準の移行手順に進むことができます。 移行ジョブを作成するをご覧ください。