PostgreSQL : types de données, objets et opérations pris en charge

Oracle GoldenGate pour PostgreSQL prend en charge la capture et la livraison des données de chargement initial et transactionnelles pour les versions de base de données PostgreSQL prises en charge.

Oracle GoldenGate pour PostgreSQL prend en charge la mise en correspondance, le filtrage et la transformation des données source, sauf indication contraire dans ce document, ainsi que la réplication des données dérivées d'autres bases de données source prises en charge par Oracle GoldenGate en bases de données PostgreSQL.

Bases de données prises en charge

Voici les bases de données prises en charge et les limites d'Oracle GoldenGate pour PostgreSQL :

Seules les bases de données utilisateur sont prises en charge pour la capture et la distribution.
Oracle GoldenGate ne prend pas en charge la capture à partir des fichiers de journalisation archivés.
La distribution n'est pas prise en charge pour les bases de données de secours de réplique.
La capture est également prise en charge à partir de bases de données de secours de réplique.
Haute disponibilité. Pour plus d'informations, reportez-vous à Remarques concernant la haute disponibilité.

Considérations relatives à la haute disponibilité

Oracle GoldenGate prend en charge la capture des données de modification à partir de la configuration haute disponibilité PostgreSQL. Cette fonctionnalité est disponible uniquement sur la base de données PostgreSQL versions 16 et ultérieures. La capture des données de modification peut être configurée sur le serveur principal ou sur tout serveur de secours en lecture seule dans la configuration Haute disponibilité. Pour éviter toute perte de données et toute intervention manuelle en cas de basculement, Oracle GoldenGate recommande de configurer la haute disponibilité à l'aide de la réplication synchrone.

Reportez-vous aux procédures Oracle GoldenGate pour PostgreSQL High Availability Failover Doc ID 2818379.1 afin d'obtenir plus de détails sur les éventuels scénarios de perte de données et d'intervention manuelle.

Pour configurer l'extraction CDC à partir d'une configuration de haute disponibilité PostgreSQL, effectuez les tâches suivantes : 1. Le processus Extract peut être configuré pour capturer des données à partir du serveur principal ou d'un serveur de secours en lecture seule dans la configuration Haute disponibilité.

Lorsque le processus Extract est configuré sur un noeud (principal ou de secours), l'emplacement de réplication portant le même nom doit être créé sur tous les autres noeuds de la configuration Haute disponibilité en même temps, avant de démarrer la capture des données.
1. Utilisez la commande REGISTER EXTRACT pour créer l'emplacement de réplication sur un serveur (où l'extraction est configurée), comme indiqué dans l'exemple suivant :
```
REGISTER EXTRACT exte
```
2. Immédiatement après l'enregistrement de l'extraction, créez l'emplacement de réplication avec le même nom. Vous devez utiliser explicitement le même nom d'emplacement de réplication sur tous les autres noeuds de la configuration Haute disponibilité.
```
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. Connectez-vous à la base de données correspondante et exécutez l'instruction pg_create_logical_replication_slot à partir de PSQL. Remarque : REMARQUE IMPORTANTE POUR REPLICATION SLOT CREATION ON STANDBY : lorsque la création de l'emplacement de réplication est tentée sur le serveur de secours en lecture seule (à l'aide de la commande REGISTER EXTRACT ou de l'instruction pg_create_logical_replication_slot), l'opération se termine uniquement après l'exécution d'une LMD (n'importe quelle LMD aléatoire) sur n'importe quelle table du serveur principal dans la configuration de haute disponibilité. La fonctionnalité de signal d'activité peut également être activée sur le serveur principal, ce qui peut entraîner l'activité LMD requise sur le serveur principal, pour terminer la création de l'emplacement de réplication sur le serveur de secours.

Les commandes ADD TRANDATA ou DELETE TRANDATA ne sont prises en charge sur aucun serveur de secours en lecture seule dans la configuration de haute disponibilité PostgreSQL. Le paramètre REPLICA IDENTITY de n'importe quelle table sur le serveur de secours en lecture seule est identique au paramètre REPLICA IDENTITY de la table correspondante sur le serveur principal.
Pour utiliser la fonctionnalité de signal d'activité lorsque la capture de données est configurée sur un serveur de secours en lecture seule, la fonctionnalité de signal d'activité doit être activée sur le serveur principal.
En cas de basculement, le fichier de paramètres d'extraction doit être modifié pour se connecter au noeud souhaité (principal/de secours, selon les besoins) afin de poursuivre la capture des données après le basculement.

Exemple

Prenons l'exemple d'une situation où le cluster de haute disponibilité PostgreSQL comporte trois noeuds, avec les alias de connexion correspondants :

Node1 (principal actuel) avec l'alias de connexion correspondant : node1

Node2 (de secours) avec l'alias de connexion correspondant : node2

Node3 (de secours) avec l'alias de connexion correspondant : node3

Avant le basculement, si le processus Extract est configuré pour capturer des données à partir de l'un des noeuds (par exemple, node2), le fichier de paramètres Extract contient une entrée similaire à la suivante :
```
USERIDALIAS node2
```
En cas de basculement, le noeud principal (node1) tombe en panne et le noeud secondaire (node2) devient le nouveau noeud principal, alors il peut y avoir deux possibilités :
1. Pour poursuivre la capture de données à partir du même fichier node2 :
  - Aucune modification n'est requise dans le fichier de paramètres Extract.
  - Redémarrez l'extraction.
2. Pour capturer les données toujours à partir d'un autre noeud :
  - Modifiez le fichier de paramètres Extract pour vous connecter au noeud souhaité, tel que Node3.
```
USERIDALIAS node3
```
  - Redémarrez l'extraction.

Types de données PostgreSQL pris en charge

Voici la liste des types de données PostgreSQL pris en charge par Oracle GoldenGate, ainsi que les limites de cette prise en charge.

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 avec/sans fuseau horaire
timestamp avec/sans fuseau horaire
tsquery
tsvector
uuid
varchar(n)
varbit
xml

Gestion du type de données de tableau

PostgreSQL prend en charge array de différents types intégrés et UDT. A partir de la version 26ai d'Oracle GoldenGate, les processus Extract et Replicat d'Oracle GoldenGate prennent en charge le type de données PostgreSQL array des types suivants :

boolean
bigint
bit
char
date
double precision
enum
int
interval
numeric
money
real
smallint
timestamp, timestampz, time, timetz
varbit
varchar
text
tsvector
tsquery

Les types de données real, double et numeric prennent en charge les valeurs numériques spéciales NaN et Infinity/-Infinity.

Pour plus d'informations sur les types de données par base de données qui prennent en charge des valeurs spéciales, reportez-vous à la section Special Values Supported by Database Data Types.

Le chargement initial et l'extraction CDC prennent en charge ces types de tableau.

Remarque : le processus Extract de chargement initial ne prend pas en charge le type de données PostgreSQL array de time.

Limites de prise en charge

Si les colonnes de type char, varchar, text ou bytea font partie d'une clé primaire ou unique, la longueur individuelle maximale de ces colonnes ne doit pas dépasser 8191 octets.
L'extraction ne peut pas traiter les enregistrements dont la taille des colonnes bytea est supérieure à 512 Mo.
Les colonnes de type de données CITEXT qui font partie de la clé primaire sont prises en charge jusqu'à 8000 octets. Les colonnes CITEXT de plus de 8000 octets qui font partie de la clé primaire ne sont pas prises en charge.
L'extraction ne peut pas traiter les enregistrements dont la taille des colonnes bytea est supérieure à 512 Mo.
Les valeurs d'entrée decimal: NaN ne sont pas prises en charge.
Les limitations suivantes s'appliquent aux types de données bit/varbit :
- Ils sont pris en charge jusqu'à 4k. Pour les longueurs supérieures à 4k, les données sont tronquées et seuls les bits 4k inférieurs sont capturés.
- La colonne bit(n) source peut être appliquée uniquement à une colonne de type caractère sur une cible autre que PostgreSQL et peut être appliquée à un type char ou à une colonne bit/varbit sur la cible PostgreSQL.
Les limitations suivantes sont applicables à timestamp avec fuseau horaire et à timestamp sans fuseau horaire :
- Les données timestamp avec des balises BC ou AD dans les données ne sont pas prises en charge.
- Les données timestamp antérieures à 1883-11-18 12:00:00 ne sont pas prises en charge.
- Les données timestamp comportant plus de 4 chiffres dans le composant YEAR ne sont pas prises en charge.
- Les chaînes d'entrée Infinity/-Infinity pour les colonnes timestamp ne sont pas prises en charge.
Les restrictions suivantes s'appliquent lors de l'utilisation de interval :
- La capture de données de signe mixte interval à partir de colonnes de type interval n'est pas prise en charge. Vous pouvez utiliser DBOPTIONS ALLOWNONSTANDARDINTERVALDATA dans le fichier de paramètres d'extraction pour capturer les données interval de signe mixte (ou tout autre format de données interval, qui n'est pas pris en charge par Oracle GoldenGate) en tant que chaîne (et non en tant que données interval standard).
Voici quelques exemples de données qui sont écrites dans le fichier trace lors de l'utilisation de DBOPTIONS ALLOWNONSTANDARDINTERVALDATA dans le fichier de paramètres d'extraction :
- +1026-9 +0 +0:0: 22.000000 est interprété comme 1026 ans, 9 mois, 0 jour, 0 heure, 0 minute, 22 secondes.
- -0-0 -0 -8 est interprété comme 0 an, 0 mois, 0 jour, -8 heures.
- +1-3 +0 +3:20 est interprété comme 1 an, 3 mois, 0 jour, 3 heures, 20 minutes.
Réplicat : si les données d'intervalle source ont été capturées à l'aide de DBOPTIONS ALLOWNONSTANDARDINTERVALDATA et écrites en tant que chaîne dans la trace, la colonne source correspondante peut être mise en correspondance avec une colonne de type char ou binary sur la cible.
Les limites de date sont les suivantes :
- Les données date avec des balises BC ou AD dans les données ne sont pas prises en charge.
- Les chaînes d'entrée Infinity/-Infinity pour les colonnes date ne sont pas prises en charge.
Les colonnes text, json, xml, bytea, char (>8191) et varchar (>8191) sont traitées en tant que colonnes LOB et présentent les limites suivantes :
- Lorsque vous utilisez GETUPDATEBEFORES, l'image "avant" des colonnes LOB n'est jamais consignée.
- Lors de l'utilisation de NOCOMPRESSUPDATES, les colonnes LOB sont journalisées dans l'image après uniquement si elles ont été modifiées.
La prise en charge de la plage et de la précision pour les nombres à virgule flottante dépend de la machine hôte. En général, la précision est de 16 chiffres significatifs, mais vous devez consulter la documentation de la base de données pour déterminer les approximations attendues. Oracle GoldenGate arrondit ou tronque les valeurs dépassant la précision prise en charge.

Types de données PostgreSQL non pris en charge

Oracle GoldenGate pour PostgreSQL ne prend pas en charge les types de données suivants :

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)
Les extensions et les modules supplémentaires fournis répertoriés à l'adresse suivante : https://www.postgresql.org/docs/current/contrib.html ne sont pas prises en charge par Oracle GoldenGate, sauf si elles sont explicitement répertoriées sous Types de données PostgreSQL pris en charge. Remarque : si le fichier de paramètres d'extraction contient une table avec des types de données non pris en charge, l'extraction s'arrête avec un message d'erreur. Pour reprendre la réplication, enlevez la table du fichier Extract ou enlevez la colonne de la table avec un type de données non pris en charge.

Objets et opérations pris en charge pour PostgreSQL

Oracle GoldenGate pour PostgreSQL prend uniquement en charge les opérations LMD (Insérer/Mettre à jour/Supprimer). La duplication de DDL n'est pas prise en charge.
Oracle GoldenGate pour PostgreSQL prend en charge la réplication des opérations de troncation commençant par PostgreSQL 11 et supérieures, et requiert le paramètre GETTRUNCATES dans Extract et Replicat.
Plusieurs opérations de troncation sont prises en charge dans pgoutput plugin uniquement.
Noms sensibles à la casse/non sensibles à la casse Utilisation :
- Les noms sans guillemets ne tiennent pas compte de la casse et sont implicitement en minuscules. Par exemple, CREATE TABLE MixedCaseTable et SELECT * FROM mixedcasetable sont équivalents.
- Les noms de table et de colonne entre guillemets respectent la casse et doivent être répertoriés correctement dans les extractions et les réplications, ainsi qu'avec les commandes Oracle GoldenGate.
Par exemple, TABLE appschema."MixedCaseTable" et ADD TRANDATA appschema."MixedCaseTable" sont requis pour prendre en charge un nom de table sensible à la casse.

Tables, vues et vues matérialisées

Les tables à inclure pour la capture et la distribution doivent répondre aux exigences suivantes et ne doivent inclure que les types de données répertoriés sous Types de données PostgreSQL pris en charge.

Oracle GoldenGate pour PostgreSQL prend en charge la capture des instructions LMD transactionnelles à partir des tables utilisateur et leur distribution aux tables utilisateur.
Oracle GoldenGate pour PostgreSQL, versions 21.14.0.0.0 et ultérieures, prend en charge la capture et la distribution vers les tables partitionnées de base. Pour capturer des données à partir de tables partitionnées PostgreSQL, le paramètre Identité de la réplique de toutes les partitions doit correspondre au paramètre Identité de la réplique de la table partitionnée de base. Cela s'applique également aux tables partitionnées multiniveau.

Pour configurer cette configuration, vous pouvez choisir l'une des méthodes suivantes :
1. Exécutez la commande ADD TRANDATA sur toutes les partitions de la table partitionnée de base ou sur les partitions requises :
```
ADD TRANDATA *partition-name* ALLCOLS
```
2. Exécutez la commande ALTER TABLE sur toutes les partitions de la table partitionnée de base ou sur les partitions requises :
```
ALTER TABLE *partition-name* REPLICA IDENTITY *replica-identity-setting*
```
La globalisation est prise en charge pour les noms d'objet (noms de table /schema/database/column) et les données de colonne.
La capture et la livraison d'une vue matérialisée sont prises en charge.
Le traitement d'extraction prend en charge les vues matérialisées, qui doivent avoir un index unique et qui doivent être actualisées simultanément.
L'identité de réplique des vues matérialisées doit être définie sur FULL afin que CDR, UNIFIED FORMAT RECORD et NOCOMPRESSDELETES, GETUPDATEBEFORES puissent être pris en charge. En outre, le paramètre d'identité de réplique FULL est requis pour que la vue matérialisée traite l'enregistrement WAL DELETE. Si l'identité de réplique de la vue matérialisée n'est pas définie sur FULL, l'enregistrement DELETE ne sera pas traité par l'extraction.

Pour définir l'identité de la réplique sur FULL, utilisez la commande suivante :
```
add trandata *schema.materialized_view*, ALLCOLS
```
Les statistiques d'un élément UPDATE ou PK UPDATE sont journalisées en tant qu'élément DELETE suivi de l'élément INSERT. Bien que cela affiche une anomalie dans les statistiques Extract, la synchronisation des données est correcte lorsque les données des vues matérialisées source et cible sont comparées.
Le résultat de PK UPDATE est DELETE, suivi de INSERT. Les statistiques d'extraction sont donc affichées différemment du nombre de lignes de la base de données. Vous devez vous appuyer sur les outils de comparaison de données pour vérifier l'intégrité des données entre les données source et cible, contenant les enregistrements de vues matérialisées.
Les données de la trace ne peuvent pas être appliquées à la vue matérialisée par le processus Replicat. Vous pouvez mettre en correspondance les données des vues matérialisées de la trace avec n'importe quelle autre table.

Limites

Oracle GoldenGate pour PostgreSQL ne prend pas en charge la capture et la distribution des vues.
Oracle GoldenGate pour PostgreSQL ne prend pas en charge la capture à partir de partitions individuelles d'une table partitionnée.

Séquences et colonnes d'identité

Les séquences sont prises en charge sur les tables source et cible pour les implémentations unidirectionnelles, bidirectionnelles et multidirectionnelles.
Les colonnes d'identité créées à l'aide de la clause GENERATED BY DEFAULT AS IDENTITY sont prises en charge sur les tables source et cible, pour les implémentations unidirectionnelles, bidirectionnelles et multidirectionnelles.
Les colonnes d'identité créées à l'aide de la clause GENERATED ALWAYS AS IDENTITY ne sont pas prises en charge dans les tables de base de données cible et la propriété Identity doit être enlevée des tables cible ou remplacée par GENERATED BY DEFAULT AS IDENTITY.
Pour les implémentations bidirectionnelles et multidirectionnelles, définissez les colonnes et les séquences d'identité avec une valeur INCREMENT BY égale au nombre de serveurs dans la configuration, avec une valeur MINVALUE différente pour chacun d'eux.

Par exemple, les valeurs MINVALUE /INCREMENT BY pour une configuration bidirectionnelle à deux bases de données sont les suivantes :

Database1, définissez MINVALUE sur 1 avec une valeur INCREMENT BY sur 2.

Database2, définissez MINVALUE sur 2 avec une valeur INCREMENT BY sur 2.

Par exemple, les valeurs MINVALUE /INCREMENT BY pour une configuration multidirectionnelle à trois bases de données sont les suivantes :

Database1, définissez MINVALUE sur 1 avec une valeur INCREMENT BY de 3.

Database2, définissez MINVALUE sur 2 avec une valeur INCREMENT BY de 3.

Database3, définissez MINVALUE sur 3 avec une valeur INCREMENT BY sur 3.