Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Legacy-Konvertierungsarbeitsbereiche sind eine ältere, eingeschränktere Art von Konvertierungsarbeitsbereichen. In Legacy-Arbeitsbereichen für Conversions werden keine Gemini-basierten Conversion-Funktionen oder der interaktive SQL-Editor unterstützt. Sie können sie nur verwenden, um Ihr Quellschema mit dem Ora2Pg-Migrationstool zu konvertieren.
Der Database Migration Service unterstützt Ora2Pg-Versionen 21.1 bis 23.2.
Wir raten davon ab, die Legacy-Version von Conversion-Arbeitsbereichen für Ihre Migrationen zu verwenden, da sie mehrere andere Einschränkungen für den Conversion-Workflow mit sich bringt:
Interaktiver Konvertierungsarbeitsbereich
Legacy-Konvertierungsarbeitsbereich
Die Konvertierung von Schema- und Codeobjekten erfolgt in Database Migration Service.
Sie führen Schema- und Codeobjektkonvertierungen außerhalb von Database Migration Service mit dem Ora2Pg-Migrationstool durch.
Sie können konvertierte Quellen direkt in Database Migration Service auf die Zieldatenbank anwenden.
Sie sind dafür verantwortlich, das konvertierte Schema auf die Zieldatenbank in Ihrem AlloyDB for PostgreSQL-Zielcluster anzuwenden.
Sie können Ihr Schema und Ihren Code direkt in Database Migration Service testen, um sicherzugehen, dass sie erfolgreich auf Ihren Zielcluster angewendet werden können.
Sie können Ihr Schema und Ihren Codeentwurf nicht testen, ohne den Zielcluster zu beeinträchtigen.
Fügt automatisch fehlende rowid-Spalten für Tabellen ohne Primärschlüssel und eindeutige Einschränkungen hinzu.
Sie müssen den Zieltabellen fehlende Primärschlüssel hinzufügen, nachdem Sie das Schema angewendet haben.
Tabelle 1: Vergleich der Funktionen von Konvertierungsarbeitsbereichen
Legacy-Konvertierungsarbeitsbereiche verwenden
Wenn in Ihrem Szenario die Verwendung von Legacy-Conversion-Arbeitsbereichen erforderlich ist, passen Sie den Migrationsprozess mit den folgenden Aktionen an:
Ora2Pg-Konfigurationsdatei schreiben
Informationen zur Verwendung des Ora2Pg-Konvertierungstools finden Sie in der
Ora2Pg-Dokumentation. Maximieren Sie die folgenden Abschnitte, um die vollständige Liste der in Database Migration Service unterstützten Direktiven aufzurufen.
Im Database Migration Service unterstützte Ora2Pg-Konfiguration
Database Migration Service verwendet die folgende Konfiguration für Ora2Pg-Dateien:
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 verwendet Verbindungsprofile, um Verbindungsdetails zu definieren. Daher müssen Sie die folgenden Informationen nicht in Ihrer Or2Pg-Konfigurationsdatei definieren:
ORACLE_DSN
ORACLE_HOME
ORACLE_PWD
ORACLE_USER
PG_DSN
PG_PWD
PG_USER
Außerdem verwendet Database Migration Service die Konfigurationsanweisung WHERE nicht, um die zu migrierenden Datensätze zu begrenzen.
Wenden Sie das konvertierte Schema manuell auf die Zieldatenbank an.
Nachdem Sie die Ora2Pg-Konfiguration und den Arbeitsbereich erstellt haben, müssen Sie den generierten Code selbst direkt auf die Zieldatenbank anwenden.
Tabellen ohne Primärschlüssel migrieren
Database Migration Service migriert nur Tabellen mit Primärschlüsseln.
Wenn Ihre Quelldatenbank Tabellen ohne Primärschlüssel enthält, müssen Sie nach dem Anwenden des konvertierten Schemas manuell Primärschlüssel oder eindeutige Einschränkungen in den konvertierten Tabellen in der Zieldatenbank erstellen. Weitere Informationen finden Sie im folgenden Abschnitt.
Primärschlüssel oder eindeutige Einschränkungen in der Zieldatenbank hinzufügen
So migrieren Sie Oracle-Tabellen ohne Primärschlüssel:
Erstellen Sie die fehlenden Primärschlüsseleinschränkungen für Ihre Tabellen. Weitere Informationen zu Primärschlüsseln finden Sie in der PostgreSQL-Dokumentation unter
Primärschlüssel.
Sie können auch die folgenden Abschnitte maximieren, um Beispiel-SQL-Befehle zu sehen:
Primärschlüssel aus vorhandenen Spalten erstellen
Ihre Tabelle hat möglicherweise bereits einen logischen Primärschlüssel, der auf einer Spalte oder einer Kombination von Spalten basiert. Beispielsweise kann es Spalten mit einer eindeutigen Einschränkung oder einem konfigurierten Index geben. Verwenden Sie diese Spalten, um einen neuen Primärschlüssel für Tabellen in Ihrer Quelldatenbank zu generieren. Beispiel:
ALTERTABLETABLE_NAMEADDPRIMARYKEY(COLUMN_NAME);
Primärschlüssel mit allen Spalten erstellen
Wenn Sie keine vorhandene Einschränkung haben, die als Primärschlüssel dienen könnte, erstellen Sie Primärschlüssel mit allen Spalten der Tabelle. Achten Sie darauf, dass die maximale Länge des Primärschlüssels, die von Ihrem PostgreSQL-Cluster zulässig ist, nicht überschritten wird. Beispiel:
Wenn Sie einen zusammengesetzten Primärschlüssel wie diesen erstellen, müssen Sie alle Spaltennamen, die Sie verwenden möchten, explizit auflisten. Es ist nicht möglich, mit einer Anweisung alle Spaltennamen für diesen Zweck abzurufen.
Eindeutige Einschränkung mit der Pseudospalte ROWID erstellen
In Oracle-Datenbanken wird die Pseudospalte ROWID verwendet, um den Speicherort jeder Zeile in einer Tabelle zu speichern. Wenn Sie Oracle-Tabellen ohne Primärschlüssel migrieren möchten, können Sie in der PostgreSQL-Zieldatenbank eine ROWID-Spalte hinzufügen. Database Migration Service füllt die Spalte mit den entsprechenden numerischen Werten aus der Oracle-Pseudospalte ROWID der Quelle.
Führen Sie den folgenden Befehl aus, um die Spalte hinzuzufügen und als Primärschlüssel festzulegen:
Nachdem Sie den Konvertierungsworkflow mit dem Legacy-Arbeitsbereich ausgeführt haben, können Sie mit den Standardmigrationsverfahren fortfahren. Weitere Informationen finden Sie unter
Migrationsjob erstellen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (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 uses supported the following configuration 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 convert schema](/database-migration/docs/oracle-to-alloydb/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 keys or unique\n constraints in the destination database\n\n To migrate Oracle tables without primary keys, do the following:\n 1. [Connect to your AlloyDB for PostgreSQL cluster with the `psql` client](/alloydb/docs/connect-psql).\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 cluster. 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 \u003cbr /\u003e\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-alloydb/create-migration-job)."]]
