Requisitos e configurações do log de transações

O Oracle GoldenGate conta com os redo logs para capturar os dados necessários para replicar as transações de origem. Os redo logs do Oracle no sistema de origem devem ser configurados corretamente antes de você iniciar o processamento do Oracle GoldenGate.

Esta seção aborda os seguintes níveis de log que se aplicam ao Oracle GoldenGate. O nível de log que você usa depende dos recursos do Oracle GoldenGate que você está usando.

Observação: O volume de redo é aumentado como resultado deste log obrigatório. Você pode esperar até estar pronto para iniciar o processamento do Oracle GoldenGate para ativar o log.

Esta tabela mostra os casos de uso do Oracle GoldenGate para as diferentes propriedades de log.

Opção Registro em Log	Nome do Comando	O que essa opção faz	Uso do caso
Modo de log forçado	`ALTER DATABASE FORCE LOGGING`;	Força o registro de todas as transações e cargas.	Fortemente recomendado para todos os casos de uso do Oracle GoldenGate. `FORCE LOGGING` substitui qualquer definição `NOLOGGING` no nível da tabela.
Registro em log complementar mínimo no nível do banco de dados Consulte Ativar Log de Replicação do Banco de Dados do Subconjunto.	`ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;`	Permite que o log complementar mínimo adicione informações de encadeamento de linhas ao redo log.	Obrigatório para todos os casos de uso do Oracle GoldenGate
Registro em log complementar no nível do esquema	`[ADD SCHEMATRANDATA](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-5DA7C3DC-5D87-4A8B-AD23-6EF587A5CF41)`	Permite o log complementar incondicional da chave primária e o log complementar condicional de chave(s) exclusiva(s) e chave(s) estrangeira(s) de todas as tabelas em um esquema. Todas essas chaves juntas são conhecidas como colunas de programação. Essa definição também garante que qualquer novo objeto criado neste esquema terá o registro em log complementar apropriado.	Ativa o registro em log de todas as tabelas atuais e futuras no esquema. Se as colunas de chave primária, chave exclusiva e chave estrangeira não forem idênticas na origem e no destino, use `ALLCOLS`.
Registro em log complementar no nível do esquema com registro em log incondicional para todas as colunas suportadas. (Consulte Ativar Registro em Log Complementar no Nível do Esquema para tipos de coluna não suportados.)	`ADD SCHEMATRANDATA` com a opção `ALLCOLS`	Permite o registro em log complementar incondicional de todas as colunas em uma tabela, para todas as tabelas em um esquema. Essa definição também garante que qualquer novo objeto criado neste esquema terá o registro em log complementar apropriado.	Usado para configurações bidirecionais e ativo-ativo nas quais todos os valores de coluna são verificados, não apenas as colunas alteradas, ao tentar executar uma atualização ou exclusão. Isso requer mais recursos, porém, permite o mais alto nível de validação de dados em tempo real e, portanto, a detecção de conflitos. Esse método também deverá ser usado se eles estiverem usando o parâmetro `HANDLECOLLISIONS` para cargas iniciais.
Registro em log complementar no nível do esquema, definição mínima	`ADD SCHEMATRANDATA` com a opção `NOSCHEDULINGCOLS`	Permite o registro em log complementar incondicional da chave primária e todos os índices exclusivos válidos de todas as tabelas em um esquema. Essa definição também garante que qualquer novo objeto criado neste esquema terá o registro em log complementar apropriado.	Usar apenas para Replicat não integrado. Este é o log mínimo necessário no nível do esquema.
Registro em log complementar no nível da tabela com suporte integrado para Replicat integrado Consulte Ativar Registro em Log Complementar no Nível da Tabela	`ADD TRANDATA`	Permite o registro complementar incondicional da chave primária e do registro complementar condicional da(s) chave(s) exclusiva(s) e chave(s) estrangeira(s) de uma tabela. Todas essas chaves juntas são conhecidas como colunas de programação.	Obrigatório para todos os casos de uso do Oracle GoldenGate, a menos que o log complementar no nível do esquema seja usado. Se as colunas de chave primária, chave exclusiva e chave estrangeira não forem idênticas na origem e no destino, use `ALLCOLS`.
Registro em log complementar no nível da tabela com registro em log incondicional para todas as colunas suportadas. (Consulte Ativar Registro em Log Complementar no Nível da Tabela para tipos de coluna não suportados.)	`ADD TRANDATA` com a opção `ALLCOLS`	Permite o registro em log complementar incondicional de todas as colunas da tabela.	Usado para configurações bidirecionais e ativo-ativo nas quais todos os valores de coluna são verificados, não apenas as colunas alteradas, ao tentar executar uma atualização ou exclusão. Isso requer mais recursos, porém, permite o mais alto nível de validação de dados em tempo real e, portanto, a detecção de conflitos. Ele também pode ser usado quando as chaves primária, exclusiva e estrangeira de origem e destino não são iguais ou estão em constante mudança entre a origem e o destino.
Registro em log complementar no nível da tabela, configuração mínima	`ADD TRANDATA` com a opção `NOSCHEDULINGCOLS`	Permite o registro em log complementar incondicional da chave primária e de todos os índices exclusivos válidos de uma tabela.	Usar para Replicat não integrado e Replicat não paralelo. Este é o log mínimo necessário no nível da tabela.
Registro em log complementar no nível da tabela para Views do JSON Relational Duality e Tabelas de Coleta JSON.	`ADD TRANDATA` com `Duality View name` e `Collection Table name`	Ativa o log complementar para as Views de Dualidade e Tabelas de Coleta especificadas.	Consulte Ativar Registro em Log Complementar para Views do JSON Relational Duality e Tabelas de Coleta JSON para obter diretrizes. Consulte também Detalhes do Suporte para Views do JSON-Relational Duality e Tabelas de Coleta JSON para saber mais.

Ativar Log de Replicação do Banco de Dados do Subconjunto

A Oracle recomenda enfaticamente colocar o banco de dados de origem Oracle no modo de registro em log forçado. O modo de log forçado impõe o registro de todas as transações e carregamentos, substituindo quaisquer definições contrárias do usuário ou de armazenamento. Isso garante que nenhum dado de origem na configuração Extract seja perdido.

Há um modo de log complementar de banco de dados granular chamado Replicação de Banco de Dados Subconjunto disponível em LogMiner, que é o modo básico recomendado para todos os clientes Oracle GoldenGate e XStream. Ele substitui o modo de Log Complementar Mínimo usado anteriormente.

O registro em log de replicação do subconjunto de banco de dados está ativado em CDB$ROOT (e todos os PDBs do usuário o herdam) no momento.

Observação: O registro em log da chave primária (PK) no nível do banco de dados e do índice exclusivo (UI) só será desencorajado se você estiver replicando um subconjunto de tabelas. Você pode usá-lo com o Live Standby ou se o Oracle GoldenGate for replicar todas as tabelas, como reduzir o tempo de inatividade de uma migração ou upgrade.

Execute as etapas a seguir para verificar e ativar, se necessário, o registro em log de replicação do subconjunto de banco de dados e o registro em log forçado.

Faça log-in no SQL*Plus como um usuário com o privilégio ALTER SYSTEM.
Emita o comando a seguir para determinar se o banco de dados está no modo de log complementar e no modo de log forçado. Se o resultado for YES para ambas as consultas, o banco de dados atenderá ao requisito do Oracle GoldenGate.
```
SELECT SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING FROM V$DATABASE;
```

Se o resultado for NO para uma ou ambas as propriedades, continue com estas etapas para ativá-las conforme necessário:

ALTER PLUGGABLE DATABASE *pdbname* ADD SUPPLEMENTAL LOG DATA SUBSET DATABASE REPLICATION;
ALTER DATABASE FORCE LOGGING;

Emita o comando a seguir para verificar se essas propriedades estão ativadas agora.
```
SELECT SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING FROM V$DATABASE;
```
A saída da consulta deve ser YES para ambas as propriedades.
Alterne os arquivos de log.
```
ALTER SYSTEM SWITCH LOGFILE;
```

Ativar Log Complementar no Nível do Esquema

O Oracle GoldenGate suporta log complementar no nível do esquema. O registro em log no nível do esquema é necessário para um banco de dados de origem e destino Oracle ao usar o recurso de replicação de DDL do Oracle GoldenGate ou no banco de dados de origem se a DDL puder ser executada (ou executada) nas tabelas que estão sendo replicadas. Em todos os outros casos de uso, é opcional, mas você deve usar o registro em log no nível da tabela (consulte Ativar Registro em Log Complementar no Nível da Tabela).

Por padrão, o registro em log no nível do esquema ativa automaticamente o registro em log complementar incondicional da chave primária e o registro em log complementar condicional de chave(s) exclusiva(s) e chave(s) estrangeira(s) de todas as tabelas em um esquema. As opções permitem alterar o registro em log conforme necessário.

Observação: A Oracle recomenda enfaticamente o uso do registro em log no nível do esquema em vez do registro em log no nível da tabela, pois isso garante que todas as novas tabelas adicionadas a um esquema sejam capturadas se atenderem às especificações de curinga. Esse método também é recomendado porque todas as alterações nas colunas-chave também são refletidas automaticamente nos dados de log complementares. Por exemplo, se uma chave for alterada, não será necessário emitir ADD TRANDATA.

Execute as etapas a seguir no sistema de origem para ativar o registro em log complementar no nível do esquema.

Inicie a linha de comando no sistema de origem.
Emita o comando DBLOGIN com o alias de um usuário no armazenamento de credenciais que tem privilégio para ativar o log complementar no nível do esquema.
```
DBLOGIN USERIDALIAS *alias*
```
Consulte USERIDALIAS na Referência de Parâmetros e Funções do Oracle GoldenGate para obter mais informações sobre USERIDALIAS e opções adicionais.
Ao usar ADD SCHEMATRANDATA ou ADD TRANDATA em um banco de dados multitenant, você pode fazer log-in diretamente no PDB e executar o comando. Como alternativa, se você estiver fazendo log-in no nível da raiz (usando um usuário C##), deverá incluir o PDB. Emita o comando ADD SCHEMATRANDATA para cada esquema cujo Oracle GoldenGate deseja capturar alterações de dados.
```
ADD SCHEMATRANDATA pdb.schema [ALLCOLS | NOSCHEDULINGCOLS]
```
Onde:
- Sem opções, o esquema ADD SCHEMATRANDATA ativa o log complementar incondicional no sistema de origem da chave primária e o log complementar condicional de todas as chaves exclusivas e chaves externas de todas as tabelas atuais e futuras no esquema fornecido. O registro em log não condicional força os valores de chave principal no log quer a chave tenha sido ou não alterada na operação atual. O log condicional registrará todos os valores de coluna de uma chave estrangeira ou exclusiva se pelo menos um deles tiver sido alterado na operação atual. O padrão é opcional para suportar o Replicat não integrado, mas é necessário para suportar o Replicat integrado, pois a chave primária, as chaves exclusivas e as chaves estrangeiras devem estar disponíveis para o servidor de entrada a fim de calcular dependências.
- ALLCOLS pode ser usado para ativar o registro em log complementar incondicional de todas as colunas de uma tabela e se aplica a todas as tabelas atuais e futuras no esquema fornecido. Use para suportar Replicat integrado quando as tabelas de origem e de destino tiverem colunas de programação diferentes. (As colunas de programação são a chave primária, a chave exclusiva e a chave estrangeira.)
- O NOSCHEDULINGCOLS registra somente os valores da chave primária e todos os índices exclusivos válidos para tabelas existentes no esquema e novas tabelas adicionadas posteriormente. Este é o nível mínimo necessário de registro em log no nível do esquema e é válido somente para o Replicat no modo não integrado.
No exemplo a seguir, o comando ativa o log complementar padrão para o esquema hr.
```
ADD SCHEMATRANDATA pdbeast.hr ALLCOLS
```
No exemplo a seguir, o comando ativa o log complementar somente para a chave primária e índices exclusivos válidos para o esquema HR.
```
ADD SCHEMATRANDATA pdbeast.hr NOSCHEDULINGCOLS
```

Ativar Registro em Log Complementar no Nível da Tabela

Ative o registro em log complementar no nível da tabela no sistema de origem nos seguintes casos:

Para ativar o nível necessário de registro em log quando não estiver usando o registro em log no nível do esquema (consulte Ativar Registro em Log Complementar no Nível do Esquema). O log em nível de esquema ou de tabela deve ser usado. Por padrão, o registro em log no nível da tabela ativa automaticamente o registro em log complementar incondicional da chave primária e do registro complementar condicional de chave(s) exclusiva(s) e chave(s) estrangeira(s) de uma tabela. As opções permitem alterar o registro em log conforme necessário.
Para impedir o registro em log da chave primária de qualquer tabela fornecida.
Registrar valores de coluna que não sejam de chave no nível da tabela para oferecer suporte a recursos específicos do Oracle GoldenGate, como filtragem e lógica de detecção e resolução de conflitos.
Se as colunas-chave forem alteradas em uma tabela que só tenha registro em log complementar no nível da tabela, você deverá executar ADD TRANDATA na tabela antes de permitir qualquer atividade DML na tabela.
Para ativar o registro em log complementar para Views JSON Relational Duality (JSON DVs) e Tabelas de Coleta JSON, você precisa seguir as diretrizes em Ativar Registro em Log Complementar para Views JSON Relational Duality e Tabelas de Coleta JSON.

Execute as etapas a seguir no sistema de origem para ativar o registro em log complementar no nível da tabela ou usar os recursos opcionais do comando.

Execute a linha de comando no sistema de origem.
Emita o comando DBLOGIN usando o alias de um usuário no armazenamento de credenciais que tem privilégio para ativar o log complementar no nível da tabela.
```
DBLOGIN USERIDALIAS *alias*
```
Consulte USERIDALIAS na Referência de Parâmetros e Funções do Oracle GoldenGate para obter mais informações sobre DBLOGIN e opções adicionais.
Emita o comando ADD TRANDATA.
```
ADD TRANDATA [*PDB*.]*schema.**table* [, COLS (*columns)*] [, NOKEY] [, ALLCOLS | NOSCHEDULINGCOLS]
```
Onde:
- PDB é o nome do contêiner raiz ou do banco de dados plugável se a tabela estiver em um banco de dados contêiner multitenant.
- schema é o esquema de origem que contém a tabela.
- table é o nome da tabela. Consulte Especificando Nomes de Objetos na Entrada do Oracle GoldenGate para obter instruções sobre como especificar nomes de objetos.
- ADD TRANDATA sem outras opções ativa automaticamente o registro em log complementar incondicional da chave primária e o registro em log complementar condicional de chave(s) exclusiva(is) e chave(s) estrangeira(s) da tabela. O registro em log não condicional força os valores de chave principal no log quer a chave tenha sido ou não alterada na operação atual. O log condicional registrará todos os valores de coluna de uma chave estrangeira ou exclusiva se pelo menos um deles tiver sido alterado na operação atual. O padrão é opcional para suportar o Replicat não integrado (consulte também NOSCHEDULINGCOLS), mas é necessário para suportar o Replicat integrado porque a chave primária, as chaves exclusivas e as chaves estrangeiras devem estar todas disponíveis para o servidor de entrada para calcular dependências.
- ALLCOLS ativa o registro em log complementar incondicional de todas as colunas da tabela. Use para suportar Replicat integrado quando as tabelas de origem e de destino tiverem colunas de programação diferentes. (As colunas de programação são a chave primária, a chave exclusiva e a chave estrangeira.)
- NOSCHEDULINGCOLS só é válido para Replicat no modo não integrado. Ele emite um comando ALTER TABLE com uma cláusula ADD SUPPLEMENTAL LOG DATA ALWAYS apropriada para o tipo de restrição exclusiva definida para a tabela ou para todas as colunas na ausência de uma restrição exclusiva. Este comando atende aos requisitos básicos de log no nível da tabela do Oracle GoldenGate quando o log no nível do esquema não for usado. Consulte Garantindo a Exclusividade da Linha na Tabela de Origem e Destino para saber como o Oracle GoldenGate seleciona uma chave ou um índice.
- As colunas do COLS registram colunas que não são de chave necessárias para uma cláusula KEYCOLS ou para filtragem e manipulação. Os parênteses são obrigatórios. Essas colunas serão registradas em log além da chave primária, a menos que a opção NOKEY também esteja presente.
- NOKEY impede o registro em log da chave primária ou exclusiva. Requer uma cláusula KEYCOLS nos parâmetros TABLE e MAP e uma cláusula COLS no comando ADD TRANDATA para registrar as colunas KEYCOLS alternativas.
Se estiver usando ADD TRANDATA com a opção COLS, crie um índice exclusivo para essas colunas no destino para otimizar a recuperação de linhas. Se você estiver registrando essas colunas como chave substituta de uma cláusula KEYCOLS, anote a adição da cláusula KEYCOLS às instruções TABLE e MAP ao configurar os processos do Oracle GoldenGate.

Ativar Registro em Log Complementar para Views do JSON Relational Duality e Tabelas de Coleta JSON

Antes de replicar as Views do JSON Relational Duality e as Tabelas de Coleta JSON, configure o log complementar no Oracle GoldenGate. Por padrão, o log complementar não está ativado para Views do JSON Relational Duality e Tabelas de Coleta JSON. Você pode usar as seguintes diretrizes ao ativar o registro em log complementar para Views de Dualidade e Tabelas de Coleta:

Ativar Replicação Lógica: A ativação da replicação lógica (usando ADD TRANDATA) é obrigatória para capturar alterações feitas em Views de Dualidade e Tabelas de Coleta. Esse processo permite o registro em log complementar necessário para rastrear alterações no nível de documento JSON.

Consulte ADD TRANDATA para obter detalhes.

No Oracle AI Database, uma cláusula foi adicionada no CREATE/ALTER DDL para Views do JSON Relational Duality e Tabelas de Coleta JSON. Esta cláusula permite o registro em log complementar no nível da view. Esse log é adicional a qualquer log existente nas tabelas base.

Para obter detalhes, consulte a seção logical_replication_clause em CREATE TABLE/CREATE JSON RELATIONAL DUALITY VIEW e os comandos ALTER TABLE/ALTER JSON RELATIONAL DUALITY VIEWS no Oracle AI Database SQL Language Reference.
Alterações DML para Views do JSON Duality e Tabelas de Coleta JSON: Para operações INSERT e UPDATE, o documento JSON completo e o atributo de chave _id são registrados de forma complementar. Para operações DELETE, somente o atributo _id da chave é registrado.
Log de Commit da Transação para Views do JSON Relational Duality: O log complementar para Views do Duality ocorre no momento do commit. Somente as alterações Líquidas são registradas.

Por exemplo, se você INSERT um registro e UPDATE esse registro duas vezes em uma transação que contém uma View JSON Duality, somente uma alteração lógica existirá, contendo uma INSERT com o registro atualizado.
Views JSON Duality para Replicação de Views JSON Duality usando Tabelas Subjacentes: As alterações de replicação no nível de tabela relacional subjacente das Views Duality são mais eficientes. Uma View de Dualidade que está na parte superior da tabela relacional subjacente reflete automaticamente essas alterações, pois ela é uma view. Nesse caso, nenhum registro complementar adicional nas Visualizações de dualidade é necessário.

Para obter as etapas para configurar o registro em log complementar no nível da tabela, consulte Ativar Registro em Log Suplementar no Nível da Tabela.

Remover Registro em Log Complementar no Nível da Tabela

Se uma tabela não precisar mais ser capturada pelo Oracle GoldenGate e o parâmetro TABLE da tabela tiver sido removido do arquivo de parâmetros Extract ou se o parâmetro TABLEEXCLUDE for usado para excluir a tabela de uma instrução curinga, o log complementar poderá ser removido da tabela.

Observação: Se o processo Extract resolver uma tabela que não tenha o registro em log complementar ativado, ele será interrompido de acordo com o tipo de operação DML.

O uso de DELETE TRANDATA para remover o log complementar define o nível de Identidade do Replicat da tabela como NOTHING. O log complementar pode ser desativado usando a interface Web da Arquitetura de Microsserviços na página Serviço de Administração, Configuração, na Credencial criada para um banco de dados de origem ou pode ser emitido com o comando DELETE TRANDATA.

Veja a seguir a sintaxe para a emissão de DELETE TRANDATA.

DBLOGIN USERIDALIAS alias_name
DELETE TRANDATA schema.tablename

Para verificar o nível de registro em log complementar:

INFO TRANDATA schema.tablename