ADD HEARTBEATTABLE

Válida para todas las bases de datos soportadas. Consulte la matriz de certificación para obtener más información sobre las bases de datos admitidas.

Este comando requiere una conexión de base de datos con DBLOGIN.

Utilice ADD HEARTBEATTABLE para crear los objetos necesarios para utilizar la funcionalidad de latidos automáticos. Este comando efectúa las tareas siguientes

Crea una tabla de valores iniciales de latido, una tabla de latidos y una tabla de historial de latidos.
Crea las vistas GG_LAG y GG_LAG_HISTORY.
Crea los procedimientos GG_UPDATE_HB_TAB y GG_PURGE_HB_TAB que llaman los trabajos del programador.
Crea los trabajos del programador que actualizan periódicamente la tabla de latidos y la de valores iniciales, y depuran la tabla de historial. Sin embargo, no crea estos trabajos para Azure SQL Database, PostgreSQL, Teradata y TimesTen.
Rellena la tabla de valores iniciales.
Para las bases de datos multiinquilino de Oracle:
- Los objetos y trabajos de latidos se crean en el esquema del usuario que se haya conectado a la base de datos utilizando el comando DBLOGIN. Los objetos de latidos de Oracle GoldenGate Extract y Replicat buscan los objetos de latidos en el esquema USERID o USERIDALIAS. Al realizar la conexión utilizando DBLOGIN, asegúrese a que está definido en el esquema USERID o USERIDALIAS adecuado que utilizarán el proceso de Extract y Replicat.
- Extract: utilice el nombre de esquema en cada PDB. Cada PDB con la que se registra el Extract debe tener su propia tabla de latidos.
- Replicat: cada Replicat debe tener su propia tabla de latidos para su PDB.
- Para la replicación bidireccional activo-activo, la tabla de latidos debe estar en el mismo esquema para los Extracts salientes y los Replicats entrantes en cada sitio. Por ejemplo, vea el siguiente caso de uso:
  
  Sitio A Sitio B
  
  EAB —————> ` RAB`
  
  RBA —————> ` EBA`
  
  En este ejemplo, las tablas de los latidos EAB y RBA deben utilizar el mismo esquema. Sin embargo, EAB y RAB pueden utilizar diferentes esquemas.

Oracle GoldenGate para la administración de las tablas de latidos de Oracle se ha simplificado eliminando la necesidad de GGSCHEMA (o del parámetro HEARTBEATTABLE) excepto en circunstancias limitadas. Las operaciones de administración de tabla de los latidos solo se realizan en el esquema del usuario DBLOGIN. Excepto en el caso del Extract raíz de Oracle CDB, los procesos de Extract y Replicat buscan las tablas de latidos en el esquema o el usuario conectado de ER. La siguiente tabla muestra el comportamiento de Extract y Replicat para Oracle AI Database:

Procesos de Extract/Replicat	Comportamiento
Extract no raíz (no CDB y PDB)	Si es el primer usuario de Extract, se utiliza `GGSCHEMA`, o en el caso de Autonomous AI Database, el usuario debe ser `ggadmin`. Si se crea un latido después del inicio del Extract, se busca solo en el usuario de Extract.
Extract raíz de CDB	Se utiliza `GGSCHEMA`.
Replicat	Si es el primer usuario de Replicat, se utiliza `GGSCHEMA`. Para ADB, el usuario debe ser `ggadmin`. Si se crea un latido después del inicio del Replicat, se busca solo en el usuario de Replicat.
`DELETE EXTRACT/REPLICAT`	Si es el primer usuario de Extract o Replicat, se utiliza `GGSCHEMA`. Para ADB, el usuario debe ser `ggadmin`.

Esta función permite el uso de tablas de latidos en despliegues del hub de Oracle GoldenGate, donde se gestionan varias bases de datos con diferentes esquemas de administrador de Oracle GoldenGate.

Nota: Los objetos de la tabla de latidos nunca se deben crear en la CDB raíz de una base de datos Oracle Multitenant.

En el caso del caso de las bases de Datos heterogéneas o no Oracle, los objetos y los trabajos de latidos se crean en el valor GGSCHEMA que aparece en el archivo GLOBALS.

Los nombres de las tablas de Valores Iniciales, latidos y de historial por defecto son GG_HEARTBEAT_SEED, GG_HEARTBEAT y GG_HEARTBEAT_HISTORY, respectivamente.

En Microservices Architecture, el esquema se configura utilizando Replication Settings.

Los nombres por defecto pueden sustituirse especificando HEARTBEATTABLE hbschemaname.hbtablename en el archivo GLOBALS.
Las tablas, los procedimientos y los trabajos se crean en el esquema, hbschemaname.
La tabla inicial y la tabla de historial se crean mediante la adición de _SEED y _HISTORY a la tabla, hbtablename.

Para Db2 LUW, debe definir la propiedad DB2_ATS_ENABLE con el comando db2set DB2_ATS_ENABLE=yes.

Para Db2 for i, para gestionar el cambio de versión o la configuración incorrecta de las funcionalidades de tabla de los latidos, puede volver a ejecutar el comando ADD HEARTBEATTABLE, el cual reparará la funcionalidad del valor de Heartbeattable existente sin suprimir los datos del latido existentes.

Para Db2 for i, se debe instalar el programa con licencia, 5770SS1 Option 39 International Components for Unicode.

Para Db2 for i, es necesario registrar la tabla de latidos en el mismo registro que los objetos que se estén replicando en el Extract utilizando dicha tabla de latidos. De lo contrario, el Extract finalizará anormalmente e indicará que hay más de un registro disponible. Además, cualquier otro Extract de la instalación de Oracle GoldenGate específica que no esté leyendo el mismo registro no podrá tener la tabla de latidos activada.

Para Amazon Aurora MySQL, la variable global event_scheduler debe estar activada en el grupo de parámetro porque Amazon RDS no permite definir variables globales. Cuando se reinicia la base de Datos, event_scheduler vuelve a estar desactivado. Para evitarlo, debe activar event_scheduler en el archivo my.cnf/ini.

Para PostgreSQL, se debe crear una tarea del sistema de forma manual para llamar de manera periódica a la función gg_hb_job_run de actualización de registros de latidos y purga de registros de historial. Por ejemplo, se podría crear un trabajo cronológico que se ejecute cada minuto. La función comprobará la configuración actual de frecuencia de purga y actualización de registros de latido y solo procesará las operaciones dentro de esos límites:

PGPASSWORD="$passwd" psql -U gguser -d dbname -h dbhostname -p dbport# -c "select <ggschema.gg_hb_job_run();" >/dev/null 2>&1

Para Azure SQL Database, solo está soportado ADD HEARTBEATTABLE TARGETONLY, y debido a que No hay ningún Agente de SQL Server con Azure SQL Database, no se puede crear la rutina para depurar. Por ello, los usuarios deben ejecutar periódicamente el procedimiento GG_PURGE_HB_TAB almacenado para eliminar registros de latido antiguos.

Sintaxis

ADD HEARTBEATTABLE
[, FREQUENCY number_in_seconds]
[, RETENTION_TIME number_in_days] |
[, PURGE_FREQUENCY number_in_days]
[, PARTITIONED]
[, TARGETONLY]

FREQUENCY number_in_seconds

Especifica la frecuencia con la que se generan los registros de latidos. El valor por defecto es 60 segundos.

Considere los siguientes límites:

Para Oracle AI Database, el valor mínimo es 0, y el máximo es 7999.
Para Db2 for i Series, el valor mínimo es 0, y el máximo es 7999.
Para Db2 LUW y Db2 z/OS, el valor mínimo es 60, y el máximo es 7999.
La frecuencia para Db2 /zOS y Db2 LUW debe ser un múltiplo de 60 para valores inferiores a 3600, y múltiplos de 3600 para valores mayores o iguales a 3600.
Para MySQL, el valor mínimo es 0, y el máximo es 7999.
Para SQL Server, el valor mínimo es 10, y el máximo es 7999.
Para PostgreSQL, el valor mínimo es 60, y el máximo es 7999.
Para Sybase, el valor mínimo es 1 minuto (60 segundos) y el máximo es 133 minutos (7999 segundos).
Las bases de datos que soportan la configuración de FREQUENCY en 0 pausarán el programador de registros del latido.

RETENTION_TIME number_in_days

Especifica que se depuran las entradas de latidos anteriores al tiempo de retención de la tabla del historial de latidos. El valor por defecto es de 30 días.

El valor mínimo para todas las bases de datos es 1, y el máximo es 2147483646.

PURGE_FREQUENCY number_in_days

Especifica la frecuencia con la que se ejecuta el programador de depuración para suprimir las entradas de tabla que son anteriores al tiempo de retención de la tabla del historial de latidos. El valor por defecto es 1 día.

Para Db2 LUW y Db2 z/OS, el valor mínimo es 1, y el máximo es 31.

Para todas las demás bases de datos soportadas, el valor mínimo es 1, y el máximo es 199.

PARTITIONED

Válido para Oracle.

Activa la partición en la tabla del historial de latidos. La columna para el registro de hora de latido recibido se utiliza para realizar la partición de la tabla con un intervalo de un día. Por defecto, la tabla del historial de latidos no está particionada.

TARGETONLY

Válido para Oracle AI Database, serie i Db2, LUW Db2, z/OS Db2, MySQL, PostgreSQL y SQL Server.

No activa el registro complementario en la tabla de latidos y en la de valores iniciales de latido, y no crea un trabajo del programador para actualizar la tabla de latidos.

Ejemplos

El siguiente comando crea tablas, procedimientos y trabajos de latido por defecto.

ADD HEARTBEATTABLE

El siguiente comando crea las tablas, los procedimientos y los trabajos de latido con una frecuencia, un tiempo de retención y una frecuencia de depuración personalizados.

ADD HEARTBEATTABLE, FREQUENCY 120, RETENTION_TIME 10, PURGE_FREQUENCY 2

El siguiente comando crea las tablas, los procedimientos y los trabajos de latido con el particionamiento activado en la tabla del historial de latidos, y el registro complementario no está activado en las tablas de latidos y de valores iniciales de latido.

ADD HEARTBEATTABLE, partitioned, TARGETONLY