Se você acha que o Oracle apenas lê o seu SELECT e te entrega o dado, este post é para você. Aqui eu vou te revelar o que acontece entre o “Enter” e o resultado é uma verdadeira odisseia de algoritmos e estruturas de memória. Detalharei as etapas desse processamento, do Parsing à Execução.

1. SQL Parsing: A “Triagem” da Instrução

O parsing é o primeiro contato do banco com o seu código. O banco precisa quebrar sua instrução em estruturas de dados que ele consiga processar.

As Três Fronteiras do Parse:

• Sintaxe: O banco verifica se você não esqueceu uma vírgula ou errou palavras-chave, como escrever FORM no lugar de FROM.

SQL> SELECT * FORM employees;
SELECT * FORM employees
         *
ERROR at line 1:
ORA-00923: FROM keyword not found where expected

• Semântica: Aqui a checagem é de existência. A tabela existe? A coluna pertence a essa tabela? Você tem privilégios para vê-la?.

SQL> SELECT * FROM nonexistent_table;
SELECT * FROM nonexistent_table
              *
ERROR at line 1:
ORA-00942: table or view does not exist

• Shared Pool Check: Esta é a parte “mágica”. O Oracle aplica um algoritmo de hashing no seu SQL para gerar um SQL ID único. Ele busca na Library Cache (dentro da Shared Pool) para ver se esse ID já existe lá.

Hard Parse vs. Soft Parse (A luta pela performance)

• Hard Parse: Se o SQL for inédito, o banco precisa fazer todo o trabalho pesado: checar dicionário de dados, usar latches (travas de memória leves) para proteger as definições de objetos e gerar um plano do zero. Isso custa CPU e tempo.
  Dica: O Oracle sempre faz Hard Parse em instruções DDL.
• Soft Parse: Se o SQL já estiver lá, ele pula as fases de otimização e geração de row source e vai direto para a execução. É o paraíso da escalabilidade!

2. Otimização: O Cérebro do Custo

Durante o Hard Parse, o otimizador entra em cena apenas para instruções SELECT e DML (INSERT, DELETE, UPDATE). Ele analisa estatísticas e decide o caminho mais eficiente — o famoso Plano de Execução. O Oracle nunca otimiza um DDL puro, a menos que ele contenha um sub-DML (como um CREATE TABLE AS SELECT).

3. Row Source Generation: Criando o Programa Iterativo

O plano de execução ótimo chega ao gerador de Row Source. O resultado é uma árvore iterativa (o Row Source Tree). Cada nó dessa árvore é uma operação que entrega um conjunto de linhas para a próxima fase. Esse mapa mostra:

• A ordem de acesso às tabelas.
• O método de acesso (Índice vs. Full Scan).
• O método de Join (Hash Join, Nested Loops).

4. SQL Execution: Onde o “Filho Chora e a Mãe não Vê”

Aqui o motor SQL percorre a árvore gerada na fase anterior. Se o dado não estiver no Buffer Cache, ele busca no disco. Durante a execução, o banco aplica os locks e latches necessários para garantir a integridade.

DML vs. DDL: Processamentos Distintos

A Inteligência no DML: Consistência de Leitura (Multi-Version)

Quando você consulta dados, o Oracle garante a Consistência de Leitura. Se um SELECT demora e um UPDATE altera o bloco no meio do caminho, o Oracle usa os dados de UNDO para reconstruir o bloco como ele era no início da sua consulta. Você sempre vê o dado consistente com o “ponto no tempo” em que o cursor foi aberto.

A Complexidade no DDL: SQL Recursivo

O processamento de um DDL (como CREATE TABLE) é diferente porque ele altera o Dicionário de Dados. Para um simples comando de criação, o Oracle dispara dezenas de SQLs Recursivos nos bastidores para:

1. Validar permissões e quotas de tablespace.
2. Garantir que não existam nomes duplicados no schema.
3. Inserir linhas nas tabelas internas do sistema (o dicionário).
4. Gerar COMMITs automáticos antes e depois da execução.

Conclusão de DBA

Entender que um simples comando aciona engrenagens complexas como Library Cache, Undo segments e SQL recursivo é o que nos permite diagnosticar desde uma lentidão por falta de índice até uma contenção severa de Shared Pool por falta de bind variables.