Antes de Adicionar Processos de Extract e Replicat

Saiba mais sobre as configurações de pré-requisito necessárias antes de criar os processos Extract e Replicat para uma implantação do Oracle GoldenGate.

Adicionar TRANDATA

Válido para Db2 para i, Db2 LUW, Db2 z/OS, Oracle, PostgreSQL, SQL Server e Sybase.

Dependendo do banco de dados de origem, o registro em log complementar deve ser ativado para capturar operações DML e pode ser ativado por meio do menu Trandata de uma conexão de banco de dados na interface Web ou no Admin Client emitindo ADD TRANDATA ou ADD SCHEMATRANDATA (somente para Oracle).

Não é necessário adicionar TRANDATA em um banco de dados de origem para um Extract de carga inicial. No entanto, se o Extract de carga inicial e o Extract de captura de dados de alteração (CDC) forem usados em conjunto, para uma instanciação on-line, o TRANDATA deverá ser adicionado antes de iniciar o Extract de carga inicial.

Ativar TRANDATA ou SCHEMATRANDATA para o Oracle AI Database

Isso pode ser feito no nível de tabela, esquema ou global (banco de dados).

Para ativar o registro em log complementar, conecte-se ao banco de dados na página Conexões de BD, selecione o menu Trandata e execute as seguintes etapas:

Selecione a opção Tabela ou Esquema conforme necessário e clique no sinal de mais para adicionar.
Insira o nome da tabela para a qual você precisa configurar o registro em log complementar. Certifique-se de informar o nome completo da tabela com o nome do esquema, como HR.EMP. Também é possível usar curinga em vez de um nome de tabela específico.
Clique em Enviar.

Você pode ignorar ADD TRANDATA em caso de carga inicial sem CDC.

Você também pode usar os comandos ADD TRANDATA e ADD SCHEMATRANDATA para configurar trandata e trandata no nível do esquema.

Observação: Antes de executar o comando ADD TRANDATA, primeiro você precisa se conectar ao banco de dados no qual o Extract será adicionado, usando o comando DBLOGIN. Além disso, execute os comandos ADD TRANDATA ou ADD SCHEMATRANDATA antes de adicionar o Extract.

Ativar TRANDATA para Bancos de Dados Não Oracle

Válido para Db2 i, Db2 LUW, Db2 z/OS, PostgreSQL, SQL Server e Sybase.

Isso pode ser feito no nível de tabela ou global (banco de dados). Para ativar o registro em log complementar, conecte-se ao banco de dados na página Conexões de BD, selecione o menu Trandata e execute as seguintes etapas:

Selecione a opção Tabela e clique no sinal de mais para adicionar.
Insira o nome da tabela para a qual você precisa configurar o registro em log complementar. Certifique-se de inserir o nome completo da tabela, como EMPLOYEE. Também é possível usar curinga em vez de um nome de tabela específico.
Clique em Enviar.

Para Ativar a Captura de Alteração para Db2 para i

Para capturar alterações em uma tabela em um diário, você pode executar o comando STRJRNPF na linha de comando IBM i ou executar o comando ADD TRANDATA do Admin Client. O comando ADD TRANDATA chama STRJRNPF e é o método recomendado para iniciar o registro em diário das tabelas, porque ele garante que o atributo de imagem de diário necessário do Registro Images (IMAGES): *BOTH esteja definido no comando STRJRNPF.

O comando ADD TRANDATA é:

ADD TRANDATA table_specification

Em que: table_specification é uma das seguintes:

*schema.table* [JOURNAL *library/journal*]

*library/file* [JOURNAL *library/journal]*)

Especificando um Lançamento Padrão

Para especificar um diário padrão para várias tabelas ou arquivos no comando ADD TRANDATA, em vez de especificar a palavra-chave JOURNAL, use o comando a seguir antes de emitir ADD TRANDATA.

DEFAULTJOURNAL *library/journal*

Qualquer comando ADD TRANDATA usado sem um diário pressupõe o diário de DEFAULTJOURNAL.

Para exibir a definição atual de DEFAULTJOURNAL, você pode emitir o comando com nenhum argumento.

Removendo uma Especificação de Lançamento Padrão**

Para remover o uso de um diário padrão, use o seguinte comando:

DEFAULTJOURNAL CLEAR

Para Ativar a Captura de Alterações para Db2 LUW

Configure o Db2 para registrar alterações de dados no formato expandido fornecido pelo recurso DATA CAPTURE CHANGES dos comandos CREATE TABLE e ALTER TABLE. Esse formato fornece ao Oracle GoldenGate todas as imagens antes e depois das linhas que são alteradas por instruções de atualização. Execute o comando ALTER TABLE da seguinte forma:

Emita o comando a seguir.

ADD TRANDATA owner.table

em que owner.table é o nome totalmente qualificado da tabela. É possível utilizar um caractere curinga para especificar vários nomes de tabela.

ADD TRANDATA emite o seguinte comando, que inclui registrar em log a imagem anterior das colunas LONGVAR:

ALTER TABLE name DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;

Exemplo 7-1 Para Excluir o Registro em Log LONGVAR:

Para omitir a cláusula INCLUDE LONGVAR COLUMNS do comando ALTER TABLE, use ADD TRANDATA com a opção EXCLUDELONG.

ADD TRANDATA *owner.table*, EXCLUDELONG

Observação: Se as colunas LONGVAR forem excluídas do registro em log, os recursos do Oracle GoldenGate que exigem imagens anteriores, como os parâmetros GETUPDATEBEFORES, NOCOMPRESSUPDATES e NOCOMPRESSDELETES, poderão retornar erros se as tabelas contiverem essas colunas. Para obter uma solução alternativa, consulte as opções REQUIRELONGDATACAPTURECHANGES | NOREQUIRELONGDATACAPTURECHANGES do parâmetro TRANLOGOPTIONS.

Adicionar uma Tabela de Checkpoint

Uma tabela de checkpoint é necessária para todos os Replicats não paralelos e deve ser criada no banco de dados antes da adição de um Replicat. Um ponto de verificação tem êxito ou falha na transação; portanto, o Replicat garante que uma transação seja aplicada apenas uma vez, mesmo que haja uma falha do processo ou do banco de dados.

Você pode exibir a tabela de checkpoint na seção de checkpoint. Para adicionar uma tabela de checkpoint, estabeleça conexão com o banco de dados de destino na página Conexões de Banco de Dados, selecione Checkpoint e execute as seguintes etapas:

Clique no sinal de mais para ativar a adição de uma tabela de checkpoint.
Adicionar o nome da tabela de checkpoint no formato
```
*table*.*checkpoint_table_name*
```
Clique em Enviar. Depois que o checkpoint for criado, você poderá ver na lista de tabelas de checkpoint.

Para executar essa tarefa na linha de comando, consulte ADD CHECKPOINTTABLE no Command Line Interface Reference for Oracle GoldenGate.

Adicionar uma Tabela de Checkpoint com Lançamento em Db2 para i

No Db2 do banco de dados de destino i, cada checkpoint gravado na tabela de checkpoint deve ser registrado no diário na transação Replicat.

Um método comum para criar a tabela de checkpoint com o lançamento é o seguinte:

No sistema de destino, crie o arquivo de checkpoint do Replicat.

Defina o nome do diário que deve ser usado para o arquivo de checkpoint. O padrão será GGSCHEMA/OGGJRN.

Você pode alterá-lo definindo o padrão para a sessão atual do Admin Client usando o comando DEFAULTJOURNAL. A sintaxe do comando DEFAULTJOURNAL é:
```
DEFAULTJOURNAL *library_name*/*journal_name*
```
Em que: library_name é o nome da biblioteca e journal_name é o nome do diário a ser usado para operações subsequentes que podem opcionalmente ter um diário especificado.

Adicione a tabela de checkpoint.

ADD CHECKPOINTTABLE *library_name*.chkptab

Adicionar diário à tabela de checkpoint.
```
ADD TRANDATA *library_name*.CHKPTAB
```

Para obter mais informações sobre como criar uma tabela de checkpoint, consulte Adicionar uma Tabela de Checkpoint.

Adicionar Tabela de Integridade

As tabelas de pulsação são usadas para monitorar o atraso em todo o ciclo de replicação de dados. Os heartbeats automáticos são enviados de cada banco de dados de origem para os fluxos de replicação, atualizando os registros em uma tabela de seed de heartbeat e uma tabela de heartbeat e construindo um registro de histórico de heartbeat.

Cada processo no fluxo de replicação atualiza o registro de pulsação com informações de rastreamento que, em seguida, são atualizadas na tabela de pulsação do banco de dados de destino. Esses registros de pulsação são inseridos ou atualizados na tabela de pulsação nos bancos de dados de destino.

Observação: A criação da tabela de pulsação é opcional, mas é recomendada.

Para adicionar uma tabela de pulsação, conecte-se a cada banco de dados de origem e de destino na página Conexões do BD, selecione o menu Pulsação e execute as seguintes etapas:

Clique no sinal de mais (+) ao lado para adicionar uma tabela de pulsação.
Aceite as configurações padrão ou modifique os valores disponíveis conforme necessário.

Observação: Para bancos de dados que têm uma opção para Somente Destino, selecione essa opção se esse banco de dados só for usado como banco de dados de destino no fluxo de replicação, para evitar a criação de jobs desnecessários que seriam associados a um banco de dados de origem.
Clique em Enviar.

Para executar esta tarefa na linha de comando e revisar limitações importantes específicas do banco de dados, consulte ADD HEARTBEATTABLE em Command Line Interface Reference for Oracle GoldenGate.

As etapas a seguir descrevem os comandos para configurar a tabela de pulsação.

Inicie o Admin Client na linha de comando.

Conecte-se à implantação do Admin Client.

CONNECT https://remotehost:*srvmgrport* DEPLOYMENT *deployment_name* AS *deployment_user* PASSWORD *deployment_password*

Veja um exemplo:

CONNECT https://remotehost:16000 DEPLOYMENT *ggdep_postgres* AS ggadmin PASSWORD P@ssWord

Estabeleça conexão com os bancos de dados de origem e de destino usando o comando DBLOGIN USERIDALIAS. O exemplo a seguir mostra a conexão com o banco de dados de origem com o alias de credencial ggeast:
```
(https://remotehost:16000 ggdep_postgres)> DBLOGIN USERIDALIAS ggeast
```

Adicione a tabela do heartbeat:

(https://remotehost:16000 ggdep_postgres)> ADD HEARTBEATTABLE

Opcionalmente, para um banco de dados somente de destino, um que seja usado apenas para replicação unidirecional, você pode incluir a opção TARGETONLY que não criará uma função de atualização de registro de pulsação.

Consulte ADD HEARTBEATTABLE para obter detalhes sobre opções de comando.

Executando a Função de Atualização e Expurgação de Heartbeat para PostgreSQL

O Oracle GoldenGate for PostgreSQL suporta uma configuração de tabela de integridade, com algumas limitações relacionadas às tarefas de atualização e expurgação.

A tabela de pulsação e as funções associadas são criadas com base no comando ADD HEARTBEATTABLE; no entanto, para PostgreSQL, não há um scheduler automático para chamar as funções.

Uma função principal controla a atualização do registro de pulsação e as funções de limpeza da tabela de histórico de pulsação. As configurações padrão para esses dois recursos são 60 segundos para a frequência de atualização e 1 dia para a limpeza do registro de histórico, o que exclui todos os registros com mais de 30 dias por padrão.

Para chamar a função principal de registro de pulsação, os usuários devem criar um job no nível do sistema operacional que execute

"select ggschema.gg_hb_job_run();"

Quando essa função for chamada, ela levará em consideração as configurações de frequência de atualização e as configurações de limpeza de registro de histórico e usará esses valores, independentemente das configurações do scheduler para a chamada de função.

Por exemplo, os usuários podem criar um Job Cron com a sintaxe a seguir e executá-lo a cada minuto.

PGPASSWORD="gguserpasswd" psql -U gguser -d dbname -h remotehost -p 5432 -c "select ggschema.gg_hb_job_run();" >/dev/null
 2>&1

Agendador de Tarefas do Windows, pgAdmin ou pg_cron são outros programas que podem ser usados para programar a chamada de função.

Criar a Tarefa de Limpeza do CDC do Oracle GoldenGate

Para usuários do SQL Server, há um requisito para criar tarefas de Limpeza do CDC do Oracle GoldenGate antes de adicionar um Extract. Você pode fazer isso executando as etapas em Detalhes do Processo de Limpeza CDC do Oracle GoldenGate.

PostgreSQL: Considerações de Extração para Implantação Remota

Para uma implantação remota, o banco de dados de origem e o Oracle GoldenGate são instalados em servidores separados. As implantações remotas são a única opção disponível para suportar bancos de dados em nuvem, como o Azure para PostgreSQL ou o Amazon Aurora PostgreSQL.

Para implantações remotas, o endianness do sistema operacional entre o servidor de banco de dados e o servidor do Oracle GoldenGate precisa ser o mesmo.

O horário e os fusos horários do servidor do Oracle GoldenGate devem ser sincronizados com o do servidor de banco de dados. Se isso não for possível, o posicionamento de um Extract ao criar ou alterar um precisará ser feito pelo LSN.

Em casos de uso de captura remota, o uso de SQLEXEC pode introduzir latência adicional, pois a operação SQLEXEC deve ser feita em série para cada registro que o processo Extract. Se a filtragem especial que exigiria um SQLEXEC for feita por um Extract de hub remoto e o impacto no desempenho for muito grave, pode ser necessário aproximar o processo Extract do banco de dados de origem.

Com implantações remotas, a baixa latência de rede é importante e é recomendável que a latência de rede entre o servidor Oracle GoldenGate e o servidor de banco de dados de origem seja inferior a 1 milissegundo.