PostgreSQL: Unterstützte Datentypen, Objekte und Vorgänge

Oracle GoldenGate für PostgreSQL unterstützt die Erfassung und Zustellung von anfänglichen Lade- und Transaktionsdaten für unterstützte PostgreSQL-Datenbankversionen.

Oracle GoldenGate für PostgreSQL unterstützt die Zuordnung, Filterung und Transformation von Quelldaten, sofern in diesem Dokument nichts anderes angegeben ist, sowie die Replikation von Daten, die von anderen von Oracle GoldenGate unterstützten Quelldatenbanken abgeleitet werden, in PostgreSQL-Datenbanken.

Unterstützte Datenbanken

Im Folgenden werden unterstützte Datenbanken und Einschränkungen für Oracle GoldenGate für PostgreSQL aufgeführt:

• Nur Benutzerdatenbanken werden für Erfassung und Zustellung unterstützt.

• Oracle GoldenGate unterstützt keine Erfassung aus archivierten Logs.

• Die Zustellung wird für Replikate und Standbydatenbanken nicht unterstützt.

• Capture wird auch von Replikaten und Standbydatenbanken unterstützt.

• Hohe Verfügbarkeit. Weitere Informationen finden Sie unter Überlegungen zu High Availability.

Überlegungen zur Hochverfügbarkeit

Oracle GoldenGate unterstützt das Erfassen von Änderungsdaten aus der High Availability-Konfiguration PostgreSQL. Diese Funktionalität ist nur auf PostgreSQL-Datenbankversionen 16 und höher verfügbar. Die Erfassung von Änderungsdaten kann auf dem Primärserver oder einem beliebigen schreibgeschützten Standby-Server im High Availability-Setup konfiguriert werden. Um mögliche Datenverluste und manuelle Eingriffe bei Failover zu vermeiden, empfiehlt Oracle GoldenGate, das High Availability-Setup mit synchroner Replikation zu konfigurieren.

Weitere Informationen zu möglichen Datenverlusten und Szenarios für manuelle Eingriffe finden Sie in den Oracle GoldenGate-Prozeduren für PostgreSQL High Availability Failover Doc ID 2818379.1.

Um den CDC-Extrakt aus einem PostgreSQL High Availability-Setup zu konfigurieren, führen Sie die folgenden Aufgaben aus: 1. Extract kann so konfiguriert werden, dass Daten vom Primärserver oder einem schreibgeschützten Standby-Server im High Availability-Setup erfasst werden.

1. Wenn Extract auf einem Knoten (primär oder Standby) konfiguriert ist, muss der Replikations-Slot mit demselben Namen auf allen anderen Knoten im High Availability-Setup gleichzeitig erstellt werden, bevor die Datenerfassung gestartet wird.

   1. Verwenden Sie den Befehl REGISTER EXTRACT, um den Replikationsslot auf einem Server (auf dem der Extract konfiguriert ist) zu erstellen, wie im folgenden Beispiel dargestellt:

      REGISTER EXTRACT exte

   2. Erstellen Sie unmittelbar nach der Registrierung von Extract den Replikations-Slot mit demselben Namen. Sie müssen denselben Replikations-Slot-Namen auf allen anderen Knoten im High Availability-Setup explizit verwenden.

      postgres=# select pg_create_logical_replication_slot('exte_ac6b520cab2871b7', 'test_decoding');
       pg_create_logical_replication_slot
      
      ------------------------------------
       (exte_ac6b520cab2871b7,0/8169E00)
      (1  row)

      2025-01-20T06:58:22Z  INFO    OGG-25355  Successfully created replication slot 'exte_ac6b520cab2871b7' for Extract group 'EXTE' in database 'postgres'.

   3. Melden Sie sich bei der entsprechenden Datenbank an, und führen Sie die pg_create_logical_replication_slot-Anweisung aus PSQL aus. Hinweis: WICHTIGER HINWEIS FÜR REPLICATION SLOT CREATION ON STANDBY: Wenn die Erstellung des Replikations-Slots auf dem schreibgeschützten STANDBY-Server versucht wird (entweder mit dem Befehl REGISTER EXTRACT oder der Anweisung pg_create_logical_replication_slot), wird der Vorgang erst abgeschlossen, nachdem eine DML (eine beliebige zufällige DML) für eine Tabelle auf dem primären Server im High Availability-Setup ausgeführt wurde. Alternativ kann die Heartbeat-Funktionalität auf dem primären Server aktiviert werden. Dies kann dazu führen, dass die erforderliche DML-Aktivität auf der primären Datenbank die Erstellung des Replikations-Slots auf dem Standby-Server abschließt.

1. ADD TRANDATA- oder DELETE TRANDATA-Befehle werden auf keinen schreibgeschützten Standbyservern im High Availability-Setup PostgreSQL unterstützt. Die Einstellung REPLICA IDENTITY einer Tabelle auf dem schreibgeschützten Standby-Server entspricht der Einstellung REPLICA IDENTITY der entsprechenden Tabelle auf dem Primärserver.

2. Um die Heartbeat-Funktionalität zu verwenden, wenn die Datenerfassung auf einem schreibgeschützten Standby-Server konfiguriert ist, muss die Heartbeat-Funktionalität auf dem primären Server aktiviert sein.

3. Im Falle eines Failovers sollte die Extrahierungsparameterdatei so geändert werden, dass eine Verbindung zum gewünschten Knoten hergestellt wird (entweder Primär-/Standby, basierend auf der Anforderung), um die Datenerfassung nach dem Failover fortzusetzen.

   Beispiel

   Betrachten Sie eine Situation, in der sich drei Knoten im High Availability-Cluster PostgreSQL mit entsprechenden Verbindungsaliasnamen befinden:

   Node1 (aktuelle Primärdatenbank) mit dem entsprechenden Verbindungsalias: node1

   Node2 (Standby) mit dem entsprechenden Verbindungsalias: node2

   Node3 (Standby) mit dem entsprechenden Verbindungsalias: node3

   Wenn der Extract vor dem Failover so konfiguriert ist, dass Daten von einem der Knoten (wie node2) erfasst werden, enthält die Extract-Parameterdatei einen Eintrag wie den folgenden:

   USERIDALIAS node2

   Bei einem Failover wird der primäre Knoten (node1) heruntergefahren, und der sekundäre Knoten (node2) wird zum neuen primären Knoten. Dann gibt es zwei Möglichkeiten:

   1. So fahren Sie mit der Datenerfassung aus demselben node2 fort:

      • In der Extract-Parameterdatei sind keine Änderungen erforderlich.

      • Starten Sie den Extract neu.

   2. So erfassen Sie die Daten immer von einem anderen Knoten aus:

      • Ändern Sie die Extract-Parameterdatei, um eine Verbindung zum gewünschten Knoten herzustellen, wie Node3.

        USERIDALIAS node3

      • Starten Sie den Extract neu.

Unterstützte PostgreSQL-Datentypen

Im Folgenden finden Sie eine Liste der PostgreSQL-Datentypen, die Oracle GoldenGate unterstützt, sowie die Einschränkungen dieser Unterstützung.

• array

• bigint

• bigserial

• bit(n)

• bit varying(n)

• boolean

• bytea

• char (n)

• cidr

• citext

• date

• decimal

• double precision

• Enumerated Types

• inet

• integer

• interval

• json

• jsonb

• macaddr

• macaddr8

• money

• numeric

• pgvector extension

• real

• serial

• smallint

• smallserial

• text

• time mit/ohne Zeitzone

• timestamp mit/ohne Zeitzone

• tsquery

• tsvector

• uuid

• varchar(n)

• varbit

• xml

Arraydatentyp verarbeiten

PostgreSQL unterstützt array verschiedener integrierter und UDT-Typen. Ab Oracle GoldenGate-Release 26ai unterstützen Oracle GoldenGate Extract und Replicat den Datentyp PostgreSQL array der folgenden Typen:

• boolean

• bigint

• bit

• char

• date

• double precision

• enum

• int

• interval

• numeric

• money

• real

• smallint

• timestamp, timestampz, time, timetz

• varbit

• varchar

• text

• tsvector

• tsquery

Die Datentypen real, double, numeric unterstützen die speziellen numerischen Werte NaN und Infinity/-Infinity.

Weitere Informationen zu Datentypen nach Datenbanken, die spezielle Werte unterstützen, finden Sie unter Von Datenbankdatentypen unterstützte Sonderwerte.

Sowohl das erstmalige Laden als auch der CDC-Extrakt unterstützen diese Array-Typen.

Hinweis: Initial Load Extract unterstützt PostgreSQL array des Datentyps time nicht.

Einschränkungen des Supports

• Wenn die Spalten der Datentypen char, varchar, text oder bytea Teil eines Primär- oder eindeutigen Schlüssels sind, darf die maximale individuelle Länge für diese Spalten 8191 Byte nicht überschreiten.

• Extract kann keine Datensätze verarbeiten, deren bytea-Spalten größer als 512 MB sind.

• Spalten des Datentyps CITEXT, die Teil des Primärschlüssels sind, werden bis zu 8000 Byte unterstützt. CITEXT-Spalten, die mehr als 8000 Byte umfassen und Teil des Primärschlüssels sind, werden nicht unterstützt.

• Extract kann keine Datensätze verarbeiten, deren bytea-Spalten größer als 512 MB sind.

• decimal: NaN-Eingabewerte werden nicht unterstützt.

• Die folgenden Einschränkungen gelten für bit/varbit-Datentypen:

  • Sie werden bis zu 4k unterstützt. Bei Längen größer als 4k werden die Daten abgeschnitten, und nur die unteren 4k-Bits werden erfasst.

  • Die Quellbitspalte (n) kann nur auf eine Zeichentypspalte in einem Nicht-PostgreSQL-Ziel angewendet werden und auf einen char-Typ oder eine bit/varbit-Spalte in einem PostgreSQL-Ziel angewendet werden.

• Die folgenden Einschränkungen gelten sowohl für timestamp mit Zeitzone als auch für timestamp ohne Zeitzone:

  • Die Daten timestamp mit BC- oder AD-Tags in den Daten werden nicht unterstützt.

  • Die Daten der timestamp, die älter als 1883-11-18 12:00:00 sind, werden nicht unterstützt.

  • Die Daten der timestamp mit mehr als 4 Stellen in der YEAR-Komponente werden nicht unterstützt.

  • Infinity/-Infinity-Eingabezeichenfolgen für timestamp-Spalten werden nicht unterstützt.

• Bei der Verwendung von interval gelten die folgenden Einschränkungen:

  • Das Erfassen von interval-Daten mit gemischtem Vorzeichen aus Spalten des Typs interval wird nicht unterstützt. Sie können DBOPTIONS ALLOWNONSTANDARDINTERVALDATA in der Extract-Parameterdatei verwenden, um die interval-Daten mit gemischtem Vorzeichen (oder ein anderes Format von interval-Daten, das von Oracle GoldenGate nicht unterstützt wird) als Zeichenfolge (nicht als interval-Standarddaten) zu erfassen.

  Im Folgenden finden Sie einige Beispiele für Daten, die in die Traildatei geschrieben werden, wenn DBOPTIONS ALLOWNONSTANDARDINTERVALDATA in der Extract-Parameterdatei verwendet wird:

  • +1026-9 +0 +0:0: 22.000000 wird als 1026 Jahre, 9 Monate, 0 Tage, 0 Stunden, 0 Minuten, 22 Sekunden interpretiert.

  • -0-0 -0 -8 wird als 0 Jahre, 0 Monate, 0 Tage, -8 Stunden interpretiert.

  • +1-3 +0 +3:20 wird als 1 Jahr, 3 Monate, 0 Tage, 3 Stunden, 20 Minuten interpretiert.

• Replicat: Wenn die Quellintervalldaten mit DBOPTIONS ALLOWNONSTANDARDINTERVALDATA erfasst und als Zeichenfolge in den Trail geschrieben wurden, kann die entsprechende Quellspalte entweder einer Spalte vom Typ char oder binary im Ziel zugeordnet werden.

• date-Einschränkungen:

  • Die Daten date mit BC- oder AD-Tags in den Daten werden nicht unterstützt.

  • Infinity/-Infinity-Eingabezeichenfolgen für date-Spalten werden nicht unterstützt.

• Spalten von text, json, xml, bytea, char (>8191), varchar (>8191) werden als LOB-Spalten behandelt und haben die folgenden Einschränkungen:

  • Wenn Sie GETUPDATEBEFORES verwenden, wird das Before Image der LOB-Spalten nicht protokolliert.

  • Wenn Sie NOCOMPRESSUPDATES verwenden, werden LOB-Spalten nur dann im After-Image protokolliert, wenn sie geändert wurden.

• Die Unterstützung von Reichweite und Genauigkeit für Gleitkommazahlen hängt vom Hostrechner ab. Im Allgemeinen ist die Genauigkeit auf 16 signifikante Stellen genau, aber Sie sollten die Datenbankdokumentation überprüfen, um die erwarteten Näherungen zu ermitteln. Oracle GoldenGate rundet oder schneidet Werte ab, die den unterstützten Nachkommastellenwert überschreiten.

Nicht unterstützte PostgreSQL-Datentypen

Oracle GoldenGate für PostgreSQL unterstützt die folgenden Datentypen nicht:

• box

• bpchar

• circle

• Composite Types

• Domain Types

• line

• lseq

• Object Identifiers Types

• path

• pg_lsn

• pg_snapshot

• point

• polygon

• Pseudo-Types

• Range Types

• User-defined Types (UDTs)

• Erweiterungen und zusätzliche bereitgestellte Module, die unter https://www.postgresql.org/docs/current/contrib.html aufgeführt sind, werden von Oracle GoldenGate nur unterstützt, wenn sie explizit unter Unterstützte PostgreSQL-Datentypen aufgeführt sind. Hinweis: Wenn die Extract-Parameterdatei eine Tabelle mit nicht unterstützten Datentypen enthält, wird der Extract mit einer Fehlermeldung gestoppt. Um die Replikation fortzusetzen, entfernen Sie die Tabelle aus der Extract-Datei, oder entfernen Sie die Spalte mit einem nicht unterstützten Datentyp aus der Tabelle.

Unterstützte Objekte und Vorgänge für PostgreSQL

• Oracle GoldenGate für PostgreSQL unterstützt nur DML-Vorgänge (Einfügen/Aktualisieren/Löschen). DDL-Replikationen werden nicht unterstützt.

• Oracle GoldenGate für PostgreSQL unterstützt die Replikation von Truncate-Vorgängen ab PostgreSQL 11 und erfordert den Parameter GETTRUNCATES in Extract und Replicat.

• Mehrere Truncate-Vorgänge werden nur in pgoutput plugin unterstützt.

• Verwendung von Bezeichnungen, bei denen die Groß-/Kleinschreibung beachtet wird:

  • Bei Namen ohne Anführungszeichen wird die Groß-/Kleinschreibung nicht beachtet. Sie sind implizit in Kleinbuchstaben geschrieben. Beispiel: CREATE TABLE MixedCaseTable und SELECT * FROM mixedcasetable sind äquivalent.

  • Bei Tabellen- und Spaltennamen in Anführungszeichen muss die Groß-/Kleinschreibung beachtet werden. Sie müssen in Extracts und Replicats sowie mit Oracle GoldenGate-Befehlen korrekt aufgeführt werden.

  Beispiel: TABLE appschema."MixedCaseTable" und ADD TRANDATA appschema."MixedCaseTable" sind erforderlich, um einen Tabellennamen zu unterstützen, bei dem die Groß-/Kleinschreibung beachtet wird.

Tabellen, Views und Materialized Views

Tabellen, die für die Erfassung und Übermittlung eingeschlossen werden sollen, müssen die folgenden Anforderungen erfüllen und dürfen nur Datentypen enthalten, die unter Unterstützte Datentypen PostgreSQL aufgeführt sind.

• Oracle GoldenGate für PostgreSQL unterstützt die Erfassung von Transaktions-DML aus Benutzertabellen und die Bereitstellung an Benutzertabellen.

• Oracle GoldenGate für PostgreSQL, Version 21.14.0.0.0 und höher, unterstützt Capture- und Delivery-Vorgänge für partitionierte Basistabellen. Um Daten aus partitionierten PostgreSQL-Tabellen zu erfassen, muss die Replikatidentitätseinstellung aller Partitionen mit der Replikatidentitätseinstellung der partitionierten Basistabelle übereinstimmen. Dies gilt auch für partitionierte Tabellen mit mehreren Ebenen.

  Zum Einrichten dieser Konfiguration stehen Ihnen folgende Möglichkeiten zur Verfügung:

  1. Führen Sie den Befehl ADD TRANDATA für alle oder die erforderlichen Partitionen der base-partitionierten Tabelle aus:

     ADD TRANDATA *partition-name* ALLCOLS

  2. Führen Sie den Befehl ALTER TABLE für alle oder erforderliche Partitionen der Basistabelle aus:

     ALTER TABLE *partition-name* REPLICA IDENTITY *replica-identity-setting*

• Die Globalisierung wird für Objektnamen (Tabellennamen /schema/database/column) und Spaltendaten unterstützt.

• Erfassung und Zustellung für eine Materialized View werden unterstützt.

• Der Extraktionsprozess unterstützt Materialized Views, die einen eindeutigen Index aufweisen müssen und gleichzeitig aktualisiert werden müssen.

• Die Replikatidentität von Materialized Views muss auf FULL gesetzt sein, damit CDR, UNIFIED FORMAT RECORD und NOCOMPRESSDELETES, GETUPDATEBEFORES unterstützt werden können. Außerdem ist die Einstellung FULL der Replikatidentität erforderlich, damit die Materialized View den Datensatz WAL DELETE verarbeiten kann. Wenn die Replikatidentität für die Materialized View nicht auf FULL gesetzt ist, wird der Datensatz DELETE nicht von Extract verarbeitet.

  Um die Replikatidentität auf FULL zu setzen, verwenden Sie den folgenden Befehl:

  add trandata *schema.materialized_view*, ALLCOLS

• Die Statistiken für eine UPDATE oder PK UPDATE werden als DELETE gefolgt von INSERT protokolliert. Dies zeigt zwar eine Anomalie in den Extract-Statistiken an, aber die Datensynchronisierung ist korrekt, wenn die Materialized View-Daten der Quelle und des Ziels verglichen werden.

• Die PK UPDATE führt zu DELETE gefolgt von INSERT, sodass die Extract-Statistiken anders angezeigt werden als die Datenbankzeilenanzahl. Sie müssen sich auf die Datenvergleichstools verlassen, um die Datenintegrität zwischen Quell- und Zieldaten mit den Materialized Views-Datensätzen zu prüfen.

• Die Daten aus dem Trail können vom Replicat-Prozess nicht auf die Materialized View angewendet werden. Sie können die Materialized View-Daten aus dem Trail stattdessen einer anderen Tabelle zuordnen.

Einschränkungen

• Oracle GoldenGate für PostgreSQL unterstützt keine Erfassung und Zustellung von Ansichten.

• Oracle GoldenGate für PostgreSQL unterstützt keine Erfassung von einzelnen Partitionen einer partitionierten Tabelle.

Sequenzen und Identity-Spalten

• Sequenzen werden in Quell- und Zieltabellen für unidirektionale, bidirektionale und multidirektionale Implementierungen unterstützt.

• Identitätsspalten, die mit der Klausel GENERATED BY DEFAULT AS IDENTITY erstellt wurden, werden in Quell- und Zieltabellen für unidirektionale, bidirektionale und multidirektionale Implementierungen unterstützt.

• Identitätsspalten, die mit der Klausel GENERATED ALWAYS AS IDENTITY erstellt wurden, werden in Zieldatenbanktabellen nicht unterstützt. Die Eigenschaft "Identität" muss aus Zieltabellen entfernt oder in GENERATED BY DEFAULT AS IDENTITY geändert werden.

• Definieren Sie für bidirektionale und multidirektionale Implementierungen die Identity-Spalten und -Sequenzen mit einem INCREMENT BY-Wert, der der Anzahl der Server in der Konfiguration entspricht, und einem anderen MINVALUE-Wert für jeden.

  Beispiel: Die Werte MINVALUE /INCREMENT BY für eine bidirektionale Konfiguration mit zwei Datenbanken lauten wie folgt:

  Database1, setzen Sie MINVALUE auf 1 mit einem INCREMENT BY von 2.

  Database2, setzen Sie die MINVALUE auf 2 mit einem INCREMENT BY von 2.

  Beispiel: MINVALUE /INCREMENT BY-Werte für eine multidirektionale Konfiguration mit drei Datenbanken lauten wie folgt:

  Database1, setzen Sie MINVALUE auf 1 mit einem INCREMENT BY von 3.

  Database2, setzen Sie MINVALUE auf 2 mit dem Wert INCREMENT BY auf 3.

  Database3, setzen Sie MINVALUE auf 3 mit dem Wert INCREMENT BY von 3.