Freigeben über

Bewährte Methoden für die Migration von Oracle zu Azure Database for PostgreSQL

In den folgenden Szenarien werden einige der potenziellen Herausforderungen beschrieben, die während einer Migration von Oracle zu Azure Postgres auftreten können. Die empfohlenen Lösungen können bei der Überwindung dieser Herausforderungen hilfreich sein, wenn Sie Ihre eigene Migration planen und ausführen.

Szenario: Es wurden zwei separate latenzarme Clientanwendungen mit hohem Durchsatz ermittelt, die unabhängig voneinander dieselbe Datenbank verwenden. Die Anwendung haben versehentlich die zwischengespeicherten Abfragen der jeweils anderen aus den Puffern entfernt. Die gemeinsam genutzte Last und Ressourcenkonflikte erzeugten eine Situation, in der die gemeinsam genutzten Puffer der Datenbank zu häufig geleert wurden, was zu einer beeinträchtigten Leistung in beiden Systemen führte.

Empfohlene Lösung: Stellen Sie sicher, dass Ihre anfänglichen Bewertungen ALLE Aspekte der Umgebung Ihrer Datenbankplattform erfassen, einschließlich der Speichernutzung und Nutzungsmuster der Speicherstrukturen von SGA (System Global Area) und PGA (Program Global Area). Wählen Sie die geeignete Computeserie aus, die Ihren Ressourcenanforderungen entspricht, und stellen Sie sicher, dass die geplante Kapazität von Postgres bei Bedarf angepasst wird.

Tipp

Die pg_buffercache-Erweiterung bietet eine Möglichkeit zum Untersuchen der Auslastung und ermöglicht es Ihnen, zu beobachten, was im freigegebenen Puffercache in Echtzeit passiert.

Puffercache-Trefferquote

Das Untersuchen der Trefferraten ermöglicht Ihnen, die Effektivität des Caches zu bewerten und zu bestimmen, ob die Größe des freigegebenen Puffers angemessen ist. Eine gute Cachetrefferrate ist ein Zeichen dafür, dass die meisten Datenanforderungen aus dem Arbeitsspeicher und nicht vom Datenträger bereitgestellt werden, was für eine optimale Leistung sorgt:

SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;

Tabellen und Indizes mit den meisten Zugriffen

Indem Sie untersuchen, auf welche Tabellen und Indizes am häufigsten zugegriffen wird und/oder den meisten Speicherplatz im Puffercache belegen, können Sie Hotspots für die Zwischenspeicherung im Arbeitsspeicher erkennen:

SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;

Konflikte im Pufferpool

Erhebliche Konflikte im Pufferpool deuten möglicherweise darauf hin, dass mehrere Abfragen denselben Pufferspeicher nutzen, was zu Leistungsengpässen führen kann. Die Untersuchung von Ort und Häufigkeit des Pufferzugriffs kann bei der Diagnose solcher Probleme hilfreich sein:

SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;

Szenario: Eine Migration wurde zwischen Releases im Veröffentlichungszyklus der Postgres-Plattform und releaseübergreifend initiiert. Trotz neuer Features und Verbesserungen, die im neuesten Release verfügbar sind, blieb die zu Beginn der Migration ausgewählte Version unverändert. Anschließend wurden zusätzliche Anstrengungen, Zeit und Kosten aufgewendet, um die Postgres-Datenbankversion nach der anfänglichen Migration zu upgraden, um eine optimale Leistung zu erzielen und die neuen Funktionen zu nutzen.

Empfohlene Lösung: Priorisieren Sie nach Möglichkeit die Einführung der neuesten Version von Postgres bei der Migration. Die Entwicklungsteams der Postgres-Community arbeiten unglaublich hart daran, jede Möglichkeit zur Verbesserung von Leistung und Stabilität in jedes neue Release zu übernehmen. Wenn Sie also etwas zurückhalten, bedeutet dies, dass Sie Leistungseinbußen in Kauf nehmen müssen. Außerdem können Sie nur so von den Vorteilen neuer Azure-Features profitieren. Zu den neuen Features von Azure Postgres gehören: SSDv2-Speicher, die neueste Serverfamilie für die Infrastruktur sowie automatisierte Indexoptimierung und autonome Optimierungsfunktionen für Serverparameter.

Szenario: Organisationen, die zum ersten Mal nach Postgres migrieren, sind möglicherweise nicht vertraut mit bewährten Methoden und Ansätzen bei der Identifizierung langsam ausgeführter Abfragen. Besondere Sorgfalt und Aufmerksamkeit sollten der Implementierung geeigneter neuer Indextypen zukommen. Insbesondere ist die Postgres-Datenbank-Engine so konzipiert, dass die Abfrageleistung optimiert wird, ohne dass Abfragehinweise angegeben werden müssen oder können.

Empfohlene Lösung: Erweiterungen sind von integraler Bedeutung für die Leistungsfähigkeit von Postgres. Es gibt mehrere Erweiterungen, mit denen Sie wichtige Features bereitstellen können, um sicherzustellen, dass Ihre Datenbank mit Leistung arbeitet. Einige zu berücksichtigende Erweiterungen:

  • auto_explain: protokolliert automatisch Ausführungspläne für Abfragen, die über einen festgelegten Schwellenwert hinausgehen. Ermöglicht Datenbankadministratorteams, Leistungsprobleme zu diagnostizieren und die Abfrageleistung zu optimieren, ohne für jede Abfrage EXPLAIN manuell ausführen zu müssen.

  • pg_trgm: stellt Funktionen und Operatoren zur Bestimmung der Ähnlichkeit von textbasierten Daten mithilfe der Trigrammzuordnung bereit. Diese Erweiterung ist nützlich für Aufgaben, die Textsuche, Fuzzyübereinstimmung und auf Ähnlichkeit basierende Abfragen umfassen. Sie bietet in Kombination mit GIN- oder GIST-Indizes für Textspalten eine höhere Leistung bei LIKE-Abfragen und Ähnlichkeitssuchen.

  • pg_cron: ermöglicht die Planung und Verwaltung regelmäßiger Vorgänge direkt in der Datenbank. Sie integriert eine cron-ähnliche Planung in Postgres und ermöglicht die Automatisierung von Routinewartungsaufgaben, Datenverarbeitung und ähnlichen sich wiederholenden Vorgängen.

Tipp

Wenn Ihre Datenbankvorgänge eine erhebliche Anzahl wiederholter Erstellungs- und Löschungsaufgaben für Datenbankobjekte umfassen, steigt die Anzahl älterer Tupel in der Systemtabelle „pg_catalog“, was zu einer „Aufblähung“ der Tabelle führt. Da pg_catalog eine Systemtabelle ist, die an vielen Datenbankvorgängen beteiligt ist, kann eine Wartung dieser Tabelle ohne entsprechende Gegenmaßnahmen zu einer Beeinträchtigung der Leistung der gesamten Datenbank führen. Durch die Konfiguration eines wiederkehrenden pg_cron-Zeitplans kann sichergestellt werden, dass pg_catalog angemessen gewartet und bereinigt wird.

  • pg_hint_plan: Postgres zielt darauf ab, eine konsistente und zuverlässige Leistung ohne manuelle Eingriffe zu bieten. Dies führt dazu, dass die beabsichtigte Entwurfsentscheidung keine Abfragehinweise enthält. Für einige Szenarien, in denen spezifische und präzise Kontrolle über Abfrageplandesigns erforderlich sind, bietet pg_hint_plan eine Möglichkeit, die Entscheidungen des Abfrageplaners mithilfe von Hinweisen zu beeinflussen, die in SQL-Kommentare eingebettet sind. Diese Hinweise ermöglichen Es Datenbankadministratoren, den Abfrageplaner zu leiten, bestimmte Pläne auszuwählen, um komplexe Abfragen zu optimieren oder Leistungsprobleme zu beheben, die der Planner möglicherweise nicht alleine verarbeiten kann.

Hinweis

Diese Beispiele sind nur eine sehr kleine Auswahl der unglaublich riesigen Anzahl Erweiterungen, die für Ihre Postgres-Datenbank zur Verfügung steht. Es wird empfohlen, alle Erweiterungen zu erkunden, um Ihre Postgres-Datenbank zu optimieren. Darüber hinaus können Sie auch überlegen, eigene Erweiterungen zu erstellen, wenn Sie Potenzial erkennen, Postgres über seine aktuellen Funktionen hinaus zu erweitern. Die leistungsstarke und flexible Erweiterungsarchitektur stellt sicher, dass Sie Postgres jederzeit an Ihre Plattformanforderungen anpassen und weiterentwickeln können.

Szenario: In einigen Fällen haben Strategien zur Partition von Legacytabellen zur Erstellung von Tausenden von Partitionen geführt. Obwohl dies möglicherweise bei früherer Verwendung wirksam war, können diese Strategien die Abfrageleistung in Postgres unter bestimmten Umständen verlangsamen. In sehr bestimmten Fällen kann der Abfrageplaner beim Analysieren der Abfrage möglicherweise den entsprechenden Partitionsschlüssel nicht ermitteln. Aufgrund des resultierenden Verhaltens verlängert sich die Planungszeit, sodass die Abfrageplanung länger dauert als die eigentliche Abfrageausführung.

Empfohlene Lösung: Bewerten Sie die Notwendigkeit für Partitionierungsstrategien neu, die eine übermäßige Anzahl von Partitionen generieren. Das Postgres-Datenbankmodul erfordert möglicherweise nicht mehr dieselbe Segmentierung von Daten und eine Verringerung der Anzahl von Partitionen könnte wahrscheinlich die Leistung verbessern. Wenn ein älteres Partitionierungsschema bewertet und als erforderlich festgelegt wurde, sollten Sie die Abfrage in separaten Vorgängen umstrukturieren, um zuerst dynamische Partitionsschlüssel zu identifizieren und zu extrahieren und anschließend die Partitionsschlüssel in Ihren Abfragevorgängen zu verwenden.

Szenario: Manchmal müssen externe Abhängigkeiten und Umgebungsverhältnisse hybride Datenbankszenarien erfordern, in denen sowohl Oracle- als auch Azure Postgres-Datenbanken koexistieren müssen. Es kann z. B. Vorkommen geben, in denen phasenweise Migrationen erforderlich sind, um direkt aus Azure Postgres auf Oracle-Daten zuzugreifen und diese abzufragen, ohne dass der Aufwand für das Importieren von Daten oder das Ändern komplexer ETL-Prozesse besteht. In anderen Fällen können parallele Datenüberprüfungen durchgeführt werden, indem äquivalente Datasets in Oracle- und Azure Postgres-Umgebungen gleichzeitig verglichen werden, um die Datenkonsistenz und -integrität während und/oder nach der Migration sicherzustellen.

Empfohlene Lösung: FDW-Erweiterungen (Foreign Data Wrapper) von PostgreSQL sind ein wichtiges Feature von Postgres, mit dem Sie auf in externen Systemen gespeicherte Daten so zugreifen und diese bearbeiten können, als wenn sie nativ in der Azure Postgres-Datenbank gespeichert sind. FDWs ermöglichen Azure Postgres, als Verbunddatenbank zu fungieren und damit die Integration einer beliebigen Anzahl externer Datenquellen (einschließlich Oracle-Datenbanken) zu ermöglichen. FDWs erstellen Fremdtabellendefinitionen in Ihrer Postgres-Datenbank. Diese Fremdtabellen dienen dann als Proxy für Ihre definierte externe Datenquelle, sodass Benutzende diese Fremdtabellen mithilfe regulärer SQL-Abfragen abfragen können. Intern verwendet die Postgres-Engine die externe FDW-Definition, um nach Bedarf mit Daten aus der Remotedatenquelle zu kommunizieren und diese zu koordinieren.

oracle_fdw: (Foreign Data Wrapper for Oracle) ist eine Postgres-Erweiterung, mit der Sie in Azure Postgres auf Oracle-Datenbanken zugreifen können. Bei der Migration von Oracle zu Azure Postgres kann oracle_fdw eine entscheidende Rolle spielen, da Funktionen für Datenzugriff, Datenüberprüfung, inkrementelle Migration und Echtzeitdatensynchronisierung bereitgestellt werden. Berücksichtigen Sie bei Verwendung von FDWs die folgenden wichtigen Überlegungen:

  • Das Ausführen von Abfragen über oracle_fdw führt zu Mehraufwand durch Netzwerkkommunikation und Aushandlung der Authentifizierung, während die Daten verarbeitet und vom Oracle-Remoteserver abgerufen werden.
  • Einige Datentypen benötigen möglicherweise eine spezielle Behandlung oder Konvertierung, um sicherzustellen, dass Datentypen zwischen Systemen ordnungsgemäß zugeordnet sind.

Die effektive Verwendung von oracle_fdw kann dazu beitragen, den Datenbankübergang zu vereinfachen und die Zugänglichkeit von Daten sicherzustellen, da Ihre Anwendungen und Daten während des gesamten Migrationsprozesses zugänglich bleiben.

Verwandte Inhalte

  • Last updated on