 |
| Bellacosa Mainframe mergulhando em performance e custo de query db2 no Mainframe |
🔥☕ “O MAINFRAME NÃO ESTÁ LENTO — SEU SQL É QUE ESTÁ INCENDIANDO A CPU DO IBM Z” 💾🚨
A Verdade Brutal que Todo Sysprog Júnior Descobre Quando Entra no Mundo Real do DB2 for z/OS
Por Bellacosa Mainframe
Existe um momento na vida de todo sysprog júnior…
aquele instante mágico, traumático e inesquecível…
quando ele percebe que:
💣 O problema não era o CICS.
💣 Não era o z/OS.
💣 Não era o storage.
💣 Nem o “mainframe velho”.
Era um único SQL.
Sim.
Uma linha aparentemente inocente:
SELECT *
FROM CLIENTES
WHERE CPF = '12345678900'
…destruindo CPU, queimando MIPS, elevando MSU, congestionando buffer pool e transformando a LPAR num inferno termonuclear digital.
Bem-vindo ao mundo real do DB2 for z/OS.
☕ O DIA EM QUE O PADAWAN DESCOBRE QUE CPU NO MAINFRAME = DINHEIRO
No universo distribuído moderno, quando falta performance, a resposta costuma ser:
sobe mais VM
coloca Kubernetes
aumenta cluster
escala horizontalmente
No mainframe?
HAHAHAHA.
Aqui a conversa é outra.
Aqui:
CPU = LICENSING
CPU = MLC
CPU = 4HRA
CPU = FATURA MILIONÁRIA
Um SQL ruim não deixa apenas o sistema “mais lento”.
Ele:
aumenta custo mensal
afeta SLA
derruba throughput
impacta batch
congestiona CICS
aumenta I/O
cria lock contention
vira incidente de produção
E o mais assustador?
Muitas vezes tudo começa com um programador dizendo:
“Mas é só um SELECT…”
🏛️ O MAINFRAME NÃO PENSA COMO VOCÊ
O sysprog júnior normalmente imagina que o DB2 executa SQL exatamente como foi escrito.
Não.
O DB2 é muito mais sofisticado.
Quando você envia um SQL, o DB2 chama uma entidade quase mística:
🔥 O OPTIMIZER
Ele analisa:
estatísticas
cardinalidade
índices
distribuição de dados
filtros
joins
sort
predicates
paralelismo
buffer access
E então decide:
“Qual será o caminho menos custoso para encontrar esses dados?”
Esse caminho se chama:
☕ ACCESS PATH
E é aqui que nascem:
os heróis
os vilões
os incêndios de CPU
e os DBA traumatizados.
💣 O TABLESPACE SCAN — O DEMÔNIO QUE ASSOMBRA PRODUÇÃO
Imagine uma tabela com:
900 milhões de linhas
14 TB
milhões de acessos diários
Agora imagine um SQL sem índice adequado:
SELECT *
FROM CLIENTES
WHERE CPF = '12345678900'
Sem índice…
o DB2 pode precisar ler:
página por página
bloco por bloco
segmento por segmento
Isso se chama:
🚨 TABLESPACE SCAN
Ou seja:
o DB2 sai varrendo o oceano inteiro para encontrar um peixinho.
Resultado:
GETPAGE explode
CPU dispara
synchronous I/O aumenta
elapsed cresce
batch atrasa
CICS sofre
E o sysprog júnior começa a ouvir palavras assustadoras no war room:
“buffer pool saturation”
“RID failure”
“class 2 CPU”
“dynamic statement cache”
“DSNZPARM”
“DSNDB07 lotado”
☕ O PODER SOBRENATURAL DE UM ÍNDICE
Agora veja a mesma consulta com índice:
CREATE INDEX IXCPF
ON CLIENTES (CPF)
O cenário muda completamente.
Agora o DB2:
acessa diretamente o valor
evita scan massivo
reduz GETPAGE
diminui I/O
baixa CPU
O que levava:
40 minutos
passa a levar:
2 segundos
Sem exagero.
No mundo IBM Z isso acontece TODOS OS DIAS.
🔥 O ERRO MAIS COMUM DOS PROGRAMADORES COBOL
Padawan…
grave isso na alma:
“O COBOL não mata CPU sozinho.”
“O SQL dentro dele mata.”
Um clássico infernal:
PERFORM VARYING WS-I FROM 1 BY 1
EXEC SQL
SELECT ...
END-EXEC
END-PERFORM
Parabéns.
Você acabou de criar:
☠️ O APOCALIPSE DO ROW-BY-ROW PROCESSING
Também conhecido como:
slow by slow
chatty SQL
cursor abuse
O programa funciona.
Mas em produção:
executa milhões de SQLs
congestiona DB2
aumenta context switch
explode CPU
O júnior acha:
“Funcionou no teste.”
O veterano olha e já sente dor física.
🧠 O MITO DO “SELECT *”
Outra heresia clássica:
SELECT *
Isso é praticamente um ritual proibido em ambientes críticos.
Porque talvez você precise:
2 colunas
Mas o DB2 entrega:
180 colunas
LOBs
dados inúteis
mais I/O
mais buffer
mais sort
mais CPU
O correto:
SELECT NOME, CPF
No mainframe:
eficiência é religião.
☕ RUNSTATS — O ALIMENTO DO OPTIMIZER
O optimizer do DB2 depende de estatísticas.
Sem elas:
ele fica cego.
RUNSTATS informa:
quantidade de linhas
distribuição
cardinalidade
clustering
seletividade
Sem RUNSTATS atualizada…
o DB2 toma decisões absurdas.
Exemplo real:
Tabela cresceu de:
10 milhões
para800 milhões linhas
Mas estatística continua antiga.
O optimizer acredita que a tabela ainda é pequena.
Escolhe nested loop inadequado.
Resultado:
💣 CPU 100x maior
🔥 EXPLAIN — O RAIO-X DA ALMA DO SQL
Veterano de DB2 não confia em “achismo”.
Ele usa:
EXPLAIN PLAN
Porque EXPLAIN revela:
índice usado
join method
scans
sorts
custo estimado
stage 1 / stage 2
parallelism
É literalmente:
a anatomia do pensamento do DB2.
☕ STAGE 2 — O CEMITÉRIO DA INDEXABILITY
Veja isso:
WHERE SUBSTR(NOME,1,3) = 'MAR'
Parece elegante.
Mas pode impedir uso eficiente de índice.
Outro clássico:
WHERE YEAR(DATA) = 2025
Muito bonito.
Muito moderno.
Muito destrutivo.
Melhor:
WHERE DATA BETWEEN '2025-01-01'
AND '2025-12-31'
Porque agora:
o índice pode respirar
o optimizer consegue navegar melhor
🔥 GETPAGE — A PALAVRA QUE FAZ DBA SUAR FRIO
No DB2 z/OS:
GETPAGE = acesso à página de dados.
Muito GETPAGE:
mais CPU
mais latch
mais memória
mais I/O
Veteranos monitoram:
GETPAGE
sync read
class 1
class 2
lock wait
RID list
como cardiologista monitorando ECG.
☕ “RÁPIDO” NÃO SIGNIFICA “BARATO”
Essa é uma das maiores lições do mainframe.
Às vezes:
elapsed time está ótimo
MAS:
CPU está monstruosa.
O usuário acha:
“Nossa, ficou rápido!”
O financeiro vê:
💸🔥💸🔥💸🔥
Porque no IBM Z:
CPU custa dinheiro real.
🤖 A ERA DA IA NO TUNING DB2
Hoje ferramentas modernas analisam:
SQLs problemáticos
regressão de access path
mudanças após REBIND
índices ausentes
scans perigosos
CPU anomalies
E algumas usam IA para:
prever degradação
sugerir rewrite
detectar padrões tóxicos
identificar SQLs assassinos
O futuro do tuning DB2 já começou.
🏛️ O QUE O SYSprog JÚNIOR PRECISA ENTENDER URGENTEMENTE
Mainframe não é:
“computador velho”
“COBOL antigo”
“legado ultrapassado”
Mainframe é:
engenharia extrema de throughput.
E DB2 for z/OS é:
um dos motores transacionais mais eficientes já criados pela humanidade.
Ele processa:
bancos
cartões
bolsa
aviação
seguros
governo
PIX
ATM
clearing financeira
Em escala absurda.
☕ A GRANDE VERDADE FINAL
O mundo moderno fala:
cloud
containers
microservices
IA
Mas nos bastidores…
existe um IBM Z executando milhões de transações por segundo…
e um DBA desesperado tentando descobrir:
🔥 “QUAL SQL ESTÁ QUEIMANDO A CPU?” 🔥
Porque no fim…
o COBOL processa o negócio…
o CICS coordena as transações…
mas:
