PostgreSQL: tipos de dato, objetos y operaciones soportados

Oracle GoldenGate para PostgreSQL soporta la captura y entrega de datos transaccionales y de carga inicial para las versiones de base de datos PostgreSQL soportadas.

Oracle GoldenGate for PostgreSQL soporta la asignación, el filtrado y la transformación de datos de origen, a menos que se indique lo contrario en este documento, así como la replicación de datos derivados de otras bases de datos de origen soportadas por Oracle GoldenGate en bases de datos PostgreSQL.

Bases de datos soportadas

Las siguientes son bases de datos soportadas y limitaciones para Oracle GoldenGate para PostgreSQL:

• Solo están soportadas las bases de datos de usuario para la captura y entrega.

• Oracle GoldenGate no soporta la captura de archive logs.

• La entrega no está soportada en bases de datos de réplica y en espera.

• La captura también está soportada desde bases de datos de réplica y en espera.

• Alta Disponibilidad. Consulte Consideraciones de alta disponibilidad para obtener más información.

Consideraciones de alta disponibilidad

Oracle GoldenGate soporta la captura de datos de cambio desde la configuración de alta disponibilidad PostgreSQL. Esta funcionalidad solo está disponible en las versiones 16 y posteriores de la base de datos PostgreSQL. La captura de datos de cambio se puede configurar en el servidor principal o en cualquier servidor en espera de solo lectura en la configuración de alta disponibilidad. Para evitar posibles pérdidas de datos y la intervención manual en casos de failover, Oracle GoldenGate recomienda configurar la configuración de alta disponibilidad mediante la replicación síncrona.

Consulte los procedimientos de Oracle GoldenGate para el ID de documento de failover de alta disponibilidad PostgreSQL 2818379.1 para obtener más información sobre posibles escenarios de pérdida de datos e intervención manual.

Para configurar el Extract de CDC desde una configuración de alta disponibilidad PostgreSQL, realice las siguientes tareas: 1. Extract se puede configurar para capturar datos del servidor principal o de un servidor en espera de solo lectura en la configuración de alta disponibilidad.

1. Cuando el Extract se configura en un nodo (principal o en espera), la ranura de replicación con el mismo nombre se debe crear en todos los demás nodos de la configuración de alta disponibilidad al mismo tiempo, antes de iniciar la captura de datos.

   1. Utilice el comando REGISTER EXTRACT para crear la ranura de replicación en un servidor (donde se configura Extract), como se muestra en el siguiente ejemplo:

      REGISTER EXTRACT exte

   2. Inmediatamente después de registrar Extract, cree la ranura de replicación con el mismo nombre. Debe utilizar explícitamente el mismo nombre de ranura de replicación en todos los demás nodos de la configuración de alta disponibilidad.

      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. Conéctese a la base de datos correspondiente y ejecute la sentencia pg_create_logical_replication_slot desde PSQL. Nota: NOTA IMPORTANTE PARA LA CREACIÓN DE SLOT DE REPLICACIÓN EN STANDBY: cuando se intenta crear la ranura de replicación en el servidor en espera de solo lectura (mediante el comando REGISTER EXTRACT o la sentencia pg_create_logical_replication_slot), la operación se completa solo después de que se ejecuta algún DML (puede ser cualquier DML aleatorio) en cualquier tabla del servidor principal en la configuración de alta disponibilidad. También se puede activar la funcionalidad de latido en el servidor principal, lo que puede hacer que la actividad DML necesaria en el servidor principal complete la creación de la ranura de replicación en el servidor en espera.

1. Los comandos ADD TRANDATA o DELETE TRANDATA no están soportados en ningún servidor en espera de solo lectura en la configuración de alta disponibilidad PostgreSQL. El valor REPLICA IDENTITY de cualquier tabla en el servidor en espera de sólo lectura sería el mismo que el valor REPLICA IDENTITY de la tabla correspondiente en el servidor principal.

2. Para utilizar la funcionalidad de latido cuando la captura de datos se configura en un servidor en espera de solo lectura, la funcionalidad de latido se debe activar en el servidor principal.

3. En caso de failover, el archivo de parámetros de extracción se debe modificar para conectarse al nodo deseado (principal/en espera, según el requisito) para continuar la captura de datos después de la operación de failover.

   Ejemplo

   Considere una situación en la que hay tres nodos en el cluster de alta disponibilidad PostgreSQL, con los alias de conexión correspondientes:

   Node1 (principal actual) con el alias de conexión correspondiente: node1

   Node2 (en espera) con el alias de conexión correspondiente: node2

   Node3 (en espera) con el alias de conexión correspondiente: node3

   Antes del failover, si Extract está configurado para capturar datos de uno de los nodos (como node2), el archivo de parámetros Extract contendría una entrada similar a la siguiente:

   USERIDALIAS node2

   En caso de failover, el nodo primario (node1) se cae y el secundario (node2) se convierte en el nuevo primario, puede haber dos posibilidades:

   1. Para continuar con la captura de datos desde el mismo node2:

      • No es necesario realizar cambios en el archivo de parámetros de Extract.

      • Reinicie el Extract.

   2. Para capturar los datos siempre desde un nodo diferente:

      • Cambie el archivo de parámetros Extract para conectarse al nodo deseado, como Node3.

        USERIDALIAS node3

      • Reinicie el Extract.

Tipos de datos PostgreSQL soportados

A continuación, se muestra una lista de los tipos de dato PostgreSQL que soporta Oracle GoldenGate junto con las limitaciones de este soporte.

• 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/sin zona horaria

• timestamp con/sin zona horaria

• tsquery

• tsvector

• uuid

• varchar(n)

• varbit

• xml

Manejo del tipo de datos de matriz

PostgreSQL soporta array de varios tipos incorporados y UDT. A partir de la versión 26ai de Oracle GoldenGate, Oracle GoldenGate Extract y Replicat soportan el tipo de dato PostgreSQL array de los siguientes tipos:

• boolean

• bigint

• bit

• char

• date

• double precision

• enum

• int

• interval

• numeric

• money

• real

• smallint

• timestamp, timestampz, time, timetz

• varbit

• varchar

• text

• tsvector

• tsquery

Los tipos de dato real, double, numeric soportan los valores numéricos especiales NaN y Infinity/-Infinity.

Para obtener más información sobre los tipos de dato por bases de datos que soportan valores especiales, consulte Valores especiales soportados por tipos de dato de base de datos.

Tanto la carga inicial como el extracto de CDC admiten estos tipos de matriz.

Nota: El Extract de carga inicial no soporta PostgreSQL array del tipo de dato time.

Limitaciones del soporte

• Si las columnas de los tipos de dato char, varchar, text o bytea forman parte de una clave primaria o única, las longitudes individuales máximas para estas columnas no deben superar los 8191 bytes.

• Extract no puede procesar registros con columnas bytea de más de 512 MB de tamaño.

• Las columnas del tipo de dato CITEXT que forman parte de la clave primaria están soportadas con un tamaño de hasta 8000 bytes. Las columnas CITEXT que tienen más de 8000 bytes y forman parte de la clave primaria no están soportadas.

• Extract no puede procesar registros con columnas bytea de más de 512 MB de tamaño.

• Los valores de entrada decimal: NaN no están soportados.

• Las siguientes limitaciones se aplican a los tipos de dato bit/varbit:

  • Están soportados hasta 4k de longitud. Para longitudes mayores que 4k, los datos se truncan y solo se capturan los bits 4k inferiores.

  • La columna bit(n) de origen solo se puede aplicar a una columna de tipo de carácter en un destino que no sea PostgreSQL y se puede aplicar a un tipo char o a una columna bit/varbit en un destino PostgreSQL.

• Las siguientes limitaciones se aplican tanto a timestamp con zona horaria como a timestamp sin zona horaria:

  • Los datos timestamp con etiquetas BC o AD en los datos no están soportados.

  • Los datos timestamp anteriores a 1883-11-18 12:00:00 no están soportados.

  • Los datos timestamp con más de 4 dígitos en el componente YEAR no están soportados.

  • Las cadenas de entrada Infinity/-Infinity para las columnas timestamp no están soportadas.

• A continuación se muestran las limitaciones al utilizar interval:

  • La captura de datos de signo mixto interval de las columnas de tipo interval no está soportada. Puede utilizar DBOPTIONS ALLOWNONSTANDARDINTERVALDATA en el archivo de parámetros Extract para capturar los datos interval de signo mixto (o cualquier otro formato de datos interval, que no está soportado por Oracle GoldenGate) como cadena (no como datos interval estándar).

  A continuación se muestran algunos ejemplos de datos que se escriben en el archivo de pista, al utilizar DBOPTIONS ALLOWNONSTANDARDINTERVALDATA en el archivo de parámetros de Extract:

  • +1026-9 +0 +0:0: 22.000000 se interpreta como 1026 años, 9 meses, 0 días, 0 horas, 0 minutos, 22 segundos.

  • -0-0 -0 -8 se interpreta como 0 años, 0 meses, 0 días, -8 horas.

  • +1-3 +0 +3:20 se interpreta como 1 año, 3 meses, 0 días, 3 horas, 20 minutos.

• Replicat: si los datos del intervalo de origen se han capturado mediante DBOPTIONS ALLOWNONSTANDARDINTERVALDATA y se han escrito como una cadena en la pista, la columna de origen correspondiente se puede asignar a una columna de tipo char o binary en el destino.

• Las limitaciones de date son:

  • Los datos date con etiquetas BC o AD en los datos no están soportados.

  • Las cadenas de entrada Infinity/-Infinity para las columnas date no están soportadas.

• Las columnas de text, json, xml, bytea, char (>8191), varchar (>8191) se tratan como columnas LOB y tienen las siguientes limitaciones:

  • Al utilizar GETUPDATEBEFORES, la imagen anterior de las columnas LOB nunca se registra.

  • Al utilizar NOCOMPRESSUPDATES, las columnas LOB se registran en la imagen posterior solo si se han modificado.

• El soporte de rango y precisión para los números de punto flotante depende de la máquina host. En general, la precisión es de 16 dígitos significativos, pero debe revisar la documentación de la base de datos para determinar las aproximaciones esperadas. Oracle GoldenGate redondea o trunca los valores que superan la precisión soportada.

Tipos de dato PostgreSQL no soportados

Oracle GoldenGate para PostgreSQL no soporta los siguientes tipos de dato:

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

• Las extensiones y los módulos adicionales proporcionados que se muestran en: https://www.postgresql.org/docs/current/contrib.html no están soportados por Oracle GoldenGate a menos que se muestren explícitamente en Tipos de datos PostgreSQL soportados. Nota: Si el archivo de parámetros Extract contiene una tabla con tipos de dato no soportados, Extract se parará con un mensaje de error. Para reanudar la replicación, elimine la tabla del archivo Extract o elimine la columna de la tabla con un tipo de dato no soportado.

Objetos y operaciones soportados para PostgreSQL

• Oracle GoldenGate para PostgreSQL solo soporta operaciones DML (Insertar/Actualizar/Supresión). No se admite la replicación de DDL.

• Oracle GoldenGate para PostgreSQL soporta la replicación de operaciones de truncamiento que empiecen por PostgreSQL 11 y posteriores y necesita el parámetro GETTRUNCATES en Extract y Replicat.

• Solo se admiten varias operaciones de truncamiento en pgoutput plugin.

• Uso de Nombres Sensibles a Mayúsculas/Minúsculas/No Sensibles:

  • Los nombres sin comillas no son sensibles a mayúsculas/minúsculas y están implícitamente en minúsculas. Por ejemplo, CREATE TABLE MixedCaseTable y SELECT * FROM mixedcasetable son equivalentes.

  • Los nombres de tabla y columna entre comillas distinguen entre mayúsculas y minúsculas y se deben mostrar correctamente en Extracts and Replicats y con los comandos de Oracle GoldenGate.

  Por ejemplo, TABLE appschema."MixedCaseTable" y ADD TRANDATA appschema."MixedCaseTable" serían necesarios para soportar un nombre de tabla sensible a mayúsculas/minúsculas.

Tablas, Vistas y Vistas Materializadas

Las tablas que se van a incluir para la captura y entrega deben cumplir los siguientes requisitos y solo deben incluir los tipos de dato que se muestran en Tipos de dato PostgreSQL soportados.

• Oracle GoldenGate for PostgreSQL soporta la captura de DML transaccional de tablas de usuario y la entrega a tablas de usuario.

• Oracle GoldenGate para PostgreSQL, versiones 21.14.0.0.0 y posteriores, soporta la captura y entrega en tablas particionadas base. Para capturar datos de tablas particionadas PostgreSQL, el valor de Identidad de réplica de todas las particiones debe coincidir con el valor de Identidad de réplica de la tabla particionada base. Esto también se aplica a las tablas particionadas de varios niveles.

  Para configurar esta configuración, puede elegir una de las siguientes maneras:

  1. Ejecute el comando ADD TRANDATA en todas las particiones o en las particiones necesarias de la tabla particionada base:

     ADD TRANDATA *partition-name* ALLCOLS

  2. Ejecute el comando ALTER TABLE en todas las particiones o en las particiones necesarias de la tabla particionada base:

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

• La globalización está soportada para los nombres de objeto (nombres de tabla /schema/database/column) y los datos de columna.

• Está soportada la captura y entrega de una vista materializada.

• El proceso de extracción soporta vistas materializadas, que deben tener un índice único y se deben refrescar simultáneamente.

• La identidad de réplica de las vistas materializadas se debe definir en FULL para que se puedan soportar CDR, UNIFIED FORMAT RECORD y NOCOMPRESSDELETES, GETUPDATEBEFORES. Además, el valor de identidad de réplica FULL es necesario para que la vista materializada procese el registro WAL DELETE. Si la identidad de réplica de la vista materializada no está definida en FULL, Extract no procesará el registro DELETE.

  Para establecer la identidad de réplica en FULL, utilice el siguiente comando:

  add trandata *schema.materialized_view*, ALLCOLS

• Las estadísticas de un UPDATE o PK UPDATE se registrarán como DELETE seguido de INSERT. Aunque esto muestra una anomalía en las estadísticas de Extract, pero la sincronización de datos es correcta cuando se comparan los datos de las vistas materializadas de origen y destino.

• PK UPDATE da como resultado DELETE seguido de INSERT para que las estadísticas de Extract se muestren de forma diferente al recuento de filas de la base de datos. Debe confiar en las herramientas de comparación de datos para comprobar la integridad de los datos entre los datos de origen y de destino, que contienen los registros de vistas materializadas.

• Los datos de la pista no se pueden aplicar a la vista materializada mediante el proceso Replicat. En su lugar, puede asignar los datos de vistas materializadas de la pista a cualquier otra tabla.

Limitaciones

• Oracle GoldenGate para PostgreSQL no soporta la captura y entrega de vistas.

• Oracle GoldenGate para PostgreSQL no soporta la captura a partir de particiones individuales de una tabla particionada.

Secuencias y Columnas de Identidad

• Las secuencias están soportadas en las tablas de origen y destino para implantaciones unidireccionales, bidireccionales y multidireccionales.

• Las columnas de identidad creadas mediante la cláusula GENERATED BY DEFAULT AS IDENTITY están soportadas en las tablas de origen y destino, para implantaciones unidireccionales, bidireccionales y multidireccionales.

• Las columnas de identidad creadas mediante la cláusula GENERATED ALWAYS AS IDENTITY no están soportadas en las tablas de la base de datos de destino y la propiedad Identity se debe eliminar de las tablas de destino o cambiar a GENERATED BY DEFAULT AS IDENTITY.

• Para implantaciones bidireccionales y multidireccionales, defina las columnas y secuencias de identidad con un valor INCREMENT BY igual al número de servidores de la configuración, con un valor MINVALUE diferente para cada una.

  Por ejemplo, los valores MINVALUE /INCREMENT BY para una configuración bidireccional de dos bases de datos serían los siguientes:

  Database1, defina MINVALUE en 1 con un INCREMENT BY de 2.

  Database2, defina MINVALUE en 2 con un INCREMENT BY de 2.

  Por ejemplo, los valores MINVALUE /INCREMENT BY para una configuración multidireccional de tres bases de datos serían los siguientes:

  Database1, defina MINVALUE en 1 con un INCREMENT BY de 3.

  Database2, defina MINVALUE en 2 con un INCREMENT BY de 3.

  Database3, defina MINVALUE en 3 con un valor INCREMENT BY de 3.