APRENDER. PRATICAR. EVOLUIR.1. Formular a pergunta antes de escolher o comando
Num fecho fictício de fundos, o job de backup terminou sem erro, mas a equipa não sabe se conseguirá recuperar no ambiente alternativo. Começa por separar quatro perguntas: o repositório conhece as peças, os canais conseguem alcançá-las, os blocos necessários são legíveis e o serviço recupera dentro do prazo? LIST descreve registos; CROSSCHECK atualiza a correspondência com os meios; validação lê conteúdo conforme a opção; um ensaio completo escreve ficheiros, aplica recuperação e verifica a aplicação. A evidência deve identificar base, container, conjunto de ficheiros, hora, canal e resultado. Um resultado verde com âmbito desconhecido não permite aceitar o serviço de fundos. Reserva também capacidade para a leitura de validação: não escrever ficheiros restaurados não significa ausência de I/O ou impacto operacional.
2. EXPIRED descreve disponibilidade observada
CROSSCHECK verifica o cabeçalho de backups em disco e consulta o catálogo do media manager para peças em fita. Não lê todos os blocos para demonstrar integridade. Se o caminho não estiver montado ou o canal SBT estiver mal configurado, uma peça pode aparecer EXPIRED sem ter sido destruída. Identifica a falha de acesso antes de eliminar registos. Depois de corrigir a disponibilidade, repete o crosscheck e confirma se o estado regressa a AVAILABLE. O comando não remove por si só os ficheiros nem os registos do repositório. UNAVAILABLE é outro estado, usado para impedir seleção; não deve ser confundido com o resultado de uma pesquisa física. No relatório, regista qual canal e tipo de dispositivo foram realmente verificados.
3. PREVIEW, cabeçalhos e conteúdo respondem a perguntas diferentes
RESTORE PREVIEW mostra a seleção baseada nos metadados; não lê as peças. Um preview pode continuar a listar uma peça cujo ficheiro foi movido depois do backup, até se atualizar o estado observado. VALIDATE HEADER acrescenta verificação dos cabeçalhos selecionados, sem escrever os ficheiros de destino. RESTORE VALIDATE lê os blocos dos backups escolhidos para o restauro, também sem escrever esses ficheiros. VALIDATE BACKUPSET permite selecionar explicitamente um conjunto, enquanto RESTORE escolhe segundo o pedido, os metadados e as opções. Se houver várias cópias, uma validação bem-sucedida pode ter usado outra peça. Conserva os handles e a seleção nos logs para saber o que foi efetivamente lido. A ausência de erro não prova leitura de todas as cópias existentes. No laboratório, um preview restrito por FROM TAG encontrou o datafile mas não uma cadeia elegível de archived logs. Os logs tinham backup com outra tag. A preparação foi corrigida para disponibilizar backups coerentes com a seleção; AVAILABLE, por si só, não significa elegível para qualquer comando. Conserva este tipo de falha, em vez de declarar recuperação demonstrada quando apenas um ficheiro foi listado.
4. Integridade física não é correção de negócio
Os controlos físicos procuram problemas como checksums inválidos ou estruturas de bloco inconsistentes. CHECK LOGICAL acrescenta verificações lógicas suportadas nos blocos; não demonstra que um pagamento tem o montante correto, que a aplicação respeitou uma autorização ou que todas as relações entre blocos foram verificadas. V$DATABASE_BLOCK_CORRUPTION e os registos de diagnóstico têm âmbitos que é necessário compreender. O valor MAXCORRUPT também altera o que pode ser tolerado durante um backup: sucesso com blocos marcados não é prova de ausência de corrupção. Perante um erro, delimita ficheiro, bloco, objeto e impacto antes de escolher reparação. A validação da aplicação deve acrescentar contagens, totais de controlo e transações representativas, com dados sintéticos no ensaio.
5. Desenhar um ensaio que deteta falsa confiança
Num laboratório isolado, cria um tablespace e uma pequena tabela de controlo, regista os valores e produz um backup com tag própria. Conserva o log e identifica a peça efetivamente criada. Simula indisponibilidade apenas dessa peça do laboratório, preservando uma forma de a repor. Compara preview, validação e crosscheck; depois repõe a peça e repete a verificação. Cada resultado responde a um âmbito diferente. Não uses este procedimento para mover backups de produção. Um segundo ensaio deve testar restauro e recuperação, com escrita posterior ao backup e reconciliação após aplicar redo. Mantém separados os resultados executados, os testes ainda planeados e as dependências ausentes, como fita, keystore ou ambiente de recuperação alternativo.
Uma peça deslocada pode continuar no preview, falhar na leitura e passar a EXPIRED após crosscheck. São observações diferentes, não resultados contraditórios.
Armadilhas comuns
Confundir AVAILABLE com integridade; apagar registos após falha de montagem; tratar preview como leitura; confundir CHECK LOGICAL com reconciliação financeira.
Tópicos relacionados: Backup e prova de recuperação · Recuperação seletiva e ensaios isolados · Patches, upgrades e handover
Escolhe a evidência pela pergunta: inventário, disponibilidade, integridade e recuperação têm provas próprias.
Referência: Validating Database Files and Backups · 1Z0-183 public objectives inspected 2026-09-30; revision date not published