Restore e recovery com RMAN

Conduz passo a passo o retorno correto com RMAN no momento da falha: 19 cenários — perda de datafile, SYSTEM/UNDO, tempfile, blocos corrompidos, online redo log, controlfile e spfile; restore completo, restore para outro diretório/ASM e para outro servidor; recuperação point-in-time (PITR de CDB ou PDB), Flashback Database, PITR de tablespace, recuperação de uma única tabela (RECOVER TABLE), PDB descartado; restore pela rede a partir do Data Guard (FROM SERVICE), restore apenas de archive logs, registro de backups movidos (CATALOG) e um ensaio que não grava dados (PREVIEW/VALIDATE). Cada cenário segue a ordem diagnóstico → rede de segurança → execução → verificação → novo backup e traz etapas separadas para instância única, Oracle Restart e RAC (recuperação em uma única instância com CLUSTER_DATABASE=FALSE). Trata de recuperar, não de fazer backup; para o plano de backup, consulte o guia "Estratégia de backup do Oracle".

Topologia: 1 servidor (instância única ou Oracle Restart) ou RAC; origem + destino no cenário de novo host

Cenários

• Ensaio: RESTORE … PREVIEW / VALIDATE (não altera nada) — Nada está quebrado; você quer ver, sem gravar dados, se os backups realmente bastam para uma recuperação (o banco de dados continua aberto). Também é o primeiro passo do teste mensal de restore e de quando você não tem certeza de qual cenário escolher.
• Backups movidos para outro diretório / RMAN não encontra o backup (CATALOG) — As backup pieces existem, mas o RMAN não as conhece (foram movidas, o NFS mudou, vieram de outro servidor): você recebe RMAN-06023/06025. O banco de dados continua aberto.
• Restaurar apenas os archive logs (RESTORE ARCHIVELOG) — Você precisa em disco dos archive logs de um intervalo de sequence específico para LogMiner, um gap no standby ou recovery manual; o banco de dados continua aberto e nenhum arquivo é sobrescrito.
• Perda/corrupção de um único datafile ou tablespace (o banco de dados continua aberto) — O banco de dados está aberto, apenas um datafile ou tablespace não pode ser lido (ORA-01157/01110/01116); todo o resto funciona. Se o arquivo pertence a SYSTEM/UNDO, escolha o cartão "SYSTEM ou UNDO"; se for um tempfile, o cartão "Tempfile"; se o arquivo abre mas alguns blocos estão corrompidos (ORA-01578), o cartão "Bloco corrompido".
• Há blocos corrompidos (ORA-01578, block media recovery) — Uma consulta retorna ORA-01578/ORA-26040, o backup para com ORA-19566 ou o VALIDATE encontrou blocos corrompidos; o restante do arquivo está íntegro. O banco de dados continua aberto e apenas os blocos corrompidos são reparados (Enterprise Edition; no SE2 o arquivo é restaurado). Se o arquivo inteiro não abre (ORA-01157), use o cartão "Datafile único".
• Perda de datafile do SYSTEM ou do UNDO (o banco de dados não abre) — O arquivo perdido ou corrompido pertence à tablespace SYSTEM ou UNDO: não pode ser colocado offline, o banco de dados (ou apenas aquele PDB, se for um arquivo de PDB) é fechado e restaurado em MOUNT. Não há perda de dados. Se for um arquivo de outra tablespace, o cartão "Datafile único" resolve sem fechar o banco de dados.
• Tempfile perdido ou corrompido (tablespace TEMP) — Operações de sort/hash retornam ORA-01157/ORA-01187/ORA-25153 e o arquivo é um tempfile (o número na mensagem de erro é maior que o valor de db_files, por exemplo data file 201). Não é necessário restore; um novo tempfile é adicionado e o banco de dados continua aberto.
• Online redo log perdido ou corrompido — No alert log aparece ORA-00313/00312 (não pode ser aberto) ou ORA-00327/00366/00367 (corrompido). Se um membro foi perdido ou o grupo está INACTIVE, o banco de dados continua aberto; se o grupo CURRENT foi perdido, são necessários restore + RESETLOGS e as últimas transações se perdem. A etapa de diagnóstico mostra o estado do grupo; escolha de acordo com ele.
• Todas as cópias do controlfile perdidas — Na fase MOUNT a instância não encontra ou não consegue ler o controlfile (ORA-00205/00202/00210); datafiles e redo estão íntegros. Se uma das cópias estiver íntegra, não é necessário restore (a etapa de diagnóstico mostra); se todas foram perdidas, ele é restaurado a partir do autobackup e o banco é aberto com RESETLOGS; como o online redo está íntegro, não há perda de dados.
• spfile perdido — O spfile foi excluído ou corrompido; a instância não sobe (ORA-01078/LRM-00109) ou está no ar, mas o arquivo não existe. Os datafiles não são tocados e não há perda de dados; se a instância ainda está no ar, também não há indisponibilidade.
• Restore completo no mesmo servidor (datafiles perdidos; controlfile e redo íntegros) — Todos ou quase todos os datafiles se foram, o controlfile e os online redo logs estão íntegros; o banco de dados é fechado e não há perda de dados. Se o disco/diretório antigo dos arquivos não pode mais ser usado, escolha o cartão "outro diretório"; se o controlfile também foi perdido, primeiro o cartão "controlfile"; se o servidor se foi por completo, o cartão "Restore para outro servidor".
• Disco perdido: restaurar o banco de dados para outro diretório / ASM (SET NEWNAME) — O disco ou disk group onde estão os datafiles não pode ser usado; controlfile e redo estão íntegros. Os arquivos são restaurados em um novo diretório ou disk group ASM, o banco de dados é fechado e não há perda de dados.
• Voltar a um horário / SCN (PITR, RESETLOGS) — DELETE/UPDATE/TRUNCATE errado ou versão defeituosa da aplicação: leva o banco de dados (ou apenas o PDB) a um momento do passado; todas as alterações posteriores a esse momento se perdem (RESETLOGS). Veja antes os caminhos mais restritos: uma tabela → "Recuperar uma única tabela", uma tablespace → TSPITR, flashback ativado → "Flashback Database" (não faz restore, é muito mais rápido).
• Retroceder com Flashback Database (restore point / SCN / horário) — O flashback está ativado ou existe um guaranteed restore point, e nenhum arquivo foi perdido: o banco é retrocedido em minutos sem restore (Enterprise Edition). RESETLOGS é necessário. Está ativado? SELECT flashback_on FROM v$database; → YES, ou uma linha com GUARANTEE_FLASHBACK_DATABASE = YES em v$restore_point.
• Voltar uma tablespace a um momento do passado (TSPITR) — A operação errada afetou apenas objetos de uma tablespace; o restante do banco de dados deve permanecer no presente (Enterprise Edition). A tablespace fica offline durante a operação e todos os objetos nela voltam ao momento de destino; se apenas uma ou duas tabelas foram afetadas, "Recuperar uma única tabela" reverte menos coisas.
• Recuperar uma única tabela (RECOVER TABLE, 12c+ Enterprise Edition) — Uma única tabela foi excluída ou danificada por engano; o restante do banco de dados deve ficar como está (12c+ Enterprise Edition). Se sofreu DROP sem PURGE, veja primeiro a recyclebin: FLASHBACK TABLE … TO BEFORE DROP leva segundos (a etapa de diagnóstico mostra).
• Trazer de volta um PDB descartado (DROP PLUGGABLE DATABASE) — Um PDB foi removido com DROP PLUGGABLE DATABASE. Se os arquivos ainda existem, ele é plugado de novo com o XML; se foram excluídos, é trazido do backup (21c+ com um único comando, 19c por meio de um CDB auxiliar). O CDB continua aberto.
• Restore para outro servidor (novo host, a partir do autobackup do controlfile) — O servidor se perdeu por completo ou será montado um ambiente de cópia/teste: o backup é restaurado em outro servidor (somente instância única, file system). A recuperação vai até o último archive log com backup; o que vem depois se perde; a cópia é aberta com RESETLOGS.
• Data Guard: obter o arquivo do standby/primary pela rede (FROM SERVICE) — Há Data Guard: você obtém o datafile perdido do primary a partir do standby, ou o standby atrasado ou o controlfile perdido do standby a partir do primary, sem usar backup pieces (12c+).

Antes de começar

• O incidente foi registrado e a equipe da aplicação foi informada: quando, o que aconteceu, qual mensagem de erro. Antes de iniciar a recuperação, se foi possível copiar o estado atual, a cópia foi feita (snapshot do servidor/disco ou ao menos uma cópia dos datafiles restantes, do controlfile e dos online redo logs); um passo errado pode piorar a situação.
• Os backups estão acessíveis: …… e, para os archive logs, a FRA …… estão montados e legíveis. Se os backups estão em fita/MML, o canal SBT e o agente do software estão funcionando.
• O DBID é conhecido (…). Se não for: a linha connected to target database: … (DBID=…) nos logs antigos do RMAN… ou o nome do arquivo de autobackup (…_cf_c-<DBID>-<YYYYMMDD>-<nn>)….
• O diretório auxiliary … existe e tem espaço livre equivalente a SYSTEM + SYSAUX + UNDO + a tablespace da tabela; o servidor tem ~2 GB de RAM livre para a instância temporária.
• …RECOVER TABLE ("Recovering tables and table partitions from RMAN backups") é um recurso da Enterprise Edition.…No Standard Edition 2 não existe RECOVER TABLE: em vez das etapas abaixo, restaure o backup em outro servidor ("Restore para outro servidor" + PITR) e extraia a tabela com Data Pump.…
• No servidor de destino, a mesma versão do Oracle e o mesmo nível de RU estão instalados apenas como software (opatch lspatches igual nos dois lados), o usuário/grupos oracle e a estrutura de diretórios são iguais aos da origem e há disco suficiente. No destino não há banco de dados rodando com o mesmo nome.
• A janela de manutenção/indisponibilidade foi aprovada… (neste cenário o banco de dados continua aberto; apenas os objetos envolvidos são afetados)…. O agendador de backup (cron/systemd/scheduler) foi parado até o fim da recuperação; caso contrário, um backup ou DELETE OBSOLETE pode rodar no meio do trabalho.
• O registro no Clusterware é conhecido: local do spfile e do arquivo de senhas, …instâncias e nós…estado do banco de dados… (srvctl config database -db …). Guarde esta saída antes da recuperação.
• …Block media recovery…Tablespace point-in-time recovery…Flashback Database… é um recurso da Enterprise Edition; no Standard Edition 2 o comando não funciona. O caminho SE2 deste cenário é mostrado separadamente nas etapas.
• Para a instância temporária (auxiliary), há no diretório …………… espaço livre equivalente a SYSTEM + SYSAUX + UNDO… + …… + PDB…, e o servidor tem memória livre de pelo menos o sga_target do destino (por padrão, o RMAN dá à instância temporária a mesma SGA).
• O Data Guard está pronto: o arquivo de senhas é o mesmo nos dois lados (mesma senha de SYS ou SYSBACKUP), o tnsnames.ora deste servidor tem as entradas … e …, COMPATIBLE ≥ 12.0. FROM SERVICE não funciona com autenticação do sistema operacional (rman target /); o RMAN se conecta com senha.
• Para o Flashback Database, a FRA está definida e o flashback logging está ativado (FLASHBACK_ON = YES) ou o momento de destino é um guaranteed restore point. Nenhum datafile está perdido/corrompido (o flashback não traz de volta um arquivo perdido) e, depois do momento de destino, nenhum datafile foi reduzido (shrink) nem o controlfile foi recriado.

Fases do guia

• Levantamento da situação — Levantar a situação · Levantar a situação · Verificar a recyclebin (se foi DROP, talvez não seja preciso backup) · Determinar o momento de destino
• O backup necessário existe? — Iniciar a instância em modo MOUNT · Iniciar a instância em modo MOUNT (srvctl) · Listar os backups · Localizar os arquivos de autobackup · Pré-visualizar a recuperação (PREVIEW) · Ler e validar as backup pieces (VALIDATE) …
• Recuperação de datafile / tablespace (online) — Colocar … offline · Restaurar e recuperar … · Colocar … online
• Restore completo (mesmo servidor) — Restaurar, recuperar e abrir o banco de dados · …Voltar ao modo cluster e iniciar o banco de dados pelo Clusterware…Reiniciar o banco de dados pelo Clusterware (Oracle Restart)…
• Voltar a um horário / SCN (PITR) — Fazer backup do estado atual antes de voltar · Colocar o banco de dados em MOUNT como instância única (srvctl) · Levar …o PDB…o banco de dados… de volta ao momento de destino · …Voltar ao modo cluster e iniciar o banco de dados pelo Clusterware…Reiniciar o banco de dados pelo Clusterware (Oracle Restart)…
• Recuperar uma única tabela (RECOVER TABLE) — Preparar o diretório auxiliary · Recuperar a tabela a partir do momento de destino · Comparar os dados recuperados
• Recuperação do controlfile — Verificar se resta alguma cópia do controlfile · Verificar se resta alguma cópia do controlfile (ASM) · Iniciar a instância em NOMOUNT (srvctl) · Restaurar o controlfile a partir do autobackup e abrir · …Voltar ao modo cluster e iniciar o banco de dados pelo Clusterware…Reiniciar o banco de dados pelo Clusterware (Oracle Restart)…
• Recuperação do spfile — Regravar o spfile a partir dos parâmetros em memória · Gravar o spfile no ASM a partir dos parâmetros em memória · Restaurar o spfile a partir do autobackup · Restaurar o spfile no ASM a partir do autobackup · Verificar se a instância foi iniciada com o spfile
• Servidor de origem: coletar informações e transferir os backups — Fazer um backup atualizado · Gravar o DBID, o autobackup e a lista de diretórios · Copiar os backups e o arquivo de senhas para o destino
• Servidor de destino: restore e recovery — Criar os diretórios · Adicionar a entrada no oratab · Restaurar o spfile e o controlfile e fazer o MOUNT · Registrar as backup pieces (CATALOG) · Restaurar, recuperar até o último archive log e abrir · Separar a cópia da origem (opcional)
• Diagnóstico: por que o RMAN não encontra o backup? — Ver o novo local das backup pieces · Listar os backups que o RMAN conhece e os que faltam
• Rede de segurança — Copiar o estado atual do controlfile
• Registrar os backups no RMAN — Registrar as pieces do novo diretório (CATALOG START WITH) · Limpar os registros do local antigo
• Verificação: os backups agora são encontrados? — Pré-visualizar a recuperação novamente · Ajustar o script de backup ao novo local
• Diagnóstico: quais archive logs são necessários e eles estão no backup? — Verificar se os archive logs estão em disco · Encontrar o backup dos archive logs e pré-visualizar
• Rede de segurança: diretório de destino e espaço — Preparar o diretório de restore
• Restaurar os archive logs — Restaurar os archive logs (RESTORE ARCHIVELOG)
• Verificação e limpeza — Listar os archive logs restaurados · Excluir os archive logs restaurados ao terminar
• Diagnóstico: é bloco corrompido? — Varrer o arquivo (VALIDATE) · Listar os blocos corrompidos e o objeto a que pertencem
• Rede de segurança: existem uma cópia íntegra e a cadeia de archive logs? — Pré-visualizar os backups do arquivo e a cadeia de recuperação
• Reparar os blocos corrompidos — Reparar os blocos corrompidos a partir do backup (RECOVER CORRUPTION LIST) · Standard Edition 2: restaurar o datafile · Corrigir blocos NOLOGGING (se houver)
• Verificação: os blocos estão íntegros? — Varrer o arquivo novamente · Buscar a causa raiz: erros de disco e de storage
• Diagnóstico: o arquivo é do SYSTEM ou do UNDO? — Iniciar a instância em modo MOUNT · Iniciar a instância em modo MOUNT (srvctl) · Confirmar que o arquivo é do SYSTEM ou do UNDO · Pré-visualizar e validar o backup necessário
• Rede de segurança — Copiar o estado atual do controlfile
• Restaurar o datafile do SYSTEM / UNDO — Fechar o PDB · Restaurar, recuperar e abrir o datafile · …Voltar ao modo cluster e iniciar o banco de dados pelo Clusterware…Reiniciar o banco de dados pelo Clusterware (Oracle Restart)…
• Diagnóstico: o arquivo perdido é um tempfile? — Ver os tempfiles e seu estado · Verificar o arquivo e o alert log
• Rede de segurança: verificação de espaço — Verificar se há espaço para o novo tempfile
• Adicionar um novo tempfile e remover o perdido — Adicionar um novo tempfile e remover o perdido
• Verificação — Verificar a tablespace temporária
• Diagnóstico: qual grupo, em que estado? — Ver o estado dos grupos de redo log