Hoje este artigo não é técnico, bem longe disso. Ele é inspirador, de alguém que luta todos os dias por condições melhores e que jamais nega uma boa briga.
Agora vou contar para vocês o que ninguém conta sobre o exame:
Sem dúvida este é o exame mais difícil da Oracle !!!!
Inicio do Desafio
Existem conquistas que você comemora.
E existem conquistas que te transformam.
Essa com toda certeza, está me transformou em um DBA Foda!!
Aqui eu entendi uma coisa que muitos ignoram:
Saber Oracle não é o mesmo que saber Performance e Tuning de verdade.
Você pode conhecer RMAN, Data Guard, SQL, Exadata ...
Mas quando entra em temas:
…ou você entende profundamente, ou você cai.
E eu caí, mas não desisti.
Virada de Chave
Na segunda tentativa, já não era mais ignorância.
📉 Segunda tentativa — 44%
Era um confronto interno. Eu entregava alta performance nos ambientes reais, mas na hora da prova, não conseguia transpor esse conhecimento para o papel.
Melhorou? Sim.
Mas ainda não era suficiente.
Foi aqui que a chave virou:
Eu parei de estudar para a prova e comecei a estudar como um especialista.
Comecei a:
simular cenários reais
testar comportamento do otimizador
analisar planos de execução na prática
questionar o “porquê” de cada decisão tomada pelo oracle
falar com especialistas da área, procurar entender a mentalidade de alguém que lida somente com performance no dia-a-dia
Não era mais sobre acertar questão.
Era sobre entender o mecanismo por trás, se não entender o porquê, você não aprende.
Então me dediquei pelo menos mais de 180H de montagem de laboratório, até que eu entendesse o porquê, item a item.
Aprovação
🔥 Terceira tentativa — 60% (APROVADO)
Não foi perfeito.
Foi no limite.
Mas dessa vez foi diferente.
Cada questão não era mais “chute técnico”.
Era decisão baseada em:
experiência prática
análise crítica
entendimento real
E quando veio o “Passed”, eu sabia:
Não foi sorte. Foi construção, foi determinação e muito estudo.
Eu não estudei para a prova, não decorei conceito, eu simplesmente entendi os PORQUÊS...
Temas Abordas no Exame
Minhas dicas de estudos:
🔧 1. Monte laboratório — e confronte teoria com prática o tempo todo
Não leia apenas. Teste. Quebre. Simule cenários reais.
Performance tuning só se aprende vendo o comportamento do banco na prática.
🤖 2. Use IA para acelerar seus cenários de teste
Gerar massa de dados, simular problemas, criar queries complexas…
A IA pode te economizar horas de setup e te colocar direto no que importa: análise e diagnóstico.
📊 3. Domine os Advisors e ferramentas internas
Estude profundamente:
Isso é extremamente cobrado — e mais importante: é o que você usa no mundo real.
🧠 4. Entenda o CBO de verdade (não superficialmente)
Se você entende isso, você deixa de reagir… e passa a antecipar o comportamento do banco.
📈 5. Aprenda a ler planos de execução como um especialista
Não é só olhar o custo.
É interpretar:
E principalmente: o porquê daquele plano existir.
🧪 6. Trabalhe com traces e diagnóstico profundo
10046, SQL Trace, tkprof…
Aqui você sai do “achismo” e entra no diagnóstico baseado em evidência.
⚙️ 7. Desenvolva sua própria metodologia de tuning
Pare de atuar no improviso.
Crie um processo:
Identificar o problema
Coletar evidências
Analisar
Testar hipóteses
Validar resultado
Isso muda completamente seu nível como DBA.
📚 8. Conheça profundamente as views V$ e GV$
Aqui está a verdade do banco.
Sessões
Esperas
Consumo de recursos
Histórico
Se você domina essas views, você enxerga o banco por dentro.
⏱️ 9. Entenda Wait Events (de verdade)
Não decore — interprete.
Por que está esperando?
Onde está o gargalo?
É CPU, IO, lock, rede?
Saber correlacionar wait events com cenários reais é um divisor de águas.
🧩 10. Entenda problemas físicos de dados
Migrated rows
Chained rows
E principalmente: o impacto disso na performance.
📐 11. Cardinalidade e seletividade são o jogo
Se você entende isso, você entende o CBO.
E se você entende o CBO…
você consegue influenciar o plano de execução de forma inteligente.
Conclusão
💡 O que essa jornada realmente me ensinou
Essa prova não mede só conhecimento.
Ela mede maturidade técnica.
Ela separa:
quem executa comando de quem entende comportamento
quando utilizar cada método, dependendo da situação ou cenário.
Tuning é um aprendizado contínuo: confronto constante de cenários e situações adversas que consolida conceitos, permite praticar e aperfeiçoar técnicas, transformando o DBA em referência.
Isto força você a sair do superficial e entrar no nível onde realmente importa, ser critico e fazer sempre a pergunta: 👉 por que o banco se comportou desta forma?
Não tive mentor nem fiz curso algum, mas mergulhei em diversas fontes e materiais — com destaque para a documentação oficial da Oracle. Meu foco foi confrontar conceitos e "meias-verdades", validando tudo na prática para solidificar o aprendizado.
🧠 A maior lição
Você não falha quando reprova.
Você falha quando: desiste ou contínua estudando do mesmo jeito
Eu precisei de 3 tentativas.
E cada uma delas foi necessária, não para me ensinar teoria, mas para me formar, me dar a visão que um especialista precisa frente a situações adversas.
