Informazioni sugli spazi di lavoro di conversione legacy
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
I workspace della conversione legacy sono un tipo di workspace della conversione precedente e più limitato. I workspace della conversione legacy non supportano le funzionalità di conversione avanzate con Gemini o l'editor SQL interattivo. Puoi utilizzarli solo per convertire lo schema di origine con lo strumento di migrazione Ora2Pg.
Non consigliamo di utilizzare il tipo precedente di spazi di lavoro di conversione per le migrazioni, in quanto presentano diverse altre limitazioni al flusso di lavoro di conversione:
Workspace di conversione interattivo
Workspace di conversione legacy
La conversione di schema e oggetti di codice avviene in Database Migration Service.
Esegui le conversioni di schemi e oggetti di codice al di fuori di Database Migration Service utilizzando lo strumento di migrazione Ora2Pg.
Puoi applicare le origini convertite al database di destinazione direttamente in Database Migration Service.
Sei responsabile dell'applicazione dello schema convertito al database di destinazione nell'istanza di destinazione Cloud SQL per PostgreSQL.
Puoi testare la bozza di schema e il codice direttamente in Database Migration Service per assicurarti che possano essere applicati correttamente all'istanza di destinazione.
Non puoi testare la bozza di schema e il codice senza influire
sull'istanza di destinazione.
Aggiunge automaticamente le colonne rowid mancanti per le tabelle che
non hanno chiavi primarie e vincoli univoci.
Devi aggiungere le chiavi primarie mancanti alle tabelle di destinazione dopo aver
applicato lo schema.
Tabella 1: confronto delle funzionalità dell'area di lavoro della conversione
Utilizzare i workspace di conversione legacy
Se il tuo scenario richiede l'utilizzo delle aree di lavoro di conversione precedenti,
modifica la procedura di migrazione con le seguenti azioni:
Scrivi un file di configurazione Ora2Pg.
Consulta la
documentazione di Ora2Pg per istruzioni su come utilizzare
lo strumento di conversione Ora2Pg. Espandi le sezioni seguenti per visualizzare l'elenco completo delle direttive supportate in Database Migration Service.
Configurazione Ora2Pg supportata in Database Migration Service
Database Migration Service supporta i seguenti elementi di configurazione per i file 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 utilizza i profili di connessione per definire i dettagli di connettività, in modo da non dover definire le seguenti informazioni nel file di configurazione Or2Pg:
ORACLE_DSN
ORACLE_HOME
ORACLE_PWD
ORACLE_USER
PG_DSN
PG_PWD
PG_USER
Inoltre, Database Migration Service non utilizza la direttiva di configurazione WHERE
per limitare i record da migrare.
Applica manualmente lo schema convertito al database di destinazione.
Dopo aver creato la configurazione Ora2Pg e l'area di lavoro,
devi applicare il codice generato direttamente al database di destinazione.
Esegui la migrazione delle tabelle senza chiavi primarie.
Database Migration Service esegue la migrazione solo delle tabelle con chiavi primarie.
Se il database di origine include tabelle senza chiavi primarie,
devi creare manualmente chiavi primarie o vincoli univoci nelle
tabelle convertite nel database di destinazione dopo aver
applicato lo schema convertito. Espandi la sezione seguente per ulteriori dettagli.
Aggiungi vincoli di chiave primaria nel database di destinazione
Per eseguire la migrazione delle tabelle Oracle senza chiavi primarie:
Connettiti all'istanza Cloud SQL di destinazione con un client SQL. Puoi
utilizzare i seguenti metodi:
psql client. Puoi utilizzare questo metodo per connetterti
all'IP privato dell'istanza, ma potrebbe essere necessario creare
una macchina virtuale Compute Engine.
comando gcloud sql connect. Questo comando
funziona solo per le istanze Cloud SQL con un indirizzo IP pubblico
abilitato.
Crea i vincoli di chiave primaria mancanti per le tue tabelle. Per saperne di più sulle chiavi primarie, consulta la sezione
Chiavi primarie nella documentazione di PostgreSQL.
Puoi anche espandere le seguenti sezioni per visualizzare comandi SQL di esempio:
Creare chiavi primarie utilizzando le colonne esistenti
La tabella potrebbe già avere una chiave primaria logica basata su una
colonna o una combinazione di colonne. Ad esempio, potrebbero esserci
colonne con un indice o un vincolo univoco configurato. Utilizza queste
colonne per generare una nuova chiave primaria per le tabelle nel database di origine. Ad esempio:
ALTERTABLETABLE_NAMEADDPRIMARYKEY(COLUMN_NAME);
Crea una chiave primaria utilizzando tutte le colonne
Se non hai un vincolo preesistente che possa fungere da chiave primaria, crea chiavi primarie utilizzando tutte le colonne della tabella. Assicurati
di non superare la lunghezza massima della chiave primaria
consentita dall'istanza PostgreSQL. Ad esempio:
Quando crei una chiave primaria composita come questa, devi elencare
esplicitamente tutti i nomi delle colonne che vuoi utilizzare. Non è possibile utilizzare un'istruzione
per recuperare tutti i nomi delle colonne a questo scopo.
Crea un vincolo univoco con la pseudocolonna ROWID
I database Oracle utilizzano la
pseudocolonna ROWID per memorizzare
la posizione di ogni riga in una tabella. Per eseguire la migrazione delle tabelle Oracle
che non hanno chiavi primarie, puoi aggiungere una colonna ROWID
nel database PostgreSQL di destinazione. Database Migration Service
compila la colonna con i valori numerici corrispondenti della
pseudocolonna ROWID di Oracle di origine.
Per aggiungere la colonna e impostarla come chiave primaria, esegui il comando seguente:
Dopo aver eseguito il flusso di lavoro di conversione con il workspace legacy,
puoi procedere con le procedure di migrazione standard. Vedi
Creare un job di migrazione.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 UTC."],[],[],null,["# About legacy conversion workspaces\n\nLegacy conversion workspaces are an older, more limited type of conversion\nworkspaces. Legacy conversion workspaces don't support Gemini-enhanced\nconversion features or the interactive SQL editor. You can only use them to convert your\nsource schema with the Ora2Pg migration tool.\n| **Important:** Database Migration Service supports Ora2Pg versions `21.1` - `23.2`.\n\nWe don't recommend using the legacy type of conversion workspaces for your\nmigrations as they present multiple other limitations to the conversion\nworkflow:\n\nUse legacy conversion workspaces\n--------------------------------\n\nIf your scenario requires the use of legacy conversion workspaces,\nmodify the migration process with the following actions:\n\n1. Write an Ora2Pg configuration file.\n\n Refer to the\n [Ora2Pg documentation](https://ora2pg.darold.net/documentation.html#CONFIGURATION) for guidance on how to use\n the Ora2Pg conversion tool. Expand the following sections for the full\n list of directives supported in Database Migration Service. \n\n #### Ora2Pg configuration supported in Database Migration Service\n\n Database Migration Service supports the following configuration items for Ora2Pg files:\n - `BOOLEAN_VALUES`\n - `DATA_TYPE`\n - `DEFAULT_NUMERIC`\n - `ENABLE_MICROSECOND`\n - `EXPORT_SCHEMA`\n - `MODIFY_STRUCT`\n - `MODIFY_TYPE`\n - `PG_INTEGER_TYPE`\n - `PG_NUMERIC_TYPE`\n - `PG_SCHEMA`\n - `PRESERVE_CASE`\n - `REPLACE_AS_BOOLEAN`\n - `REPLACE_COLS`\n - `REPLACE_TABLES`\n - `REPLACE_ZERO_DATE`\n - `SCHEMA`\n\n Database Migration Service uses connection profiles to define\n connectivity details, so you don't need to define the following information\n in your Or2Pg configuration file:\n - `ORACLE_DSN`\n - `ORACLE_HOME`\n - `ORACLE_PWD`\n - `ORACLE_USER`\n - `PG_DSN`\n - `PG_PWD`\n - `PG_USER`\n\n Additionally, Database Migration Service doesn't use the `WHERE`\n configuration directive to limit the records to migrate.\n2. [Create a legacy conversion workspace, and upload the Ora2Pg file to convert\n your schema](/database-migration/docs/oracle-to-postgresql/create-conversion-workspace#legacy-ws).\n3. Manually apply converted schema to the destination database.\n\n\n After you create the Ora2Pg configuration and create the workspace,\n you must apply the generated code by yourself directly on the destination\n database.\n | **Important:** With legacy conversion workspaces, you can't test the schema before you migrate. If you encounter any issues when you apply the converted schema, you need to clear the faulty schema from the destination database, adjust your Ora2Pg file, and re-create the legacy conversion workspace with the Ora2Pg file.\n4. Migrate tables without primary keys.\n\n\n Database Migration Service migrates only tables that have primary keys.\n If your source database includes tables that don't have primary keys,\n you need to manually create primary keys or unique constraints in the\n converted tables in the destination database after you\n apply the converted schema. Expand the following section for more details. \n\n #### Add primary key constraints in the destination database\n\n To migrate Oracle tables without primary keys, do the following:\n 1. Connect to your destination Cloud SQL instance with a SQL client. You can use the following methods:\n - [`psql` client](/sql/docs/postgres/connect-admin-ip). You can use this method to connect to your instance private IP, but it might require that you create a Compute Engine virtual machine.\n - [`gcloud sql connect`](/sdk/gcloud/reference/sql/connect) command. This command works only for Cloud SQL instances that have a public IP address enabled.\n 2. Create the missing primary key constraints for your tables. For more information about primary keys, see [Primary Keys](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-PRIMARY-KEYS) in the PostgreSQL documentation.\n\n You can also expand the following sections to see sample SQL commands: \n\n #### Create primary keys using existing columns\n\n Your table might already have a logical primary key based on a\n column or a combination of columns. For example, there might be\n columns with a unique constraint or index configured. Use these\n columns to generate a new primary key for tables in your source\n database. For example: \n\n ```sql\n ALTER TABLE TABLE_NAME\n ADD PRIMARY KEY (COLUMN_NAME);\n ```\n\n \u003cbr /\u003e\n\n #### Create a primary key using all columns\n\n If you don't have a pre-existing constraint that could serve as a\n primary key, create primary keys using all columns of the table. Make\n sure that you don't exceed the maximum length of the primary key\n allowed by your PostgreSQL instance. For example: \n\n ```sql\n ALTER TABLE TABLE_NAME\n ADD PRIMARY KEY (COLUMN_NAME_1, COLUMN_NAME_2, COLUMN_NAME_3, ...);\n ```\n\n When creating a composite primary key like this, you need to explicitly\n list all column names you want to use. It's not possible to use a statement\n to retrieve all column names for this purpose. \n\n #### Create a unique constraint with the `ROWID` pseudocolumn\n\n Oracle databases use the\n [`ROWID` pseudocolumn](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/ROWID-Pseudocolumn.html) to store\n the location of each row in a table. To migrate Oracle tables\n that don't have primary keys, you can add a `ROWID`\n column in the destination PostgreSQL database. Database Migration Service\n populates the column with the corresponding numeric values from\n the source Oracle `ROWID` pseudocolumn.\n\n To add the column and to set it as the primary key, run the following: \n\n ```sql\n ALTER TABLE TABLE_NAME ADD COLUMN rowid numeric(33,0) NOT NULL;\n CREATE SEQUENCE TABLE_NAME_rowid_seq INCREMENT BY -1 START WITH -1 OWNED BY TABLE_NAME.rowid;\n ALTER TABLE TABLE_NAME ALTER COLUMN rowid SET DEFAULT nextval('\u003cvar translate=\"no\"\u003eTABLE_NAME\u003c/var\u003e_rowid_seq');\n ALTER TABLE TABLE_NAME ADD CONSTRAINT CONSTRAINT_DISPLAY_NAME PRIMARY KEY (rowid);\n ```\n\nWhat's next\n-----------\n\nAfter you perform the conversion workflow with the legacy workspace,\nyou can proceed with the standard migration procedures. See\n[Create a migration job](/database-migration/docs/oracle-to-postgresql/create-migration-job)."]]
