CrashSimulator: levando laboratórios de RMAN, Restore & Recovery para outro nível
Recentemente ministrei um Workshop de Boas Práticas de RMAN, Restore & Recovery em Oracle Database e, durante a preparação dos laboratórios, utilizei uma ferramenta que realmente me impressionou: o CrashSimulator.
Quem já ministrou treinamentos de Backup & Recovery sabe que existe um desafio interessante:
como criar falhas realistas, reproduzíveis e didáticas para que o aluno realmente precise investigar e recuperar o banco?
É relativamente simples montar um laboratório onde mostramos:
RMAN> BACKUP DATABASE;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
Mas isso não necessariamente prepara um DBA para uma situação real.
Em produção ninguém chega dizendo:
“Execute RESTORE DATAFILE 7 e depois RECOVER DATAFILE 7.”
O que normalmente recebemos é algo mais próximo de:
“O banco caiu.”
E agora?
É justamente nesse ponto que achei o CrashSimulator extremamente interessante.
O que é o CrashSimulator?
O CrashSimulator, desenvolvido por Francisco Muñoz Alvarez, é um projeto open source criado para possibilitar a construção de diferentes cenários de falha em ambientes Oracle Database.
A ideia é fantástica para quem trabalha com treinamento e laboratório: quebrar o ambiente de maneira controlada para depois entender como recuperá-lo.
Em vez de começar o laboratório sabendo exatamente qual comando executar, podemos começar pelo problema.
FALHA
↓
DIAGNÓSTICO
↓
IDENTIFICAÇÃO DO IMPACTO
↓
ESTRATÉGIA DE RECUPERAÇÃO
↓
RESTORE
↓
RECOVER
↓
VALIDAÇÃO
Essa abordagem muda completamente a experiência de estudar RMAN.
Backup é apenas metade da história
Uma frase que sempre gosto de reforçar quando falamos de RMAN:
Ter backup não significa necessariamente ter capacidade de recuperação.
Podemos possuir:
Full Backup;Incremental Level 0;Incremental Level 1;Archive Logs;Controlfile Autobackup;SPFILE;Recovery Catalog;FRA configurada.
Mas a pergunta realmente importante é:
você consegue utilizar tudo isso quando o banco apresenta uma falha?
E mais: quanto tempo você leva para identificar o problema e definir a estratégia correta de recuperação?
É aqui que entram conceitos extremamente importantes como:
RPO — Recovery Point Objective
Quanto de dados a organização aceita perder?
RTO — Recovery Time Objective
Quanto tempo o serviço pode permanecer indisponível?
Um bom DBA não precisa apenas conhecer os comandos do RMAN.
Ele precisa entender qual estratégia utilizar diante de cada cenário.
0. Fluxo de Utilização do Pacote
Este foi o fluxo que adotei para utilizar o CrashSimulator durante os laboratórios práticos:
┌─────────────────────────────┐
│ CONFIGURAÇÃO │
│ --show-config │
└──────────────┬──────────────┘
↓
┌─────────────────────────────┐
│ DISCOVERY │
│ --discover │
└──────────────┬──────────────┘
↓
┌─────────────────────────────┐
│ LISTAR CENÁRIOS │
│ --list │
└──────────────┬──────────────┘
↓
┌─────────────────────────────┐
│ ESTUDAR CENÁRIO │
│ --runbook <ID> │
└──────────────┬──────────────┘
↓
┌─────────────────────────────┐
│ DRY-RUN / CHECK │
│ --dry-run │
└──────────────┬──────────────┘
↓
┌─────────────────────────────┐
│ CRIAR A FALHA │
│ cenário escolhido │
└──────────────┬──────────────┘
↓
💥 DATABASE 💥
↓
┌─────────────────────────────┐
│ DIAGNÓSTICO │
│ Alert Log / Views / RMAN │
└──────────────┬──────────────┘
↓
┌─────────────────────────────┐
│ RESTORE & RECOVERY │
│ RMAN │
└──────────────┬──────────────┘
↓
┌─────────────────────────────┐
│ VALIDAÇÃO │
│ Banco / PDB / Aplicação │
└─────────────────────────────┘
E é exatamente aqui que a ferramenta começou a fazer muito sentido para mim durante o workshop.
1. Descobrindo o ambiente Oracle
Um dos recursos que gostei bastante foi o processo de discovery.
A ferramenta consegue mapear o ambiente Oracle e identificar características importantes que serão utilizadas posteriormente para determinar quais cenários podem ou não ser executados.
2. Quais cenários estão disponíveis?
Aqui conseguimos visualizar todos os cenários de disaster disponibilizados pela ferramenta.
CrashSimulator
│
├── Database
│
├── Datafiles
│
├── Tablespaces
│
├── Controlfiles
│
├── Redo
│
├── Archive Logs
│
├── ASM
│
├── RAC
│
├── Data Guard
│
└── PDB / Multitenant
A disponibilidade e os requisitos devem sempre ser conferidos na versão da ferramenta utilizada.
3. Entender o cenário
A ideia do parâmetro --runbook é extremamente interessante, pois permite entender melhor o objetivo do cenário, o componente afetado, o impacto esperado, os pré-requisitos, a estratégia de recuperação e os cuidados necessários.
Aqui também fica evidente o trabalho envolvido no desenvolvimento da ferramenta: definição dos cenários, validações, programação, testes e mecanismos de segurança. Parabéns aos desenvolvedores pelo excelente trabalho.
4. Validando se o cenário pode ser executado
Aqui estou dizendo:
Quero verificar se o cenário 88 pode ser utilizado contra a PDB1 neste ambiente, ou seja, posso → “executá-lo?”
No meu caso, o retorno foi: Result: NOT RUNNABLE (dry-run planning only)
Já no cenário 1, que simula a perda de um Controlfile, tivemos um retorno positivo: Result: RUNNABLE.
Aqui temos exemplos dos dois tipos de resposta. Na prática, avance somente quando o cenário estiver RUNNABLE. Caso contrário, analise e trate o motivo apresentado pela ferramenta antes de prosseguir.
Observe as seguintes informações:
Scenario 1: Loss of one
control file Group: Core
Scope: CDB/non-CDB
Impact: destructive
Requires: primary
Essas informações nos ajudam a compreender o escopo, os pré-requisitos e o impacto da ação antes de executá-la.
5. DRY-RUN: simule a ação antes de executá-la
Antes de provocar qualquer alteração no ambiente, podemos utilizar o parâmetro --dry-run.
Ele permite visualizar o que a ferramenta pretende executar sem efetivamente provocar a falha.
Esse, sem dúvida, é um dos recursos que mais gostei no CrashSimulator, principalmente quando estamos trabalhando com cenários destrutivos.
Já o --protect possui outra finalidade: preparar a proteção necessária para aquele cenário, quando suportada, antes de provocarmos a falha.
Em resumo:
--dry-run = visualizar/simular o plano
--protect = preparar a proteção
--scenario ... --execute = provocar a falha
6. Proteção — preparando o ambiente antes do cenário destrutivo
Após as confirmações, a ferramenta executa a etapa de proteção e registra as evidências nos logs de auditoria.
O comando solicita duas confirmações:
1ª confirmação PROTECT-30
2ª confirmação de segurança LAB-APPROVED
Neste caso, conseguimos confirmar que o CrashSimulator realizou o backup do Datafile 12, pertencente à tablespace USERS, utilizando uma TAG CSIM30_20260905_010344 específica. Dessa forma, temos um backup preparado para o processo de recuperação após a execução do cenário.
7. Agora sim: executando cenários
Depois do dry-run, para simular de fato a falha você usa o mesmo cenário com --scenario <ID> --execute.
Após as confirmações de segurança, o CrashSimulator apresenta/executa as ações planejadas para provocar o cenário de falha:
PDB: PDB1 Type EXECUTE-30 to continue: EXECUTE-30
Type LAB-APPROVED to confirm this environment is approved for destructive CrashSimulator execution: LAB-APPROVED
Em seguida, a ferramenta executa as ações previstas para reproduzir o cenário de falha:
rm -f /u01/app/oracle/oradata/ORADB/pdb1/users01.dbf mv /u01/app/oracle/oradata/ORADB/pdb1/users01.dbf \ /u01/app/oracle/oradata/ORADB/pdb1/users01.dbf.20260905_011400.crashsim.bak kill -9 24138
8. Recuperando o ambiente após a falha
Após a execução do cenário, nossa instância está DOWN. Vamos iniciá-la novamente e verificar o comportamento da PDB1.
Ao tentar abrir a PDB, encontramos exatamente a condição que queríamos reproduzir no laboratório: o Datafile 12 não está mais disponível no local esperado pelo Oracle.
Agora começa efetivamente o trabalho do DBA.
Com a falha identificada e o backup criado anteriormente durante a etapa de proteção, podemos iniciar o processo de Restore & Recovery via RMAN.
A falha ficou evidente: o Datafile 12 está indisponível e a PDB não pode ser aberta normalmente. Temos agora um cenário real de recuperação para resolver.
Agora vamos recuperar o ambiente do cenário de desastre que acabamos de provocar. E é justamente aqui que a etapa de proteção realizada anteriormente mostra seu valor: temos um backup válido para restaurar o Datafile.
Após realizarmos o Restore e o Recover do Datafile afetado, conseguimos abrir novamente a PDB com sucesso:
Onde está o verdadeiro valor do CrashSimulator?
Depois de utilizar a ferramenta num workshop, vejo o CrashSimulator não apenas como um “gerador de falhas”, mas principalmente como uma forma de construir laboratórios reproduzíveis de resiliência e recuperação.
Ele permite sair daquele modelo:
Aprenda o comando
↓
Execute o comando
↓
Laboratório concluído
para algo muito mais próximo da realidade:
Falha
↓
Investigue
↓
Entenda o impacto
↓
Decida a estratégia
↓
Recupere
↓
Valide
E isso muda bastante a forma de estudar RMAN.
Porque, quando um incidente acontece em produção, ninguém entrega para o DBA uma folha dizendo:
“Datafile 12 perdido. Execute RESTORE e RECOVER.”
O que normalmente chega é:
“O banco está com problema.”
A partir daí, é conhecimento de arquitetura, troubleshooting e experiência que fazem a diferença.
Onde encontrar o CrashSimulator
O CrashSimulator é um projeto open source, desenvolvido por Francisco Muñoz Alvarez e disponibilizado publicamente no GitHub.
Todo o código-fonte, documentação, instruções de instalação e atualizações do projeto podem ser encontrados no repositório oficial:
🔗 CrashSimulator — GitHub:
github.com/fmunozalvarez/crashsimulator
Recomendo consultar sempre o repositório oficial antes de iniciar os laboratórios, pois novos cenários, funcionalidades e melhorias podem ser adicionados ao projeto.
E fica a reflexão: “você apenas monitora se seus backups terminaram com sucesso ou testa regularmente sua capacidade de recuperação?”
Porque descobrir que o backup não é suficiente durante um incidente real é tarde demais.
Até o próximo laboratório, DBAs!
