ADD HEARTBEATTABLE

Válido para todos os bancos de dados com suporte. Consulte a Matriz de Certificação para obter detalhes sobre bancos de dados suportados.

Este comando requer um log-in no banco de dados usando DBLOGIN.

Use ADD HEARTBEATTABLE para criar os objetos necessários para usar a funcionalidade automática de pulsação. Esse comando executa as seguintes tarefas:

Cria uma tabela de pré-implantação de integridade, uma de integridade e uma de histórico.
Cria as views GG_LAG e GG_LAG_HISTORY.
Cria os procedimentos GG_UPDATE_HB_TAB e GG_PURGE_HB_TAB que são chamados pelos jobs do scheduler.
Cria os jobs do scheduler que periodicamente atualizam a tabela de integridade e de pré-implantação, e expurgam a tabela de histórico. No entanto, ele não cria esses jobs para o Banco de Dados SQL do Azure, PostgreSQL, Teradata e TimesTen.
Preenche a tabela de pré-implantação.
Em bancos de dados multitenant Oracle:
- Os objetos de pulsação e os jobs são criados no esquema do usuário que está conectado ao banco de dados usando o comando DBLOGIN. O Oracle GoldenGate Extract e o Replicat procuram os objetos do heartbeat no esquema USERID ou USERIDALIAS. Ao fazer a conexão usando DBLOGIN, verifique se ela está definida para o esquema USERID ou USERIDALIAS apropriado que seus processos Extract e Replicat usarão.
- Extract: Use o nome do esquema em cada PDB. Cada PDB com o qual o Extract está registrado deve ter sua própria tabela de integridade.
- Replicat: Cada Replicat deve ter sua própria tabela de integridade para seu PDB.
- Para replicação bidirecional ativa/ativa, a tabela de integridade deve estar no mesmo esquema dos Extracts de saída e dos Replicats de entrada em cada local. Por exemplo, consulte o seguinte caso de uso:
  
  Site B do Local A
  
  EAB —————> ` RAB`
  
  RBA —————> ` EBA`
  
  Neste exemplo, as tabelas de pulsação EAB e RBA devem usar o mesmo esquema. No entanto, o EAB e o RAB podem usar diferentes esquemas.

A administração da tabela de pulsação do Oracle GoldenGate for Oracle foi simplificada, eliminando a necessidade de GGSCHEMA (ou parâmetro HEARTBEATTABLE), exceto por circunstâncias limitadas. As operações de administração das tabelas de integridade só são feitas no esquema do usuário DBLOGIN. Exceto para Extract raiz do Oracle CDB, os processos Extract e Replicat procuram tabelas de integridade no esquema do usuário conectado com o ER. A tabela a seguir mostra o comportamento do processo Extract e Replicat do Oracle AI Database:

Processos Extract/Replicat	Comportamento
Extract não raiz (não CDB e PDB)	Se for o primeiro usuário de Extract, `GGSCHEMA` será usado ou, no caso do Autonomous AI Database, o usuário deverá ser `ggadmin`. Se a pulsação for criada após a inicialização do Extract, procure apenas no usuário do Extract.
Extract Raiz do CDB	`GGSCHEMA` é usado.
Replicat	Se for o primeiro usuário Replicat, o `GGSCHEMA` será usado. Para ADB, o usuário deve ser `ggadmin`. Se a pulsação for criada após a inicialização do Replicat, procure apenas no usuário do Replicat.
`DELETE EXTRACT/REPLICAT`	Se for o primeiro usuário Extract ou Replicat, `GGSCHEMA` será usado. Para ADB, o usuário deve ser `ggadmin`.

Esse recurso permite o uso de tabelas de integridade em implantações no Hub do Oracle GoldenGate, em que vários bancos de dados são gerenciados com diferentes esquemas de administrador do Oracle GoldenGate.

Observação: Os objetos da tabela de pulsação nunca devem ser criados no CDB raiz de um Banco de Dados Oracle Multitenant.

Para bancos de Dados heterogêneos ou não Oracle, os objetos de pulsação e os jobs são criados no valor GGSCHEMA listado no arquivo GLOBALS.

Os nomes da tabela de pré-implantação, pulsação e histórico padrão são GG_HEARTBEAT_SEED, GG_HEARTBEAT e GG_HEARTBEAT_HISTORY, respectivamente.

Na Arquitetura de Microsserviços, o esquema é configurado usando Definições de Replicação.

Os nomes padrão podem ser substituídos, especificando HEARTBEATTABLE hbschemaname.hbtablename no arquivo GLOBALS.
As tabelas, os procedimentos e as tarefas são criados no esquema, hbschemaname.
A tabela pré-implantada e de histórico é criada anexando um _SEED e um _HISTORY à tabela, hbtablename.

Para a LUW Db2, defina a propriedade DB2_ATS_ENABLE com o comando db2set DB2_ATS_ENABLE=yes.

Para Db2 para i, para tratar o upgrade ou configuração incorreta da funcionalidade de tabela de pulsação, você pode executar o comando ADD HEARTBEATTABLE novamente, que reparará a funcionalidade de uma configuração de pulsação existente sem excluir os dados existentes de pulsação.

Para Db2 para i, o programa licenciado, 5770SS1 Option 39 International Components for Unicode, deve ser instalado.

No Db2 for i, a tabela de integridade deve ser lançada no mesmo diário dos objetos que estão sendo replicados no Extract usando a tabela de integridade mencionada. Caso contrário, o Extract será encerrado de modo anormal, indicando que mais de um diário está disponível. Além disso, qualquer outro Extract na instalação específica do Oracle GoldenGate que não esteja lendo o mesmo diário não poderá ter a tabela de integridade ativada para ele.

Para o Amazon Aurora MySQL, a variável global event_scheduler deve ser ativada no grupo de parâmetro porque o Amazon RDS não permite definir variáveis globais. Quando o banco de dados é reiniciado, o event_scheduler retorna para ser desativado. Para evitar isso, você precisa ativar a event_scheduler no arquivo my.cnf/ini.

Para PostgreSQL, um job de sistema deve ser criado manualmente para chamar periodicamente a função atualização do registro de pulsação e expurgação de registro de histórico, gg_hb_job_run. Por exemplo, é possível criar um job cron que seja executado a cada minuto. A função verificará a atualização real do registro de pulsação, expurgará as definições de frequência da configuração de pulsação e processará apenas as operações dentro desses limites:

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

Para o Azure SQL Database, somente ADD HEARTBEATTABLE TARGETONLY é suportado e como não há Agente do SQL Server com o Azure SQL Database, a rotina da expurgação não pode ser criada. Portanto, os usuários devem executar periodicamente o procedimento armazenado GG_PURGE_HB_TAB para remover registros antigos de integridade.

Sintaxe

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

FREQUENCY number_in_seconds

Especifica com que frequência os registros de pulsação são gerados. O padrão são 60 segundos.

Considere os seguintes limites:

Para o Oracle AI Database, o valor mínimo é 0 e o máximo é 7999.
No Db2 for i Series, o valor mínimo é 0 e o máximo é 7.999.
No Db2 LUW e no Db2 z/OS, o valor mínimo é 60 e o máximo é 7.999.
A frequência no Db2 /zOS e no Db2 LUW deve ser um múltiplo de 60 para valores inferiores a 3.600 e múltiplos de 3.600 para valores superiores ou iguais a 3.600.
No MySQL, o valor mínimo é 0 e o máximo é 7.999.
No SQL Server, o valor mínimo é 10 e o máximo é 7.999.
No PostgreSQL, o valor mínimo é 60 e o máximo é 7.999.
Para Sybase, o valor mínimo é 1 minuto (60 segundos) e o máximo é 133 minutos (7999 segundos).
Os bancos de dados que suportam a definição do FREQUENCY como 0 pausarão o scheduler de registros de integridade.

RETENTION_TIME number_in_days

Especifica que as entradas de pulsação posteriores ao tempo de retenção na tabela de histórico de pulsação serão expurgadas. O padrão é 30 dias.

O valor mínimo para todos os bancos de dados é 1 e o máximo é 2.147.483.646.

PURGE_FREQUENCY number_in_days

Especifica com que frequência o scheduler de expurgação é executado para excluir entradas de tabela mais antigas que o tempo de retenção da tabela de histórico de pulsação. O valor default é de 1 dia.

No Db2 LUW e no Db2 z/OS, o valor mínimo é 1 e o máximo é 31.

Para todos os outros bancos de dados compatíveis, o valor mínimo é 1 e o valor máximo é 199.

PARTITIONED

Válido para Oracle.

Ativa o particionamento na tabela de histórico de integridade. A coluna do timestamp de integridade recebido é usada para particionar a tabela com um intervalo de um dia. Por padrão, a tabela de histórico de integridade não é particionada.

TARGETONLY

Válido para Oracle AI Database, série Db2 i, Db2 LUW, Db2 z/OS, MySQL, PostgreSQL e SQL Server.

Não ativa o registro em log complementar nas tabelas de pré-implantação de integridade e de integridade e não cria um job do scheduler para atualizar a tabela de integridade.

Exemplos

O comando a seguir cria tabelas de integridade, procedimentos e jobs padrão.

ADD HEARTBEATTABLE

O comando a seguir cria as tabelas de integridade, os procedimentos e os jobs com frequência, tempo de retenção e frequência de expurgação personalizados.

ADD HEARTBEATTABLE, FREQUENCY 120, RETENTION_TIME 10, PURGE_FREQUENCY 2

O comando a seguia criar tabelas de integridade, procedimentos e jobs com o particionamento ativado na tabela de histórico de integridade e o registro em log complementar não é ativado nas tabelas de integridade e pré-implantação de integridade.

ADD HEARTBEATTABLE, partitioned, TARGETONLY