Preparar Logs de Transação z/OS Db2 para o Oracle GoldenGate

Aprenda a configurar o log de transações Db2 para suportar a captura de dados pelo Oracle GoldenGate Extract.

O Oracle GoldenGate pode capturar dados de transação do Db2 dos logs ativos e arquivados. Siga estas diretrizes para configurar os logs para que o Extract possa capturar dados.

Para ativar a captura de alterações do Oracle GoldenGate para Db2 z/OS, consulte Ativar TRANDATA para Bancos de Dados Não Oracle

Ativar Acesso a Registros de Log

Ative a Classe 1 de Rastreamento do Monitor Db2 ("TRACE(MONITOR) CLASS(1) ") para que Db2 permita que o Extract leia o log ativo. O destino padrão de OPX é suficiente porque o Oracle GoldenGate não usa um destino.

Para iniciar o rastreamento manualmente

Faça log-on em Db2 como um usuário Db2 com o privilégio TRACE ou pelo menos a autoridade SYSOPR.
Emita o seguinte comando:

start trace(monitor) class(1) scope(group)

Para Iniciar o Rastreamento Automaticamente Quando Db2 for Iniciado

Execute um dos seguintes procedimentos:

Defina MONITOR TRACE como "YES" no painel de rastreamento de instalação DSNTIPN.
Defina 'DSN6SYSP MON=YES ' no job de instalação DSNTIJUZ, conforme descrito no Db2 UDB Installation Guide.

Observação: O ID de autorização principal, ou um dos IDs de autorização secundários, do executor do plano ODBC também deve ter o privilégio MONITOR2.

Dimensionar e Reter Logs

Mais dados são registrados quando as tabelas são definidas com DATA CAPTURE CHANGES do que quando são definidas com DATA CAPTURE NONE. Se qualquer uma das seguintes afirmações for verdadeira, talvez seja necessário aumentar o número e o tamanho dos logs ativos e arquivados.

Seus aplicativos geram grandes quantidades de dados Db2.
Seus aplicativos têm commits pouco frequentes.
Você espera interromper a Extração por longos períodos.
Sua rede não é confiável ou lenta.

Use o parâmetro do sistema DSN6LOGP MAXARCH no job de instalação DSNTIJUZ para controlar a retenção de log.

Reter dados de log suficientes para que o Extract possa começar novamente de seus pontos de verificação depois de interrompê-lo ou após uma interrupção não planejada. O processo Extract deve ter acesso ao log que contém o início da unidade de trabalho não confirmada mais antiga e a todos os logs depois disso.

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

Altere o Extract para capturar de um ponto posterior no tempo para o qual os dados de log estão disponíveis (e aceite possíveis perdas de dados no destino).
Ressincronize as tabelas de origem e destino e inicie o ambiente do Oracle GoldenGate novamente. Observação: A documentação da IBM faz recomendações para melhorar o desempenho das leituras de log. Em particular, você pode usar buffers de saída de log grandes, logs ativos grandes e fazer arquivos em disco.

Usar Logs de Arquivamento em Fita

O Oracle GoldenGate pode ler logs de arquivo Db2 em fita, o que degrada o desempenho. Por exemplo, o Db2 reserva arquivos compactados gravados para uma única tarefa de recuperação, fazendo com que o Extract não consiga ler uma fita de arquivo que está sendo usada para recuperar uma tabela até que a recuperação seja concluída. Você poderia usar o DFHSM ou uma ferramenta equivalente para mover os logs de arquivo perfeitamente entre o armazenamento DASD on-line e a fita, mas o Extract terá que aguardar até que a transferência seja concluída. Os atrasos no processamento do Extract aumentam a latência entre os dados de origem e de destino.

Se o Extract do Oracle GoldenGate puder ou estará lendo de uma fita, de uma fita física ou de uma fita virtual, é altamente recomendável garantir que os seguintes ZPARMs sejam considerados:

DESALTE

O parâmetro do subsistema DEALLCT determina o período de tempo durante o qual uma unidade de fita de leitura de arquivo deve permanecer sem uso antes de ser desalocada.

Atualização: opção 43 no painel DSNTIPB

DSNZPxxx: DSN6LOGP DEALLCT

A Oracle recomenda que DEALLCT seja definido como 0, 1 (1 segundo de atraso de realocação). O padrão é desalocar imediatamente. Isso impedirá que Db2 realoque imediatamente uma fita entre as leituras do Extract.

MAXRTU

O parâmetro do subsistema MAXRTU especifica o número máximo de unidades de fita dedicadas que podem ser alocadas para volumes de fita de log de arquivamento lidos simultaneamente.

Atualização: opção 43 no painel DSNTIPB

DSNZPxxx: DSN6LOGP MAXRTU

O padrão é 2 unidades de fita, mas deve ser definido para o número de processos esperados que podem ser lidos simultaneamente a partir de tape+1. Por exemplo, se houver 4 Extracts e 2 outros aplicativos que possam ser lidos de fitas, MAXRTU deverá ser pelo menos 7 (4 + 2 + 1).

Para obter o melhor desempenho e o mínimo de atrasos na leitura da fita, o Oracle GoldenGate Extract deve usar:

TRANLOGOPTIONS BUFSIZE 33554432

Essa será uma indicação para que o Extract leia até 32 MB por vez no log de transações, em vez do padrão de 1 MB por leitura. Essa definição não aumentará as alocações de memória que o Oracle GoldenGate usa em z/OS, ECSA (64 bytes) ou memória compartilhada de 64 bits (1MB). As alocações de memória transitórias Db2 podem aumentar enquanto o Extract lê os buffers grandes.

Além disso, no arquivo de parâmetros Extract, antes do parâmetro DBLOGIN, o seguinte também pode ser usado para fornecer a capacidade de ajustar ainda mais o buffer de comunicação TCP do driver Db2. Por exemplo:

SETENV(DB2SOSNDBUF='524288')
SETENV(DB2SORCVBUF='524288')

Isso informaria o driver Db2 a usar 512KB para os buffers de envio e recebimento. Outros valores poderiam ser usados e poderiam ser ajustados para cada instalação.

Descargas de Log de Controle

Ao ler o log de transações, o processo Extract não processa uma transação até capturar o registro de commit. Se o registro de commit estiver em um bloco de dados que não esteja cheio, ele não poderá ser capturado até que mais atividades de log sejam geradas para concluir o bloco. A API que o Extract usa para ler os logs só recupera blocos de dados físicos completos.

Um atraso no recebimento de blocos que contêm commits pode causar latência entre os dados de origem e de destino. Se os aplicativos não estiverem gerando registros de log suficientes para preencher um bloco, o Extract gerará registros de log emitindo instruções SAVEPOINT e COMMIT até que o bloco seja preenchido de uma forma ou de outra e seja liberado.

Em um grupo de compartilhamento de dados, cada chamada de API faz com que o Db2 descarregue os blocos de dados de todos os membros ativos, eliminando a necessidade de o Extract executar descargas.

Para evitar que o Extract execute descargas, use o parâmetro Extract TRANLOGOPTIONS com a opção NOFLUSH.