APRENDER. PRATICAR. EVOLUIR.1. Retenção é uma regra de recuperabilidade
REDUNDANCY define quantos backups completos ou de nível zero de cada ficheiro são mantidos pela política, não quantos dias de história foram demonstrados. Uma recovery window expressa o intervalo para o qual se pretende conservar capacidade de recuperação. Pode ser necessário um backup anterior ao início desse intervalo, juntamente com os incrementais e logs dependentes; eliminar pela idade do ficheiro ignora essa cadeia. REPORT OBSOLETE identifica candidatos segundo a política e os metadados. Não os elimina nem demonstra sozinho que os meios continuam acessíveis. Antes de uma eliminação autorizada, confirma os requisitos de recuperação, o âmbito, a política efetiva e exceções como backups KEEP. No serviço de fundos, uma regra de sete dias não substitui a decisão de negócio sobre retenção mais longa ou reconciliação.
2. Espaço livre e capacidade de recuperar
Perante pressão na recovery area, não trates EXPIRED e OBSOLETE como sinónimos. EXPIRED resulta de indisponibilidade observada pelo crosscheck; OBSOLETE resulta da política de retenção. DELETE EXPIRED trata registos correspondentes a peças indisponíveis e não é uma estratégia geral para libertar espaço de ficheiros válidos. DELETE OBSOLETE pode remover fisicamente backups que deixaram de ser necessários segundo a política aplicável. Arquivos de redo têm ainda dependências e regras de eliminação próprias, incluindo requisitos de ambientes standby quando configurados. Verifica também consumo por restore points e a taxa de geração de redo. Resolver o incidente significa recuperar margem operacional sem destruir a cadeia exigida, identificando o responsável pela decisão e medindo a projeção de novo enchimento. Confirma o comando exato: DELETE ARCHIVELOG ALL considera a política de eliminação de archived logs, não a política de retenção de backups. DELETE OBSOLETE usa a retenção de backups para determinar obsolescência e não usa a política de eliminação de archived logs para essa decisão. Não assumes que ambos aplicam automaticamente a união de todas as regras.
3. O backup é um ponto de partida
Considera uma tabela sintética com dois registos e total 350 no momento do backup. Depois é confirmado um terceiro registo de 150. Repor o datafile a partir do backup não demonstra que o total 500 foi recuperado: é necessário aplicar a recuperação correspondente, usando os dados de redo necessários. O plano deve identificar quais ficheiros estão afetados e o modo de acesso requerido, em vez de escolher imediatamente uma recuperação de toda a base. Num tablespace de aplicação isolado e elegível, restauro e recuperação do datafile podem limitar o âmbito. Não generalizes o procedimento a SYSTEM, undo ativo, bases sem ARCHIVELOG ou topologias diferentes. Confirma os pré-requisitos da versão e conserva um caminho de retorno autorizado antes de executar alterações em ambientes reais.
4. Aceitar a base e aceitar o serviço
O ensaio deve observar restauro, aplicação de recuperação, retorno do tablespace ao estado esperado e leitura dos valores de controlo. Um comando concluído não valida automaticamente os serviços, jobs, permissões e dependências externas. Acrescenta uma transação sintética representativa e confirma idempotência ou reconciliação antes de reexecutar batches financeiros. Mede o tempo desde o início do incidente simulado até à aceitação do serviço, incluindo preparação, obtenção de meios e validação. A duração isolada de RESTORE não é o RTO. Para RPO, compara o ponto efetivamente recuperado com o requisito, sem inferir perda zero de um backup diário bem-sucedido. Regista limitações como amostra pequena, armazenamento local, ausência de concorrência e mesmo host Docker.
5. Entregar evidência utilizável pela próxima equipa
O pacote de handover deve identificar versão e edição, DBID, container, ficheiro, tag, handles, configuração relevante e resultados por etapa. Guarda os scripts originais, saídas e critérios de aceitação com dados fictícios. Para uma base real, documenta separadamente quem obtém os meios, quem disponibiliza keystores, quais serviços podem voltar e que autorização é necessária para eliminar backups. Um teste local Free não comprova funcionalidades Enterprise, RAC, Data Guard ou recuperação em fita. A comparação de dois ensaios serve para detetar dependências escondidas e melhorar o runbook; não transforma automaticamente um ambiente pequeno num benchmark de produção. As lacunas devem permanecer explícitas, com owner e próxima verificação, mesmo quando a recuperação das linhas sintéticas foi demonstrada.
Backup: duas linhas, total 350. Depois: três linhas, total 500. A aceitação exige observar 500 após restauro e recuperação, além do estado operacional.
Armadilhas comuns
Eliminar só pela idade; usar DELETE EXPIRED como limpeza geral; confundir restauro com recuperação; medir RTO só pelo comando; equiparar Free local à topologia de produção.
Tópicos relacionados: Backup e prova de recuperação · Recuperação seletiva e ensaios isolados · Patches, upgrades e handover
Protege a cadeia necessária e aceita a recuperação pelos dados e pelo serviço, com limites de evidência explícitos.
Referência: Performing Complete Database Recovery · 1Z0-183 public objectives inspected 2026-09-30; revision date not published