Defasagem do monitor

As estatísticas de lag mostram o quão bem os processos do Oracle GoldenGate estão acompanhando o volume de dados que estão sendo gerados pelos aplicativos de negócios. Com essas informações, você pode diagnosticar problemas suspeitos e ajustar o desempenho dos processos do Oracle GoldenGate para minimizar a latência entre os bancos de dados de origem e de destino.

Sobre Atraso

Para o Extract, o atraso é a diferença, em segundos, entre o tempo em que um registro foi processado pelo Extract (com base no relógio do sistema) e o timestamp desse registro na origem de dados.

Para o Replicat, o atraso é a diferença, em segundos, entre o tempo em que um registro foi processado pelo Replicat (com base no relógio do sistema) e o timestamp desse registro na trilha.

Para exibir estatísticas de lag, use os comandos [LAG](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-52D1B2C3-6ACF-4461-9ED2-FD3AE9121022) ou [SEND ER](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-DD62102E-A84D-4866-9A3A-9C2281CFEED7), [SEND EXTRACT](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-2A83CA04-DAB8-494B-BF36-F8D15E645749) e [SEND REPLICAT](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-DBA8F45C-6016-4AB4-BF9A-00C117029E7F).

Observação: O comando INFO também retorna uma estatística de atraso, mas essa estatística é obtida do último registro que foi submetido a checkpoint, não do registro atual que está sendo processado. É menos preciso que LAG ou INFO.

Monitorar Defasagem Usando Tabelas Automáticas de Heartbeat

Você pode usar a funcionalidade padrão da tabela de pulsação automática para monitorar o atraso de replicação de ponta a ponta. As pulsações automáticas são enviadas de cada banco de dados de origem para os fluxos de replicação, atualizando os registros em uma tabela de implantações de pulsação e em uma tabela de pulsação e construindo uma heartbeat history table. Cada um dos processos de replicação no processo de caminho de replicação registra e atualiza as informações neles contidas. Esses registros de pulsação são inseridos ou atualizados na tabela de pulsação nos bancos de dados de destino.

As tabelas de pulsação contêm as seguintes informações:

Banco de dados de origem
Banco de dados de destino
Informações sobre os fluxos de replicação de saída:
- Nomes dos processos Extract, Distribution Service e/ou Replicat no caminho
- Timestamps quando os registros de pulsação foram processados pelos processos de replicação.
Informações sobre os fluxos de replicação recebidos:
- Nomes dos processos Extract, Distribution Service e/ou Replicat no caminho
- Timestamps quando os registros de pulsação foram processados pelos processos de replicação.

Usando as informações na tabela de pulsação e na tabela de histórico de pulsação, as defasagens atuais e históricas em cada replicação podem ser calculadas.

O Replicat pode rastrear a posição de reinicialização atual do Extract com tabelas de pulsação automática (LOGBSN). Isso permite gerar novamente os arquivos de trilha do banco de dados de origem, se necessário, e minimiza o período de retenção de redo log do banco de dados de origem. Além disso, ao rastrear a posição de reinicialização do Extract mais recente, as tabelas de lápide para as tabelas automáticas de detecção e resolução de conflitos (ACDR) podem ser limpas com mais frequência.

Em uma configuração bidirecional, a tabela de pulsação tem tantas entradas quanto o número de caminhos de replicação para os vizinhos que o banco de dados tem e, em uma configuração unidirecional, a tabela na origem está vazia. As colunas de saída têm os timestamps e o caminho de saída, o Extract local e os processos downstream. As colunas de entrada têm os timestamps e o caminho dos processos upstream e do Replicat local.

Em uma configuração unidirecional, o banco de dados de destino preencherá apenas as colunas de entrada na tabela de integridade.

Observação: A funcionalidade Heartbeat Automático não é suportada no MySQL versão 5.5.

Fluxo de Replicação de Ponta a Ponta da Tabela de Heartbeat

O processo de replicação de ponta a ponta para tabelas de integridade baseia-se no uso do formato de trilha do Oracle GoldenGate. O processo é o seguinte:

Adicione uma tabela de integridade a cada um dos seus bancos de dados com o comando ADD HEARTBEATTABLE. Adicione a tabela de pulsação a todas as instâncias de origem e destino e reinicie os processos existentes do Oracle GoldenGate para ativar a funcionalidade de pulsação. Dependendo do banco de dados, pode ou não ser necessário criar ou ativar um trabalho para preencher os dados da tabela de pulsação.

Consulte a seguinte amostra:

DBLOGIN USERIDALIAS *alias*  [DOMAIN domain]|[SYSDBA | SQLID sqlid][SESSIONCHARSET character_set]}

ADD HEARTBEATTABLE

(Opcional) Para Bancos de Dados Oracle, você deve garantir que o Oracle DBMS_SCHEDULER esteja operando corretamente, pois a atualização de pulsação depende dele. Você pode consultar o DBMS_SCHEDULER emitindo:

SELECT START_DATE, LAST_START_DATE, NEXT_RUN_DATE
FROM DBA_SCHEDULER_JOBS

Onde job_name ='GG_UPDATE_HEARTBEATS';

Em seguida, procure entradas válidas para NEXT_RUN_DATE, que é a próxima vez que o scheduler será executado. Se este for um timestamp no passado, nenhum job será executado e você deverá corrigi-lo.

Um motivo comum para o scheduler não funcionar é quando o parâmetro job_queue_processes é definido muito baixo (normalmente zero). Aumente o número de job_queue_processes configurados no banco de dados com o comando ALTER SYSTEM SET JOB_QUEUE_PROCESSES = ##;, em que ## é o número de processos da fila de jobs.

Execute um Extract, que ao receber os LCR (Logical Change Records, Registros de alteração lógica) verifica o valor na coluna OUTGOING_EXTRACT.

Se o nome da Extração corresponder a esse valor, a coluna OUTGOING_EXTRACT_TS será atualizada e o registro será inserido na trilha.
Se o nome do processo Extract não corresponder, o LCR será descartado.
Se o valor OUTGOING_EXTRACT for NULL, ele será preenchido com OUTGOING_EXTRACT_TS e o registro será inserido na trilha.

O Serviço de Distribuição ao ler o registro verifica o valor na coluna OUTGOING_ROUTING_PATH. Esta coluna tem uma lista de caminhos de distribuição.

Se o valor for NULL, a coluna será atualizada com o nome do grupo atual (e o caminho se este for um Serviço de Distribuição),"*", atualizará a coluna OUTGOING_ROUTING_TS e o registro será gravado em seu arquivo de trilha de destino.

Se o valor tiver uma "*" na lista, substitua-o por group name[:pathname],"*"', atualize a coluna OUTGOING_ROUTING_TS e o registro será gravado em seu arquivo de trilha de destino. Quando o valor não tiver um asterisco (*) na lista e o nome do caminho de distribuição estiver na lista, o registro será enviado para o caminho especificado no par group name[:pathname],"*"' relevante na lista. Se o nome do caminho de distribuição não estiver na lista, o registro será descartado.

Execute um Replicat, que, ao receber o registro, verifica o valor na coluna OUTGOING_REPLICAT.

Se o nome do processo Replicat corresponder ao valor, a linha na tabela de integridade será atualizada e o registro será inserido na tabela de histórico.
Se o nome do processo Replicat não corresponder, o registro será descartado.

Se o valor for NULL, a linha nas tabelas de histórico de pulsação e pulsação será atualizada com uma chamada implícita do mapeamento da coluna Replicat.

Mapeamento Automático de Colunas de Replicat:

REMOTE_DATABASE         = LOCAL_DATABASE
INCOMING_EXTRACT        = OUTGOING_EXTRACT
INCOMING_ROUTING_PATH      = OUTGOING_ROUTING_PATH with "*"    removed
INCOMING_REPLICAT       = @GETENV ("GGENVIRONMENT", "GROUPNAME")
INCOMING_HEARTBEAT_TS   = HEARTBEAT_TIMESTAMP
INCOMING_EXTRACT_TS = OUTGOING_EXTRACT_TS
INCOMING_ROUTING_TS = OUTGOING_ROUTING_TS
INCOMING_REPLICAT_TS          = @DATE ('UYYYY-MM-DD HH:MI:SS.FFFFFF','JTSLCT',@GETENV ('JULIANTIMESTAMP'))
LOCAL_DATABASE  = REMOTE_DATABASE
OUTGOING_EXTRACT    = INCOMING_EXTRACT
OUTGOING_ROUTING_PATH   = INCOMING_ROUTING_PATH
OUTGOING_HEARTBEAT_TS     = INCOMING_HEARTBEAT_TS
OUTGOING_REPLICAT   = INCOMING_REPLICAT
OUTGOING_HEARTBEAT_TS   = INCOMING_HEARTBEAT_TS

Considerações Adicionais:

A computação fica atrasada à medida que a pulsação flui pelo sistema, dependendo dos relógios dos sistemas de origem e destino a serem configurados corretamente. É possível que o atraso possa ser negativo se o sistema de destino estiver à frente do sistema de origem. O atraso é mostrado como um número negativo para que você esteja ciente de sua discrepância de relógio e possa tomar medidas para corrigi-lo.

O timestamp que flui pelo sistema está em UTC. Não há fuso horário associado ao timestamp; portanto, ao visualizar as tabelas de pulsação, o atraso pode ser visualizado rapidamente, mesmo que diferentes componentes estejam em fusos horários diferentes. Você pode escrever qualquer view que quiser na parte superior das tabelas subjacentes; UTC é recomendado.

Todas as entradas de pulsação são gravadas na trilha no UTF-8.

Os caminhos de saída e entrada juntos determinam exclusivamente uma linha. Isso significa que, se você tiver duas linhas com o mesmo caminho de saída e um caminho de entrada diferente, serão consideradas duas entradas exclusivas.

Detalhes da Tabela de Heartbeat

A tabela GG_HEARTBEAT exibe informações de timestamp do tempo de replicação de ponta a ponta e as informações de tempo nos diferentes componentes Extract e Replicat primário e secundário.

Em um ambiente unidirecional, somente o banco de dados de destino contém informações sobre o lag de replicação. Esse é o momento em que um registro é gerado no banco de dados de origem e se torna visível para os clientes no banco de dados de destino. Observação: as tabelas de pulsação automática não preenchem as colunas OUTGOING_% com dados, quando os bancos de dados de origem e remotos têm o mesmo nome. Para alterar o nome do banco de dados, use o utilitário DBNEWID. Para obter detalhes, consulte o Utilitário DBNEWID.

Coluna	Tipo de Dados	Descrição
`LOCAL_DATABASE`	`VARCHAR2`	O banco de dados local onde o tempo de replicação do banco de dados remoto é medido.
`HEARTBEAT_TIMESTAMP`	`TIMESTAMP(6)`	O ponto no tempo em que um timestamp é gerado no banco de dados remoto.
`REMOTE_DATABASE`	`VARCHAR2`	Banco de dados remoto no qual o timestamp é gerado
`INCOMING_EXTRACT`	`VARCHAR2`	Nome do processo Extract principal (capturar) no banco de dados remoto
`INCOMING_ROUTING_PATH`	`VARCHAR2`	Nome do Extract secundário (pump) no banco de dados remoto
`INCOMING_REPLICAT`	`VARCHAR2`	Nome do processo Replicat no banco de dados local.
`INCOMING_HEARTBEAT_TS`	`TIMESTAMP(6)`	Timestamp final quando as informações são inseridas na tabela `GG_HEARTBEAT` no banco de dados local.
`INCOMING_EXTRACT_TS`	`TIMESTAMP(6)`	O timestamp do timestamp gerado é processado pelo Extract principal no banco de dados remoto.
`INCOMING_ROUTING_TS`	`TIMESTAMP(6)`	O timestamp do timestamp gerado é processado pelo Extract secundário no banco de dados remoto.
`INCOMING_REPLICAT_TS`	`TIMESTAMP(6)`	O timestamp do timestamp gerado é processado pelo Replicat no banco de dados local.
`OUTGOING_EXTRACT`	`VARCHAR2`	Replicação bidirecional/N-way: Nome do Extract principal no banco de dados local.
`OUTGOING_ROUTING_PATH`	`VARCHAR2`	Replicação bidirecional/N-way: Nome do Extract secundário no banco de dados local.
`OUTGOING_REPLICAT`	`VARCHAR2`	Replicação bidirecional/N-way: Nome do Replicat no banco de dados remoto.
`OUTGOING_HEARTBEAT_TS`	`TIMESTAMP(6)`	Replicação bidirecional/N-way: Timestamp final quando as informações são inseridas na tabela no banco de dados remoto.
`OUTGOING_EXTRACT_TS`	`TIMESTAMP(6)`	Replicação bidirecional/N-way: O timestamp do timestamp gerado é processado pelo Extract principal no banco de dados local.
`OUTGOING_ROUTING_TS`	`TIMESTAMP(6)`	Replicação bidirecional/N-way: O timestamp do timestamp gerado é processado pelo Extract secundário no banco de dados local.
`OUTGOING_REPLICAT_TS`	`TIMESTAMP(6)`	Replicação bidirecional/N-way: O timestamp do timestamp gerado é processado pelo Replicat no banco de dados remoto.
`INCOMING_REPLICAT_LW_CSN`	`VARCHAR2`	-
`INCOMING_EXTRACT_HEARTBEAT_CSN`	`VARCHAR2`	-
`INCOMING_EXTRACT_RESTART_CSN`	`VARCHAR2`	-
`INCOMING_EXTRACT_RESTART_TS`	`TIMESTAMP(6)`	-

A tabela GG_HEARTBEAT_HISTORY exibe informações de timestamp histórico do tempo de replicação de ponta a ponta e as informações de tempo nos diferentes componentes Extract e Replicat primário e secundário.

Em um ambiente unidirecional, somente o banco de dados de destino contém informações sobre o atraso de replicação.

Os timestamps são gerenciados no fuso horário UTC. Esse é o momento em que um registro é gerado no banco de dados de origem e se torna visível para os clientes no banco de dados de destino.

Coluna	Tipo de Dados	Descrição
`LOCAL_DATABASE`	`VARCHAR2`	Banco de dados local em que o atraso de ponta a ponta é medido.
`HEARTBEAT_RECEIVED_TS`	`TIMESTAMP(6)`	O momento em que um timestamp do banco de dados remoto é recebido no banco de dados local.
`REMOTE_DATABASE`	`VARCHAR2`	Banco de dados remoto no qual o timestamp é gerado.
`INCOMING_EXTRACT`	`VARCHAR2`	Nome do Extract principal no banco de dados remoto.
`INCOMING_ROUTING_PATH`	`VARCHAR2`	Nome do Extract secundário do banco de dados remoto.
`INCOMING_REPLICAT`	`VARCHAR2`	Nome do processo Replicat no banco de dados local.
`INCOMING_HEARTBEAT_TS`	`TIMESTAMP(6)`	Timestamp final quando as informações são inseridas na tabela `GG_HEARTBEAT_HISTORY` no banco de dados local.
`INCOMING_EXTRACT_TS`	`TIMESTAMP(6)`	Timestamp quando o timestamp gerado é processado pelo Extract principal no banco de dados remoto.
`INCOMING_ROUTING_TS`	`TIMESTAMP(6)`	Timestamp quando o timestamp gerado é processado pelo Extract secundário no banco de dados remoto.
`INCOMING_REPLICAT_TS`	`TIMESTAMP(6)`	Timestamp quando o timestamp gerado é processado pelo Replicat no banco de dados local.
`OUTGOING_EXTRACT`	`VARCHAR2`	Replicação bidirecional/N-way: Nome do Extract principal do banco de dados local.
`OUTGOING_ROUTING_PATH`	`VARCHAR2`	Replicação bidirecional/N-way: Nome do Extract secundário do banco de dados local.
`OUTGOING_REPLICAT`	`VARCHAR2`	Replicação bidirecional/N-way: Nome do Replicat no banco de dados remoto.
`OUTGOING_HEARTBEAT_TS`	`TIMESTAMP(6)`	Replicação bidirecional/N-way: Timestamp final quando as informações são persistentemente inseridas na tabela do banco de dados remoto.
`OUTGOING_EXTRACT_TS`	`TIMESTAMP(6)`	Replicação bidirecional/N-way: Timestamp quando o timestamp gerado é processado pelo Extract principal no banco de dados local.
`OUTGOING_ROUTING_TS`	`TIMESTAMP(6)`	Replicação bidirecional/N-way: Timestamp quando o timestamp gerado é processado pelo Extract secundário no banco de dados local.
`OUTGOING_REPLICAT_TS`	`TIMESTAMP(6)`	Replicação bidirecional/N-way: Timestamp quando o timestamp gerado é processado pelo Replicat no banco de dados remoto.
`REPLICAT_LOW_WATERMARK_CSN`	`String`	Essa coluna é preenchida pelo Replicat quando ele processa esse registro de pulsação. Ele preenche esta coluna com sua marca d'água baixa (LWM) atual ao processar esse registro. Isso nos permite escolher um LOGBSN de um registro de pulsação que seja a partir do Replicat LWM.
`SOURCE_EXTRACT_HEARTBEAT_CSN`	`String`	Esta coluna é preenchida pelo Extract e contém o SCN de confirmação de origem para a transação de pulsação no banco de dados de origem. O job de pulsação no banco de dados de origem não pode preencher esse valor, pois ele não saberá o apriori SCN de commit.
`SOURCE_EXTRACT_RESTART_CSN`	`String`	Esta coluna será preenchida pelo Extract e conterá o LOGBSN atual quando o Extract processar esse registro de pulsação específico. O job de pulsação no banco de dados de origem não preencherá esse valor.
`SOURCE_EXTRACT_RESTART_CSN_TS`	`TIMESTAMP`	Esta coluna será preenchida pelo Extract e conterá o timestamp de redo no UTC que corresponde ao LOGBSN atual quando o Extract processar esse registro de pulsação específico. O job de pulsação no banco de dados de origem não preencherá esse valor.

A view GG_LAG exibe informações sobre o atraso de replicação entre os bancos de dados local e remoto.

Em um ambiente unidirecional, somente o banco de dados de destino contém informações sobre o atraso de replicação. O atraso é medido em segundos.

Coluna	Tipo de Dados	Descrição
`LOCAL_DATABASE`	`VARCHAR2`	O banco de dados local em que o atraso de replicação de ponta a ponta do banco de dados remoto é medido.
`CURRENT_LOCAL_TS`	`TIMESTAMP(6)`	Timestamp atual do banco de dados local.
`REMOTE_DATABASE`	`VARCHAR2`	Banco de dados remoto no qual o timestamp é gerado.
`INCOMING_HEARTBEAT_AGE`	`NUMBER`	A idade da pulsação mais recente recebida do banco de dados remoto.
`INCOMING_PATH`	`VARCHAR2`	Caminho de replicação do banco de dados remoto para o banco de dados local com os componentes Extract e Replicat.
`INCOMING_LAG`	`NUMBER`	Lag de replicação do banco de dados remoto para o banco de dados local. Este é o horário em que a pulsação foi gerada no banco de dados remoto menos o horário em que as informações foram inseridas persistentemente na tabela no banco de dados local.
`OUTGOING_HEARTBEAT_AGE`	`NUMBER`	A idade da pulsação mais recente do banco de dados local para o banco de dados remoto.
`OUTGOING_PATH`	`VARCHAR2`	Caminho de Replicação do banco de dados local para o banco de dados remoto com os componentes Extract e Replicat
`OUTGOING_LAG`	`NUMBER`	Lag de Replicação do banco de dados local para o banco de dados remoto. Este é o momento em que a pulsação é gerada no banco de dados local menos o momento em que as informações foram inseridas persistentemente na tabela no banco de dados remoto.
`REMOTE_EXTRACT_RESTART_CSN`	`String`	Posição de reinicialização da Extração de Origem.
`REMOTE_DATABASE DB_UNIQUE_NAME`	`String`	O nome exclusivo do banco de dados remoto é exibido. Se não existir um nome exclusivo, o valor `DB_NAME` será exibido.
`REMOTE_EXTRACT_RESTART_CSN_TIME`	`Timestamp`	Timestamp associado à posição de redo do Extract de origem.
`REMOTE_DB_OLDEST_OPEN_TXN_AGE`	`Timestamp`	Idade da transação aberta mais antiga no banco de dados de origem que o processo Extract está em processamento no momento. Essa coluna pode ser calculada como `SYSTIMESTAMP - REMOTE_EXTRACT_RESTART_TIME`.
`LOCAL_REPLICAT_LWM_CSN`	`String`	CSN de marca d'água inferior do Replicat local quando ele processou a pulsação.

A view GG_LAG_HISTORY exibe as informações do histórico sobre o histórico de lag de replicação entre os bancos de dados local e remoto.

Em um ambiente unidirecional, somente o banco de dados de destino contém informações sobre o atraso de replicação.

A unidade das unidades de defasagem é em segundos.

Coluna	Tipo de Dados	Descrição
`LOCAL_DATABASE`	`VARCHAR2`	O banco de dados local em que o atraso de replicação de ponta a ponta do banco de dados remoto é medido.
`HEARTBEAT_RECEIVED_TS`	`TIMESTAMP(6)`	O momento em que um timestamp do banco de dados remoto é recebido no banco de dados local.
`REMOTE_DATABASE`	`VARCHAR2`	Banco de dados remoto no qual o timestamp é gerado.
`DB_NAME`	String	Nome do banco de dados remoto.
`DB_UNIQUE_NAME`	String	Nome exclusivo do banco de dados remoto. Se o nome exclusivo do banco de dados não existir, o `DB_NAME`e o `DB_UNIQUE_NAME` serão iguais. Em um cenário de switchover para stand-by, o `db_unique_name` será alterado, mas o `db_name` e o caminho de replicação permanecem os mesmos
`INCOMING_HEARTBEAT_AGE`	`NUMBER`	A idade da mesa de batimentos cardíacos.
`INCOMING_PATH`	`VARCHAR2`	Caminho de replicação do banco de dados remoto para o banco de dados local com os componentes Extract e Replicat.
`INCOMING_LAG`	`NUMBER`	Lag de replicação do banco de dados remoto para o banco de dados local. Este é o momento em que a pulsação foi gerada no banco de dados remoto menos o momento em que as informações foram inseridas persistentemente na tabela no banco de dados local.
`OUTGOING_HEARTBEAT_AGE`	`NUMBER`
`OUTGOING_PATH`	`VARCHAR2`	Caminho de replicação do banco de dados local para o banco de dados remoto com os componentes Extract e Replicat.
`OUTGOING_LAG`	`NUMBER`	Lag de replicação do banco de dados local para o banco de dados remoto. Este é o momento em que a pulsação foi gerada no banco de dados local menos o momento em que as informações foram inseridas persistentemente na tabela no banco de dados remoto.
`REMOTE_EXTRACT_RESTART_CSN`	`String`	Posição de reinicialização da Extração de Origem.
`REMOTE_EXTRACT_RESTART_CSN_TIME`	`TIMESTAMP`	Timestamp associado à posição de redo do Extract de origem.
`REMOTE_DB_OLDEST_OPEN_TXN_AGE`	`TIMESTAMP`	Idade da transação aberta mais antiga no banco de dados de origem que o processo Extract está em processamento no momento. Esta coluna pode ser calculada como: `SYSTIMESTAMP - REMOTE_EXTRACT_RESTART_TIME`
`LOCAL_REPLICAT_LWM_CSN`	`String`	CSN de marca d'água inferior do Replicat local quando ele processou a pulsação.
`INCOMING_EXTRACT_LAG`	-	-
`INCOMING_ROUTINE_LAG`	-	-
`INCOMING_REPLICAT_READ_LAG`	-	-
`INCOMING_REPICAT_LAG`	-	-
`OUTGOING_EXTRACT_LAG`	-	-
`OUTGOING_ROUTINE_LAG`	-	-
`OUTGOING_REPLICAT_READ_LAG`	-	-
`OUTGOING_REPLICAT_LAG`	-	-

Atualizar Tabelas de Integridade

A coluna HEARTBEAT_TIMESTAMP na tabela pré-implantada de pulsação deve ser atualizada periodicamente por um job de banco de dados. O intervalo de pulsação padrão é de 1 minuto e esse intervalo pode ser especificado ou substituído usando a linha de comando ou a interface Web do Administration Service.

Para o Oracle AI Database, o job de banco de dados é criado automaticamente.

Para PostgreSQL, você pode configurar uma tarefa automatizada para atualizar a tabela de pulsação. Consulte Configurar Tarefa de Automação para Atualizar a Tabela de Heartbeat para PostgreSQL.

Para todos os outros bancos de dados suportados, você deve criar jobs em segundo plano para atualizar o timestamp de pulsação usando a funcionalidade do scheduler específico do banco de dados.

Consulte [ADD HEARTBEATTABLE](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-126E30A2-DC7A-4C93-93EC-0EB8BA7C13CB), [ALTER HEARTBEATTABLE](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-08BC29F9-8A5D-4AD9-B355-528A270EECC8) para obter detalhes sobre como atualizar a tabela de integridade.

Configurar Tarefa de Automação para Atualizar a Tabela de Heartbeat para PostgreSQL

A interface Web do Oracle GoldenGate for PostgreSQL fornece a funcionalidade de criar um job cron para atualizar periodicamente a tabela de integridade.

Veja a seguir as etapas para criar esta tarefa a partir da interface web:

No painel de navegação esquerdo, expanda Tarefas e selecione a opção Atualizar Tarefas de Pulsação.

\

\
Clique no sinal de mais na página Atualizar Tarefas de Pulsação. A caixa de diálogo Criar uma Nova Tarefa de Pulsação é exibida.\
Especifique os seguintes valores na caixa de diálogo e clique em Submeter:
- Nome: Especifique um nome para a tarefa.
- Domínio da Credencial: Selecione o nome do domínio na lista drop-down.
- Alias da Credencial: Selecione o alias da credencial para a instância do banco de dados PostgreSQL para a qual você está criando a tarefa de integridade de atualização.
- Intervalo de Frequência: Especifique o intervalo de frequência para executar a tarefa de atualização. O valor mínimo é 60 (padrão) e o valor máximo pode ser definido como 7999.

Para modificar ou excluir uma tarefa Atualizar pulsação, você pode usar as seguintes etapas: 1. No painel de navegação esquerdo da interface do Administration Service, selecione Tarefas.

Clique em Atualizar Tarefas de Pulsação. Uma lista de tarefas de atualização de pulsação existentes é exibida.
Na coluna Ações, clique no ícone de lápis. A caixa de diálogo Editar Tarefa de Heartbeat de Atualização é exibida.
Você pode alterar ou modificar o domínio da credencial, o alias ou o intervalo de frequência e clicar em Submeter. A tarefa de atualização de pulsação modificada é listada na página Atualizar tarefas de pulsação.
Para deletar uma tarefa, clique no ícone Deletar da coluna Ações da tarefa. Clique em OK para confirmar a exclusão.

Limpar as tabelas de histórico de pulsação

A tabela de histórico de pulsação é expurgada periodicamente usando um job. O intervalo padrão é de 30 dias e esse intervalo pode ser especificado ou substituído usando uma interface de linha de comando, como o Admin Client ou a interface web do Administration Service.

Para o Oracle AI Database, o job de banco de dados é criado automaticamente.

Para todos os outros bancos de dados suportados, você deve criar jobs em segundo plano para expurgar a tabela de histórico de pulsação usando a funcionalidade do scheduler específico do banco de dados.

Melhores Práticas

A Oracle recomenda que você:

Use a mesma frequência de pulsação em todos os bancos de dados para facilitar o diagnóstico.
Ajuste o período de retenção se o espaço for um problema.
Mantenha a frequência padrão da tabela de pulsação; a frequência definida para ser de 30 a 60 segundos fornece os melhores resultados para a maioria das cargas de trabalho.
Use estatísticas de histórico de atraso para coletar informações de atraso e idade.

Usando os Comandos Automáticos de Pulsação

Você pode usar os comandos da tabela de integridade para controlar a funcionalidade de pulsação automática do Oracle GoldenGate da seguinte forma.

Comando	Descrição
`ADD HEARTBEATTABLE`	Cria as tabelas de pulsação necessárias para a funcionalidade de pulsação automática, incluindo as colunas `LOGBSN`.
`ALTER HEARTBEATTABLE`	Altera objetos de integridade existentes.
`ALTER HEARTBEATTABLE UPGRADE`	Altera as tabelas de pulsação para adicionar as colunas `LOGBSN` às tabelas de pulsação. Essa definição é opcional.
`DELETE HEARTBEATTABLE`	Exclui objetos de integridade existentes.
`DELETE HEARTBEATENTRY`	Exclui entradas da tabela de integridade.
`INFO HEARTBEATTABLE`	Exibe informações da tabela de integridade.

Atraso de Relatório

Os relatórios de atraso podem ser acessados no Administration Service. Você pode configurar uma tarefa Relatório de Atraso para gerar automaticamente relatórios de atraso para um determinado prazo e emitir avisos se o valor de atraso ultrapassar o limite especificado. Para configurar uma tarefa automatizada para gerar relatórios de atraso: 1. No painel de navegação esquerdo do Administration Service, clique em Tarefas e selecione Relatório de Atraso.

A coluna Ação contém todas as opções para excluir, alterar, atualizar e exibir os detalhes da tarefa do relatório de atraso.
Selecione a opção obrigatória.
Se você selecionar a opção Alterar tarefa, serão apresentadas opções para editar o relatório de atraso. As opções são:
- Ativado: Para continuar processando a tarefa do relatório de atraso.
- Check Every (em minutos): Para definir um intervalo de tempo para verificar o relatório de atraso.
- Relatório: Para gerar um relatório de atraso automaticamente se o limite especificado for excedido. É possível especificar o valor limite na caixa Se exceder.
- Se for Excedido: para especificar um limite após o qual um aviso será iniciado. O valor pode ser segundos, minutos ou horas.
- Aviso: para permitir que um aviso seja gerado caso o limite de atraso exceda o limite especificado.
- Quando Excedido: o limite de atraso após o qual o aviso é acionado.
Clique em Enviar.

Identificando Defasagem no Replicat

Para identificar o atraso no processo Replicat e modificar as colunas de uma tabela:

Suspender a atividade no banco de dados de origem para todas as tabelas vinculadas ao Oracle GoldenGate.
Inicie o Admin Client.
Execute este comando para o grupo Replicat:

INFO REPLICAT *group*

Na linha Checkpoint Lag, verifique se há algum atraso no Replicat. Se necessário, continue a emitir INFO REPLICAT até que a defasagem seja zero, o que indica que todos os dados na trilha foram processados.
Interrompa o grupo Replicat.

STOP REPLICAT *group*

Execute as modificações de tabela nos bancos de dados de destino.
Iniciar o processo Replicat.

START REPLICAT *group*

Permita que a atividade do usuário seja retomada em todas as tabelas de origem vinculadas ao Oracle GoldenGate.