Bewährte Verfahren für die Schemakonvertierung von Oracle zu Azure Database for PostgreSQL Flexible Server

Dieser Artikel enthält bewährte Methoden und Empfehlungen für das Feature zur Schemakonvertierung von Oracle zu Azure Database for PostgreSQL in Visual Studio Code mit Microsoft Foundry. Befolgen Sie diese Richtlinien, um zuverlässige, qualitativ hochwertige Ergebnisse zu erhalten.

Planen Sie die Konvertierung des Schemas

Eine erfolgreiche Konvertierung beginnt mit der Planung. Entscheiden Sie, was konvertiert werden soll, wie Sie iterieren und an welches Azure Database for PostgreSQL Ziel sie ausrichten, bevor Sie das Tool ausführen.

Umfang der Quellschemata festlegen

Geben Sie an, welche Oracle-Anwendungsschemas Konvertiert werden sollen. Der Extraktionsworkflow schließt automatisch Oracle-System- und integrierte Schemas aus, wie SYS, SYSTEM, XDB, MDSYS, CTXSYS und WMSYS.

Ausrichten der Ziel-PostgreSQL-Hauptversion

Verwenden Sie für die Scratch-Datenbank dieselbe PostgreSQL-Hauptversion wie für den Produktionszielserver Azure Database for PostgreSQL – Flexible Server. Das Konvertierungstool sendet DDL, die auf eine bestimmte PostgreSQL-Hauptversion ausgerichtet ist. Die Konvertierung für eine Hauptversion und die Bereitstellung in einer anderen können während der Bereitstellung Syntax- oder Funktionsunterschiede sichtbar machen.

Suchen nach nicht unterstützten Objekten im Voraus

Überprüfen Sie oracle, um flexible Serverschemakonvertierungseinschränkungen zu Azure Database for PostgreSQL, bevor Sie beginnen. Entscheiden Sie für jedes nicht unterstützte Objekt im Voraus, ob die Funktionalität nativ auf PostgreSQL neu erstellt werden soll, sie auf einen geeigneten Azure-Dienst umformt oder aus dem Migrationsbereich entfernt werden soll.

Planen der Korrektur für nicht unterstützte Objekte

Zeichnen Sie für jedes im vorherigen Schritt identifizierte nicht unterstützte Objekt den ausgewählten Wartungspfad auf, bevor Sie die Konvertierung ausführen. Verfolgen:

• Der Oracle-Objektname und -Typ.
• Der ausgewählte Pfad: neu erstellen, replatformieren oder ablegen.
• Der Azure-Zieldienst oder das PostgreSQL-Muster, falls Sie eine Replattformierung durchführen.

Auswählen, wo die Konvertierung ausgeführt werden soll

Für kleine Schemas können Sie die Konvertierung von Ihrer lokalen Arbeitsstation ausführen. Führen Sie für größere Schemas stattdessen Visual Studio Code und das Schemakonvertierungstool auf einem Azure virtuellen Computer aus.

Eine große Konvertierung wird lange ausgeführt und führt dauerhafte Aufrufe an Ihre Oracle-Quelle, die Scratch-Datenbank und Microsoft Foundry. Wenn Sie von einem Azure virtuellen Computer ausgeführt werden, erhalten Sie folgende Aktionen:

• Netzwerknähe: Der virtuelle Computer befindet sich in derselben Azure Region wie Ihr Azure Database for PostgreSQL flexibler Server und Ihre Microsoft Foundry-Ressource, wodurch die Roundtriplatenz für die vielen Aufrufe reduziert wird, die eine Konvertierung macht.
• Stabile, lange laufende Sitzungen: Die Konvertierung wird nicht durch den Ruhezustand der Arbeitsstation, Neustarts, VPN-Tropfen oder Timeouts des Unternehmensnetzwerks unterbrochen.
• Private Konnektivität: Sie können den virtuellen Computer in demselben virtuellen Netzwerk wie Ihr Zielserver und Microsoft privaten Endpunkt für Foundry platzieren, sodass der Datenverkehr das öffentliche Internet nicht durchläuft.
• Vorhersagbare Ressourcen: Sie können CPU, Arbeitsspeicher und Datenträger für die Konvertierungsauslastung anpassen und Artefakte auf einem verwalteten Datenträger speichern, den Sie sichern.

Platzieren Sie den virtuellen Computer in der Region, in der Ihre Scratch-Datenbank gehostet wird, und gewähren Sie ihm Netzwerkzugriff auf die Oracle-Quelldatenbank. Wenn Sie den Dicken Clientmodus verwenden, installieren Sie Oracle Instant Client auf dem virtuellen Computer. Weitere Informationen finden Sie unter Oracle-Konnektivitätsmodi.

Vorbereiten der Oracle-Quellumgebung

Bereiten Sie vor dem Ausführen einer Konvertierung die Oracle-Quellumgebung vor. Gewähren Sie dem Konvertierungstool die Berechtigungen, die sie zum Lesen von Schemametadaten benötigen, und stellen Sie sicher, dass die gleichzeitige Sitzungskapazität ausreicht, damit das Tool ein vollständiges und genaues Schema extrahieren kann.

Erforderliche Oracle-Berechtigungen

Der Oracle-Verbindungsbenutzer, den das Konvertierungstool verwendet, benötigt Lesezugriff auf den Oracle-Metadatenkatalog. Das Tool liest Schemametadaten aus DBA_* Katalogansichten.

Erteilen Sie entweder SELECT_CATALOG_ROLE oder SELECT ANY DICTIONARY, damit der Benutzer die erforderlichen DBA_*-Ansichten lesen kann. Verwenden Sie den Zugriff mit den geringsten Rechten gemäß der Organisationsrichtlinie. Der Benutzer benötigt keine Berechtigungen für eine Anwendungstabelle oder zum Lesen von Daten auf Zeilenebene. Das Tool fragt niemals Anwendungsdaten ab; es liest nur Schemametadaten.

Festlegen des Oracle-Sitzungsparameters

Stellen Sie sicher, dass der Oracle-Parameter sessions größer als 10 ist, damit das Tool genügend gleichzeitige Metadatenlesevorgänge öffnen kann. Überprüfen Sie den aktuellen Wert mit:

SELECT name, value
FROM v$parameter
WHERE name = 'sessions';

Die temporäre Datenbank vorbereiten

Das Schemakonvertierungstool verwendet eine temporäre Datenbank auf Azure Database for PostgreSQL Flexible Server, um konvertierte Objekte zu validieren. Stellen Sie den Server bereit und konfigurieren Sie sie, bevor Sie eine Konvertierung starten, sodass das Überprüfungsverhalten mit dem letztendlichen Produktionsziel übereinstimmt.

Erforderliche PostgreSQL-Berechtigungen

Der PostgreSQL-Verbindungsbenutzer, den das Konvertierungstool verwendet, benötigt Berechtigungen zum Erstellen und Überprüfen von Objekten in der Scratch-Datenbank:

• Die Mitgliedschaft in der Rolle azure_pg_admin, die zum Erstellen der Erweiterungen erforderlich ist, von denen das Tool abhängt.
• CREATE- und USAGE-Berechtigungen für das temporäre Schema, damit das Werkzeug konvertierte Objekte zur Validierung erstellen kann.
• CONNECT Berechtigung für die Scratch-Datenbank.

Wählen Sie eine geeignete Größe für die temporäre Datenbank

Die Scratch-Datenbank überprüft nur DDL; es hostt keine Anwendungsworkloads. Verwenden Sie eine Computeebene, die stabile Verbindungskapazität für Konvertierungs- und Validierungsaktivitäten bereitstellt. Dimensionieren Sie die temporäre Datenbank getrennt vom Produktionsziel, und verkleinern Sie sie nach Abschluss der Konvertierung.

Zulassungsliste und Installation erforderlicher Erweiterungen

Das Schemakonvertierungstool hängt von mehreren PostgreSQL-Erweiterungen ab. Diese Erweiterungen übersetzen integrierte Oracle-Pakete, räumliche Typen, Partitionierung und Volltextsuche. Sie ermöglichen auch die Beobachtbarkeit für die Scratch-Datenbank. Allowlist and install the extensions that the converted schema needs before your first conversion run.

In der folgenden Tabelle sind häufig verwendete Erweiterungen für Konvertierungen von Oracle zu Azure Database for PostgreSQL aufgeführt. Nehmen Sie die auf, die auf das Quellschema zutreffen, und fügen Sie alle weiteren hinzu, die für die Workload erforderlich sind.

Das Tool erstellt plpgsql_check automatisch in der Entwurfsdatenbank, wenn die Erweiterung zugelassen ist. Allowlist it before your first run so converted routines get full body validation. Wenn die Erweiterung nicht verfügbar ist, ist die Konvertierung weiterhin erfolgreich, aber die zusätzliche Überprüfung wird im Hintergrund übersprungen. plpgsql_check ist nur für die Entwurfsdatenbank erforderlich. Das konvertierte Schema hängt nicht zur Laufzeit davon ab.

Nur hinzugefügt dblink , wenn das Quellschema verwendet PRAGMA AUTONOMOUS_TRANSACTIONwird. In diesem Fall benötigt dblink der konvertierte Code auf dem Zielserver nicht nur die Entwurfsdatenbank.

Schritt 1: Allowlist der Erweiterungen

Öffnen Sie im Azure-Portal den Azure Database for PostgreSQL flexiblen Server, auf dem Ihre Scratch-Datenbank gehostet wird. Wählen Sie Serverparameter aus, suchen Sie nach azure.extensions und wählen Sie jede Erweiterung in der Liste aus. Speichere deine Änderungen. Erweiterungen wie pg_partman, pg_stat_statementsund plpgsql_check erfordern auch Einträge in shared_preload_libraries. Diese Einträge benötigen einen Serverneustart. Weitere Informationen finden Sie unter Verwenden von PostgreSQL-Erweiterungen.

Schritt 2: Installieren der Erweiterungen in der Scratch-Datenbank

Stellen Sie eine Verbindung mit der Entwurfsdatenbank als Mitglied der azure_pg_admin-Rolle her, und erstellen Sie jede Erweiterung:

CREATE EXTENSION IF NOT EXISTS orafce;
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS postgis;
CREATE EXTENSION IF NOT EXISTS postgis_topology;
CREATE EXTENSION IF NOT EXISTS postgis_tiger_geocoder;
CREATE EXTENSION IF NOT EXISTS pg_partman;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS plpgsql_check;

Schritt 3: Konfigurieren von search_path für Oracle-Kompatibilität

orafceinstalliert Oracle-kompatible Pakete in dedizierten Schemas (oracle, dbms_*, , plv*utl_file). Legen Sie search_path auf Datenbankebene fest, damit diese Schemas zusammen mit den PostGIS -Schemas (topology, tiger) für jede Verbindung verfügbar sind. Eine Einstellung auf Datenbankebene umfasst auch Objekte, die einen Verweis selbst nicht qualifizieren können, z. B. Ansichten, CHECK Einschränkungen, Spaltenstandardwerte und generierte Spalten.

ALTER DATABASE <database_name> SET search_path = public, oracle, topology, tiger,
    dbms_random, dbms_alert, dbms_assert, dbms_output, dbms_pipe,
    dbms_sql, dbms_utility, plvchr, plvdate, plvlex, plvstr,
    plvsubst, plunit, utl_file;

Schließen Sie nur die Schemas für die erweiterungen ein, die Sie installiert haben. Stellen Sie die Verbindung wieder her, nachdem Sie diese Anweisung ausgeführt haben, da der neue Wert auf Sitzungen angewendet wird, die nach der Änderung beginnen. Verwenden Sie ALTER ROLE <role_name> SET search_path = ...zum Festlegen der Einstellung stattdessen eine einzelne Rolle.

Konfigurieren Microsoft Foundry-Kapazität

Microsoft Foundry-Kapazität wirkt sich direkt auf die Konvertierungssicherheit aus, insbesondere bei großen oder komplexen Oracle-Schemas. Stellen Sie ausreichende Token pro Minute (TPM) bereit und überwachen Sie die Verwendung, sodass Konvertierungen ohne Unterbrechung abgeschlossen werden.

Bereitstellen ausreichender Token pro Minute

• Konfigurieren Sie Ihre Microsoft Foundry-Bereitstellung mit einem Kontingent von mindestens 500.000 Token pro Minute (TPM) für eine optimale Leistung. Komplexe Schemaobjekte verbrauchen während der Konvertierung erhebliche Tokenkapazität.
• Überwachen Sie den Verbrauch im Microsoft Foundry-Portal und erhöhen Sie das Limit, wenn Sie während eines Konvertierungslaufs eine Drosselung feststellen.

Führen Sie jeweils nur ein Projekt aus.

Führen Sie jeweils ein einzelnes Schemakonvertierungsprojekt aus. Gleichzeitige Projekte konkurrieren mit demselben Microsoft Foundry-Kontingent und können Drosselung, teilweise Konvertierungen und unerwartete Tokenkosten verursachen. Verarbeiten Sie Projekte sequenziell, um das Verhalten vorhersagbar und einfacher zu debuggen.

Sichern des Konvertierungsworkflows

Das Konvertierungstool läuft lokal in Visual Studio Code und verbindet sich mit drei Endpunkten: der Microsoft Foundry-Bereitstellung, der Oracle-Quelldatenbank und dem Zielserver Azure Database for PostgreSQL – Flexible Server. Bevor Sie eine Konvertierung starten, vergewissern Sie sich, dass Visual Studio Code alle drei Endpunkte von Ihrer Arbeitsstation aus erreichen können, und wenden Sie dann standardmäßige Sicherheitskontrollen für Unternehmen auf jede Verbindung an.

Bestätigen der Netzwerkkonnektivität von Visual Studio Code

Stellen Sie sicher, dass die Arbeitsstation, auf der Visual Studio Code ausgeführt wird, den Microsoft Foundry-Endpunkt, die Oracle-Quelldatenbank und den Azure Database for PostgreSQL flexiblen Server erreichen kann. Wenn eine Verbindung von einer Unternehmensfirewall, einem VPN oder einer Netzwerksicherheitsgruppe blockiert wird, arbeiten Sie mit Ihrem Netzwerkteam zusammen, um ausgehenden Zugriff zuzulassen, bevor Sie eine Konvertierung starten.

Verwenden privater Endpunkte oder Firewallregeln für das Ziel

Einschränken des Netzwerkzugriffs auf den Azure Database for PostgreSQL flexiblen Server. Verwenden Sie private Endpunkte für VNet-integrierte Arbeitsstationen oder konfigurieren Sie Firewallregeln , die nur die von Ihrem Team verwendeten IP-Bereiche zulassen.

Verwenden Sie die Microsoft Entra ID-Authentifizierung.

Stellen Sie mit dem flexiblen Server von Azure Database for PostgreSQL eine Verbindung mithilfe der Microsoft Entra-Authentifizierung anstelle der Kennwortauthentifizierung her. Microsoft Entra Authentifizierung zentralisiert die Zugriffssteuerung, unterstützt Richtlinien für bedingten Zugriff und erzeugt auditierbare Anmeldeereignisse.

Sicheres Verwalten von Anmeldeinformationen

Betten Sie keine Oracle- oder PostgreSQL-Anmeldeinformationen in Nur-Text ein und übernehmen Sie sie nicht zur Quellcodeverwaltung. Speichern Sie sie in Azure Key Vault oder im Secret-Manager Ihrer Organisation, und verweisen Sie beim Herstellen der Verbindung in der Verbindungskonfiguration des Konvertierungstools in Visual Studio Code darauf.

Überprüfen des konvertierten Schemas

Die automatisierte Konvertierung beschleunigt die Migration, aber eine manuelle Überprüfung ist unerlässlich, um semantische Unterschiede, plattformspezifische Verhaltensweisen und Edgefälle abzufangen, die KI oder Tools möglicherweise verpassen. Der Schemakonvertierungsbericht kennzeichnet Objekte, die das Tool extrahiert, aber nicht vollständig konvertieren konnte, als Überprüfungsaufgaben. Arbeiten Sie diese Aufgaben zuerst durch und prüfen Sie anschließend komplexe Objekte stichprobenartig, die problemlos konvertiert wurden.

Ausführliche Informationen zu den Artefakten, die das Tool erzeugt, und der empfohlenen Prüfreihenfolge finden Sie unter Schemakonvertierungsberichte für Oracle zu Azure Database for PostgreSQL flexiblen Server.

Überprüfen komplexer Codeobjekte

Überprüfen Sie nach der Konvertierung manuell die folgenden komplexen Oracle-Codeobjekte:

• Gespeicherte Prozeduren: Überprüfen Sie die konvertierte Prozedurlogik, die Parameterbehandlung und die Ausnahmeverwaltung.
• Pakete: Überprüfen Der Paketstruktur und der Abhängigkeitsauflösung anhand von PostgreSQL-Schemas.
• Funktionen: Überprüfen sie Rückgabetypen, Parameterzuordnungen und die Genauigkeit der Geschäftslogik.

Überprüfungsworkflow

1. Lösen Sie alle Überprüfungsaufgaben im Bericht zur Schemakonvertierung, optional mit Unterstützung von GitHub Copilot im Agent-Modus.
2. Überprüfen Sie jedes komplexe Objekt, das von KI konvertiert wurde, auch wenn keine Überprüfungsaufgabe erstellt wurde.
3. Führen Sie konvertierte Prozeduren und Funktionen in der Entwurfsdatenbank mit repräsentativen Testdaten aus.
4. Vergewissern Sie sich, dass die Geschäftslogik und die Ergebnismengen denen der Oracle-Quelle entsprechen, bevor Sie das Schema in die Produktion überführen.

Erneutes Ausführen und Iterieren

Ein Konvertierungslauf ist wiederholbar. Führen Sie die Konvertierung erneut aus, wenn sich die Eingaben ändern, sodass der Bericht und die generierte DDL den aktuellen Zustand widerspiegeln.

Wann eine Konvertierung erneut ausgeführt werden soll

Führen Sie die Konvertierung erneut aus, wenn Sie:

• Passen Sie die Ziel-Scratch-Datenbank an. Sie können z. B. eine fehlende Erweiterung zulassen, eine neue Erweiterung installieren oder korrigieren search_path.
• Passen Sie die Quellseite von Oracle an. Sie bringen z. B. ein zusätzliches Schema in den Bereich, legen ein Problemobjekt ab oder beheben Metadatenbeschädigungen in einem Quellobjekt.
• Microsoft Foundry-Kapazität anpassen. Zum Beispiel erhöhen Sie das TPM-Kontingent, nachdem Sie im vorherigen Durchlauf eine Drosselung beobachtet haben.

Vergleichen Sie den neuen Konvertierungsbericht mit dem vorherigen, um sicherzustellen, dass die Änderung die beabsichtigte Wirkung hatte, und um unbeabsichtigte Nebenwirkungen bei Objekten zu erkennen, die nicht von der Änderung betroffen sind.

Beibehalten von Konvertierungsartefakten

Speichern Sie den generierten PostgreSQL DDL-Ordner zusammen mit allen Berichten, die vom Konvertierungstool als Überwachungsartefakt für das Migrationsprojekt erstellt wurden. Diese Artefakte sind nützlich für:

• Compliance- und Auditprüfungen.
• Vergleiche der Differenzen mit künftigen Neukonvertierungen.
• Wissenstransfer zu Betriebs- oder Anwendungsteams.

Speichern Sie die Artefakte im Quellcodeverwaltungs- oder Dokumentverwaltungssystem Ihres Teams.

Verwandte Inhalte

• Was ist Oracle, um eine flexible Serverschemakonvertierung zu Azure Database for PostgreSQL?
• Lernprogramm: Oracle zur Azure Database for PostgreSQL flexiblen Serverschemakonvertierung
• Überprüfen von Aufgaben und Ausgabeordnern für Oracle zum Azure Database for PostgreSQL flexiblen Serverschemakonvertierung
• Oracle zur Azure Database for PostgreSQL flexiblen Serverschemakonvertierungseinschränkungen