PostgreSQL: tipi di dati, oggetti e operazioni supportati

Oracle GoldenGate for PostgreSQL supporta l'acquisizione e la consegna del caricamento iniziale e dei dati transazionali per le versioni di database PostgreSQL supportate.

Oracle GoldenGate for PostgreSQL supporta il mapping, il filtro e la trasformazione dei dati di origine, a meno che non venga indicato diversamente in questo documento, nonché la replica dei dati derivati da altri database di origine supportati da Oracle GoldenGate, nei database PostgreSQL.

Database supportati

Di seguito sono riportati i database supportati e le limitazioni per Oracle GoldenGate for PostgreSQL:

• Solo i database utente sono supportati per l'acquisizione e la consegna.

• Oracle GoldenGate non supporta l'acquisizione dai log archiviati.

• La consegna non è supportata nei database di replica e standby.

• L'acquisizione è supportata anche dai database di replica e standby.

• High Availability. Per informazioni dettagliate, vedere Considerazioni sull'alta disponibilità.

Considerazioni sull'alta disponibilità

Oracle GoldenGate supporta l'acquisizione dei dati di modifica dalla configurazione High Availability PostgreSQL. Questa funzionalità è disponibile solo nelle versioni di database PostgreSQL 16 e successive. L'acquisizione dei dati di modifica può essere configurata sul server primario o su qualsiasi server in standby di sola lettura nell'impostazione High Availability. Per evitare possibili perdite di dati e interventi manuali in caso di failover, Oracle GoldenGate consiglia di configurare l'impostazione High Availability utilizzando la replica sincrona.

Per ulteriori dettagli su possibili scenari di perdita di dati e intervento manuale, consultare le procedure di Oracle GoldenGate per l'ID documento 2818379.1 PostgreSQL High Availability Failover.

Per configurare CDC Extract da un'impostazione PostgreSQL High Availability, eseguire i task riportati di seguito. 1. L'estrazione può essere configurata per acquisire dati dal server primario o da un server in standby di sola lettura nell'impostazione High Availability.

1. Quando Extract è configurato su un nodo (primario o in standby), lo slot di replica con lo stesso nome deve essere creato contemporaneamente su tutti gli altri nodi nell'impostazione High Availability, prima di avviare l'acquisizione dei dati.

   1. Utilizzare il comando REGISTER EXTRACT per creare lo slot di replica su un server (in cui è configurato Extract), come mostrato nell'esempio riportato di seguito.

      REGISTER EXTRACT exte

   2. Subito dopo la registrazione di Extract, creare lo slot di replica con lo stesso nome. È necessario utilizzare lo stesso nome slot di replica su tutti gli altri nodi nell'impostazione High Availability in modo esplicito.

      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. Connettersi al database corrispondente ed eseguire l'istruzione pg_create_logical_replication_slot da PSQL. Nota: NOTA IMPORTANTE PER REPLICATION SLOT CREATION ON STANDBY: quando si tenta di creare lo SLOT di replica sul server in STANDBY di sola lettura (utilizzando il comando REGISTER EXTRACT o l'istruzione pg_create_logical_replication_slot), l'operazione viene completata solo dopo che alcuni DML (può essere un DML casuale) vengono eseguiti su qualsiasi tabella del server primario nell'impostazione di High Availability. In alternativa, è possibile abilitare la funzionalità heartbeat sul server primario, che può causare l'attività DML richiesta sul database primario, per completare la creazione dello slot di replica sul server in standby.

1. I comandi ADD TRANDATA o DELETE TRANDATA non sono supportati su alcun server in standby di sola lettura nell'impostazione High Availability PostgreSQL. L'impostazione REPLICA IDENTITY di qualsiasi tabella nel server di standby di sola lettura equivale all'impostazione REPLICA IDENTITY della tabella corrispondente nel server primario.

2. Per utilizzare la funzionalità di heartbeat quando l'acquisizione dei dati è configurata su un server in standby di sola lettura, la funzionalità di heartbeat deve essere abilitata sul server primario.

3. In caso di failover, il file dei parametri di estrazione deve essere modificato per connettersi al nodo desiderato (principale/standby, in base al requisito) per continuare l'acquisizione dei dati dopo il failover.

   Esempio

   Si consideri una situazione in cui sono presenti tre nodi nel cluster High Availability PostgreSQL, con gli alias di connessione corrispondenti:

   Node1 (principale corrente) con alias di connessione corrispondente: node1

   Node2 (standby) con alias di connessione corrispondente: node2

   Node3 (standby) con alias di connessione corrispondente: node3

   Prima del failover, se Extract è configurato per acquisire i dati da uno dei nodi (ad esempio node2), il file dei parametri Extract conterrà una voce simile alla seguente:

   USERIDALIAS node2

   In caso di failover, il nodo primario (node1) diventa inattivo e il nodo secondario (node2) diventa il nuovo nodo primario, quindi possono esserci due possibilità:

   1. Per continuare l'acquisizione dei dati dallo stesso node2:

      • Nessuna modifica richiesta nel file dei parametri Extract.

      • Riavviare l'estrazione.

   2. Per acquisire i dati sempre da un nodo diverso:

      • Modificare il file dei parametri Extract per connettersi al nodo desiderato, ad esempio Node3.

        USERIDALIAS node3

      • Riavviare l'estrazione.

Tipi di dati PostgreSQL supportati

Di seguito è riportata una lista dei tipi di dati PostgreSQL supportati da Oracle GoldenGate insieme alle limitazioni di questo supporto.

• 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 con/senza fuso orario

• timestamp con/senza fuso orario

• tsquery

• tsvector

• uuid

• varchar(n)

• varbit

• xml

Tipo di dati array gestione

PostgreSQL supporta array di vari tipi built-in e UDT. A partire dalla release 26ai di Oracle GoldenGate, Oracle GoldenGate Extract e Replicat supportano il tipo di dati PostgreSQL array dei tipi seguenti:

• boolean

• bigint

• bit

• char

• date

• double precision

• enum

• int

• interval

• numeric

• money

• real

• smallint

• timestamp, timestampz, time, timetz

• varbit

• varchar

• text

• tsvector

• tsquery

I tipi di dati real, double e numeric supportano i valori numerici speciali NaN e Infinity/-Infinity.

Per ulteriori informazioni sui tipi di dati in base ai database che supportano valori speciali, vedere Valori speciali supportati dai tipi di dati del database.

Sia il caricamento iniziale che l'estrazione CDC supportano questi tipi di array.

Nota: l'estrazione del caricamento iniziale non supporta PostgreSQL array del tipo di dati time.

Limitazioni del supporto

• Se le colonne dei tipi di dati char, varchar, text o bytea fanno parte di una chiave primaria o univoca, le singole lunghezze massime per queste colonne non devono superare gli 8191 byte.

• Extract non è in grado di elaborare i record con colonne bytea di dimensioni superiori a 512 MB.

• Le colonne del tipo di dati CITEXT che fanno parte della chiave primaria sono supportate con una dimensione massima di 8000 byte. Le colonne CITEXT con dimensione superiore a 8000 byte e che fanno parte della chiave primaria non sono supportate.

• Extract non è in grado di elaborare i record con colonne bytea di dimensioni superiori a 512 MB.

• I valori di input decimal: NaN non sono supportati.

• Le seguenti limitazioni si applicano ai tipi di dati bit/varbit:

  • Sono supportati fino a 4k di lunghezza. Per lunghezze superiori a 4k, i dati vengono troncati e vengono acquisiti solo i bit 4k inferiori.

  • La colonna bit(n) di origine può essere applicata solo a una colonna di tipo carattere in una destinazione non PostgreSQL e può essere applicata a un tipo char o a una colonna bit/varbit nella destinazione PostgreSQL.

• Le seguenti limitazioni sono applicabili sia a timestamp con fuso orario che a timestamp senza fuso orario:

  • I dati timestamp con tag BC o AD nei dati non sono supportati.

  • I dati timestamp precedenti alle 1883-11-18 12:00:00 non sono supportati.

  • I dati timestamp con più di 4 cifre nel componente YEAR non sono supportati.

  • Le stringhe di input Infinity/-Infinity per le colonne timestamp non sono supportate.

• Di seguito sono riportate le limitazioni relative all'utilizzo di interval.

  • L'acquisizione di dati interval con segno misto da colonne di tipo interval non è supportata. È possibile utilizzare DBOPTIONS ALLOWNONSTANDARDINTERVALDATA nel file dei parametri Extract per acquisire i dati interval del segno misto (o qualsiasi altro formato di dati interval, che non è supportato da Oracle GoldenGate) come stringa (non come dati interval standard).

  Di seguito sono riportati alcuni esempi di dati che vengono scritti nel file trail quando si utilizza DBOPTIONS ALLOWNONSTANDARDINTERVALDATA nel file del parametro Extract.

  • +1026-9 +0 +0:0: 22.000000 è interpretato come 1026 anni, 9 mesi, 0 giorni, 0 ore, 0 minuti, 22 secondi.

  • -0-0 -0 -8 è interpretato come 0 anni, 0 mesi, 0 giorni, -8 ore.

  • +1-3 +0 +3:20 viene interpretato come 1 anno, 3 mesi, 0 giorni, 3 ore, 20 minuti.

• Replicat: se i dati dell'intervallo di origine sono stati acquisiti utilizzando DBOPTIONS ALLOWNONSTANDARDINTERVALDATA e scritti come stringa nel trail, la colonna di origine corrispondente può essere mappata a una colonna di tipo char o binary nella destinazione.

• Le limitazioni di date sono:

  • I dati date con tag BC o AD nei dati non sono supportati.

  • Le stringhe di input Infinity/-Infinity per le colonne date non sono supportate.

• Le colonne di text, json, xml, bytea, char (>8191), varchar (>8191) vengono trattate come colonne LOB e presentano le seguenti limitazioni:

  • Quando si utilizza GETUPDATEBEFORES, l'immagine precedente delle colonne LOB non viene mai registrata.

  • Quando si utilizza NOCOMPRESSUPDATES, le colonne LOB vengono registrate nell'immagine successiva solo se sono state modificate.

• Il supporto della gamma e della precisione per i numeri a virgola mobile dipende dalla macchina host. In generale, la precisione è accurata a 16 cifre significative, ma è necessario esaminare la documentazione del database per determinare le approssimazioni previste. Oracle GoldenGate arrotonda o tronca i valori che superano la precisione supportata.

Tipi di dati PostgreSQL non supportati

Oracle GoldenGate for PostgreSQL non supporta i tipi di dati riportati di seguito.

• 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)

• Le estensioni e i moduli aggiuntivi forniti elencati all'indirizzo https://www.postgresql.org/docs/current/contrib.html non sono supportati da Oracle GoldenGate a meno che non siano elencati in modo esplicito in Tipi di dati PostgreSQLSupportati. Nota: se il file dei parametri Extract contiene una tabella con tipi di dati non supportati, l'estrazione verrà interrotta con un messaggio di errore. Per riprendere la replica, rimuovere la tabella dal file Extract o rimuovere la colonna dalla tabella con un tipo di dati non supportato.

Oggetti e operazioni supportati per PostgreSQL

• Oracle GoldenGate for PostgreSQL supporta solo le operazioni DML (Inserisci/Aggiorna/Elimina). Replica DDL non supportata.

• Oracle GoldenGate for PostgreSQL supporta la replica delle operazioni di troncamento che iniziano con PostgreSQL 11 e versioni successive e richiede il parametro GETTRUNCATES in Extract e Replicat.

• Più operazioni di troncamento sono supportate solo in pgoutput plugin.

• Uso nomi con distinzione tra maiuscole e minuscole/senza distinzione tra maiuscole e minuscole:

  • I nomi senza virgolette non fanno distinzione tra maiuscole e minuscole e sono implicitamente minuscole. Ad esempio, CREATE TABLE MixedCaseTable e SELECT * FROM mixedcasetable sono equivalenti.

  • I nomi delle tabelle e delle colonne citate fanno distinzione tra maiuscole e minuscole e devono essere elencati correttamente in Estrazioni e repliche e con i comandi di Oracle GoldenGate.

  Ad esempio, per supportare un nome di tabella con distinzione tra maiuscole e minuscole, sono richiesti TABLE appschema."MixedCaseTable" e ADD TRANDATA appschema."MixedCaseTable".

Tabelle, viste e viste materializzate

Le tabelle da includere per l'acquisizione e la consegna devono soddisfare i seguenti requisiti e includere solo i tipi di dati elencati in Tipi di dati PostgreSQL supportati.

• Oracle GoldenGate for PostgreSQL supporta l'acquisizione di DML transazionali dalle tabelle utente e la consegna alle tabelle utente.

• Oracle GoldenGate for PostgreSQL, versioni 21.14.0.0.0 e successive, supporta l'acquisizione e la consegna alle tabelle partizionate di base. Per acquisire dati da tabelle partizionate PostgreSQL, l'impostazione Identità replica di tutte le partizioni deve corrispondere all'impostazione Identità replica della tabella partizionata di base. Questo è applicabile anche alle tabelle partizionate su più livelli.

  Per impostare questa configurazione è possibile scegliere uno dei modi riportati di seguito.

  1. Eseguire il comando ADD TRANDATA su tutte le partizioni o sulle partizioni richieste della tabella partizionata di base.

     ADD TRANDATA *partition-name* ALLCOLS

  2. Eseguire il comando ALTER TABLE su tutte le partizioni o su quelle richieste della tabella partizionata di base.

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

• La globalizzazione è supportata per i nomi oggetto (nomi tabella /schema/database/column) e i dati colonna.

• L'acquisizione e la consegna di una vista materializzata sono supportate.

• Il processo di estrazione supporta le viste materializzate, che devono avere un indice univoco e devono essere aggiornate contemporaneamente.

• L'identità di replica delle viste materializzate deve essere impostata su FULL in modo da poter supportare CDR, UNIFIED FORMAT RECORD e NOCOMPRESSDELETES, GETUPDATEBEFORES. Inoltre, l'impostazione FULL dell'identità di replica è necessaria per consentire alla vista materializzata di elaborare il record WAL DELETE. Se l'identità di replica per la vista materializzata non è impostata su FULL, il record DELETE non verrà elaborato da Extract.

  Per impostare l'identità di replica su FULL, utilizzare il comando seguente:

  add trandata *schema.materialized_view*, ALLCOLS

• Le statistiche per un UPDATE o PK UPDATE verranno registrate come DELETE seguite da INSERT. Sebbene venga visualizzata un'anomalia nelle statistiche di estrazione, la sincronizzazione dei dati è corretta quando si confrontano i dati delle viste materializzate di origine e destinazione.

• PK UPDATE restituisce DELETE seguito da INSERT in modo che le statistiche di estrazione vengano visualizzate in modo diverso rispetto al conteggio delle righe del database. È necessario fare affidamento sugli strumenti di confronto dei dati per controllare l'integrità dei dati tra i dati di origine e di destinazione, contenenti i record delle viste materializzate.

• I dati del trail non possono essere applicati alla vista materializzata dal processo Replicat. È invece possibile mappare i dati delle viste materializzate dal trail a qualsiasi altra tabella.

Limitazioni

• Oracle GoldenGate for PostgreSQL non supporta l'acquisizione e la consegna per le viste.

• Oracle GoldenGate for PostgreSQL non supporta l'acquisizione da singole partizioni di una tabella partizionata.

Sequenze e colonne identità

• Le sequenze sono supportate sulle tabelle di origine e di destinazione per implementazioni unidirezionali, bidirezionali e multidirezionali.

• Le colonne di identità create utilizzando la clausola GENERATED BY DEFAULT AS IDENTITY sono supportate nelle tabelle di origine e di destinazione per le implementazioni unidirezionali, bidirezionali e multidirezionali.

• Le colonne di identità create utilizzando la clausola GENERATED ALWAYS AS IDENTITY non sono supportate nelle tabelle di database di destinazione e la proprietà Identità deve essere rimossa dalle tabelle di destinazione o modificata in GENERATED BY DEFAULT AS IDENTITY.

• Per le implementazioni bidirezionali e multidirezionali, definire le colonne e le sequenze di identità con un valore INCREMENT BY uguale al numero di server nella configurazione, con un MINVALUE diverso per ciascuno.

  Ad esempio, i valori MINVALUE/INCREMENT BY per una configurazione bidirezionale a due database sono i seguenti:

  Database1, impostare il MINVALUE a 1 con un INCREMENT BY di 2.

  Database2, impostare il MINVALUE a 2 con un INCREMENT BY di 2.

  Ad esempio, i valori MINVALUE/INCREMENT BY per una configurazione a tre database multidirezionale sono i seguenti:

  Database1, impostare il MINVALUE a 1 con un INCREMENT BY di 3.

  Database2, impostare il MINVALUE a 2 con un INCREMENT BY di 3.

  Database3, impostare il MINVALUE a 3 con un INCREMENT BY di 3.