 |
| Bellacosa Mainframe e o sql sem misterios no db2 for z/os |
☕ Um Café no Bellacosa Mainframe
SQL sem Mistérios no Db2 for z/OS
A Jornada Completa de uma Query no IBM Z — O Guia Definitivo do Programador COBOL Padawan Inspirado em Jornada nas Estrelas
"A lógica é o começo da sabedoria, não o fim."
— Sr. Spock
Introdução — Bem-vindo à USS Enterprise... digo... ao IBM Z
Imagine que você acabou de embarcar na USS Enterprise.
Você é um jovem cadete da Academia da Frota Estelar.
Seu trabalho não é pilotar a nave.
Também não é disparar phasers.
Sua missão é muito mais importante.
Você precisa descobrir como um simples pedido chega ao computador da nave, é analisado, processado e retorna em poucos milissegundos.
No universo Star Trek, esse computador responde perguntas como:
"Computador, localizar todos os oficiais Vulcanos da nave."
No mundo corporativo existe outro computador igualmente impressionante.
Ele atende pelo nome de IBM Z.
E seu cérebro de dados chama-se Db2 for z/OS.
Quando um programa COBOL executa um simples:
SELECT *
FROM CLIENTE
WHERE CPF='12345678900'
A maioria dos iniciantes imagina algo parecido com isto:
"O Db2 abriu a tabela, procurou o CPF e devolveu o registro."
Se fosse tão simples, este artigo terminaria aqui.
Mas...
Na realidade, entre o momento em que o programa envia o SQL e o momento em que os dados retornam, acontece uma verdadeira operação digna da Frota Estelar.
São dezenas de decisões inteligentes.
Milhares de estatísticas.
Análises matemáticas.
Escolha de estratégias.
Gerenciamento de memória.
Uso de caches.
Escolha de índices.
Controle de concorrência.
Tudo isso acontece quase instantaneamente.
Hoje vamos fazer uma viagem completa por essa jornada.
Prepare seu café.
Dr. Spock será nosso guia.
Capítulo 1 — O Computador Nunca Faz Apenas o Que Você Escreveu
Existe um dos maiores mitos entre iniciantes.
"Eu escrevi primeiro o SELECT."
Então ele executa primeiro.
Errado.
Na verdade, o Db2 praticamente ignora a ordem em que você escreveu.
Ele interpreta a intenção da consulta.
Depois decide sozinho como obter o resultado da forma mais eficiente possível.
É exatamente como Spock faria.
Se Kirk diz:
"Chegue até Vulcano."
Spock não pergunta:
"Qual estrada devo pegar?"
Ele calcula:
combustível
gravidade
buracos negros
campos de dobra
rotas inimigas
economia de energia
O destino é o mesmo.
O caminho muda.
O Db2 pensa exatamente assim.
Capítulo 2 — A Ponte de Comando do Db2
Imagine a ponte da Enterprise.
Cada oficial possui uma função.
No Db2 também.
| Oficial | Componente Db2 |
|---|---|
| Capitão Kirk | Aplicação COBOL |
| Sr. Spock | Optimizer |
| Scotty | Buffer Manager |
| Uhura | SQL Parser |
| Sulu | Access Path |
| Chekov | Index Manager |
| Computador | Buffer Pools |
| Engenharia | Disk Storage |
O COBOL faz a pergunta.
Spock decide a melhor estratégia.
Scotty garante que tudo funcione.
O computador responde.
Capítulo 3 — A Missão Começa: EXEC SQL
Tudo começa aqui.
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE CPF=:WS-CPF
END-EXEC.
Parece simples.
Mas isso ainda nem é SQL.
O COBOL sequer entende SQL.
Quem entende é o Pré-compilador.
Capítulo 4 — O Tradutor Universal
Antes da compilação acontece algo exclusivo do mundo Mainframe.
O famoso:
Pré-Compiler.
Ele encontra cada bloco EXEC SQL.
Substitui por chamadas internas.
Gera o famoso:
DBRM
(Database Request Module)
Este DBRM será utilizado posteriormente no BIND.
Curiosidade:
Oracle não trabalha assim.
SQL Server também não.
Este é um dos diferenciais históricos do Db2 z/OS.
Capítulo 5 — O Conselho Vulcano: BIND
Aqui mora uma das maiores diferenças entre o Db2 e praticamente todos os bancos relacionais.
O comando:
BIND PACKAGE
é como uma reunião do Alto Conselho Vulcano.
O Db2 olha para a consulta e pensa:
"Se esta SQL for executada milhões de vezes, qual será o melhor caminho?"
Ele cria um PACKAGE, contendo o plano de acesso ideal para aquele momento.
É aqui que nasce o famoso Access Path.
Capítulo 6 — O Dr. Spock Analisa as Probabilidades
Imagine duas tabelas.
CLIENTES
50 milhões de linhas.
ESTADOS
27 linhas.
Você faria o JOIN começando por qual?
Até um cadete responderia:
ESTADOS.
Mas...
Como o Db2 sabe disso?
A resposta chama-se:
RUNSTATS.
Capítulo 7 — RUNSTATS: Os Sensores de Longo Alcance
Os sensores da Enterprise informam:
quantas naves existem;
velocidade;
distância;
massa.
O RUNSTATS faz exatamente isso.
Ele informa ao Optimizer:
quantidade de linhas;
cardinalidade;
distribuição;
frequência;
seletividade;
clustering;
número de páginas;
estatísticas dos índices.
Sem RUNSTATS...
O Optimizer fica praticamente cego.
E um Spock sem sensores toma decisões muito piores.
Capítulo 8 — Álgebra Relacional: O Idioma Secreto do Computador
Depois que o SQL é validado, ele deixa de existir como texto.
Internamente transforma-se em Álgebra Relacional.
Por exemplo:
SELECT NOME
FROM CLIENTES
WHERE CIDADE='SP'
vira algo semelhante a:
σ Cidade='SP'
↓
π Nome
↓
CLIENTES
Ou seja:
primeiro seleciona.
Depois projeta.
O SQL desaparece.
Nasce um plano matemático.
Capítulo 9 — O Optimizer: O Verdadeiro Sr. Spock do IBM Z
Se existe um personagem que representa perfeitamente o Optimizer...
é o próprio Spock.
Ele nunca trabalha por emoção.
Somente lógica.
Ele calcula:
custo de CPU;
custo de I/O;
uso de Buffer Pools;
seletividade dos índices;
paralelismo;
volume esperado;
quantidade de páginas;
custo de SORT;
bloqueios.
Depois escolhe o menor custo possível.
Nem sempre será o caminho mais curto.
Será o mais eficiente.
Capítulo 10 — A Ordem Lógica da Consulta
Agora chegamos ao famoso diagrama.
Embora escrevamos:
SELECT
FROM
JOIN
ON
WHERE
GROUP BY
HAVING
ORDER BY
FETCH FIRST
O Db2 raciocina assim:
FROM
↓
JOIN
↓
ON
↓
WHERE
↓
GROUP BY
↓
HAVING
↓
SELECT
↓
ORDER BY
↓
FETCH FIRST
Mas cuidado.
Isto ainda não representa a ordem física.
Ela continua sendo decidida pelo Optimizer.
Capítulo 11 — O Access Path: A Rota Estelar
Aqui está o segredo.
O Db2 pode resolver exatamente a mesma SQL de dezenas de maneiras diferentes.
Ele escolhe entre:
Table Space Scan;
Index Scan;
Index Only Access;
List Prefetch;
Dynamic Prefetch;
Sequential Detection;
Nested Loop Join;
Merge Scan Join;
Hybrid Join;
Star Join;
Parallelism;
Materialized Query Table;
Sparse Index.
É como escolher diferentes rotas pelo Quadrante Alfa.
O destino é igual.
O caminho muda.
Capítulo 12 — O Buffer Pool: O Scotty da Memória
Scotty sempre dizia:
"Captain, I'm giving her all she's got!"
O Buffer Pool faz exatamente isso.
Antes de acessar o disco...
Ele pergunta:
"Essa página já está na memória?"
Se estiver...
Não existe I/O.
A resposta vem em microssegundos.
Grande parte do desempenho do Db2 depende da eficiência dos Buffer Pools.
Capítulo 13 — Os Predicados Stage 1 e Stage 2
Aqui existe uma armadilha clássica.
Observe:
WHERE YEAR(DATA)=2026
Parece bonito.
Mas destrói o uso do índice.
Muito melhor:
WHERE DATA BETWEEN
'2026-01-01'
AND
'2026-12-31'
No primeiro caso:
Stage 2.
No segundo:
Stage 1.
O primeiro costuma obrigar o Db2 a avaliar linha por linha.
O segundo permite filtrar diretamente pelo índice.
Dica Bellacosa: sempre que possível, escreva predicados que possam ser avaliados durante o acesso aos dados. Essa é uma das otimizações mais valiosas para quem desenvolve em COBOL com Db2.
Capítulo 14 — EXPLAIN: A Caixa-Preta da Enterprise
Nenhum engenheiro sério tenta descobrir um problema apenas olhando para a nave.
Ele consulta os sensores.
No Db2 fazemos exatamente isso.
Utilizamos:
EXPLAIN
Ele revela:
qual índice foi escolhido;
ordem dos JOINs;
tipo de acesso;
custo estimado;
necessidade de SORT;
paralelismo;
número estimado de linhas.
Nunca adivinhe.
Sempre consulte o plano.
Capítulo 15 — Locks: O Controle de Segurança da Federação
Enquanto tudo acontece...
O Db2 protege os dados.
Existem diversos tipos de bloqueio:
IS (Intent Share)
IX (Intent Exclusive)
S (Share)
U (Update)
X (Exclusive)
SIX (Share with Intent Exclusive)
Além disso, os níveis de isolamento (UR, CS, RS e RR) determinam o equilíbrio entre concorrência e consistência. Em sistemas bancários e de cartões de crédito, essa gestão é essencial para evitar leituras incorretas, perdas de atualização e conflitos entre milhares de transações simultâneas.
Capítulo 16 — Paralelismo: Quando a Enterprise Usa Toda a Tripulação
Em grandes consultas analíticas, o Db2 pode dividir o trabalho.
Imagine:
CPU 1 lê uma partição.
CPU 2 lê outra.
CPU 3 realiza o JOIN.
CPU 4 faz a agregação.
No IBM Z isso acontece utilizando múltiplos processadores e, em muitos cenários, explorando zIIPs para determinadas cargas elegíveis, reduzindo o impacto sobre os CPs tradicionais.
Capítulo 17 — Quando Fazer REBIND?
Imagine que a Enterprise recebeu um novo motor de dobra.
Você continuaria usando os cálculos antigos?
Claro que não.
No Db2 acontece o mesmo.
Após mudanças significativas, como:
criação de índices;
remoção de índices;
crescimento expressivo das tabelas;
execução de RUNSTATS;
alterações na distribuição dos dados;
vale analisar um REBIND PACKAGE ou REBIND PLAN, permitindo que o Optimizer recalcule um novo Access Path mais eficiente.
Capítulo 18 — O Programador COBOL Jedi... ou Vulcano?
Existe um momento em que o programador deixa de escrever SQL "que funciona".
E começa a escrever SQL "que escala".
Ele passa a pensar:
Meu predicado usa índice?
Meu JOIN é seletivo?
O EXPLAIN confirma minha hipótese?
As estatísticas estão atualizadas?
O SORT pode ser eliminado?
Estou lendo mais linhas do que preciso?
O FETCH FIRST pode reduzir trabalho?
Existe uma forma mais eficiente de escrever esta consulta?
Esse é o verdadeiro salto de maturidade.
Easter Egg Bellacosa ☕
No episódio "The Ultimate Computer", a Enterprise recebe o computador M-5, projetado para tomar decisões automaticamente.
No começo, tudo parece perfeito.
Depois surgem consequências inesperadas.
O Db2 Optimizer lembra um pouco essa história.
Ele toma decisões sozinho, mas depende da qualidade das informações que recebe.
Se as estatísticas estiverem desatualizadas, um índice importante não existir ou o modelo físico estiver inadequado, até um excelente otimizador poderá escolher um plano ruim.
A diferença é que, felizmente, o Optimizer não tenta assumir o comando da Enterprise nem entra em combate por conta própria.
Curiosidades
O Db2 for z/OS está entre os bancos de dados com os otimizadores mais sofisticados do mercado, evoluindo continuamente desde a década de 1980.
Um único
SELECTpode gerar dezenas de operações internas invisíveis ao desenvolvedor.Em ambientes de missão crítica, o mesmo SQL pode ser executado milhões de vezes por dia, tornando pequenas otimizações responsáveis por economias enormes de CPU e tempo.
Muitos problemas de desempenho atribuídos ao COBOL, na verdade, são consequência de SQL mal escrito ou de um plano de acesso inadequado.
Conclusão — A Lógica é a Maior Aliada do Programador
Ao final desta jornada, descobrimos que uma instrução SQL percorre um caminho muito maior do que imaginávamos. Ela nasce no programa COBOL, passa pelo pré-compilador, gera um DBRM, é ligada a PACKAGEs e PLANs durante o BIND, tem seu plano analisado pelo Optimizer, consulta estatísticas produzidas pelo RUNSTATS, escolhe um Access Path, utiliza Buffer Pools, controla bloqueios, decide estratégias de JOIN e somente então retorna os dados solicitados.
Para um programador COBOL Padawan, compreender essa sequência é um divisor de águas. Você deixa de enxergar o Db2 como uma simples "caixa-preta" e passa a entendê-lo como um verdadeiro computador da Frota Estelar: um sistema que utiliza lógica, estatística e otimização para tomar a melhor decisão possível a cada consulta.
Como diria o Sr. Spock, "A lógica é o começo da sabedoria, não o fim." No universo do IBM Z, essa lógica está presente em cada SELECT, em cada índice e em cada plano de acesso. Quanto melhor você compreender esse funcionamento, mais preparado estará para construir aplicações COBOL rápidas, escaláveis e confiáveis — dignas de uma missão de cinco anos explorando as fronteiras da computação corporativa.
