About legacy conversion workspaces

Legacy conversion workspaces are an older, more limited type of conversion workspaces. Legacy conversion workspaces don't support Gemini-enhanced conversion features or the interactive SQL editor. You can only use them to convert your source schema with the Ora2Pg migration tool.

We don't recommend using the legacy type of conversion workspaces for your migrations as they present multiple other limitations to the conversion workflow:

Interactive conversion workspaceLegacy conversion workspace
Schema and code object conversion happens in Database Migration Service. You perform schema and code object conversions outside Database Migration Service by using the Ora2Pg migration tool.
You can apply converted sources to the destination database directly in Database Migration Service. You are responsible for applying the converted schema to the destination database in your Cloud SQL for PostgreSQL destination instance.
You can test your draft schema and code directly in Database Migration Service to ensure they can be successfully applied to your destination instance. You can't test your draft schema and code without affecting the destination instance.
Automatically adds missing rowid columns for tables that don't have primary keys and unique constraints. You must add missing primary keys to destination tables after you apply the schema.
Table 1: Conversion workspace feature comparison

Use legacy conversion workspaces

If your scenario requires the use of legacy conversion workspaces, modify the migration process with the following actions:

  1. Write an Ora2Pg configuration file.

    Refer to the Ora2Pg documentation for guidance on how to use the Ora2Pg conversion tool. Expand the following sections for the full list of directives supported in Database Migration Service.

    Ora2Pg configuration supported in Database Migration Service

    Database Migration Service supports the following configuration items for Ora2Pg files:

    • 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 uses connection profiles to define connectivity details, so you don't need to define the following information in your Or2Pg configuration file:

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

    Additionally, Database Migration Service doesn't use the WHERE configuration directive to limit the records to migrate.
  2. Create a legacy conversion workspace, and upload the Ora2Pg file to convert your schema.

  3. Manually apply converted schema to the destination database.

    After you create the Ora2Pg configuration and create the workspace, you must apply the generated code by yourself directly on the destination database.

  4. Migrate tables without primary keys.

    Database Migration Service migrates only tables that have primary keys. If your source database includes tables that don't have primary keys, you need to manually create primary key constraints in the converted tables in the destination database after you apply the converted schema. Expand the following section for more details.

    Add primary key constraints in the destination database

    To migrate Oracle tables without primary keys, do the following:

    1. Connect to your destination Cloud SQL instance with a SQL client. You can use the following methods:
      • psql client. You can use this method to connect to your instance private IP, but it might require that you create a Compute Engine virtual machine.
      • gcloud sql connect command. This command works only for Cloud SQL instances that have a public IP address enabled.
    2. Create the missing primary key constraints for your tables. For more information about primary keys, see Primary Keys in the PostgreSQL documentation.

      You can also expand the following sections to see sample SQL commands:

      Create primary keys using existing columns

      Your table might already have a logical primary key based on a column or a combination of columns. For example, there might be columns with a unique constraint or index configured. Use these columns to generate a new primary key for tables in your source database. For example: 

      ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME);

      Create a primary key using all columns

      If you don't have a pre-existing constraint that could serve as a primary key, create primary keys using all columns of the table. Make sure that you don't exceed the maximum length of the primary key allowed by your PostgreSQL instance. For example: 

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

      When creating a composite primary key like this, you need to explicitly list all column names you want to use. It's not possible to use a statement to retrieve all column names for this purpose.

What's next

After you perform the conversion workflow with the legacy workspace, you can proceed with the standard migration procedures. See Create a migration job.