Oracle Data Guard: operação diária e cenários de falha (19c / 23ai)

Runbook de operação diária e recuperação de falhas para uma configuração Data Guard (physical standby) já existente; para a instalação, use o guia de instalação do Data Guard. Se não tiver certeza do que fazer, comece por 'Verificação de status e atraso': o diagnóstico somente leitura indica o cenário certo (switchover planejado, failover, reinstate do primary antigo, gap de archive log, roll forward com RECOVER … FROM SERVICE, recriação do standby, snapshot standby, apply/read-only, modo de proteção/FSFO/observer, tarefas de datafile e redo log, backup RMAN a partir do standby). Todo cenário segue o padrão diagnóstico → rede de segurança → execução → verificação → pós-ação; traz os caminhos com broker (DGMGRL) e sem broker (SQL), com as diferenças entre instância única / Oracle Restart / RAC.

Topologia: Primary (instância única / Oracle Restart / RAC) + physical standby (instância única / Oracle Restart / RAC) + observer opcional

Cenários

• Verificação de status e atraso (está tudo em ordem?) — Somente leitura: configuração, transport/apply lag, gap de archive log, processos e alert log; nada é alterado. Se não tiver certeza do que fazer, comece aqui: o último passo indica o cenário certo com base na saída.
• Switchover planejado (trocar os papéis) — Primary e standby estão saudáveis e você quer trocar os papéis de forma planejada (manutenção, teste de DR, retorno dos papéis); não há perda de dados, a aplicação fica parada por alguns minutos. Enquanto você conseguir acessar o primary, escolha sempre esta opção para a transição de papéis.
• Primary perdido: failover para o standby — O primary está inacessível e não vai voltar (perda de servidor, storage ou site); o standby passa a ser o primary. Irreversível: em MaxPerformance os dados dos últimos segundos podem ser perdidos, e o primary antigo depois exige reinstate ou recriação. Se você ainda consegue acessar o primary, escolha switchover.
• Após o failover, trazer o primary antigo de volta como standby (reinstate) — Houve failover e o servidor do primary antigo voltou; se o Flashback Database estiver habilitado, ele vira standby do novo primary sem recriação. O novo primary continua aberto. Se o flashback estiver desabilitado ou a janela não for suficiente, o passo de diagnóstico direciona para a recriação.
• Gap de archive log: o standby está aguardando archive logs ausentes — v$archive_gap retorna linhas ou o alert log mostra mensagens de FAL/gap; o apply travou em uma sequence. Os bancos continuam abertos. Se os archive logs ausentes não existirem em lugar nenhum, uma opção no formulário muda para o caminho de roll forward.
• Standby muito atrasado ou sem archive logs: roll forward (RECOVER FROM SERVICE) — Os archive logs do gap não existem em lugar nenhum, operações NOLOGGING corromperam o standby ou o standby está dias atrasado; o standby é sincronizado de forma incremental a partir do primary, sem recriação (18c+).
• Recriar o standby do zero — Não é possível fazer reinstate (sem flashback) nem roll forward, ou os arquivos/control file do standby foram perdidos; o standby é removido e criado novamente com DUPLICATE. O primary continua aberto, mas fica sem proteção até o fim da recriação (se não houver outro standby).
• Converter para snapshot standby / reverter (cópia gravável para testes) — Você quer abrir o standby temporariamente em leitura e gravação para testes e depois descartar as alterações e voltar a physical standby; o primary não é afetado e o redo continua chegando, mas durante o snapshot este standby não está pronto para failover.
• Parar / iniciar o Redo Apply, trocar a instância de apply, abrir em read-only — Você quer parar ou reiniciar o MRP para manutenção, mover o apply para outra instância em um standby RAC ou abrir o standby para relatórios (aviso de licença do Active Data Guard).
• Modo de proteção, Fast-Start Failover e observer — Você quer alternar entre MaxPerformance / MaxAvailability / MaxProtection, habilitar ou desabilitar o FSFO ou gerenciar o observer.
• Adicionar datafile, redo log e standby redo log / arquivo UNNAMED — Um datafile ou redo log será adicionado ao primary, surgiu um arquivo UNNAMED no standby (ORA-01111/ORA-01274) ou faltam standby redo logs.
• Fazer backup RMAN a partir do standby — Você quer executar o backup RMAN no standby para tirar a carga de backup do primary e ajustar a política de exclusão de archive logs de acordo.

Antes de começar

• Em todos os servidores, o profile do usuário oracle define ORACLE_HOME=…, ORACLE_SID (…no RAC por nó …1, …2 …………) e PATH; sqlplus, rman…, dgmgrl… funcionam. A configuração foi montada com o guia de instalação do Data Guard ou equivalente (aliases TNS …, …, entradas estáticas _DGMGRL no listener, o mesmo arquivo de senhas).
• Foi verificado que os papéis correspondem às entradas: atualmente … é o primary e … é o physical standby. Caso contrário (ex.: houve um switchover antes), troque os nomes nas entradas.
• A senha do SYS é conhecida (transição de papéis, reinício da instância remota e RMAN FROM SERVICE exigem conexão autenticada por senha). A senha não contém @, /, " nem espaços.
• Licença: o Data Guard está incluído no Enterprise Edition. Usar o standby aberto com o apply rodando, block change tracking no standby e Far Sync exigem licença do Active Data Guard. Snapshot standby e abertura em read-only com o apply parado não exigem licença.
• A mudança está em uma janela de manutenção aprovada; as equipes de aplicação e de monitoramento foram avisadas… (as conexões ficam interrompidas por alguns minutos)….
• A decisão de failover foi tomada por uma pessoa autorizada; está garantido que o primary antigo não será aberto novamente (split-brain): o servidor está desligado, isolado da rede ou a instância está mantida em MOUNT.

Fases do guia

• Status: configuração, atraso e processos (somente leitura) — Mostrar a configuração do broker e a prontidão para transição de papéis · Verificar o lado do primary com SQL · Verificar o lado do standby com SQL · Procurar erros do Data Guard nos alert logs · Interpretar o resultado e escolher o cenário certo
• 1. Diagnóstico: está pronto para o switchover? — Verificar a prontidão (VALIDATE) · Verificar a prontidão (SWITCHOVER … VERIFY) · Verificar o atraso do standby
• 2. Rede de segurança — Salvar a configuração atual (primary) · Salvar a configuração atual (standby)
• 3. Execução: switchover — Switchover: tornar … o primary (broker) · Iniciar o switchover (primary → standby) · Abrir o novo primary (…) · Atualizar o papel no Clusterware (novo primary) · Abrir a outra instância (novo primary, nó …: …) · Montar o primary antigo como standby (…) …
• 4. Verificação — Verificar os novos papéis e a configuração · Verificar o apply e o atraso no novo standby
• 5. Pós-ação — Verificações de aplicação, jobs e monitoramento
• 1. Diagnóstico: o failover é realmente necessário? — Tentar acessar o primary uma última vez (a partir do standby) · Avaliar o estado do standby e a possível perda de dados · Mostrar o estado visto pelo broker (a partir do standby)
• 2. Rede de segurança e redo restante — Salvar as configurações atuais do standby · Montar o primary antigo e enviar o redo restante (FLUSH REDO) · Copiar manualmente os archive logs ausentes (sem broker, se possível)
• 3. Execução: failover — Failover: tornar … o primary (broker) · Parar o Redo Apply e executar o failover (SQL) · Abrir o novo primary (SQL) · Atualizar o papel no Clusterware (novo primary) · Abrir a outra instância (novo primary, nó …: …)
• 4. Verificação — Verificar o novo primary
• 5. Pós-ação — Fazer um backup completo do novo primary · Se o primary antigo voltar: NÃO O ABRA
• Serviço da aplicação (baseado em papel) — Definir e iniciar o serviço no lado … (Clusterware) · Definir o serviço no lado … (Clusterware) · Definir o serviço e o trigger de papel (sem Grid) · Configurar o descritor de conexão do cliente com dois endereços
• 1. Diagnóstico: o reinstate é possível? — Verificar o novo primary e o SCN da transição de papéis · Mostrar o status do broker (novo primary) · Montar o primary antigo e verificar a janela de flashback
• 2. Rede de segurança — Salvar o control file e os parâmetros do primary antigo
• 3. Execução: reinstate — Fazer o reinstate do primary antigo (broker) · Iniciar as outras instâncias (primary antigo, RAC) · Reverter com flashback e converter em physical standby (SQL) · Habilitar o destino … no novo primary (SQL) · Iniciar o Redo Apply e passar pelos registros da transição de papéis (SQL)
• 4. Verificação — Verificar a configuração · Verificar o apply no primary antigo (novo standby)
• 5. Pós-ação — Restaurar os papéis originais (opcional) e eliminar a causa raiz
• 1. Diagnóstico: onde está o gap, os archive logs existem? — Mostrar o gap e os processos no standby · Verificar a conexão FAL e o alert log (standby) · Os archive logs ausentes ainda estão no primary? · Os archive logs ausentes estão em um backup RMAN?
• 2. Rede de segurança — Verificar se há espaço na FRA do standby
• 3. Execução: obter e registrar os archive logs ausentes — Se os archive logs estiverem só em backup: restaurá-los no primary · Copiar os archive logs ausentes para o sistema de arquivos e enviá-los ao standby (primary) · Registrar os archive logs no standby · Reiniciar o Redo Apply (standby)
• 4. Verificação — Acompanhar o fechamento do gap (standby)
• 5. Pós-ação — Apagar as cópias temporárias · Eliminar a causa raiz
• 1. Diagnóstico: quão atrasado está o standby? — Mostrar o SCN e o estado do standby · Verificar operações NOLOGGING e o valor de COMPATIBLE no primary
• 2. Rede de segurança — Fazer backup do control file e do spfile do standby
• 3. Execução: roll forward do standby — Parar o Redo Apply (standby) · Montar o standby… (somente a instância 1)… · Roll forward do standby a partir do primary (RECOVER STANDBY DATABASE FROM SERVICE) · Iniciar as outras instâncias do standby · Verificar os standby redo logs e o status do flashback · Iniciar o Redo Apply (standby)
• 4. Verificação — Verificar se o atraso zerou
• 5. Pós-ação — Eliminar a causa raiz
• 1. Diagnóstico: recriar é realmente necessário? — Mostrar o estado da configuração e do primary
• 2. Rede de segurança — Guardar os arquivos de configuração do standby
• 3. Execução: remover e recriar — Remover o standby da configuração do broker · Suspender o destino do standby no primary (DEFER) · Remover o banco standby antigo · Limpar os arquivos restantes de broker, init e senhas · Renomear o init file antigo (nó standby …: …) · Recriar o standby com o guia de instalação …