Konvertierungsarbeitsbereiche

Mit Konvertierungsarbeitsbereichen können Sie das Schema und die Objekte aus Ihrer Quelldatenbank in die SQL-Syntax konvertieren, die mit Ihrer Zieldatenbank kompatibel ist. Auf dieser Seite finden Sie eine Übersicht über die Konvertierungsarbeitsbereiche von Database Migration Service:

Bestimmte Datentypen werden für Oracle-Migrationen nicht unterstützt. Weitere Informationen finden Sie unter Bekannte Einschränkungen für Datentypen.

Übersichten zum Konvertierungsfortschritt

Konvertierungsarbeitsbereiche bieten eine umfassende Übersicht mit Informationen zur Gesamtzahl der ausstehenden oder behobenen Konvertierungsprobleme, zu von Gemini unterstützten Erweiterungen und zum allgemeinen Zustand Ihres Konvertierungsprozesses.

Bildschirm „Konvertierungsarbeitsbereich“ mit dem Tab „Konvertierungsübersicht“, auf dem Sie die Anzahl der konvertierten Objekte, Konvertierungsprobleme und von Gemini unterstützte Konvertierungsverbesserungen sehen.
Abbildung 1. Übersichtsbildschirm des Konvertierungsarbeitsbereichs, auf dem Sie den Fortschritt der Konvertierung verfolgen, Probleme ansehen und den resultierenden PostgreSQL-Code prüfen können. (Zum Vergrößern klicken)
Bildschirm „Konvertierungsarbeitsbereich“ mit dem Tab „Konvertierungsübersicht“, auf dem Sie die Anzahl der konvertierten Objekte, Konvertierungsprobleme und von Gemini unterstützte Konvertierungsverbesserungen sehen.

In dieser Ansicht können Sie Objekte in Ihrem Schema nach Typ, Schweregrad des Problems, erforderlichen Maßnahmen oder Umwandlungsstatus filtern.

Bildschirm des Konvertierungsarbeitsbereichs, auf dem zu sehen ist, wie konvertierte Objekte nach Typ oder Status gefiltert werden können.
Abbildung 2. Konvertierte Objekte nach Status und Objekttyp filtern. (Zum Vergrößern klicken)
Bildschirm des Konvertierungsarbeitsbereichs, auf dem zu sehen ist, wie konvertierte Objekte nach Typ oder Status gefiltert werden können.

Weitere Informationen zur Verwendung von Conversion-Übersichten zum Prüfen von Conversion-Ergebnissen finden Sie unter Mit Conversion-Arbeitsbereichen arbeiten.

Deterministischer Code und Schemakonvertierung

Wenn Sie einen Konvertierungsarbeitsbereich erstellen, führt Database Migration Service sofort die erste Schemakonvertierung mit einer Reihe deterministischer Konvertierungsregeln durch, bei denen bestimmte Oracle-Datentypen und -Objekte bestimmten PostgreSQL-Datentypen und -Objekten zugeordnet werden. Dieser Prozess unterstützt eine sehr spezifische Teilmenge der verfügbaren Oracle-Datenbankobjekte.

Die deterministische Codekonvertierung unterstützt die folgenden Oracle-Datenbankobjekte:

Unterstützte Oracle-Schemaelemente

  • Einschränkungen
  • Indexe (nur Indexe, die im selben Schema wie ihre Tabelle erstellt werden)
  • Materialisierte Ansichten
  • Objekttypen (teilweise Unterstützung)
  • Sequenzen
  • Synonyme
  • Tabellen
  • Aufrufe

Unterstützte Oracle-Codeelemente

  • Trigger (nur auf Tabellenebene)
  • Pakete
  • Funktionen
  • Gespeicherte Prozeduren

Interaktiver SQL-Editor

Mit dem interaktiven SQL-Editor können Sie die konvertierte PostgreSQL-Syntax direkt in Database Migration Service ändern. Sie können damit Conversion-Probleme beheben oder das Schema an Ihre Anforderungen anpassen. Einige Objekte können im integrierten Editor nicht geändert werden.

Bearbeitbare Oracle-Objekte

Nachdem Sie den Code und das Schema der Quelldatenbank konvertiert haben, können Sie den generierten SQL-Code für bestimmte Objekttypen mit dem interaktiven Editor ändern. Die folgenden Oracle-Objekte werden vom Editor unterstützt:

  • Tabellentrigger (Berechtigung erforderlich)
  • Materialisierte Ansichten
  • Pakete
  • Funktionen, gespeicherte Prozeduren
  • Synonyme
  • Aufrufe
  • Einschränkungen
  • Indexe
  • Sequenzen

Außerdem werden einige Objekte konvertiert, können aber nicht direkt in Database Migration Service bearbeitet werden. Wenn Sie solche Objekte ändern möchten, müssen Sie die Aktualisierungen direkt in der Zieldatenbank vornehmen, nachdem Sie das konvertierte Schema und den konvertierten Code angewendet haben.

Objekte, die nicht bearbeitet werden können:

  • Benutzerdefinierte Objekttypen
  • Tabellen
  • Schemas

Code- und Schemakonvertierung mit Gemini beschleunigen

In Database Migration Service ist Gemini für Google Cloud in Konvertierungsarbeitsbereiche integriert, um den Konvertierungsprozess in den folgenden Bereichen zu beschleunigen und zu verbessern:

  • Verbessern Sie die deterministischen Konvertierungsergebnisse mit der automatischen Konvertierung auf Gemini-Basis, um die Leistungsfähigkeit von KI zu nutzen und die Anzahl der manuellen Anpassungen in Ihrem PostgreSQL-Code deutlich zu reduzieren.

  • Mit dem Konvertierungsassistenten können Sie Code-Erklärungsfunktionen nutzen: eine Reihe von speziellen Prompts, mit denen Sie die Konvertierungslogik besser nachvollziehen, Korrekturen für Konvertierungsprobleme vorschlagen oder konvertierten Code optimieren können.

  • Mit Gemini-Codekonvertierungsvorschlägen können Sie Korrekturen für Konvertierungsprobleme beschleunigen. Dabei lernt das Gemini-Modell, während Sie Konvertierungsprobleme beheben, und schlägt Änderungen für andere fehlerhafte Objekte im Arbeitsbereich vor.

Weitere Informationen zur mit Gemini optimierten Konvertierung finden Sie auf den folgenden Seiten:

Dateien für die Conversion-Zuordnung

Sie können die Conversion-Logik mit einer Conversion-Zuordnungsdatei anpassen. Die Konvertierungszuordnungsdatei ist eine Textdatei, die genaue Anweisungen (Konvertierungsanweisungen) dafür enthält, wie Ihre Oracle-Objekte in PostgreSQL-Objekte konvertiert werden sollen.

Unterstützte Conversion-Direktiven

Database Migration Service unterstützt die folgenden Konvertierungsanweisungen für Konvertierungszuordnungsdateien:

EXPORT_SCHEMA

EXPORT_SCHEMA ist eine obligatorische Direktive für alle Dateien zur Conversion-Zuordnung. Database Migration Service benötigt diese Anweisung, um sicherzustellen, dass Ihre Quellschemas in die richtigen Zielschemas konvertiert werden. Ihre Dateien für das Conversion-Mapping müssen diese Zeile enthalten: 

EXPORT_SCHEMA 1

SCHEMA

Database Migration Service muss ermitteln können, welches Schema die Objekte enthält, die mit Ihren Konvertierungsanweisungen geändert werden sollen. Mit der Anweisung SCHEMA werden alle anderen Anpassungsanweisungen in Ihrer Datei auf Objekte in diesem bestimmten Schema angewendet.

  • Wenn Sie diese Direktive verwenden, werden auch andere Schemas in Ihrer Datenbank konvertiert, aber ihre Objekte werden nicht geändert.
  • Wenn Sie diese Direktive in die Datei für die Conversion-Zuordnung aufnehmen, werden alle Anpassungen nur auf Objekte angewendet, die in diesem bestimmten Schema enthalten sind.
  • Wenn Sie diese Direktive überspringen, müssen Sie vollständig qualifizierte Objektnamen angeben, die den Schemanamen für Objekte enthalten, die von anderen Konvertierungsdirektiven geändert werden. Wenn Sie beispielsweise SOURCE_TABLE_NAME für die REPLACE_TABLES-Anweisung verwenden, müssen Sie stattdessen "SCHEMA_NAME.SOURCE_TABLE_NAME" verwenden.
  • So passen Sie Objekte in verschiedenen Schemas an:
    • Erstellen Sie separate Dateien für die Conversion-Zuordnung für andere Schemas und laden Sie sie in den Konvertierungsarbeitsbereich hoch.
    • Verwenden Sie für Objekte, die sich in anderen Schemas als dem befinden, das Sie für die SCHEMA-Anweisung angeben, vollqualifizierte Objektnamen, die den Schemanamen enthalten.

Verwenden Sie das folgende Format:

SCHEMA SCHEMA_NAME

Dabei ist SCHEMA_NAME der Name des Schemas in der Quelldatenbank.

CASE_HANDLING

Standardmäßig konvertiert Database Migration Service alle Objektnamen in Kleinbuchstaben. Sie können dieses Verhalten mit der CASE_HANDLING-Anweisung ändern.

  • Diese Anweisung wird von der Anweisung SCHEMA nicht beeinflusst. Sie funktioniert weltweit und betrifft alle Objekte im Konvertierungsarbeitsbereich.
  • Die Anweisungen RENAME_*, MOVE_* und REPLACE_* haben Vorrang vor der Anweisung CASE_HANDLING und benennen Ihre Objekte unabhängig von der Eigenschaft CASE_HANDLING genau um.
  • Wenn diese Direktive in mehreren Konfigurationsdateien mit widersprüchlichen Werten vorhanden ist, gibt Database Migration Service beim Schemaimport einen Fehler aus.

Verwenden Sie das folgende Format:

CASE_HANDLING OPTION

Dabei kann OPTION für folgendes stehen:

  • UPPERCASE: Konvertiert alle Objektnamen in Großbuchstaben.
  • LOWERCASE: Konvertiert alle Objektnamen in Kleinbuchstaben (Standardverhalten).
  • PRESERVE_ORIGINAL: Behält die ursprüngliche Groß-/Kleinschreibung aus dem Quellschema bei. Das ist nützlich, wenn in Ihren Anwendungen case-sensitive Kennungen verwendet werden.

Beispiel:

CASE_HANDLING PRESERVE_ORIGINAL

Objekte umbenennen (RENAME_*)

Sie können verschiedene Datenbankobjekte während der Konvertierung umbenennen. Database Migration Service aktualisiert automatisch alle Codeverweise (in Ansichten, gespeicherten Prozeduren, Funktionen usw.) für die Verwendung der neuen Namen.

Allgemeine Syntax

RENAME_OBJECT_TYPE SOURCE_NAME1:DESTINATION_NAME1 SOURCE_NAME2:DESTINATION_NAME2 ...

Wichtige Hinweise

  • Bei den RENAME_*-Anweisungen wird auf die Groß- und Kleinschreibung geachtet. Sie haben Vorrang vor der CASE_HANDLING-Anweisung. Wenn Sie beispielsweise beide Anweisungen verwenden: 

    SCHEMA MySchema
CASE_HANDLING PRESERVE_ORIGINAL
# Destination objects are renamed exactly
# to 'SoMe_tAbLe' and 'RenamedView', respecting the case
# despite the CASE_HANDLING directive
RENAME_TABLES some_table:SoMe_tAbLe
RENAME_VIEWS MyView:RenamedView

  • Verweisen Sie für SOURCE_NAME immer auf den ursprünglichen Objektnamen, auch wenn Sie andere Direktiven wie MOVE_* verwenden. Wenn Sie beispielsweise eines Ihrer Ansichtsobjekte umbenennen und in ein neues Schema verschieben möchten, verweisen Sie in beiden Direktiven auf den ursprünglichen Ansichtsnamen: 

    RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
  • Mit der RENAME_TABLES-Anweisung wird die REPLACE_TABLES-Anweisung in einer einzelnen Datei überschrieben. Wenn Sie eine Tabelle sowohl umbenennen als auch verschieben möchten, empfehlen wir stattdessen die Verwendung der MOVE_*-Anweisung.

  • Das vollständige Format der Variablen SOURCE_NAME hängt davon ab, ob Sie auch die Direktive SCHEMA verwenden:

    • Mit der SCHEMA-Anweisung:Verwenden Sie nicht qualifizierte Namen, z. B. MyTable.
    • Ohne SCHEMA-Anweisung:Verwenden Sie vollqualifizierte Namen, z. B. MySchema.MyTable.

Unterstützte RENAME_*-Direktiven

  • RENAME_SCHEMA: Benennt ein Schema um.
    Eine einzelne Konfigurationsdatei kann nur eine RENAME_SCHEMA-Anweisung enthalten. Wenn die SCHEMA-Anweisung angegeben ist, kann RENAME_SCHEMA nur dieses bestimmte Schema umbenennen.
  • RENAME_TABLES: Benennt Tabellen um. Überschreibt die REPLACE_TABLES in derselben Datei.
  • RENAME_COLUMNS: Benennt Spalten in Tabellen um. Überschreibt die REPLACE_COLS-Anweisung in derselben Datei. Verwenden Sie das folgende Format: 
    RENAME_COLUMNS TABLE1.SRC_COL:DEST_COL TABLE2.SRC_COL:DEST_COL

    Wenn Sie die SCHEMA-Anweisung verwenden, müssen Sie nicht qualifizierte Tabellennamen verwenden. Wenn Sie die SCHEMA-Anweisung nicht verwenden, geben Sie die voll qualifizierten Tabellennamen an, z. B. SCHEMA.TABLE1.

  • RENAME_VIEWS
  • RENAME_MATERIALIZED_VIEWS
  • RENAME_SEQUENCES
  • RENAME_FUNCTIONS
  • RENAME_STORED_PROCEDURES
  • RENAME_TRIGGERS

  • RENAME_PACKAGES: Database Migration Service konvertiert Oracle-Pakete in PostgreSQL-Schemas. Wenn Ihr Schema Pakete mit gemeinsamen Namen enthält, kann es im PostgreSQL-Code zu Namenskonflikten kommen, wenn versucht wird, zwei Schemas mit demselben Namen zu erstellen. Mit dieser Direktive können Sie solche Konflikte vermeiden.

    Wenn Sie beispielsweise Pakete wie SALES.REPORTING_PKG und HR.REPORTING_PKG haben, können Sie sie in eindeutige Namen umbenennen: 

    RENAME_PACKAGES SALES.UTILS:SALES_UTILS
RENAME_PACKAGES HR.UTILS:HR_UTILS

  • RENAME_USER_DEFINED_TYPES

    Verfügbares Alias: RENAME_UDTS.

Objekte verschieben (MOVE_*)

Sie können Objekte in der Zieldatenbank in andere Schemas verschieben. Das ist nützlich, um die Datenbankstruktur während der Migration neu zu organisieren. Database Migration Service aktualisiert automatisch alle Codeverweise in Ansichten, gespeicherten Prozeduren, Funktionen usw.

Allgemeine Syntax

MOVE_OBJECT_TYPE SOURCE_NAME1:DESTINATION_SCHEMA1 SOURCE_NAME2:DESTINATION_SCHEMA2 ...

Wichtige Hinweise

  • Verweisen Sie für SOURCE_NAME immer auf den ursprünglichen Objektnamen, auch wenn Sie andere Direktiven wie RENAME_* verwenden. Wenn Sie beispielsweise eines Ihrer Ansichtsobjekte umbenennen und in ein neues Schema verschieben möchten, verweisen Sie in beiden Direktiven auf den ursprünglichen Ansichtsnamen: 

    RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
  • Die Richtlinie erwartet nur den Namen DESTINATION_SCHEMA, nicht den vollständigen Objektnamen.

  • Das vollständige Format der Variablen SOURCE_NAME hängt davon ab, ob Sie auch die Direktive SCHEMA verwenden:

    • Mit der SCHEMA-Anweisung:Verwenden Sie nicht qualifizierte Namen, z. B. MyTable.
    • Ohne SCHEMA-Anweisung:Verwenden Sie vollqualifizierte Namen, z. B. MySchema.MyTable.

Unterstützte MOVE_*-Direktiven

  • MOVE_TABLES: Verschiebt Tabellen in ein anderes Schema. Hat Vorrang vor REPLACE_TABLES für Schemaänderungen in einer einzelnen Konfigurationsdatei.
  • MOVE_VIEWS
  • MOVE_MATERIALIZED_VIEWS
  • MOVE_SEQUENCES
  • MOVE_FUNCTIONS
  • MOVE_STORED_PROCEDURES

  • MOVE_USER_DEFINED_TYPES

    Verfügbares Alias: MOVE_UDTS.

Beispiel: Schemas neu organisieren

SCHEMA LegacyApp

# Moves the 'LegacyApp.Users' and 'LegacyApp.Orders' tables
# to the 'data' schema.
MOVE_TABLES Users:data Orders:data

# Moves the 'LegacyApp.CreateUser' and 'LegacyApp.ProcessOrder'
# stored procedures to the 'api' schema
MOVE_STORED_PROCEDURES CreateUser:api ProcessOrder:api

# Moves the 'LegacyApp.SalesSummary' views to the 'reporting' schema
MOVE_VIEWS SalesSummary:reporting

DATA_TYPE

Mit dieser Direktive können Sie jeden unterstützten Datentyp explizit zwischen Oracle- und PostgreSQL-Syntax zuordnen. Diese Direktive erwartet eine durch Kommas getrennte Liste von Zuordnungen. Die gesamte Definition muss in einer einzigen Zeile angegeben werden. Sie können jedoch mehrere DATA_TYPE-Anweisungen in Ihre Konfigurationsdatei aufnehmen. Verwenden Sie das folgende Format: 

DATA_TYPE ORACLE_DATA_TYPE1:PGSQL_DATA_TYPE1
DATA_TYPE ORACLE_DATA_TYPE2:PGSQL_DATA_TYPE2...

Dabei sind ORACLE_DATA_TYPE und PGSQL_DATA_TYPE Datentypen, die von den jeweiligen Oracle- und PostgreSQL-Versionen unterstützt werden, die Sie für die Migration verwenden. Informationen zu unterstützten Versionen finden Sie unter Szenarioübersicht.

Beispiel:

DATA_TYPE REAL:double precision,SMALLINT:integer

Weitere Informationen zu Oracle- und PostgreSQL-Datentypen finden Sie unter:

MODIFY_TYPE

Mit der MODIFY_TYPE-Anweisung können Sie festlegen, in welchen Datentyp Database Migration Service eine bestimmte Spalte in der Quelltabelle konvertiert. Diese Direktive erwartet eine durch Kommas getrennte Liste von Zuordnungen. Die gesamte Definition muss in einer einzigen Zeile angegeben werden. Sie können jedoch mehrere MODIFY_TYPE-Anweisungen in Ihre Konfigurationsdatei aufnehmen. Verwenden Sie das folgende Format: 

MODIFY_TYPE SOURCE_TABLE_NAME1:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE
MODIFY_TYPE SOURCE_TABLE_NAME2:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE...

Wobei:

  • SOURCE_TABLE_NAME ist der Name der Tabelle, die die Spalte enthält, deren Datentyp Sie ändern möchten.
  • COLUMN_NAME ist der Name der Spalte, für die Sie die Conversion-Zuordnung anpassen möchten.
  • EXPECTED_END_RESULT_DATA_TYPE ist der PostgreSQL-Datentyp, der für die konvertierte Spalte verwendet werden soll.

Beispiel:

MODIFY_TYPE events:dates_and_times:DATETIME,users:pseudonym:TEXT

PG_INTEGER_TYPE

Standardmäßig konvertiert Database Migration Service die NUMBER(p,s)-Typen in den PostgreSQL-Typ DECIMAL(p,s).

Sie können dieses Verhalten mit der Direktive PG_INTEGER_TYPE ändern. Legen Sie den Wert auf 1 fest und erzwingen Sie, dass alle Ihre NUMBER-Typen mit Genauigkeit und Skalierung (NUMBER(p,s)) basierend auf der Anzahl der Genauigkeitsziffern in die PostgreSQL-Typen smallint, integer oder bigint konvertiert werden.

Fügen Sie Ihrer Datei für die Conversion-Zuordnung die folgende Einstellung hinzu: 

PG_INTEGER_TYPE 1

PG_NUMERIC_TYPE

Legen Sie diese Direktive auf 1 fest, wenn Sie alle Ihre NUMBER-Typen mit Genauigkeit und Skalierung (NUMBER(p,s)) in PostgreSQL-Typen real oder float konvertieren möchten (basierend auf der Anzahl der Genauigkeitsziffern).

Wenn Sie diese Direktive auf 0 festlegen, behalten Ihre NUMBER(p,s)-Werte ihren genauen Originalwert und verwenden den internen PostgreSQL-Datentyp.

Fügen Sie Ihrer Datei für die Conversion-Zuordnung die folgende Einstellung hinzu: 

PG_NUMERIC_TYPE 1

DEFAULT_NUMERIC

Die Standardkonvertierung für NUMBER ohne Genauigkeit ändert sich, je nachdem, ob Sie auch die PG_INTEGER_TYPE-Anweisung verwenden:

  • Wenn Sie die Direktive PG_INTEGER verwenden, werden NUMBERs ohne Genauigkeit in DECIMAL-Werte konvertiert.
  • Wenn Sie die PG_INTEGER-Anweisung nicht verwenden, werden NUMBER ohne Genauigkeit in BIGINT-Werte konvertiert.

Sie können dieses Verhalten ändern und mit der Direktive DEFAULT_NUMERIC angeben, welcher Datentyp für NUMBER-Typen ohne angegebene Dezimalstellen verwendet werden soll. Verwenden Sie das folgende Format: 

DEFAULT_NUMERIC POSTGRESQL_NUMERIC_DATA_TYPE

Dabei steht POSTGRESQL_NUMERIC_DATA_TYPE für integer, smallint oder bigint.

Beispiel:

DEFAULT_NUMERIC integer

REPLACE_COLS

Mit der Anweisung REPLACE_COLS können Sie Spalten in Ihrem konvertierten Schema umbenennen. Diese Direktive erwartet eine durch Kommas getrennte Liste von Zuordnungen.

Verwenden Sie das folgende Format: 

REPLACE_COLS SOURCE_TABLE_NAME1(SOURCE1_TABLE1_COLUMN_NAME1:DESTINATION_TABLE1_COLUMN_NAME1,SOURCE_TABLE1_COLUMN_NAME2:DESTINATION_TABLE1_COLUMN_NAME2),SOURCE_TABLE_NAME2(SOURCE_TABLE2_COLUMN_NAME1:DESTINATION_TABLE2_COLUMN_NAME1,SOURCE_TABLE2_COLUMN_NAME2:DESTINATION_TABLE2_COLUMN_NAME2)...

Wobei:

  • SOURCE_TABLE_NAME ist der Name der Tabelle, die die Spalte enthält, deren Namen Sie ändern möchten. Wenn Sie die SCHEMA-Anweisung nicht verwenden, müssen Sie den voll qualifizierten Tabellennamen angeben: SCHEMA_NAME.SOURCE_TABLE_NAME.
  • SOURCE_COLUMN_NAME ist der Name der Spalte in Ihrer Quelle, deren Namen Sie ändern möchten.
  • DESTINATION_COLUMN_NAME ist der neue Name für die Spalte, die Sie im konvertierten Schema verwenden möchten.

Beispiel:

REPLACE_COLS events(dates_and_times:event_dates),users(pseudonym:nickname)

REPLACE_TABLES

Mit der Anweisung REPLACE_TABLES können Sie Tabellen umbenennen oder in ein neues Schema verschieben. Diese Direktive erwartet eine Liste von Zuordnungen, die durch Leerzeichen getrennt sind. Weitere Informationen zur Syntax für die einzelnen Anwendungsfälle finden Sie in den folgenden Abschnitten.

Wenn Sie die SCHEMA-Anweisung nicht verwenden, müssen Sie die voll qualifizierten Tabellennamen in Anführungszeichen für die Quell- und Zielvariablen angeben:

  • "SCHEMA_NAME.SOURCE_TABLE_NAME"
  • "SCHEMA_NAME.DESTINATION_TABLE_NAME"

Tabellen umbenennen

Verwenden Sie das folgende Format, um Tabellen in Ihrem konvertierten Schema umzubenennen:

REPLACE_TABLES SOURCE_TABLE_NAME1:DESTINATION_TABLE_NAME1 SOURCE_TABLE_NAME2:DESTINATION_TABLE_NAME2

Wobei:

  • SOURCE_TABLE_NAME ist der Name der Quelltabelle, die Sie im konvertierten Schema umbenennen möchten.
  • DESTINATION_TABLE_NAME ist der neue Name für die Tabelle, die Sie im konvertierten Schema verwenden möchten.

Beispiel:

REPLACE_TABLES "events:login_events" "users:platform_users"

Tabellen zwischen Schemas verschieben

Mit dieser Direktive können Sie Tabellen zwischen Schemas verschieben, indem Sie dem neuen Tabellennamen das Schemapräfix hinzufügen. Dieser Mechanismus kann unabhängig davon verwendet werden, wie Sie die SCHEMA-Anweisung für die gesamte Konvertierungsdatei verwenden. Beispiel: 

REPLACE_TABLES "events:NEW_SCHEMA_NAME.login_events"

Aliase zum Anpassen von Datentypen

Wenn Sie Konvertierungsanweisungen verwenden, um zu ändern, wie Database Migration Service verschiedene Datentypen konvertiert (z. B. mit den Anweisungen DATA_TYPE, MODIFY_TYPE oder PG_NUMERIC_TYPE), können Sie Aliase anstelle Ihrer SQL-Quelldatentypen verwenden.

Maximieren Sie den folgenden Abschnitt, um die Liste der von Database Migration Service unterstützten Datentyp-Aliase aufzurufen.

Datentyp-Aliasse

Alias Konvertiert in PostgreSQL-Typ
bigint, int8 BIGINT
bool, boolean BOOLEAN
bytea BYTEA
char, character CHAR
character varying, varchar VARCHAR
date DATE
decimal, numeric DECIMAL
double precision, float8 DOUBLE PRECISION
real, float4 REAL
int, integer, int4 INTEGER
int2 SMALLINT
interval INTERVAL
json JSON
smallint SMALLINT
text TEXT
time TIME
timestamp TIMESTAMP
timestamptz TIMESTAMPTZ
timetz TIMETZ
uuid UUID
XML XML

Beispiel für eine Datei zur Conversion-Zuordnung

Unten sehen Sie eine Beispielzuordnungsdatei für die Konvertierung, in der einige der unterstützten Schema-Konvertierungsanweisungen verwendet werden:

EXPORT_SCHEMA 1
SCHEMA root

# Preserve original casing for all objects
CASE_HANDLING PRESERVE_ORIGINAL

# Data type conversions
PG_NUMERIC_TYPE 0
PG_INTEGER_TYPE 1
DEFAULT_NUMERIC integer
DATA_TYPE NUMBER(4\,0):integer
MODIFY_TYPE events:dates_and_times:TIMESTAMP

# Renaming objects using the RENAME_* directives
# These allow case-sensitive destination names
RENAME_TABLES events:LoginEvents users:PlatformUsers
RENAME_COLUMNS events.dates_and_times:EventDates users.pseudonym:Nickname
RENAME_VIEWS InternalReport:FinInternalReport

# Moving objects to new schemas using the MOVE_* directives
MOVE_TABLES audit_log:archive
MOVE_VIEWS InternalReport:reporting

Die Ergebnisse der Verwendung dieser Datei sind wie folgt:

  • EXPORT_SCHEMA 1 ist eine erforderliche Anweisung.
  • Durch SCHEMA root werden die anderen Direktiven auf Objekte im root-Schema angewendet, sofern keine vollständig qualifizierten Namen verwendet werden.
  • Mit CASE_HANDLING PRESERVE_ORIGINAL wird dafür gesorgt, dass alle Objektnamen aus dem Quellschema root ihre ursprüngliche Groß-/Kleinschreibung im Ziel beibehalten, sofern sie nicht durch eine RENAME_*-Anweisung überschrieben werden.
  • Mit PG_INTEGER_TYPE 1 werden alle numerischen Oracle-Datentypen, die in Tabellen im root-Schema gefunden werden, von Database Migration Service in PostgreSQL-spezifische Typen anstelle von ANSI-kompatiblen numerischen Typen konvertiert.
  • Mit DEFAULT_NUMERIC integer werden NUMBER-Werte ohne angegebene Genauigkeit von Database Migration Service in den PostgreSQL-Typ INTEGER konvertiert.
  • DATA_TYPE NUMBER(4\,0):integer führt dazu, dass der Database Migration Service bestimmte NUMBER(4,0)-Werte in PostgreSQL-INTEGER-Werte konvertiert.
  • Die MODIFY_TYPE events:dates_and_times:TIMESTAMP-Anweisung bewirkt, dass der Database Migration Service die Daten in der Spalte dates_and_times der Quelltabelle events speziell in den PostgreSQL-Typ TIMESTAMP konvertiert.
  • RENAME_TABLES events:LoginEvents users:PlatformUsers benennt Tabellen um und behält die angegebene Groß-/Kleinschreibung bei:
    • Die Tabelle events wird in LoginEvents umbenannt.
    • Die Tabelle users wird in PlatformUsers umbenannt.
  • RENAME_COLUMNS events.dates_and_times:EventDates user.pseudonym:Nickname benennt Spalten um und behält die angegebene Groß-/Kleinschreibung im Ziel bei:
    • In der Tabelle LoginEvents (Originalname events) wird die Spalte dates_and_times in EventDates umbenannt.
    • In der Spalte PlatformUsers (Originalname users) wird pseudonym in Nickname umbenannt.
  • Mit RENAME_VIEWS InternalReport:FinInternalReport wird die Ansicht InternalReport in FinInternalReport umbenannt.
  • Mit MOVE_TABLES audit_log:archive wird die Tabelle audit_log vom Schema root in das Schema archive verschoben.
  • Mit MOVE_VIEWS InternalReport:reporting wird die Ansicht InternalReport in das Schema reporting verschoben. Diese Ansicht wird aufgrund der RENAME_VIEWS-Anweisung auch in FinInternalReport umbenannt. Der Database Migration Service verarbeitet die Abhängigkeit: Das Objekt wird zuerst umbenannt und dann verschoben.

Alte Konvertierungsarbeitsbereiche

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.

Wir empfehlen, für Ihre Migrationen nicht den alten Conversion-Arbeitsbereichstyp zu verwenden. Wenn Sie Legacy-Konvertierungsarbeitsbereiche benötigen, lesen Sie den Abschnitt Legacy-Konvertierungsarbeitsbereiche verwenden.

Nächste Schritte

Weitere Informationen zur Verwendung von Konvertierungsarbeitsbereichen finden Sie unter: