Oracle GoldenGate: operação diária e cenários de falha (Microservices 21c / 23ai)

Runbook de operação diária e recuperação de falhas para uma replicação GoldenGate Microservices já instalada (para a instalação, use o guia de instalação do GoldenGate). Se não tiver certeza do que fazer, comece por 'Verificação de saúde e de lag': o diagnóstico somente leitura leva você ao cenário certo — Extract e Replicat em ABEND (report, discard, erros OGG-xxxxx), inclusão de uma tabela com dados na replicação (SCN consistente + AFTERCSN), remoção de tabela, ressincronização de uma única tabela, limpeza de trails (Purge Trail), reposicionamento do Extract a partir de um SCN, upgrade de versão/patch e continuidade do Extract após switchover/failover do Data Guard na origem. Todo cenário segue a sequência diagnóstico → rede de segurança → aplicação → verificação.

Topologia: Servidor de origem (deployment de origem, Integrated Extract, Distribution Path) + servidor de destino (deployment de destino, Parallel Replicat)

Cenários

• Verificação de saúde e de lag (está tudo certo?) — Somente leitura: Service Manager e os microservices, INFO ALL, lag, STATS, lag do heartbeat, status do capture no banco de dados e ggserr.log; nada é alterado. Se não tiver certeza do que fazer, comece por aqui.
• Extract ABENDED (parou com erro) — O Extract na origem está ABENDED ou reinicia continuamente: a causa (conexão, archived log ausente, log mining, privilégios, disco) é identificada pelo erro OGG-xxxxx no arquivo de report, corrigida, e o Extract é reiniciado de onde parou. O banco de dados de origem não é afetado; o lag se acumula.
• Replicat ABENDED (não consegue aplicar no destino) — O Replicat no destino não conseguiu aplicar uma transação: a tabela, a operação e o erro são identificados pelos arquivos de report e de discard; os dados são corrigidos ou ignorados temporariamente com REPERROR, e o Replicat é reiniciado de onde parou. O destino permanece aberto; o lag se acumula.
• Adicionar uma tabela com dados à replicação (carga inicial + AFTERCSN) — Adiciona uma tabela existente que já contém dados a uma replicação em execução, sem indisponibilidade: ADD TRANDATA, expdp/impdp em um SCN consistente e um Replicat separado que aplica apenas as alterações desta tabela posteriores a esse SCN (AFTERCSN). As demais tabelas continuam fluindo.
• Remover uma tabela da replicação — A tabela deixará de ser replicada: TABLEEXCLUDE no Extract (ou remoção da linha TABLE), MAPEXCLUDE no Replicat e, se necessário, DELETE TRANDATA. Os processos são reiniciados rapidamente.
• Ressincronizar uma única tabela (resync) — Os dados de uma tabela no destino divergiram da origem (alteração manual, erro ignorado, carga inicial incompleta): a tabela é recarregada da origem em um SCN consistente e um Replicat temporário aplica as alterações posteriores a esse SCN. As demais tabelas não são afetadas.
• Arquivos de trail enchendo o disco: limpeza (Purge Trail) — O diretório de trails está crescendo ou o disco está prestes a encher: verifica-se quais arquivos estão sendo lidos, uma tarefa Purge Trail (equivalente ao PURGEOLDEXTRACTS do Classic) é definida com USECHECKPOINTS; em emergência, os arquivos já lidos são excluídos manualmente.
• Reposicionar o Extract em um SCN específico — Existe um SCN a partir do qual você quer que o Extract recomece (perda de trail, ponto de início errado, retrocesso no destino): ele é iniciado em um novo arquivo de trail com ALTER EXTRACT … SCN e ETROLLOVER. Os mesmos dados podem chegar ao destino uma segunda vez.
• Upgrade de versão / patch do GoldenGate (Microservices) — Migração para uma nova versão ou patch do GoldenGate: out-of-place (instalar um novo home e mover o Service Manager e os deployments para o novo home via REST) ou in-place com OPatch. Extract/Replicat param por pouco tempo; o rollback consiste em voltar para o home antigo.
• Manter o Extract em execução após switchover/failover do Data Guard na origem — Houve um switchover ou failover no banco de dados de origem; o Extract precisa se conectar ao novo primary e continuar a partir do seu checkpoint: verificam-se a conexão (credential alias/serviço), o status do capture, o HANDLEDLFAILOVER e uma possível divergência de dados.

Antes de começar

• GoldenGate Microservices instalado como no guia de instalação: na origem, Integrated Extract … e Distribution Path … no deployment …; no destino, Parallel Replicat … no deployment …; credential aliases ggsrc/ggsrc_pdb (origem) e ggtgt (destino).
• Você tem a senha do oggadmin dos dois deployments (os passos a solicitam; ela não é gravada nos scripts).… Para a carga inicial, a senha do SYSTEM nos dois PDBs e o directory OGG_DP (…) da instalação estão prontos.…
• O serviço systemd do Service Manager (OracleGoldenGate) está em execução nos dois servidores.
• Há um registro de mudança/janela de manutenção aberto: …Extract, Distribution Path e Replicat ficam parados durante o upgrade; o lag se acumula e é zerado ao fim do trabalho…quando o Extract é retrocedido, as mesmas transações podem chegar ao destino uma segunda vez; há um plano para colisões acordado com o responsável pela aplicação…as operações ignoradas com REPERROR ficarão faltando no destino; o responsável pelo negócio aprovou…os processos são reiniciados rapidamente….

Fases do guia

• Status: processos, lag e serviços (somente leitura) — Verificar o Service Manager e as portas dos microservices · Mostrar os processos de origem, o lag do Extract e o Distribution Path (origem) · Mostrar os processos de destino e o lag do Replicat (destino) · Medir o lag de ponta a ponta com o heartbeat (destino) · Verificar o status do capture e os archived logs necessários no banco de dados de origem (origem) · Examinar o log de erros (origem) …
• 1. Diagnóstico: por que o Extract parou? — Mostrar o status do Extract e o erro no report (origem) · Verificar o status do capture e os archived logs no banco de dados (origem)
• 2. Rede de segurança — Fazer backup dos arquivos de parâmetros, checkpoint e report (origem)
• 3. Aplicação: corrigir a causa e iniciar o Extract — Restaurar os archived logs ausentes a partir do backup RMAN (origem) · Corrigir a causa · Iniciar o Extract e monitorá-lo (origem)
• 4. Verificação e pós-ação — Verificar se o lag está zerando (origem) · Prevenir a causa raiz (origem)
• 1. Diagnóstico: em qual operação o Replicat parou? — Mostrar o status do Replicat, o report e o arquivo de discard (destino) · Comparar a linha com falha no destino e na origem
• 2. Rede de segurança — Fazer backup dos arquivos de parâmetros, checkpoint e report (destino)
• 3. Aplicação: corrigir os dados e iniciar o Replicat — Corrigir os dados no destino · Redirecionar temporariamente o erro para o discard: REPERROR (destino) · Iniciar o Replicat (destino)
• 4. Verificação e pós-ação — Verificar se o Replicat está avançando (destino) · Remover o REPERROR temporário (destino)
• 1. Diagnóstico: a tabela é adequada para replicação? — Examinar a tabela na origem (origem) · Mostrar o status do supplemental logging (origem) · Verificar a tabela no destino (destino)
• 2. Rede de segurança — Fazer backup dos arquivos de parâmetros e de checkpoint (origem) · Fazer backup dos arquivos de parâmetros e de checkpoint (destino) · Fazer backup da tabela de destino (destino)
• 3. Aplicação: carregar a tabela e iniciá-la com o seu próprio Replicat — Ativar o supplemental logging no nível da tabela (origem) · Excluir a tabela do Replicat principal: MAPEXCLUDE (destino) · Remover do Replicat principal a linha MAP explícita da tabela (destino) · Adicionar a tabela ao Extract (origem) · Adicionar um novo Replicat apenas para esta tabela (destino) · Exportar a tabela em um SCN consistente (origem) …
• 4. Verificação e pós-ação — Comparar o número de linhas (origem) · Verificar o número de linhas e o novo Replicat (destino)
• 1. Diagnóstico: onde a tabela está definida? — Mostrar onde a tabela aparece nos arquivos de parâmetros e o seu supplemental logging (origem) · Mostrar o mapeamento da tabela no Replicat (destino)
• 2. Rede de segurança — Fazer backup dos arquivos de parâmetros e de checkpoint (origem) · Fazer backup dos arquivos de parâmetros e de checkpoint (destino)
• 3. Aplicação: remover a tabela do Extract e do Replicat — Remover a tabela do Extract (origem) · Aguardar a aplicação dos registros restantes do trail (destino) · Remover a tabela do Replicat (destino) · Remover a linha MAP da tabela (destino) · Remover o supplemental logging no nível da tabela (origem)
• 4. Verificação — Verificar se a tabela não é mais processada (origem)
• 1. Diagnóstico: quanto espaço os trails ocupam e quem os lê? — Mostrar o diretório e os arquivos de trail (origem) · Mostrar o diretório de trails e a posição que o Replicat lê (destino)
• 2. Aplicação: definir a tarefa Purge Trail — Definir a tarefa Purge Trail no deployment de origem · Definir a tarefa Purge Trail no deployment de destino
• 3. Emergência: excluir manualmente os arquivos de trail já lidos — Excluir os arquivos de trail já lidos
• 1. Diagnóstico: é possível voltar ao SCN? — Mostrar a posição atual do Extract (origem) · Verificar o primeiro SCN do capture e os archived logs (origem)
• 2. Rede de segurança — Fazer backup dos arquivos de parâmetros, checkpoint e report (origem)
• 3. Aplicação: posicionar o Extract no SCN — Parar o Extract, posicioná-lo no SCN e iniciá-lo em um novo arquivo de trail (origem)
• 4. Verificação — Verificar se o Extract está avançando a partir da nova posição (origem) · Acompanhar colisões no destino (destino)
• 1. Diagnóstico: versão atual e preparação — Registrar a versão atual, os patches e os processos (origem) · Registrar a versão atual, os patches e os processos (destino)
• 2. Rede de segurança — Fazer backup dos diretórios do deployment e do Service Manager (origem) · Fazer backup dos diretórios do deployment e do Service Manager (destino)
• 3. Aplicação: parar os processos e fazer o upgrade — Parar os processos de forma limpa (origem) · Parar os processos de forma limpa (destino) · Instalar o novo GoldenGate home (origem) · Instalar o novo GoldenGate home (destino) · Mover o Service Manager e o deployment para o novo home (origem) · Aplicar o patch com OPatch (origem) …
• 4. Verificação — Iniciar os processos e verificar a versão (origem) · Iniciar os processos e verificar a versão (destino) · Rollback (se necessário)
• 1. Diagnóstico: o novo primary e a conexão do Extract — Verificar a função e o status do capture no novo primary (novo primary) · Mostrar o status do Extract e os credential aliases (origem)
• 2. Rede de segurança — Fazer backup dos arquivos de parâmetros, checkpoint e report (origem)