Referenz für Konvertierungsprobleme und ‑muster

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

Übersichtsbildschirm des Konvertierungsarbeitsbereichs mit Gruppen und Kategorien von Konvertierungsproblemen.
Abbildung 1. Übersichtsbildschirm des Konvertierungsarbeitsbereichs mit Gruppen und Kategorien von Konvertierungsproblemen.
Übersichtsbildschirm 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 Database Migration Service auf eine unbekannte Syntax stößt oder der Oracle-Quellcode ungültig ist (z. B. wenn in einer gespeicherten Prozedur das Schlüsselwort END; fehlt).

Mögliche Aussetzung von Maßnahmen

Korrigieren Sie die ungültigen Objekte in der Oracle-Quelldatenbank. Aktualisieren Sie dann den Quellschema-Snapshot in 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 abhängiger Objekte zu verbessern. Wenn Ihr Code auf Objekte verweist, die nicht im Quellschema enthalten sind, kann es zu Konvertierungsproblemen kommen, da Database Migration Service die Struktur oder Datentypen für die fehlenden referenzierten Spalten, Attribute oder Objekte nicht bestimmen kann.

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

Mögliche Aussetzung von Maßnahmen

Achten Sie darauf, dass alle referenzierten Objekte dem Database Migration Service-Quellbaum hinzugefügt werden, oder passen Sie den PostgreSQL-Code manuell basierend auf Ihren Kenntnissen des Quelldatenmodells für die fehlenden Abhängigkeiten an.

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 der Quelle gefüllt. Damit INSERT-Anweisungen nach der Migration nicht fehlschlagen, erstellt Database Migration Service eine Sequenz und verwendet sie, um die Spalte rowid automatisch zu erhöhen.

Mögliche Aussetzung von Maßnahmen

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

Nicht unterstützte integrierte Oracle-Funktionen

Mögliche Ursache

Möglicherweise verwenden Sie eine integrierte Oracle-Funktion, die nicht unterstützt wird.

Mögliche Aussetzung von Maßnahmen

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

SQLCODE nicht unterstützt

Mögliche Ursache

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

Mögliche Aussetzung von Maßnahmen

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

Wenn Ihr Quellcode darauf angewiesen ist, 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 refaktorieren.

Oracle SQL-Funktion nicht unterstützt

Mögliche Ursache

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

Bestimmte 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 Aussetzung von Maßnahmen

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 genauso 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 Konvertierungsunterstützung verwenden. Weitere Informationen finden Sie unter SQL Server-Code und -Schema mit Gemini-Unterstützung 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 werden nicht vollständig konvertiert, z. B. DBMS_STATS, DBMS_UTILITY oder DBMS_SQL.

Mögliche Aussetzung von Maßnahmen

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

  • Ändere deinen Code. Anstatt DBMS_STATS.GATHER_TABLE_STATS zu verwenden, 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 den in Ihrer Zieldatenbank unterstützten Erweiterungen finden Sie unter Unterstützte Datenbankerweiterungen.

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

Mögliche Ursache

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

Mögliche Aussetzung von Maßnahmen

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 Konvertierungsarbeitsbereiche – Übersicht und unterstützte Objekte.

Namenskonflikt

Mögliche Ursache

Diese Gruppe erfasst Probleme, bei denen mehrere Datenbankobjekte (z. B. Tabellen, materialisierte Ansichten) so konvertiert werden, dass sie in der Zieldatenbank denselben Namen verwenden. Dieses Problem kann beispielsweise auftreten, wenn Sie Quellobjekte haben, deren Namen sich nur durch Groß- und Kleinschreibung unterscheiden. Bei Oracle-Objektnamen wird die Groß-/Kleinschreibung nicht berücksichtigt, bei PostgreSQL jedoch *schon*. Daher werden Objektnamen so konvertiert, dass sie denselben String verwenden.

Mögliche Aussetzung von Maßnahmen

Benennen Sie die in Konflikt stehenden Objekte direkt in der Quelldatenbank oder im konvertierten Schema im Editor des Konvertierungsarbeitsbereichs um. Sie können auch eine Conversion-Zuordnungsdatei mit der Anweisung RENAME_* verwenden.

Quellfunktion 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 unter keine andere, spezifischere Problemgruppe.

Mögliche Abhilfe

Schemaobjekttyp wird nicht unterstützt

Mögliche Ursache

Der Database Migration Service unterstützt bestimmte Oracle-Schemaobjekttypen für die Codekonvertierung nicht, da PostgreSQL keine entsprechenden Äquivalente hat. Beispiele hierfür sind indexorganisierte Tabellen (IOTs), Text Search-Indexe oder Textkörper für benutzerdefinierte Typen (UDTs).

Mögliche Aussetzung von Maßnahmen

Database Migration Service konvertiert nicht unterstützte Objekte in das nächstgelegene PostgreSQL-Äquivalent. Beispielsweise werden IOTs zu regulären Tabellen mit einer Primärschlüsseleinschränkung und Textsuchindexe werden in B-Baum-Indexe umgewandelt. 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 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 unter keine andere, spezifischere Problemgruppe.

Mögliche Abhilfe

Bulk-Bindung nicht unterstützt

Mögliche Ursache

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

Mögliche Aussetzung von Maßnahmen

Um das Problem zu beheben, müssen Sie den Code ändern, der Bulk-Bindungsfunktionen verwendet. Sie sollten die Unterschiede zwischen der PostgreSQL- und der Oracle-Architektur berücksichtigen und prüfen, ob die Array-Verarbeitung in PostgreSQL für Ihren Anwendungsfall erforderlich ist.

Es gibt mehrere Strategien für die Verarbeitung von Oracle-Bulk-Bindungsvorgängen in PostgreSQL. Ihre Verwendung hängt von Ihrem spezifischen Szenario ab. Wir empfehlen daher, die Gemini-gestützte Konvertierungshilfe zu verwenden, um Ihre spezifischen Anforderungen zu erfüllen. Hier sind einige weitere Beispiele für Empfehlungen, die Ihnen den Einstieg erleichtern:

  • Für eine vollständige BULK COLLECT (keine LIMIT) können Sie die Funktion ARRAY_AGG verwenden.
  • Für BULK COLLECT mit LIMIT können Sie versuchen, einen CURSOR FOR LOOP zu verwenden, um Batches von Zeilen in Arrays zu laden und zu verarbeiten. Wenn Ihr Fall jedoch funktionale Änderungen zulässt, wäre eine möglicherweise einfachere Alternative, 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 satzbasiertes DML mit UNNEST ausprobieren, wenn Sie die Array-Verarbeitung verwenden möchten.
  • Für SAVE EXCEPTIONS müssen Sie möglicherweise einen Ausnahme-Handler in einem zeilenbasierten CURSOR FOR LOOP schreiben, da es in PostgreSQL keine entsprechende Klausel gibt.

Sammlungen nicht unterstützt

Mögliche Ursache

Die Codekonvertierung von Database Migration Service unterstützt Oracle-Sammlungen teilweise.

Mögliche Aussetzung von Maßnahmen

Sie müssen den konvertierten PostgreSQL-Code entsprechend ändern. Denken Sie beim Beheben von Problemen mit Sammlungen daran, dass PostgreSQL-Arrays nie dünnbesetzt sind. Wenn Sie Elemente dünnbesetzt zuweisen, geben PostgreSQL-Arrays möglicherweise andere Ergebnisse und Kardinalitätszahlen als Oracle-Arrays zurück.

Da PostgreSQL keine String-indexierten Arrays unterstützt, können je nach Art der Daten die Erweiterungen JSON/JSONB oder hstore geeignet sein.

Pipelinefunktionen nicht unterstützt

Mögliche Ursache

Pipelinefunktionen werden von Database Migration Service nicht unterstützt.

Mögliche Aussetzung von Maßnahmen

Sie können Oracle-Pipelinefunktionen durch PostgreSQL-Funktionen ersetzen, die Sätze zurückgeben. Wir empfehlen, den Code so anzupassen, dass er für Ihren Anwendungsfall relevant ist. 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 Pipelinefunktion definiert. Ändern Sie dann die Return-Klausel der PostgreSQL-Funktion je nach Fall in RETURNS SETOF <type name> oder RETURNS TABLE.

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

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

Dynamisches SQL nicht unterstützt

Mögliche Ursache

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 werden jedoch nicht konvertiert.

Mögliche Aussetzung von Maßnahmen

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

Option „CONNECT BY“ wird 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 Ihre Aufmerksamkeit erfordern könnten. Die ORDER SIBLINGS BY-Klausel wird beispielsweise nur für die aufsteigende Reihenfolge unterstützt.

Mögliche Aussetzung von Maßnahmen

Es ist nicht möglich, die ORDER SIBLINGS BY-Klausel für die absteigende Reihenfolge auf einfache Weise zu replizieren. Daher müssen Sie Ihren Code möglicherweise so umstrukturieren, dass er mit der aufsteigenden Reihenfolge funktioniert.

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

JSON nicht unterstützt

Mögliche Ursache

Es gibt bestimmte Einschränkungen bei der Unterstützung von JSON durch den Database Migration Service für die Datenübertragung und Codekonvertierung:

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

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

    Beispiel:

    MODIFY_TYPE SOURCE_TABLE_NAME:BLOB_COLUMN_NAME_WITH_JSON_DATA:JSON

    Weitere Informationen zu Conversion-Zuordnungsdateien finden Sie unter Conversion-Zuordnungsdateien.

  • Wenn Sie die Oracle-Funktionen und -Operatoren JSON in PostgreSQL konvertieren möchten, können Sie PostgreSQL-Funktionen wie JSONB_ARRAY_ELEMENTS, 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
  • Teilen Sie die SAVEPOINT-Blöcke in Oracle in separate Transaktionsblöcke in PostgreSQL auf, die die ROLLBACK-Anweisung verwenden.
  • Verwenden Sie zum Implementieren von DBMS_LOCK die PostgreSQL-Erweiterung pg_dbms_lock. Diese Erweiterung vereinfacht die Migration von benutzerdefinierten Oracle-Sperren zu PostgreSQL, indem die Funktionalität des Oracle-Pakets DBMS_LOCK emuliert wird.

XML nicht unterstützt

Mögliche Ursache

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

Mögliche Aussetzung von Maßnahmen

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

So migrieren Sie Ihre XML-Daten:

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

    MODIFY_TYPE SOURCE_TABLE_NAME:BLOB_COLUMN_NAME_WITH_XML_DATA:XML

    Weitere Informationen zu Conversion-Zuordnungsdateien finden Sie unter Conversion-Zuordnungsdateien.

  2. Starten Sie den Migrationsjob. Bei diesem Prozess werden alle Daten von Oracle zu PostgreSQL migriert, mit Ausnahme von Daten in Spalten vom Typ XMLTYPE. Diese Spalten werden in PostgreSQL mit NULL-Werten gefüllt.
  3. Erstellen Sie eine Fremdtabelle 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 Fremdtabelle mit der ursprünglichen PostgreSQL-Tabelle zusammen.

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

PIVOT nicht unterstützt

Mögliche Ursache

Database Migration Service unterstützt die Transponierungsoperatoren PIVOT und UNPIVOT für die Codekonvertierung nicht.
Mögliche Aussetzung von Maßnahmen

Sie können die PIVOT-Transposition in PostgreSQL erreichen, indem Sie die Erweiterung tablefunc verwenden oder den PIVOT-Quellausdruck in bedingte Aggregationen umschreiben. Beispiel:

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

Sie können UNPIVOT-Transpositionen, die Schlüssel/Wert-Paare aus einer Reihe von Spalten erstellen, in PostgreSQL auf verschiedene Arten erstellen:

  • Kombination eines LATERAL-Joins 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 ARRAYs verwenden. Beispiel: SELECT ..., UNNEST(ARRAY['<column1-name>', '<column2-name>']) AS column_name, UNNEST(ARRAY[column1, column2]) AS column_value FROM <table>

ALTER-Anweisungsoption nicht unterstützt

Mögliche Ursache

Database Migration Service unterstützt keine ALTER-Anweisungen (die häufig in dynamischem SQL ausgeführt werden) für die Konvertierung.

Mögliche Aussetzung von Maßnahmen

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

SQL-Funktion 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 unter keine andere, spezifischere Problemgruppe. Beispiele hierfür sind Datenbankereignis-Trigger, GRANT-Anweisungen, INSERT-Vorgänge mit mehreren Tabellen, DML für Inline-Ansichten (INSERT INTO (SELECT ... FROM ...)) und laterale Ansichten.

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 unter keine andere, spezifischere Problemgruppe.

Mögliche Aussetzung von Maßnahmen

Ändern Sie Ihren Code so, dass die funktional äquivalente PostgreSQL-Syntax verwendet wird. Wir empfehlen, die KI-basierten Funktionen zur automatischen Konvertierung von Gemini zu nutzen, um den Code anzupassen. Weitere Informationen finden Sie unter Oracle-Code und -Schema mit Gemini-Unterstützung konvertieren.

Nicht unterstützte SQL-Syntax

Mögliche Ursache

Ihr Quellcode verwendet SQL-Syntax oder -Elemente, die von 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 von Database Migration Service nicht unterstützt werden. Beispielsweise werden datensatzbasierte INSERT-Anweisungen (wie INSERT INTO table VALUES r_variable) und PRAGMA RESTRICT_REFERENCES nicht unterstützt.

Mögliche Aussetzung von Maßnahmen

Ändern Sie Ihren Code so, dass die funktional äquivalente PostgreSQL-Syntax verwendet wird. Wir empfehlen, die KI-basierten Funktionen zur automatischen Konvertierung von Gemini zu nutzen, um den Code anzupassen. Weitere Informationen finden Sie unter Oracle-Code und -Schema mit Gemini-Unterstützung konvertieren.

Nicht unterstützte Syntax für Datum und Zeitstempel

Mögliche Ursache

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 Aussetzung von Maßnahmen

Sie können die meisten Datums- und Zeitstempelausdrücke mit PostgreSQL-Äquivalenten neu erstellen. Wir empfehlen, die Gemini-basierten Funktionen zur automatischen Konvertierung zu nutzen, um solche Korrekturen zu beschleunigen. Weitere Informationen finden Sie unter Oracle-Code und -Schema mit Gemini-Unterstützung konvertieren.

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

Mögliche Ursache

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

  • Die Verwendung von RAISE_APPLICATION_ERROR mit variablen Fehlercodes anstelle von literalen -20nnn-Codes.
  • Die Verwendung von SQLERRM mit einem Fehlercodeargument, da diese Syntax in PostgreSQL nicht unterstützt wird.
Mögliche Aussetzung von Maßnahmen

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

Probleme mit Datentypen und ‑konvertierungen

Mögliche Ursache

Database Migration Service kann Konvertierungsprobleme nach Kontext gruppieren (z. B. Konvertierungsprobleme, die in Typvergleichsausdrücken auftreten). Die Gruppe CW_OP0500 erfasst alle allgemeinen Probleme bei der Datentypkonvertierung, die nicht unter andere Problemgruppen fallen.

Mögliche Aussetzung von Maßnahmen

In den meisten Fällen gibt Database Migration Service im konvertierten PostgreSQL-Code eine ERROR_UNIMPLEMENTED- oder ERROR_TYPE-Nachricht aus. Beheben Sie diesen Fehler anhand Ihrer Kenntnisse der beteiligten Datentypen.

Probleme mit dem Modell für Datumsformate

Mögliche Ursache

Beim Konvertieren von Datums- oder Zeitstempelausdrücken in oder aus Strings basierend auf einem Formatmodell können Warnungen oder Probleme auftreten. Database Migration Service verwendet ein Standardmodell (derzeit DD-MON-RR), wenn Umwandlungen im Oracle-Quellcode ein explizites Datums- oder Zeitstempelformatmodell ausschließen.

Dies kann manchmal zu Problemen im konvertierten Code führen, wenn das für die implizite Umwandlung ausgegebene Formatmodell 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 Aussetzung von Maßnahmen

Prüfen und validieren Sie die konvertierten PostgreSQL-Ausdrücke im Konvertierungsarbeitsbereich.

Probleme mit dem Modell für numerische Formate

Mögliche Ursache

Database Migration Service unterstützt nicht alle Oracle-Formatmodelle. Beispiel: 'L' oder 'X' werden nicht unterstützt. Bei Code, der Strings basierend auf Oracle-Formatmodellen in Zahlen umwandelt, können Probleme oder Warnungen auftreten.

Mögliche Aussetzung von Maßnahmen

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

Probleme mit der Umwandlung von Datentypen

Mögliche Ursache

Möglicherweise treten Fehler aufgrund einer nicht unterstützten oder ungenauen Datentypumwandlung auf. 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 umzuwandeln, z. B. in Funktionsargumenten oder Prozedurparametern.

Mögliche Aussetzung von Maßnahmen

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 verfügt möglicherweise nicht über genügend Metadaten oder Informationen zu Datentypen, wenn Datenvergleichsausdrücke konvertiert werden. Dies kann beispielsweise passieren, wenn ein benutzerdefinierter Typ (UDT) mit NULL verglichen wird.

Mögliche Aussetzung von Maßnahmen

Überprüfen Sie die konvertierten PostgreSQL-Ausdrücke und beheben Sie die Probleme. Wir empfehlen, die Gemini-basierten Funktionen zur automatischen Konvertierung zu nutzen, um solche Korrekturen zu beschleunigen. Weitere Informationen finden Sie unter Oracle-Code und -Schema mit Gemini-Unterstützung konvertieren.

Probleme in dieser Kategorie stellen Fälle dar, in denen der Oracle-Quellcode korrekt in das nächstgelegene PostgreSQL-Äquivalent konvertiert wird, der resultierende Code jedoch geringfügige semantische oder funktionale Unterschiede aufweisen kann, die Sie überprüfen müssen. Dies liegt an den Unterschieden bei der Verarbeitung von Datentypen, Formaten oder Objekten durch Oracle und PostgreSQL.

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

Modell für Datumsformate überprüfen

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 genau passende Entsprechung und ihr Verhalten variiert. Ein Beispiel ist das Format RR von Oracle, das in das Format YY von PostgreSQL konvertiert wird.

Mögliche Aussetzung von Maßnahmen

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

Modell für numerische Formate überprüfen

Mögliche Ursache

Die meisten numerischen Formatmodelle der Quelle 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 Aussetzung von Maßnahmen

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

Ausnahmecode überprü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 das Präfix CW wird vorangestellt.

Mögliche Aussetzung von Maßnahmen

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 Aussetzung von Maßnahmen

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

Emulation der integrierten Oracle-Funktion überprüfen

Mögliche Ursache

Die Code- und Schemakonvertierung von Database Migration Service soll das Verhalten von Oracle-Funktionen mit PostgreSQL-Äquivalenten bereitstellen. Die Ergebnisse sind jedoch möglicherweise nicht immer für Ihr Szenario zufriedenstellend. Daher enthalten Konvertierungsarbeitsbereiche immer eine Warnung mit Funktionskonvertierungen, die Sie möglicherweise überprüfen müssen.

Mögliche Aussetzung von Maßnahmen

Wir empfehlen Ihnen, Objekte zu prüfen, bei denen Konvertierungsarbeitsbereiche Warnungen in der Problemgruppe CW_OP0605 ausgeben.

Datentyp der Fremdschlüsselspalte überprüfen

Mögliche Ursache

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

Mögliche Aussetzung von Maßnahmen

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 unter keine andere, spezifischere Problemgruppe.

Mögliche Abhilfe

Emulation der integrierten Oracle-Funktion überprüfen

Mögliche Ursache

Viele integrierte Oracle-Funktionen haben in PostgreSQL keine direkte Entsprechung. Um dieses Problem bei Migrationen zu minimieren, konvertiert Database Migration Service Ihren Code mithilfe verschiedener SQL-Ausdrücke, um ein äquivalentes 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 Aussetzung von Maßnahmen

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 Aussetzung von Maßnahmen

Sie können autonome Transaktionen in PostgreSQL mit der Erweiterung dblink, pg_background oder PL/Proxy erreichen. Datenbankaufrufe, die mit einer dieser Erweiterungen ausgeführt werden, 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 Aussetzung von Maßnahmen

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

Refaktorierung von erweiterten Warteschlangen erforderlich

Mögliche Ursache

Oracle Advanced Queuing-Pakete (DBMS_AQ, DBMS_AQADM) haben keine PostgreSQL-Entsprechungen und müssen refaktoriert werden.

Mögliche Aussetzung von Maßnahmen

Optionen:

  • Refaktorieren Sie die Warteschlangenfunktion von der Datenbank in die Anwendungsebene.
  • Verwenden Sie PostgreSQL-Tabellen, ‑Benachrichtigungen und ‑Trigger, um ein gleichwertiges Verhalten zu implementieren.
  • Wenden Sie sich an einen Mitarbeiter des Technical Solutions-Teams, 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 Pakets UTL_SMTP nicht von Database Migration Service konvertiert.

Mögliche Aussetzung von Maßnahmen

Refaktorieren Sie den E-Mail-Code Ihrer Datenbank und übertragen Sie die Verantwortung für das Senden von E-Mails an 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 übernehmen.

Refaktorierung von Jobs und Planung erforderlich

Mögliche Ursache

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

Mögliche Aussetzung von Maßnahmen

Für einfache Jobs ohne Abhängigkeiten können Sie geplante Jobs in der PostgreSQL-Zieldatenbank manuell mit der Erweiterung pg_cron erstellen.

Für komplexere Zeitpläne, die von pg_cron nicht unterstützt werden, müssen Sie möglicherweise einen Planer auf Anwendungsebene oder einen Drittanbieterplaner 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 enthält eine UTL_FILE-Emulation, funktioniert aber aufgrund eingeschränkter Datei-E/A-Funktionen möglicherweise nicht in einer von Google verwalteten PostgreSQL-Umgebung.

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

  • AlloyDB for PostgreSQL unterliegt bestimmten Einschränkungen bei den 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 Erweiterung orafce auf einer Compute Engine-VM in Ihrer VPC zu installieren. Anschließend können Sie die Erweiterung PL/Proxy 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 Synonymverweise automatisch durch das Quellschema und den Objektnamen. Wenn Sie Synonyme außerhalb von Codeobjekten verwenden, z. B. in schreibgeschützten Schemas für Nutzer von Datenbankanwendungen, müssen Sie sie manuell konvertieren.

Mögliche Aussetzung von Maßnahmen

Für die Verwendung von Synonymen außerhalb von Codeobjekten können Sie den PostgreSQL-Parameter SEARCH_PATH verwenden oder Ihren Code so refaktorieren, dass Ansichten für Abfrageobjekte verwendet werden.

Refaktorierung globaler temporärer Tabellen erforderlich

Mögliche Ursache

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

Mögliche Aussetzung von Maßnahmen

Wir empfehlen, zu 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 Abhilfe: Die hier gefundenen Probleme weisen möglicherweise nicht immer auf echte Probleme hin. Wir empfehlen jedoch dringend, alle von Gemini optimierten Conversions zu überprüfen, um sicherzustellen, dass sie Ihren Erwartungen entsprechen.

Durch KI augmentierten 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 Abhilfe: 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: Die von Gemini optimierten Vorschläge können Inhalte aus mehreren Quellen enthalten. Für bestimmte Zitate gelten möglicherweise Lizenzbeschränkungen. Wir empfehlen, den konvertierten Code auf Zitate zu überprüfen.

Metadaten-Konvertierungsprobleme
Mögliche Ursache:

Diese Gruppe umfasst alle Konvertierungsprobleme, die nicht in eine andere, spezifischere Problemgruppe fallen.

Mögliche Aussetzung von Maßnahmen

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

Metadaten-Konvertierungsprobleme
Mögliche Ursache:

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

Mögliche Abhilfe:

Beispiele für Probleme in dieser Gruppe hängen in der Regel mit Kompilierungsfehlern oder Warnungen zusammen, 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 Grenzfällen kann bei einem gültigen Oracle-Quellobjekt ein interner Fehler auftreten. Wenden Sie sich in diesem Fall an Ihr Supportteam, um weitere Unterstützung zu erhalten.

Allgemeine Konvertierungsprobleme
Mögliche Ursache

Diese Gruppe enthält alle Probleme, die nicht in eine andere, spezifischere Problemkategorie oder -gruppe fallen.

Mögliche Aussetzung von Maßnahmen

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