Preparar Tabelas para Processamento

Você deverá executar as tarefas a seguir para preparar as tabelas para uso em um ambiente do Oracle GoldenGate para Db2 z/OS.


Desativar Triggers e Constraints em Cascata

Desative triggers, exclua constraints em cascata e atualize constraints em cascata nas tabelas 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.

Garantir Exclusividade de Linha para Tabelas

O Oracle GoldenGate requer um 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 exista uma cláusula KEYCOLS 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 o Oracle GoldenGate não suporta em uma chave ou as que são excluídas da configuração do Oracle GoldenGate.

Observação: Se houver outras chaves não utilizáveis em uma tabela ou 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 mais extensa 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 nos parâmetros Extract TABLE e 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 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 nos parâmetros Extract TABLE e Replicat MAP. A chave especificada substituirá qualquer chave primária ou exclusiva existente que o Oracle GoldenGate localizar. Para obter mais informações, consulte Referência ao Oracle GoldenGate.

Tratar Tabelas com Colunas ROWID

Qualquer tentativa de inserção em uma tabela de destino que inclua uma coluna com um tipo de dados ROWID GENERATED ALWAYS (o padrão) falhará com o seguinte erro ODBC:

ODBC error: SQLSTATE 428C9 native database error -798. {DB2 FOR OS/390}{ODBC DRIVER}{DSN08015} DSNT408I SQLCODE = -798, ERROR: YOU CANNOT INSERT A VALUE INTO A COLUMN THAT IS DEFINED WITH THE OPTION GENERATED ALWAYS. COLUMN NAME ROWIDCOL.

Você pode executar um dos seguintes procedimentos para preparar tabelas com colunas ROWID a serem processadas pelo Oracle GoldenGate:

Para solucionar o problema ROWID GENERATE ALWAYS:

  1. Para a tabela de origem, crie uma instrução Extract TABLE e use uma cláusula COLSEXCEPT nessa instrução que exclua a coluna ROWID. Por exemplo:

    TABLE tab1, COLSEXCEPT (rowidcol);

    A cláusula COLSEXCEPT exclui a coluna ROWID de ser capturada e replicada na tabela de destino.

  2. Para a tabela de destino, certifique-se de que o Replicat não tente usar a coluna ROWID como chave. Isso pode ser feito de uma das seguintes maneiras:

    • Especifique uma chave primária na definição da tabela de destino.

    • Se não for possível criar uma chave, crie um parâmetro Replicat MAP para a tabela e use uma cláusula KEYCOLS nessa instrução que contenha quaisquer colunas exclusivas, exceto a coluna ROWID. O Replicat usará essas colunas como uma chave. Por exemplo:

      MAP tab1, TARGET tab1, KEYCOLS (num, ckey);

Mantendo Tabelas de Consulta Materializadas

Para manter a paridade entre as tabelas de consulta materializada (MQT) de origem e de destino, replique as tabelas base, mas não as MQTs. O banco de dados de destino mantém os MQTs com base nas alterações que o Replicat aplica às tabelas base.

Estas são as regras para configurar estas tabelas: