Preparando Tabelas para Processamento

Os atributos de tabela nas seções a seguir devem ser tratados no ambiente do Oracle GoldenGate.

Consideração do processo Replicat para Colunas, Triggers e Restrições de Identidade de Destino

Ao replicar dados em um banco de dados do SQL Server de destino que tenha colunas de identidade, triggers e restrições em cascata e de verificação, considere o seguinte:

• Para colunas que têm uma coluna de identidade, o Replicat define o IDENTITY_INSERT ON da tabela, o que pode reduzir o desempenho da entrega.

• Para tabelas que têm triggers ou restrições em cascata, a execução do trigger ou operação em cascata poderá resultar em um erro de Replicat se o Replicat estiver configurado para entregar os mesmos dados que um trigger inserirá ou a restrição em cascata atualizará ou excluirá.

  Por exemplo, TableA na origem tem um trigger que insere um registro no TableB. O Extract está configurado para capturar registros de TableA e TableB. No destino, o Replicat primeiro inserirá um registro para TableA, depois o trigger para TableA será acionado e inserido em TableB, seguido pelo Replicat que tenta inserir o mesmo registro em TableB, o que resultará em um erro de Replicat.

• Verifique se também são impostas restrições de chave estrangeira, o que pode reduzir o desempenho da entrega.

• Para tabelas no banco de dados de destino que têm triggers, defina o parâmetro SET XACT_ABORT como desativado. Isso garante que a execução da operação de acionamento não resulte em transações ausentes.

Para superar essas situações, há várias opções que podem ser implementadas com base no caso de uso de replicação.

• Para implementações unidirecionais em que um processo Replicat é o único que grava dados nas tabelas de destino, considere as opções a seguir para colunas, acionadores e restrições de Identidade nas tabelas de destino.

  • Desative ou elimine a propriedade Identity, triggers e constraints nas tabelas de destino.

  • Modifique a propriedade de identidade, os triggers e as restrições e defina a opção NOT FOR REPLICATION para cada um e certifique-se de que o driver ODBC da Microsoft seja pelo menos a versão 17.8.1.

• Para implementações multidirecionais em que um Replicat e um aplicativo gravam dados nas tabelas de destino, e os triggers e constraints são ativados, modifique a propriedade Identity, triggers e constraints e defina a opção NOT FOR REPLICATION para cada um e certifique-se de que o driver ODBC da Microsoft seja pelo menos a versão 17.8.1.

  Além disso, para usar colunas IDENTITY em uma configuração de replicação multidirecional, defina as colunas IDENTITY para ter um valor de incremento igual ao número de servidores na configuração, com um valor de pré-implantação diferente para cada um.

  Por exemplo, uma configuração de três bancos de dados seria a seguinte:

  Database1 defina o valor de seed como 0 com um incremento de 3.

  Database2 defina o valor pré-implantado como 1 com um incremento de 3.

  Database3 defina o valor de seed como 2 com um incremento de 3.

Melhorando a Replicação IDENTITY com o Processamento de Array

Como somente uma tabela por sessão pode ter IDENTITY_INSERT definido como ON, o Replicat deve alternar continuamente IDENTITY_INSERT quando aplicar dados IDENTITY a várias tabelas em uma sessão. Para melhorar o desempenho do Replicat nessa situação, use o parâmetro BATCHSQL. BATCHSQL faz com que o Replicat use o processamento de array em vez de aplicar instruções SQL uma de cada vez.

Garantindo a Exclusividade da Linha na Tabela de Origem e Destino

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 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.

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.

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.