Referenz für Konvertierungsprobleme und ‑muster

In Konvertierungsarbeitsbereichen werden alle Konvertierungsprobleme in Gruppen und Kategorien zusammengefasst, damit Sie die Behebung von Konvertierungsfehlern und ‑warnungen besser planen können. Jede Kategorie steht für die Art von Arbeit, die Sie möglicherweise ausführen müssen, um die Probleme zu beheben (Überprüfung, Refactoring, Anpassung von Datentypen). Gruppen ermöglichen eine weitere Aggregation, da sie zwischen bestimmten Fällen auf einer niedrigeren Ebene unterscheiden:

Übersichtsseite des Konvertierungsarbeitsbereichs mit Gruppen und Kategorien von Konvertierungsproblemen
Abbildung 1. Übersichtsbildschirm des Konvertierungsarbeitsbereichs mit Gruppen und Kategorien von Konvertierungsproblemen.
Übersichtsseite des Konvertierungsarbeitsbereichs mit Gruppen und Kategorien von Konvertierungsproblemen

In der folgenden Tabelle sind alle Gruppen von Konvertierungsproblemen aufgeführt, die bei der Schemakonvertierung auftreten können:

ID der Problemgruppe Beschreibung

Ungültiger Quellcode

Mögliche Ursache

Fehler in dieser Gruppe treten häufig auf, wenn im Database Migration Service unbekannte Syntax gefunden wird oder wenn der Oracle-Quellcode ungültig ist, z. B. wenn in einer gespeicherten Prozedur das END;-Schlüsselwort fehlt.

Mögliche Abhilfe

Korrigieren Sie die ungültigen Objekte in der Oracle-Quelldatenbank. Aktualisieren Sie dann den Quellschema-Snapshot im Database Migration Service und versuchen Sie es noch einmal mit der Schemakonvertierung. Alternativ können Sie das Objekt von der Migration ausschließen.

Fehlende referenzierte Objekte

Mögliche Ursache

Database Migration Service verwendet Metadaten von Objekten im Quellbaum, um die Qualität der Codekonvertierung von abhängigen Objekten zu verbessern. Wenn sich Ihr Code auf Objekte bezieht, die nicht im Quellschema enthalten sind, können Konvertierungsprobleme auftreten, da der Database Migration Service die Struktur oder Datentypen für die fehlenden referenzierten Spalten, Attribute oder Objekte nicht ermitteln kann.

Mögliche Fehler in dieser Gruppe sind falsche Datentypen für benutzerdefinierte Typen (User-Defined Types, UDTs) oder Standarddatentypen für VARCHAR für Spalten, Parameter oder Variablen.

Mögliche Abhilfe

Entweder müssen alle referenzierten Objekte dem Quellbaum von Database Migration Service hinzugefügt werden oder Sie müssen den PostgreSQL-Code manuell anpassen, basierend auf Ihrem Wissen über das Quelldatenmodell für die fehlenden Abhängigkeiten.

Tabellen ohne Primärschlüssel

Mögliche Ursache

Für die Migration mit Database Migration Service müssen alle Tabellen einen Primärschlüssel haben. Bei Tabellen ohne Primärschlüssel fügt Database Migration Service der PostgreSQL-Zieltabelle eine NUMERIC-Spalte mit dem Namen rowid hinzu. Diese Spalte wird mit den entsprechenden numerischen Werten aus der Oracle-Pseudospalte ROWID gefüllt. Damit INSERT-Anweisungen nach der Migration nicht fehlschlagen, erstellt Database Migration Service eine Sequenz und verwendet sie, um die rowid-Spalte automatisch zu inkrementieren.

Mögliche Abhilfe

Sie können die Spalte rowid nach der Migration beibehalten oder entfernen.

Nicht unterstützte integrierte Oracle-Funktionen

Mögliche Ursache

Möglicherweise verwenden Sie integrierte Oracle-Funktionen, die nicht unterstützt werden.

Mögliche Abhilfe

Suchen Sie nach ähnlichen Funktionen in PostgreSQL und passen Sie den konvertierten Code entsprechend an. In einigen Fällen wird die fehlende Funktionalität möglicherweise durch die Orafce-Erweiterung bereitgestellt, die sowohl für Cloud SQL for PostgreSQL- als auch für AlloyDB for PostgreSQL-Migrationen verfügbar ist.

SQLCODE wird noch nicht unterstützt

Mögliche Ursache

Die Oracle-Funktion SQLCODE wird für die Konvertierung nicht unterstützt. SQLCODE gibt einen INTEGER-Wert zurück, während die am besten geeignete Entsprechung in PostgreSQL die Funktion SQLSTATE ist, die TEXT-Werte zurückgibt.

Mögliche Abhilfe

Wenn Ihr Quellcode nicht darauf angewiesen ist, dass SQLCODE eine Ganzzahl zurückgibt (z. B. wenn SQLCODE nur in einer VARCHAR2-Spalte oder mit einer DBMS_OUTPUT-Meldung protokolliert wird), kann SQLSTATE problemlos im PostgreSQL-Code verwendet werden.

Wenn Ihr Quellcode darauf basiert, dass SQLCODE eine Ganzzahl zurückgibt (z. B. wenn Sie ihn mit NUMBER- oder INTEGER-Variablen verwenden oder SQLCODE-Rückgabewerte als Parameter oder Spalten speichern), müssen Sie den konvertierten Code umgestalten.

Oracle SQL-Funktion wird noch nicht unterstützt

Mögliche Ursache

Einige integrierte Oracle-Funktionen werden von Database Migration Service für die Konvertierung nicht unterstützt.

Einige Funktionen haben möglicherweise Entsprechungen in PostgreSQL (z. B. ASCII), andere haben möglicherweise denselben Namen, aber unterschiedliche Spezifikationen (z. B. REGEXP%-Funktionen). Einige Funktionen sind möglicherweise gar nicht vorhanden.

Mögliche Abhilfe

Prüfen Sie, welche Oracle-Funktion den Fehler verursacht hat.

  • Wenn die Funktion mit demselben Verhalten in PostgreSQL vorhanden ist, können Sie die Fehlermeldung ignorieren, da der konvertierte Code nach der Migration gleich funktionieren sollte.

  • Wenn eine Funktion denselben Namen hat, aber anders funktioniert oder in PostgreSQL nicht vorhanden ist, können Sie versuchen, den konvertierten Code zu korrigieren:

    • Erstellen Sie eine benutzerdefinierte Funktion (UDF) mit demselben Namen in der Zieldatenbank.
    • Ersetzen Sie den Funktionsaufruf in der Quelle durch einen entsprechenden Ausdruck.

    • Mit Gemini optimierte Unterstützung bei der Konvertierung nutzen Weitere Informationen finden Sie unter SQL Server-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

    • Einige Oracle-Datenbankfunktionen oder ‑Features können mit Erweiterungen wie Orafce repliziert werden. Weitere Informationen zu den in Ihrer Zieldatenbank unterstützten Erweiterungen finden Sie unter Unterstützte Datenbankerweiterungen.

Integrierte Oracle-Pakete werden nicht vollständig unterstützt

Mögliche Ursache

Der Database Migration Service unterstützt bestimmte integrierte Oracle-Pakete, aber viele haben keine vollständige Konvertierungsunterstützung, z. B. DBMS_STATS, DBMS_UTILITY oder DBMS_SQL.

Mögliche Abhilfe

Wenn Sie nicht unterstützte Pakete verwenden, müssen Sie möglicherweise Folgendes tun:

  • Ändern Sie den Code. Anstelle von DBMS_STATS.GATHER_TABLE_STATS können Sie beispielsweise einen einfacheren Befehl wie ANALYZE verwenden.

    Pakete wie UTL_FILE und DBMS_AQ müssen möglicherweise refaktoriert werden, da sie in PostgreSQL nicht einfach repliziert werden können.

  • Einige Oracle-Datenbankfunktionen oder ‑Features können mit Erweiterungen wie Orafce repliziert werden. Weitere Informationen zu Erweiterungen, die in Ihrer Zieldatenbank unterstützt werden, finden Sie unter Unterstützte Datenbankerweiterungen.

Oracle-Datentyp wird noch nicht für die Konvertierung unterstützt

Mögliche Ursache

Einige Oracle-Datentypen werden derzeit nicht für die Konvertierung oder den Datentransfer unterstützt.

Mögliche Abhilfe

In den meisten Fällen gibt es in PostgreSQL einen entsprechenden Datentyp. Sie können Konvertierungszuordnungsdateien verwenden, um die Konvertierungslogik anzupassen und den nicht unterstützten Oracle-Datentyp in den erforderlichen PostgreSQL-Datentyp zu transformieren.

Weitere Informationen zur Unterstützung von Datentypen finden Sie unter Conversion-Arbeitsbereiche – Übersicht und unterstützte Objekte.

Quellfunktion wird noch nicht unterstützt
Mögliche Ursache

Diese Gruppe umfasst alle allgemeinen Probleme im Zusammenhang mit Oracle-Funktionen, die für die Konvertierung nicht unterstützt werden. Probleme in dieser Gruppe fallen nicht in andere, spezifischere Problemgruppen.

Mögliche Abhilfe

Schema-Objekttyp wird nicht unterstützt

Mögliche Ursache

Database Migration Service unterstützt bestimmte Oracle-Schemaobjekttypen für die Codekonvertierung nicht, da PostgreSQL keine entsprechenden Äquivalente hat. Beispiele sind Index-Organized Tables (IOTs), Textsuchindexe oder Bodies für benutzerdefinierte Typen (User-Defined Types, UDTs).

Mögliche Abhilfe

Database Migration Service konvertiert nicht unterstützte Objekte in das nächstgelegene PostgreSQL-Äquivalent. IOTs werden beispielsweise zu regulären Tabellen mit einer Primärschlüsseleinschränkung und Textsuchindexe werden in B-Baum-Indexe konvertiert. Beachten Sie, dass diese Konvertierungen zu einem Verlust von Funktionen führen können, die für den ursprünglichen Objekttyp spezifisch sind.

PL/SQL-Funktion wird noch nicht unterstützt
Mögliche Ursache

Diese Gruppe umfasst alle allgemeinen Probleme im Zusammenhang mit PL/SQL-Funktionen, die für die Konvertierung nicht unterstützt werden. Probleme in dieser Gruppe fallen nicht in andere, spezifischere Problemgruppen.

Mögliche Abhilfe

Bulk-Bindung wird noch nicht unterstützt

Mögliche Ursache

Die Codekonvertierung von Database Migration Service unterstützt derzeit keine Oracle-Bulk-Binding-Funktionen wie BULK COLLECT, FORALL oder SAVE EXCEPTIONS.

Mögliche Abhilfe

Um das Problem zu beheben, müssen Sie den Code ändern, in dem Funktionen für die Massenbindung verwendet werden. Sie sollten die Unterschiede in der PostgreSQL- und Oracle-Architektur berücksichtigen und prüfen, ob die Arrayverarbeitung in PostgreSQL für Ihren Anwendungsfall erforderlich ist.

Es gibt mehrere Strategien für den Umgang mit Oracle-Bulk-Binding-Vorgängen in PostgreSQL. Die Nutzung hängt von Ihrem jeweiligen Szenario ab. Wir empfehlen daher, auf Gemini basierende Unterstützung bei Conversions zu verwenden, um Ihre spezifischen Anforderungen zu erfüllen. Hier sind einige weitere Beispiel-Empfehlungen für den Einstieg:

  • Wenn Sie eine vollständige BULK COLLECT (ohne LIMIT) benötigen, können Sie die Funktion ARRAY_AGG verwenden.
  • Bei BULK COLLECT mit LIMIT können Sie versuchen, eine CURSOR FOR LOOP zu verwenden, um Batches von Zeilen in Arrays zu laden und zu verarbeiten. Wenn in Ihrem Fall jedoch funktionale Änderungen möglich sind, wäre es möglicherweise einfacher, die CURSOR FOR LOOP zu verwenden, um jeweils eine Zeile zu verarbeiten, anstatt sie in Arrays zu laden.
  • Für FORALL-Vorgänge können Sie die mengenbasierte DML mit UNNEST verwenden, wenn Sie die Arrayverarbeitung nutzen möchten.
  • Für SAVE EXCEPTIONS müssen Sie möglicherweise einen Ausnahmehandler in einem zeilenbasierten CURSOR FOR LOOP schreiben, da es in PostgreSQL keine entsprechende Klausel gibt.

Sammlungen werden noch nicht unterstützt

Mögliche Ursache

Die Codekonvertierung von Database Migration Service bietet nur teilweise Unterstützung für Oracle-Sammlungen.

Mögliche Abhilfe

Sie müssen den konvertierten PostgreSQL-Code entsprechend ändern. Beachten Sie beim Beheben von Problemen mit Sammlungen, dass PostgreSQL-Arrays niemals spärlich sind. Wenn Sie Elemente nur spärlich zuweisen, geben PostgreSQL-Arrays möglicherweise andere Ergebnisse und Kardinalitätszahlen als Oracle-Arrays zurück.

Da PostgreSQL keine Arrays mit String-Index unterstützt, sind je nach Art der Daten möglicherweise JSON/JSONB oder die hstore-Erweiterungen geeignet.

Pipelinefunktionen werden noch nicht unterstützt

Mögliche Ursache

Pipelinefunktionen werden von Database Migration Service nicht unterstützt.

Mögliche Abhilfe

Sie können Oracle-Pipelined-Funktionen durch PostgreSQL-Funktionen ersetzen, die Mengen zurückgeben. Wir empfehlen, den Code an Ihren Anwendungsfall anzupassen. Hier sind einige Beispiele für den Einstieg:

  1. Verweisen Sie auf den PostgreSQL-Typ (UDT), der aus dem Oracle-Quellobjekt oder -Datensatztyp konvertiert wird, der den Zeilentyp der Pipelined-Funktion definiert. Ändern Sie dann die Rückgabeanweisung der PostgreSQL-Funktion in RETURNS SETOF <type name> oder RETURNS TABLE, je nach Ihrem speziellen Fall.

  2. Ersetzen Sie den Rückgabewert im konvertierten PIPE ROW-Code durch RETURN NEXT <row or record variable>.

Der Sammlungstyp der pipelined-Quellfunktion, der in der RETURN-Klausel der Oracle-Funktion verwendet wird, ist in PostgreSQL nicht erforderlich.

Option für dynamisches SQL wird noch nicht unterstützt

Mögliche Ursache

Der Database Migration Service bietet teilweise Unterstützung für die Konvertierung von dynamischem SQL. Die Oracle-Schlüsselwörter EXECUTE IMMEDIATE, OPEN FOR und USING/INTO werden korrekt in ihre PostgreSQL-Entsprechungen konvertiert, die tatsächlichen dynamischen SQL-, DML- oder DDL-Strings jedoch nicht.

Mögliche Abhilfe

Sie müssen den konvertierten Code an Ihre Anforderungen anpassen. Wir empfehlen dringend, Gemini-basierte Unterstützung bei der Conversion für dynamisches SQL zu verwenden.

CONNECT BY-Option wird noch nicht unterstützt

Mögliche Ursache

Die meisten CONNECT BY-Operatoren, -Funktionen und -Pseudospalten werden von Database Migration Service unterstützt und in rekursive Common Table Expressions (CTEs) von PostgreSQL konvertiert. Es gibt jedoch bestimmte Ausnahmen, die möglicherweise Ihre Aufmerksamkeit erfordern. Die ORDER SIBLINGS BY-Klausel wird beispielsweise nur für aufsteigende Reihenfolge unterstützt.

Mögliche Abhilfe

Die ORDER SIBLINGS BY-Klausel für absteigende Reihenfolge lässt sich nicht einfach replizieren. Möglicherweise müssen Sie Ihren Code so umstrukturieren, dass er mit aufsteigender Reihenfolge funktioniert.

Prüfen Sie die gemeldeten Probleme mit CONNECT BY-Operatoren und passen Sie den Code bei Bedarf an. Wir empfehlen Ihnen, die auf Gemini basierenden Funktionen zur automatischen Konvertierung zu nutzen, um solche Korrekturen zu beschleunigen. Weitere Informationen finden Sie unter Oracle-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

JSON wird noch nicht unterstützt

Mögliche Ursache

Es gibt bestimmte Einschränkungen, wie Database Migration Service JSON für die Datenübertragung und Codekonvertierung unterstützt:

  • JSONB wird für die Datenübertragung nicht unterstützt.
  • Bei der Codekonvertierung werden die JSON-Abfragefunktionen oder ‑Operatoren in Oracle (z. B. JSON_TABLE, JSON_QUERY, JSON_OBJECT[AGG], JSON_ARRAYAGG, JSON_PATCH) nicht unterstützt.
  • In Oracle-Versionen vor 21c können Sie JSON-Daten in VARCHAR2-, CLOB- oder BLOB-Spalten speichern und mit der Bedingung IS JSON überprüfen. Database Migration Service unterstützt die Konvertierung dieser Bedingung nicht.
Mögliche Abhilfe

  • Wenn Sie JSON-Daten, die in den Spalten VARCHAR2, CLOB oder BLOB gespeichert sind, nach PostgreSQL verschieben möchten, müssen Sie möglicherweise eine Konvertierungszuordnungsdatei mit der Direktive MODIFY_TYPE schreiben.

    Beispiel:

    MODIFY_TYPE SOURCE_TABLE_NAME:BLOB_COLUMN_NAME_WITH_JSON_DATA:JSON

    Weitere Informationen zu Dateien für die Conversion-Zuordnung finden Sie unter Dateien für die Conversion-Zuordnung.

  • Um die Oracle-Funktionen und ‑Operatoren JSON in PostgreSQL zu konvertieren, können Sie PostgreSQL-Funktionen wie JSONB_ARRAY_ELEMENTS und JSON_AGG verwenden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation unter JSON-Funktionen und -Operatoren.

Probleme mit Sperren und Transaktionen

Mögliche Ursache

Die Codekonvertierung von Database Migration Service unterstützt keine LOCK- oder SAVEPOINT-Anweisungen. PostgreSQL unterstützt SAVEPOINT nicht.

Mögliche Abhilfe
  • Trennen Sie die SAVEPOINT-Blöcke in Oracle, um Transaktionsblöcke in PostgreSQL zu trennen, die die ROLLBACK-Anweisung verwenden.
  • Um DBMS_LOCK zu implementieren, verwenden Sie die PostgreSQL-Erweiterung pg_dbms_lock. Diese Erweiterung vereinfacht die Migration von benutzerdefinierten Oracle-Sperren zu PostgreSQL, indem sie die Funktionalität des Oracle-Pakets DBMS_LOCK emuliert.

XML wird noch nicht unterstützt

Mögliche Ursache

Database Migration Service unterstützt Oracle XMLTYPE oder die zugehörigen XML-Funktionen und ‑Operatoren nicht.

Mögliche Abhilfe

Database Migration Service unterstützt XMLTYPE zwar nicht direkt, Sie können aber die Spalten BLOB, CLOB, NVARCHAR2 oder VARCHAR2 für die Datenübertragung in XML anpassen. PostgreSQL unterstützt XML-Funktionen.

So migrieren Sie Ihre XML-Daten:

  1. Erstellen Sie eine Datei mit der Conversion-Zuordnung mit der MODIFY_TYPE-Anweisung für XML-Daten. Beispiel: 

    MODIFY_TYPE SOURCE_TABLE_NAME:BLOB_COLUMN_NAME_WITH_XML_DATA:XML

    Weitere Informationen zu Dateien für die Conversion-Zuordnung finden Sie unter Dateien für die Conversion-Zuordnung.

  2. Starten Sie den Migrationsjob. Bei diesem Vorgang werden alle Daten aus Oracle zu PostgreSQL migriert, mit Ausnahme von Daten in Spalten des Typs XMLTYPE. Diese Spalten werden in PostgreSQL mit NULL-Werten gefüllt.
  3. Erstellen Sie eine externe Tabelle in PostgreSQL, indem Sie nur die Spalte XMLTYPE aus Oracle auswählen. Fügen Sie die Primärschlüsselspalte aus der Quelltabelle ein.
  4. Führen Sie die XML-Daten aus der externen Tabelle in die ursprüngliche PostgreSQL-Tabelle ein.

Weitere Informationen zur Verwendung von PostgreSQL mit XMLTYPE finden Sie in der PostgreSQL-Dokumentation unter XML-Funktionen.

PIVOT wird noch nicht unterstützt

Mögliche Ursache

Database Migration Service unterstützt die Transponierungsoperatoren PIVOT und UNPIVOT für die Codekonvertierung nicht.
Mögliche Abhilfe

Sie können die PIVOT-Transponierung in PostgreSQL mit der tablefunc-Erweiterung oder durch Umschreiben des PIVOT-Quellausdrucks in bedingte Aggregationen erreichen. Beispiel:

  • SUM(CASE WHEN <condition> THEN <value> ELSE 0 END)
  • COUNT(CASE WHEN <condition> THEN 1 END)

Sie können UNPIVOT-Transponierungen, mit denen Schlüssel/Wert-Paare aus einer Reihe von Spalten erstellt werden, in PostgreSQL auf verschiedene Arten erstellen:

  • Kombination eines LATERAL-Join mit einer Reihe von VALUES. Beispiel: SELECT ... FROM <table> CROSS JOIN LATERAL (VALUES ('<column1-name>', <column1>), ('<column2-name>', <column2>) AS u(column_name, column_value))
  • UNNEST mit ARRAY verwenden. Beispiel: SELECT ..., UNNEST(ARRAY['<column1-name>', '<column2-name>']) AS column_name, UNNEST(ARRAY[column1, column2]) AS column_value FROM <table>

ALTER-Anweisungsoption wird noch nicht unterstützt

Mögliche Ursache

Database Migration Service konvertiert keine ALTER-Anweisungen, die häufig in dynamischem SQL ausgeführt werden.

Mögliche Abhilfe

Ersetzen Sie die Oracle-ALTER-Anweisungen durch den SET-Befehl in PostgreSQL. Wir empfehlen Ihnen, die auf Gemini basierenden Funktionen zur automatischen Konvertierung zu nutzen, um solche Korrekturen zu beschleunigen. Weitere Informationen finden Sie unter Oracle-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

SQL-Funktion wird noch nicht unterstützt
Mögliche Ursache

Diese Gruppe umfasst alle allgemeinen Probleme im Zusammenhang mit SQL-Funktionen, die für die Konvertierung nicht unterstützt werden. Probleme in dieser Gruppe fallen nicht in andere, spezifischere Problemgruppen. Beispiele sind Datenbankereignistrigger, GRANT-Anweisungen, INSERT-Vorgänge mit mehreren Tabellen, DML für Inline-Ansichten (INSERT INTO (SELECT ... FROM ...)) und Lateral Views.

Mögliche Abhilfe

Nicht unterstützte Syntax
Mögliche Ursache

Diese Gruppe umfasst alle allgemeinen Probleme, die sich auf nicht unterstützte Oracle SQL- oder PL/SQL-Syntax beziehen. Probleme in dieser Gruppe fallen nicht in andere, spezifischere Problemgruppen.

Mögliche Abhilfe

Ändern Sie Ihren Code so, dass er funktional gleichwertige PostgreSQL-Syntax verwendet. Wir empfehlen, die auf Gemini basierenden Funktionen zur automatischen Konvertierung zu nutzen, um den Code anzupassen. Weitere Informationen finden Sie unter Oracle-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

Nicht unterstützte SQL-Syntax

Mögliche Ursache

Ihr Quellcode verwendet SQL-Syntax oder Elemente, die vom Database Migration Service nicht unterstützt werden. Beispielsweise wird der Parameter NLS_LANG in der Oracle-Funktion TO_DATE nicht unterstützt.

Mögliche Abhilfe
Nicht unterstützte PL/SQL-Syntax

Mögliche Ursache

Ihr Quellcode verwendet PL/SQL-Syntax oder Elemente, die vom Database Migration Service nicht unterstützt werden. Beispielsweise werden recordbasierte INSERT-Anweisungen (z. B. INSERT INTO table VALUES r_variable) und PRAGMA RESTRICT_REFERENCES nicht unterstützt.

Mögliche Abhilfe

Ändern Sie Ihren Code so, dass er funktional gleichwertige PostgreSQL-Syntax verwendet. Wir empfehlen, die auf Gemini basierenden Funktionen zur automatischen Konvertierung zu nutzen, um den Code anzupassen. Weitere Informationen finden Sie unter Oracle-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

Nicht unterstützte Syntax für Datum und Zeitstempel

Mögliche Ursache

Der Database Migration Service kann Fehler oder Warnungen für nicht unterstützte Datums- oder Zeitstempelsyntax, Vorgänge oder Ausdrücke ausgeben. Beispiele für diese Probleme sind Vergleiche zwischen nicht übereinstimmenden Datentypen oder die Verwendung des TZH:TZM-Formatmodells in Zeitstempeln. Weitere Informationen zu unterstützten Objekten und Datentypen finden Sie unter Konvertierungsarbeitsbereiche.

Mögliche Abhilfe

Die meisten Datums- und Zeitstempelausdrücke lassen sich mit PostgreSQL-Entsprechungen neu erstellen. Wir empfehlen Ihnen, die auf Gemini basierenden Funktionen zur automatischen Konvertierung zu nutzen, um solche Korrekturen zu beschleunigen. Weitere Informationen finden Sie unter Oracle-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

Nicht unterstützte Elemente der Oracle-Syntax für die Ausnahmebehandlung

Mögliche Ursache

Die Codekonvertierung von Database Migration Service unterstützt die folgenden PL/SQL-Ausnahmesyntaxelemente von Oracle nicht:

  • Die Verwendung von RAISE_APPLICATION_ERROR mit variablen Fehlercodes anstelle von Literal--20nnn-Codes.
  • Die Verwendung von SQLERRM mit einem Fehlercode-Argument, da diese Syntax in PostgreSQL nicht unterstützt wird.
Mögliche Abhilfe

Sie müssen diese Probleme im konvertierten Code manuell beheben. Wir empfehlen Ihnen, die auf Gemini basierenden Funktionen zur automatischen Konvertierung zu nutzen, um solche Korrekturen zu beschleunigen. Weitere Informationen finden Sie unter Oracle-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

Probleme mit Datentypen und ‑konvertierungen

Mögliche Ursache

Der Database Migration Service kann Konvertierungsprobleme nach Kontext gruppieren, z. B. Konvertierungsprobleme, die in Typvergleichsausdrücken auftreten. In der Gruppe CW_OP0500 werden alle allgemeinen Probleme bei der Konvertierung von Datentypen erfasst, die nicht in andere Problemgruppen fallen.

Mögliche Abhilfe

In den meisten Fällen gibt Database Migration Service eine ERROR_UNIMPLEMENTED- oder ERROR_TYPE-Meldung im konvertierten PostgreSQL-Code aus. Beheben Sie diesen Fehler basierend auf Ihrem Wissen über die beteiligten Datentypen.

Probleme mit der Maske für Datumsformate

Mögliche Ursache

Beim Konvertieren von Datums- oder Zeitstempelausdrücken in oder aus Strings auf Grundlage eines Formatmodells können Warnungen oder Probleme auftreten. Database Migration Service verwendet ein Standardmodell (derzeit DD-MON-RR), wenn in den Casts im Oracle-Quellcode kein explizites Modell für das Datums- oder Zeitstempelformat angegeben ist.

Dies kann manchmal zu Problemen im konvertierten Code führen, wenn das Formatmodell, das für die implizite Umwandlung ausgegeben wurde, mit einem expliziten Formatmodell im selben Ausdruck in Konflikt steht. Dieses Problem kann auch auftreten, wenn Ihre Daten wahrscheinlich von den Unterschieden zwischen dem Oracle-Format RR und dem PostgreSQL-Format YY betroffen sind.

Mögliche Abhilfe

Sehen Sie sich die konvertierten PostgreSQL-Ausdrücke im Konvertierungsarbeitsbereich an und validieren Sie sie.

Probleme mit der Maske für numerische Formate

Mögliche Ursache

Der Database Migration Service unterstützt nicht alle Oracle-Formatmodelle. Beispiel: 'L' oder 'X' werden nicht unterstützt. Es kann zu Problemen oder Warnungen bei Code kommen, der Strings basierend auf Oracle-Formatmodellen in Zahlen umwandelt.

Mögliche Abhilfe

Für Oracle-Formatmodelle, die kein Äquivalent in PostgreSQL haben, müssen Sie möglicherweise Ihre Ausdrücke oder Formatmodelle umgestalten. Wir empfehlen Ihnen, die auf Gemini basierenden Funktionen zur automatischen Konvertierung zu nutzen, um solche Korrekturen zu beschleunigen. Weitere Informationen finden Sie unter Oracle-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

Probleme beim Umwandeln von Datentypen

Mögliche Ursache

Es können Fehler aufgrund von nicht unterstützten oder ungenauen Datentypumwandlungen auftreten. Database Migration Service gibt normalerweise ERROR_UNIMPLEMENTED aus. Das liegt in der Regel an fehlenden oder unvollständigen Metadaten. Database Migration Service hat möglicherweise nicht genügend Informationen, um einen Typ zu casten, z. B. in Funktionsargumenten oder Prozedurparametern.

Mögliche Abhilfe

Passen Sie den PostgreSQL-Code an, um korrekte Datentypkonvertierungen zu gewährleisten. Für diese Korrekturen müssen Sie mit den referenzierten Attributen, Variablen und Spalten vertraut sein.

Probleme mit Vergleichen

Mögliche Ursache

Database Migration Service hat möglicherweise nicht genügend Metadaten oder Informationen zu Datentypen, um Ausdrücke für den Datenvergleich zu konvertieren. Dies kann beispielsweise passieren, wenn ein benutzerdefinierter Typ (UDT) mit NULL verglichen wird.

Mögliche Abhilfe

Sehen Sie sich die konvertierten PostgreSQL-Ausdrücke an und beheben Sie die Probleme. Wir empfehlen Ihnen, die auf Gemini basierenden Funktionen zur automatischen Konvertierung zu nutzen, um solche Korrekturen zu beschleunigen. Weitere Informationen finden Sie unter Oracle-Code und ‑Schema mit Unterstützung durch Gemini konvertieren.

Probleme in dieser Kategorie beziehen sich auf Fälle, in denen der Oracle-Quellcode korrekt in das am besten geeignete PostgreSQL-Äquivalent konvertiert wird, der resultierende Code jedoch geringfügige semantische oder funktionale Unterschiede aufweisen kann, die eine Überprüfung durch Sie erfordern. Das liegt daran, dass Oracle und PostgreSQL Datentypen, Formate oder Objekte unterschiedlich verarbeiten.

Auf den ersten Blick scheint es, als ob sich diese Kategorie mit Problemen in der Kategorie Datentypen und Conversion (CW_05) überschneidet. Es handelt sich jedoch um unterschiedliche Probleme. CW_05 enthält bekannte Probleme, bei denen Database Migration Service Oracle-Code nicht in das entsprechende PostgreSQL-Äquivalent konvertieren kann.

Überprüfen Sie die Maske für Datumsformate

Mögliche Ursache

Die meisten Oracle-Datums- und Zeitstempelformatmodelle haben entsprechende Äquivalente in PostgreSQL, sodass der konvertierte Code keine semantischen oder funktionalen Unterschiede aufweist. Für einige Modelle gibt es keine genaue Entsprechung und ihr Verhalten variiert. Ein Beispiel ist das Oracle-Format RR, das in das PostgreSQL-Format YY konvertiert wird.

Mögliche Abhilfe

Überprüfen und validieren Sie Ausdrücke mit Formatmodellkonvertierungen, um sicherzugehen, dass sich der konvertierte Code wie erwartet verhält.

Überprüfen Sie die Maske für numerische Formate

Mögliche Ursache

Die meisten numerischen Quellformatmodelle haben ein Äquivalent in PostgreSQL. Der konvertierte Code weist daher keine semantischen oder funktionalen Unterschiede auf. Für einige Formatmodelle gibt es jedoch möglicherweise keine genaue Entsprechung oder sie verhalten sich etwas anders.

Mögliche Abhilfe

Überprüfen und validieren Sie Ausdrücke mit Formatmodellkonvertierungen, um sicherzustellen, dass der konvertierte Code wie erwartet funktioniert.

Ausnahmecode prüfen

Mögliche Ursache

Wenn Sie RAISE_APPLICATION_ERROR mit einem Fehlercode im Bereich von -20000 bis -20999 verwenden, konvertiert Database Migration Service ihn in PostgreSQL RAISE EXCEPTION mit einem SQLSTATE im Bereich von CW0000 bis CW999. Bei der Konvertierung werden die letzten drei Ziffern des Quellfehlercodes beibehalten und mit CW vorangestellt.

Mögliche Abhilfe

Prüfen Sie, ob dieses Verhalten Ihren Anforderungen entspricht. Diese Überprüfung ist nur erforderlich, wenn die Quellfehlercodes für Ihre Anwendung, Supportteams oder Dokumentation von Bedeutung sind. Wenn der Wert des Fehlercodes selbst nicht aussagekräftig ist, können Sie diese Warnung ignorieren.

Überprüfen Sie die Ausnahmemeldung

Mögliche Ursache

Die Funktion SQLERRM ist sowohl in Oracle PL/SQL als auch in PostgreSQL vorhanden, gibt aber möglicherweise in jeder Engine einen anderen Fehlertext zurück. Wenn Sie beispielsweise in Oracle durch null teilen, wird der Fehlertext ORA-01476: divisor is equal to zero zurückgegeben, in PostgreSQL jedoch ERROR: division by zero.

Mögliche Abhilfe

Wenn Ihre Anwendung, Supportinfrastruktur oder Dokumentation vom Fehlertext abhängt, überprüfen Sie die Konvertierung. Andernfalls können Sie diesen Unterschied ignorieren.

Integrierte Funktionsemulation von Oracle prüfen

Mögliche Ursache

Die Code- und Schemakonvertierung von Database Migration Service soll das Verhalten von Oracle-Funktionen mit PostgreSQL-Entsprechungen bereitstellen. Die Ergebnisse sind jedoch möglicherweise nicht immer zufriedenstellend für Ihr Szenario. Daher wird in Conversion-Arbeitsbereichen immer eine Warnung mit Funktionskonvertierungen angezeigt, die möglicherweise überprüft werden müssen.

Mögliche Abhilfe

Wir empfehlen, Objekte zu prüfen, bei denen in Conversion-Arbeitsbereichen Warnungen in der Problemgruppe CW_OP0605 ausgegeben werden.

Datentyp der Fremdschlüsselspalte überprüfen

Mögliche Ursache

Database Migration Service hat inkompatible Datentypangaben zwischen übergeordneten und untergeordneten Objekten erkannt (z. B. wenn eine übergeordnete Spalte NUMBER(4) und die untergeordnete Spalte NUMBER(10) ist).

Mögliche Abhilfe

In den meisten Fällen verursachen geringfügige Abweichungen bei Datentypen keine Probleme bei der Datenbankfunktionalität. Wir empfehlen jedoch, das konvertierte Datenmodell auf Inkonsistenzen zu prüfen.

Funktionsüberprüfung empfohlen
Mögliche Ursache

Diese Gruppe umfasst alle allgemeinen Probleme, die sich auf potenzielle funktionale Unterschiede im Oracle- und PostgreSQL-Code beziehen. Probleme in dieser Gruppe fallen nicht in andere, spezifischere Problemgruppen.

Mögliche Abhilfe

Integrierte Funktionsemulation von Oracle prüfen

Mögliche Ursache

Viele integrierte Oracle-Funktionen haben keine direkte Entsprechung in PostgreSQL. Um dieses Problem bei Migrationen zu beheben, konvertiert Database Migration Service Ihren Code mithilfe verschiedener SQL-Ausdrücke, um ein gleichwertiges funktionales Verhalten in PostgreSQL zu erzielen.

In einigen Fällen können die konvertierten Ausdrücke komplex sein. Database Migration Service gibt Warnungen in der Gruppe CW_OP0702 aus, um auf mögliche Probleme hinzuweisen und darauf, dass eine Funktion mit einem Ausdruck emuliert wurde.

Mögliche Abhilfe

Prüfen Sie den konvertierten Code, um sicherzustellen, dass sich die konvertierten Funktionen in Ihrer PostgreSQL-Umgebung wie erwartet verhalten.

Refaktorierung von autonomen Transaktionen erforderlich

Mögliche Ursache

PostgreSQL unterstützt keine autonomen Transaktionen.

Mögliche Abhilfe

Sie können autonome Transaktionen in PostgreSQL mit der Erweiterung dblink, pg_background oder PL/Proxy erreichen. Datenbankaufrufe, die mit einer dieser Erweiterungen erfolgen, werden in einer anderen Sitzung ausgeführt und generieren daher eine autonome Transaktion.

Refaktorierung von Datenbanklinks erforderlich

Mögliche Ursache

Database Migration Service unterstützt keine Oracle-Datenbanklinks. Objekte, die Links verwenden, müssen refaktoriert werden.

Mögliche Abhilfe

Je nach Ziel des Datenbanklinks können Sie die entsprechende Funktionalität in PostgreSQL mit Datenbankerweiterungen wie dblink, postgres_fdw, oracle_fdw oder PL/Proxy implementieren.

Refaktorierung von erweiterten Warteschlangen erforderlich

Mögliche Ursache

Für Oracle Advanced Queuing-Pakete (DBMS_AQ, DBMS_AQADM) gibt es keine PostgreSQL-Entsprechungen und sie müssen umgestaltet werden.

Mögliche Abhilfe

Optionen:

  • Lagern Sie die Warteschlangenfunktion von der Datenbank in die Anwendungsebene aus.
  • Verwenden Sie PostgreSQL-Tabellen, ‑Benachrichtigungen und ‑Trigger, um ein entsprechendes Verhalten zu implementieren.
  • Wenden Sie sich an Ihren Ansprechpartner im Technical Solutions Team, um weitere Unterstützung zu erhalten.

Refaktorierung von Datenbank-E‑Mail-Adressen erforderlich

Mögliche Ursache

AlloyDB for PostgreSQL unterstützt das Senden von E-Mails direkt aus der Datenbank nicht. Erweiterungen, die diese Funktion ermöglichen, werden ebenfalls nicht unterstützt. Daher werden Verwendungen des UTL_SMTP-Pakets vom Database Migration Service nicht konvertiert.

Mögliche Abhilfe

Gestalten Sie den E‑Mail-Code Ihrer Datenbank um und übertragen Sie die Verantwortung für das Senden von E‑Mails auf die Anwendungsebene. Sie können die Datenbank weiterhin verwenden, um die Bedingungen zu erfassen, unter denen das Senden von E‑Mails erforderlich ist.

Eine Beispielimplementierung könnte darin bestehen, E‑Mail-Details in eine dedizierte Tabelle zu schreiben. Diese Tabelle kann auch als E-Mail-Warteschlange dienen, die Sie mit einer Cloud Run-Funktion abfragen und die eigentliche SMTP-Verarbeitung vornehmen.

Refaktorierung von Jobs und Planung erforderlich

Mögliche Ursache

Die Oracle-Pakete DBMS_JOB und DBMS_SCHEDULER werden nicht von Database Migration Service konvertiert. Sie müssen den Code, der auf diese Pakete verweist, refaktorieren.

Mögliche Abhilfe

Bei einfachen Jobs ohne Abhängigkeiten können Sie geplante Jobs in der Ziel-PostgreSQL-Datenbank manuell mit der pg_cron-Erweiterung erstellen.

Bei komplizierteren Zeitplänen, die von pg_cron nicht unterstützt werden, müssen Sie möglicherweise einen Scheduler auf Anwendungsebene oder einen Drittanbieter-Scheduler verwenden.

Refaktorierung der Datei-E/A erforderlich

Mögliche Ursache

Database Migration Service unterstützt das Oracle-Paket UTL_FILE nicht. Sie müssen den Code, der auf diese Pakete verweist, refaktorieren.

Die Orafce-Erweiterung umfasst die UTL_FILE-Emulation, funktioniert aber möglicherweise nicht in einer von Google verwalteten PostgreSQL-Umgebung, da die Datei-E/A-Funktionen eingeschränkt sind.

Mögliche Abhilfe
  • Refaktorieren Sie Ihren Code, um Abhängigkeiten von UTL_FILE zu entfernen.

  • AlloyDB for PostgreSQL hat bestimmte Einschränkungen für die Datei-E/A-Funktionen. Daher ist es nicht möglich, dieses Verhalten direkt in der Zieldatenbank zu implementieren.

    Eine mögliche Alternative wäre, PostgreSQL mit der orafce-Erweiterung auf einer Compute Engine-VM in Ihrer VPC zu installieren. Anschließend können Sie die PL/Proxy-Erweiterung in Ihrer Zieldatenbank verwenden, um die PostgreSQL-kompatible UTL_FILE-Version aufzurufen, die in der Datenbank auf der Compute Engine-VM ausgeführt wird.

Synonyme

Mögliche Ursache

PostgreSQL unterstützt keine Synonyme. Bei Codeobjekten ersetzt Database Migration Service Synonymreferenzen automatisch durch das zugehörige Quellschema und den zugehörigen Objektnamen. Wenn Sie Synonyme außerhalb von Codeobjekten verwenden, z. B. in schreibgeschützten Schemas für Datenbankanwendungsnutzer, müssen Sie sie manuell konvertieren.

Mögliche Abhilfe

Wenn Sie Synonyme außerhalb von Codeobjekten verwenden möchten, können Sie den PostgreSQL-Parameter SEARCH_PATH verwenden oder Ihren Code so umgestalten, dass Ansichten für Abfrageobjekte verwendet werden.

Globale temporäre Tabellen

Mögliche Ursache

Diese Problemgruppe ist eine Warnung, dass im Oracle-Quellcode eine globale temporäre Tabelle gefunden wurde. Für die Migration globaler temporärer Tabellen muss die PostgreSQL-Erweiterung „pgtt“ in der Zieldatenbank installiert und erstellt sein.

Mögliche Abhilfe

Wir empfehlen, dass Sie prüfen, ob die PostgreSQL-Erweiterung „pgtt“ in der Zieldatenbank installiert und erstellt wurde.

Gemini-Vorschläge überprüfen
Mögliche Ursache:

Diese Problemgruppe umfasst alle allgemeinen Fehler und Warnungen im Zusammenhang mit der Gemini-optimierten Codekonvertierung.

Mögliche Maßnahmen: Probleme, die hier gefunden werden, weisen möglicherweise nicht immer auf tatsächliche Probleme hin. Wir empfehlen Ihnen jedoch dringend, alle mit Gemini optimierten Conversions zu überprüfen, um sicherzustellen, dass sie Ihren Erwartungen entsprechen.

Mit KI erweiterten Code überprüfen
Mögliche Ursache: Dieser DDL-Code wurde mit Gemini-optimierten Funktionen konvertiert und muss möglicherweise von Ihnen auf Richtigkeit überprüft werden.

Mögliche Abhilfemaßnahmen: Wir empfehlen, mit KI-Erweiterungen konvertierten Code sorgfältig zu prüfen, um sicherzustellen, dass das Endergebnis der Funktionalität Ihres Quellschemas entspricht.

Zitate
Mögliche Ursache: Gemini-basierte Vorschläge können Inhalte enthalten, die aus mehreren Quellen zitiert werden. Für bestimmte Quellenangaben gelten möglicherweise Lizenzbeschränkungen. Wir empfehlen, den konvertierten Code auf Zitationen zu prüfen.

Metadaten-Konvertierungsprobleme
Mögliche Ursache:

In dieser Gruppe werden alle Conversion-Probleme erfasst, die nicht in andere, spezifischere Problemgruppen fallen.

Mögliche Abhilfe

Wir empfehlen, den konvertierten Code anhand Ihrer Kenntnisse des Quelldatenmodells zu überprüfen und ihn bei Bedarf anzupassen.

Metadaten-Konvertierungsprobleme
Mögliche Ursache:

Diese Gruppe umfasst alle Probleme mit dem Metadaten-Tracking, die nicht in andere, spezifischere Problemgruppen fallen.

Mögliche Abhilfe:

Beispiele für Probleme in dieser Gruppe beziehen sich in der Regel auf Kompilierungsfehler oder Warnungen, die zu Problemen mit Datentypen in der konvertierten PostgreSQL-Datenbank führen können. Wir empfehlen, den konvertierten Code anhand Ihrer Kenntnisse des Quelldatenmodells zu prüfen und die fehlerhaften Verweise anzupassen.

Kontaktieren Sie Ihr Supportteam

Mögliche Ursache

In besonderen Grenzsituationen kann es vorkommen, dass ein interner Fehler mit einem gültigen Oracle-Quellobjekt auftritt. Wenn das der Fall ist, wenden Sie sich an Ihr Supportteam, um weitere Unterstützung zu erhalten.

Allgemeine Konvertierungsprobleme
Mögliche Ursache

Diese Gruppe enthält alle Probleme, die nicht in andere, spezifischere Problemkategorien oder -gruppen fallen.

Mögliche Abhilfe

Wir empfehlen Ihnen, den konvertierten Code anhand Ihrer Kenntnisse des Quelldatenmodells und -codes zu überprüfen und ihn bei Bedarf anzupassen.