Preparar Tabelas para Processamento

Esta seção descreve como preparar as tabelas para processamento. A preparação da tabela requer as seguintes tarefas.

Garantir Exclusividade de Linha para Tabelas

O Oracle GoldenGate requer alguma forma de identificador de linha exclusivo nas tabelas de origem e destino para localizar as linhas de destino corretas para atualizações e exclusões replicadas.

A menos que uma cláusula KEYCOLS seja usada na instrução TABLE ou MAP, o Oracle GoldenGate seleciona um identificador de linha a ser usado na seguinte ordem de prioridade:

  1. Chave principal

  2. Primeira chave exclusiva alfanumérica que não contém um timestamp ou uma coluna calculada não materializada.

  3. Se nenhum dos tipos de chave anteriores existir (mesmo que possa haver outros tipos de chaves definidos na tabela), o Oracle GoldenGate construirá uma pseudochave de todas as colunas que o banco de dados permite ser usado em uma chave exclusiva, excluindo as que não são suportadas pelo Oracle GoldenGate em uma chave ou as excluídas da configuração do Oracle GoldenGate.

Observação: Se houver outras chaves não utilizáveis em uma tabela ou se não houver chaves na tabela, o Oracle GoldenGate registrará uma mensagem apropriada no arquivo de relatório. A construção de uma chave de todas as colunas impede o desempenho do Oracle GoldenGate no sistema de origem. No destino, essa chave faz com que o Replicat use uma cláusula WHERE maior e menos eficiente.

  1. Se uma tabela não tiver uma chave apropriada, ou se você preferir que a(s) chave(s) existente(s) não seja(m) usada(s), poderá definir uma chave substituta, se a tabela tiver colunas que sempre contenham valores exclusivos. Você define essa chave substituta incluindo uma cláusula KEYCOLS no parâmetro Extract TABLE e no parâmetro Replicat MAP. A chave especificada substituirá qualquer chave primária ou exclusiva existente que o Oracle GoldenGate localizar. Consulte TABLE | MAP em Reference for Oracle GoldenGate.

Tabelas com uma Chave Principal Derivada de um Índice Exclusivo

Na ausência de uma chave primária em uma tabela, o MySQL promoverá um índice exclusivo para a chave primária se a coluna indexada for NOT NULL. Se houver mais de um desses índices não nulos, o primeiro que foi criado passará a ser a chave primária. Para evitar erros de Replicat, crie esses índices na mesma ordem nas tabelas de origem e de destino.

Por exemplo, suponha que as tabelas de origem e destino denominadas ggvam.emp tenham colunas nomeadas primeiro, meio e último, e todas são definidas como NOT NULL. Se você criar índices exclusivos na ordem a seguir, o Oracle GoldenGate será encerrado no destino porque as definições da tabela não correspondem.

Origem:

CREATE UNIQUE INDEX UQL ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ2 on ggvam.emp(middle);
CREATE UNIQUE INDEX UQ3 on ggvam.emp(last);

Destino:

CREATE UNIQUE INDEX UQ1 ON ggvam.emp(last);
CREATE UNIQUE INDEX UQ2 ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ3 ON ggvam.emp(middle);

O resultado dessa sequência é que MySQL promove o índice na coluna "first" de origem para a chave primária e promove o índice na coluna "last" de destino para a chave primária. O Oracle GoldenGate selecionará as chaves primárias como identificadores quando criar seu registro de metadados e os metadados não corresponderão. Para evitar esse erro, decida qual coluna você deseja promover para a chave primária e crie esse índice primeiro na origem e no destino.

Especificar Sua Própria Chave para Uso do Oracle GoldenGate

Se uma tabela não tiver um dos tipos anteriores de identificadores de linha, ou se você preferir que esses identificadores não sejam usados, poderá definir uma chave substituta se a tabela tiver colunas que sempre contenham valores exclusivos. Você define essa chave substituta incluindo uma cláusula KEYCOLS no parâmetro Extract TABLE e no parâmetro Replicat MAP. A chave especificada substituirá qualquer chave primária ou exclusiva existente que o Oracle GoldenGate localizar.

Limitar Alterações de Linha em Tabelas que Não Têm uma Chave

Se uma tabela de destino não tiver uma chave primária ou exclusiva, poderão existir linhas duplicadas. Nesse caso, o Oracle GoldenGate poderia atualizar ou excluir muitas linhas de destino, fazendo com que os dados de origem e destino saíssem da sincronização sem mensagens de erro para alertá-lo. Para limitar o número de linhas atualizadas, use o parâmetro DBOPTIONS com a opção LIMITROWS no arquivo de parâmetros do Replicat. O LIMITROWS pode aumentar o desempenho do Oracle GoldenGate no sistema de destino porque apenas uma linha é processada.

Considerações sobre Triggers e Constraints em Cascata

Acionadores

Desative os triggers nas tabelas de destino ou altere-os para ignorar as alterações feitas pelo usuário do banco de dados do Oracle GoldenGate. O Oracle GoldenGate replica a DML resultante de um trigger. Se o mesmo trigger for ativado na tabela de destino, ele se tornará redundante por causa da versão replicada e o banco de dados retornará um erro.

Considerações sobre Restrições em Cascata

Como as atualizações e deleções em cascata capturadas pelo Oracle GoldenGate não são registradas no log de binários, elas não são capturadas. Isso é válido para MySQL e MariaDB. Por exemplo, quando você executa a instrução delete na tabela pai com um relacionamento pai/filho entre tabelas, as exclusões em cascata (se houver) acontecem para a tabela filho, mas elas não estão registradas no log de binários. Somente o registro de exclusão ou atualização da tabela pai é registrado no log de binários e capturado pelo Oracle GoldenGate.

Consulte https://mariadb.com/kb/en/replication-and-foreign-keys/ e https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html para obter detalhes.

Para tratar corretamente a replicação de operações em cascata, é recomendável desativar exclusões e atualizações em cascata na origem e codificar seu aplicativo para excluir ou atualizar explicitamente os registros filhos antes de modificar o registro pai. Como alternativa, você deve garantir que a tabela pai de destino tenha as mesmas restrições em cascata configuradas como a tabela pai de origem, mas isso pode levar a uma condição fora de sincronia entre a origem e o destino, especialmente em casos de replicação bidirecional.