Conceito e mecanismo
RESTORE repõe ficheiros a partir de uma cópia; RECOVER aplica alterações necessárias para alcançar o estado pretendido. Uma estratégia recuperável precisa de mais do que um job concluído: inclui datafiles, control file, configuração, redo, chaves e acesso ao destino. Autobackups e DBID ajudam a reconstruir contexto quando o repositório habitual não está disponível. O RPO descreve a perda de dados tolerada e o RTO o tempo tolerado até recuperação, mas escrever esses objetivos não demonstra que a implementação os cumpre. A preservação e acessibilidade da cadeia de recuperação devem ser verificadas para os pontos de falha relevantes, incluindo indisponibilidade do ambiente principal.
Aplicação guiada
Num ensaio fictício, CROSSCHECK confirma disponibilidade segundo o repositório, sem executar um restauro completo. Validação de conteúdo acrescenta leitura e verificações, mas continua a não medir todo o caminho operacional. Cronometra restauro, aplicação de redo, configuração dos serviços e reconciliação funcional. Regista o ponto de dados efetivamente recuperado. Se a FRA estiver cheia, identifica consumidores, retenção e restore points antes de libertar espaço. Expansão aprovada ou limpeza suportada pode proteger a operação; apagar ficheiros pelo shell pode destruir dependências e deixar o catálogo incoerente. O relatório do ensaio deve distinguir o que foi observado, o que falhou e o risco ainda não resolvido.
Ensaio: 20 minutos de cópia + 25 de recovery + 20 de validação excedem um RTO interno de 60 minutos.
Armadilhas comuns
CROSSCHECK como restauro; tamanho como integridade; tempo de cópia como RTO; apagar logs por idade.
Tópicos relacionados: Containers, serviços e recursos · Ciclo de vida e isolamento de PDBs · Recuperação seletiva e ensaios isolados
Demonstra a cadeia e mede o retorno útil do serviço.
Referência: Complete recovery and restore validation · 1Z0-183 public objectives inspected 2026-09-30; revision date not published