Preparando Tabelas para Processamento

Os atributos de tabela a seguir devem ser tratados em um ambiente do Oracle GoldenGate.

Desativando Triggers e Constraints em Cascata

Desative triggers, exclua constraints em cascata e atualize constraints em cascata nas tabelas Sybase de destino ou altere-as 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 ou restrição em cascata. Se o mesmo trigger ou constraint for ativado na tabela de destino, ele se tornará redundante por causa da versão replicada, 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.

1. Uma exclusão é emitida para emp_src.

2. Ela coloca uma exclusão em cascata em salary_src.

3. O Oracle GoldenGate envia as duas exclusões ao destino.

4. A exclusão pai chega primeiro e é aplicada ao emp_targ.

5. A exclusão pai coloca uma exclusão em cascata em salary_targ.

6. A exclusão em cascata de salary_src é aplicada a salary_targ.

7. Não é possível localizar a linha porque ela já foi excluída na etapa 5.

Para configurar o Replicat para desativar triggers de destino no início de sua sessão de banco de dados, execute as seguintes etapas:

1. Designe ao usuário de Replicat a atribuição de replicação.

2. Adicione a seguinte instrução de parâmetro ao nível raiz do arquivo de parâmetros Replicat.

SQLEXEC "set triggers off"

Atribuindo Identificadores de Linha

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

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

Se uma tabela de destino não tiver chave primária ou chave exclusiva, poderão existir linhas duplicadas. O Oracle GoldenGate pode atualizar ou excluir muitas linhas na tabela de destino, fazendo com que os dados de origem e de destino saiam da sincronização sem que mensagens de erro o alertem. 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.

Replicando Dados Criptografados

O Oracle GoldenGate oferece suporte a colunas criptografadas com uma senha criptografada pelo sistema, mas não a colunas criptografadas com uma senha definida pelo usuário. Verifique as tabelas das quais você deseja capturar dados com base nas seguintes limitações do Oracle GoldenGate:

• A tabela que contém as colunas criptografadas deve ter uma chave primária ou exclusiva.

• As colunas que usam criptografia não podem fazer parte da chave primária.

As colunas criptografadas são criptografadas nos arquivos de dados e no log; portanto, o Extract deve ser configurado para extrair os valores de texto não criptografado do banco de dados. Para acionar essa extração, use as opções FETCHCOLS e FETCHMODCOLS[EXCEPT] do parâmetro TABLE do Extract. FETCHCOLS força uma extração de valores que não estão no log e FETCHMODCOLS ou FETCHMODCOLS[EXCEPT] força uma extração de valores que estão nos logs. Usados juntos, esses parâmetros garantem que as colunas criptografadas sejam sempre extraídas do banco de dados.

A seguir, um exemplo de como configurar o Extract para suportar a criptografia. Neste exemplo, a coluna criptografada é cardnum.

TABLE ab.payments, FETCHCOLS (cardnum), FETCHMODCOLS (cardnum);

Preparando os Logs de Transação

Para capturar operações DML, o Oracle GoldenGate lê os logs on-line. Para garantir a continuidade e a integridade do processamento do Oracle GoldenGate, os logs devem ser configurados de acordo com as instruções nas seguintes seções:

Inicializando o Ponto de Truncação Secundário

Estabeleça um ponto de truncamento de log secundário no sistema de origem antes de executar o processo de Extração do Oracle GoldenGate. A extração usa o ponto de truncamento secundário para identificar os dados que ainda precisam ser processados.

Para inicializar o ponto de truncamento secundário, faça log-on no banco de dados como um usuário com privilégios sa_role e, em seguida, execute o seguinte comando:

dbcc settrunc( 'ltm', valid )

Por padrão, o Extract gerenciará o ponto de truncamento secundário quando ele for estabelecido. Não permita que o Extract seja interrompido por mais tempo do que o necessário; caso contrário, o log poderá ser preenchido e o banco de dados será interrompido. A única maneira de resolver esse problema é desativar o ponto de truncamento secundário e gerenciá-lo fora do Oracle GoldenGate e, em seguida, expurgar o log de transações. Os dados ainda não processados pelo Extract serão perdidos e você terá que ressincronizar os dados de origem e destino.

Para controlar como o ponto de truncamento secundário é gerenciado, use o parâmetro TRANLOGOPTIONS. Para obter mais informações, consulte Reference for Oracle GoldenGate for Windows and UNIX.

Dimensionando e Retendo os Logs

Reter dados de log suficientes no sistema de origem para que o Extract possa ser iniciado novamente em seus pontos de verificação depois que ele for interrompido ou houver uma interrupção não planejada. A extração deve ter acesso ao log que contém o início da unidade de trabalho não confirmada mais antiga e todos os logs posteriormente. Para determinar onde estão os pontos de verificação do Extract, use o comando INFO EXTRACT. Para obter mais informações sobre o INFO EXTRACT, consulte Reference for Oracle GoldenGate for Windows and UNIX.

Se os dados que o Extract precisam durante o processamento não forem retidos, nos logs online ou de backup, uma das seguintes ações corretivas poderá ser necessária:

• Talvez você precise alterar o Extract para capturar de um ponto posterior no tempo para o qual os dados de log estão disponíveis (e aceitar possíveis perdas de dados no destino). Isso pode ser feito com o comando ALTER EXTRACT.

• Talvez seja necessário ressincronizar as tabelas de origem e de destino e, em seguida, iniciar o ambiente do Oracle GoldenGate novamente.

Certifique-se de não usar opções de backup ou arquivamento que façam com que arquivos de arquivamento antigos sejam substituídos por novos backups no sistema de origem. Novos backups devem ser arquivos separados com nomes diferentes dos mais antigos. Isso garante que, se o Extract procurar um log específico, ele ainda existirá e também garante que os dados estejam disponíveis caso sejam necessários para um caso de suporte.

Ativação do Log de Transações

Use o comando ADD TRANDATA para marcar cada tabela de origem para replicação. Esse comando usa os procedimentos do sistema Sybase sp_setreptable e sp_setrepcol. ADD TRANDATA é a maneira recomendada de marcar as tabelas, em vez de usar esses procedimentos por meio da interface do banco de dados, mas o proprietário ou o administrador do sistema pode usá-las, se necessário. Para obter mais informações, consulte a documentação de Sybase.

Para marcar tabelas para replicação com ADD TRANDATA:

Execute o comando ADD TRANDATA para cada tabela a ser marcada. A sintaxe do comando ADD TRANDATA é:

ADD TRANDATA SCHEMA.TABLE LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED

LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED controla se os dados do LOB nunca são propagados, só são propagados se alterados (o padrão) ou sempre propagados. O LOBSIFCHANGED será o valor padrão se nenhuma opção de LOB for especificada. O comando ADD TRANDATA substituirá a definição de replicação LOB que está definida atualmente para a tabela.

Observação: Algumas opções do ADD TRANDATA ativam a opção ALWAYS_REPLICATE do sp_setrepcol. Se uma coluna LOB contiver um valor NULL e, em seguida, outra coluna na tabela for atualizada (mas não a LOB), essa LOB não será capturada mesmo que ALWAYS_REPLICATE esteja ativado.