Preparando Tabelas para Processamento
Os atributos de tabela a seguir devem ser tratados em um ambiente do Oracle GoldenGate para Teradata.
Desativando Triggers e Constraints em Cascata
Desative triggers, restrições de exclusão em cascata e restrições de atualização em cascata nas tabelas Teradata de destino se o Oracle GoldenGate replicar DML de uma origem que ocorreu de uma restrição de trigger ou cascata. Se o mesmo trigger ou constraint for ativado na tabela de destino, ele se tornará redundante devido aos dados de origem replicados, e o banco de dados retornará um erro. Considere o exemplo a seguir, no qual as tabelas de origem são emp_src e salary_src e as tabelas de destino são emp_targ e salary_targ.
-
Uma exclusão é emitida para
emp_src. -
Ela coloca uma exclusão em cascata em
salary_src. -
O Oracle GoldenGate envia as duas exclusões ao destino.
-
A exclusão pai chega primeiro e é aplicada ao
emp_targ. -
A exclusão pai coloca uma exclusão em cascata em
salary_targ. -
A exclusão em cascata de
salary_srcé aplicada asalary_targ. -
Não é possível localizar a linha porque ela já foi excluída na etapa 5.
Garantindo a Exclusividade da 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
-
Primeira chave exclusiva alfanumérica que não contém um timestamp ou uma coluna calculada não materializada.
-
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 nenhuma chave 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.
- 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
TABLEe no parâmetro ReplicatMAP. A chave especificada substituirá qualquer chave primária ou exclusiva existente que o Oracle GoldenGate localizar. Consulte TABLE | MAP em Referência de Parâmetros e Funções do Oracle GoldenGate.
Usando KEYCOLS para Especificar uma Chave Personalizada
Se uma tabela não tiver um identificador de linha aplicável, ou se você preferir que os identificadores não sejam usados, poderá definir uma chave substituta, desde que a tabela tenha 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 substitui qualquer chave primária ou exclusiva existente que o Oracle GoldenGate localize.
Tratando Operações de Atualização e Exclusão em Massa
As operações que atualizam ou excluem um grande número de linhas geram atualizações e exclusões discretas para cada linha no banco de dados do assinante. Isso pode causar um overflow de gerenciador de bloqueio no sistema de assinantes do Teradata e, dessa forma, encerrar o processo Replicat.
Para evitar esses erros, suspenda temporariamente a replicação dessas operações e execute-as manualmente nos sistemas de origem e de destino. Para suspender a replicação, use o comando a seguir, que suspende a replicação somente dessa sessão. As operações de outras sessões nessa tabela são replicadas normalmente.
set session override replication on;
commit;