Mostrar mensagens com a etiqueta run. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta run. Mostrar todas as mensagens

quinta-feira, 5 de novembro de 2009

☕ DB2 no IBM Mainframe: o que realmente acontece quando você executa um SQL

 

Bellacosa Mainframe explica como funciona uma query no Db2

DB2 no IBM Mainframe: o que realmente acontece quando você executa um SQL



🧠 Introdução – “É só um SELECT”… será mesmo?

Para quem está começando, parece simples:

SELECT * FROM CONTA WHERE SALDO > 1000;

Mas no IBM Mainframe, esse comando aciona uma cadeia de decisões complexas, refinadas por décadas de engenharia.
Antes de qualquer dado ser lido, o DB2 passa por um verdadeiro ritual técnico — silencioso, preciso e implacável.

Hoje vamos abrir a caixa-preta e entender, passo a passo, o que o DB2 faz quando recebe um SQL:

  1. Parse da query e validação de sintaxe

  2. Bind de tabelas e colunas

  3. Criação do executável

  4. Cálculo do plano de execução

  5. Execução do plano

Tudo isso antes do primeiro byte sair do disco.


🧩 Passo 1 – Parse da query: o DB2 vira professor de português

Parse the query and check for proper syntax

Neste primeiro momento, o DB2:

  • Analisa a sintaxe SQL

  • Verifica comandos, cláusulas e ordem

  • Garante que a query está gramaticalmente correta

Exemplo de erro clássico:

SELEC * FROM CLIENTE;

⛔ Resultado: erro imediato.
O DB2 não tenta adivinhar sua intenção.

Comentário Bellacosa
Mainframe não é Google.
Se escreveu errado, aprende rápido — na marra.


🧩 Passo 2 – Bind lógico: tabelas e colunas entram em cena

Bind the tables and columns

Aqui o DB2 pergunta:

  • Essa tabela existe?

  • Esse schema está correto?

  • Essa coluna pertence a essa tabela?

  • Você tem permissão para isso?

Exemplo:

SELECT CPF FROM ELJEFE.CLIENTE;

Se:

  • Schema errado

  • Coluna inexistente

  • Falta de autorização RACF

Falha antes da execução.

🧠 Curiosidade Bellacosa
Grande parte dos erros “objeto não encontrado” não é objeto inexistente —
é SQLID e schema mal resolvidos.


🧩 Passo 3 – Criar o executável: SQL vira código de verdade

Create an executable and hand it to the optimizer

Aqui acontece a mágica que muitos ignoram.

No DB2 z/OS:

  • SQL não é interpretado a cada execução

  • Ele é transformado em um executável

  • Esse executável é armazenado em um PACKAGE

💡 Em programas COBOL:

  • O BIND cria o package

  • O package faz parte de um PLAN

  • O programa executa o PLAN

Comentário El Jefe
No mainframe, SQL não é script descartável.
É artefato compilado, tratado com o mesmo respeito que código fonte.


🧩 Passo 4 – O Otimizador entra em ação

Calculate the optimal execution plan

Agora o DB2 pensa — muito.

O otimizador avalia:

  • Índices disponíveis

  • Estatísticas do catálogo

  • Volume de dados

  • Ordem de joins

  • Tipo de acesso (index scan, table scan, etc.)

Ele calcula:
👉 o plano de execução mais eficiente possível

🧠 Easter Egg técnico
O otimizador do DB2 z/OS é considerado um dos mais sofisticados do mundo, porque:

  • Precisa decidir rápido

  • Precisa acertar

  • E não pode errar em escala bilionária


🧩 Passo 5 – Execução do plano: agora sim, o dado anda

Run the execution plan

Somente agora:

  • O DB2 acessa tablespaces

  • Usa índices (ou não)

  • Aplica filtros

  • Retorna os dados

Importante:

  • O DB2 não executa o SQL

  • Ele executa o plano previamente calculado

Comentário Bellacosa
Você escreve SQL.
Quem manda é o plano de execução.


🧠 Visão Jedi – o fluxo completo

Tudo isso acontece nesta ordem:

SQL
 ↓
Parse (sintaxe)
 ↓
Bind lógico (tabelas / colunas / segurança)
 ↓
Criação do executável (PACKAGE)
 ↓
Otimizador calcula o plano
 ↓
Execução do plano

Se algo falhar em qualquer etapa…
👉 nada executa.


🧪 Dicas práticas Bellacosa Mainframe

✔ Erro de SQL geralmente é erro de modelagem ou schema
✔ Estatísticas ruins = plano ruim
✔ BIND mal feito vira problema eterno
✔ Não confunda SQL bonito com SQL eficiente
✔ EXPLAIN é seu melhor amigo


🥚 Curiosidades finais

  • Um mesmo SQL pode ter planos diferentes em ambientes distintos

  • ALTER de índice pode mudar performance sem mudar código

  • Em produção, o DB2 prefere estabilidade a “milagre”

  • Otimizador não é mágico — ele só decide com base no que você fornece


☕ Conclusão – SQL no Mainframe é disciplina

No IBM Mainframe:

  • SQL não é improviso

  • Execução não é tentativa

  • Performance não é sorte

Cada SELECT passa por um pipeline rigoroso, desenhado para não falhar.

No El Jefe, a verdade é simples:

Quem entende o caminho do SQL dentro do DB2, para de culpar o banco e começa a dominar o sistema.

Até o próximo café ☕
Bellacosa Mainframe