# Performance Oracle não se decora - se entende (minha jornada do 27% até a aprovação)

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:

> ### **Exam 1Z0-084: Oracle Database 19c: Performance Management and Tuning**

**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:

![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/62ad5e05-7f63-47e6-bb4a-500eceb01791.png align="left")

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:

*   CBO e Otimizador
    
*   estatísticas
    
*   plano de execução
    
*   Advisors e Tenicas diversas
    

**…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%**

![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/d5ab187d-a6ae-4431-8989-533267e2b1a8.png align="center")

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**.

![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/379be9c5-fdd2-4ef9-bb59-25850e608d9a.png align="center")

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

![](https://cdn.hashnode.com/uploads/covers/69835211e3aecdfd224c568a/7b3febda-9167-4a8e-a2ca-53142e2006a6.png align="center")

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:
> 
> *   AWR
>     
> *   ADDM
>     
> *   ASH
>     
> *   Advisors (SQL Tuning, Segment, etc.)
>     
> 
> Isso é **extremamente cobrado** — e mais importante: é o que você usa no mundo real.
> 
> 🧠 **4\. Entenda o CBO de verdade (não superficialmente)**
> 
> *   Como o otimizador pensa
>     
> *   Como ele estima cardinalidade
>     
> *   Como escolhe planos
>     
> 
> 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:
> 
> *   Join methods
>     
> *   Access paths
>     
> *   Cardinalidade estimada vs real
>     
> *   Gargalos escondidos
>     
> 
> 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:
> 
> 1.  Identificar o problema
>     
> 2.  Coletar evidências
>     
> 3.  Analisar
>     
> 4.  Testar hipóteses
>     
> 5.  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.