# 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: ```plaintext 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. ```plaintext 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: ```plaintext ┌─────────────────────────────┐ │ CONFIGURAÇÃO │ │ --show-config │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ DISCOVERY │ │ --discover │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ LISTAR CENÁRIOS │ │ --list │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ ESTUDAR CENÁRIO │ │ --runbook │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ 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. ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/05306a7c-6ec6-49fb-925d-6d38fec42d4f.png align="center") ### 2\. Quais cenários estão disponíveis? Aqui conseguimos visualizar todos os cenários de disaster disponibilizados pela ferramenta. ```plaintext 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. ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/d7f588a3-08de-43fa-b798-7f3c6bccee6e.png align="center") ### 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. ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/1712c88b-f421-44b7-8d35-56104d263e16.png align="center") 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)*** ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/aeaef964-d145-43c8-bb7e-6fbf794b9a2e.png align="center") 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** ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/7c236705-a48b-4cbc-b003-e6835392b1aa.png align="center") ### 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. ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/4fbe7232-8292-4a04-a84f-ea0928e1c74b.png align="center") 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. ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/dfa3da7f-2e19-46c2-bce9-deb83bfb3323.png align="center") ### 7\. Agora sim: executando cenários Depois do `dry-run`, para **simular de fato a falha** você usa o mesmo cenário com `--scenario --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: > ```plaintext > 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 > ``` ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/3cef2814-6ee1-48a3-b635-0e32b45a2128.png align="center") ### **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**. ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/51326330-a27a-44a9-b54f-448bc2c22706.png align="center") > **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.** ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/d1b33b94-a622-4529-986f-66d2b1019619.png align="center") 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. ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/108aa290-7aa8-4941-a90f-783f323aec3c.png align="center") > **Após realizarmos o Restore e o Recover do Datafile afetado, conseguimos abrir novamente a PDB com sucesso:** ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/7894749d-19a9-41a1-b36d-7d447365afe7.png align="center") ![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/26c4f686-eb34-41ff-b57a-58a6d8c76ef4.png align="center") ### 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: ```plaintext Aprenda o comando ↓ Execute o comando ↓ Laboratório concluído ``` para algo muito mais próximo da realidade: ```plaintext 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](https://github.com/fmunozalvarez/crashsimulator/tree/main?utm_source=chatgpt.com) 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!**