 |
| Bellacosa Mainframe com dicas para padawan cobol dominar o db2 |
🔥☕ O CAMINHO DO PADAWAN Db2 — COMO UM PROGRAMADOR COBOL JÚNIOR SOBREVIVE AO MUNDO REAL DOS BANCOS NO MAINFRAME ☕🔥
Tem uma coisa que quase nenhum curso ensina direito.
O problema de aprender Db2 no mainframe NÃO é decorar:
SELECT
FETCH
CURSOR
JOIN
Isso qualquer apostila faz.
O verdadeiro desafio é entender:
🚀 COMO O Db2 “PENSA”
Porque no ambiente bancário:
performance é dinheiro
CPU custa milhões
lock errado derruba sistema
SQL ruim gera guerra entre desenvolvimento e DBA
um tablespace scan pode parar um banco inteiro
E é aqui que nasce a diferença entre:
um programador COBOL comum
e um verdadeiro guerreiro do z/OS.
☕ O MAIOR ERRO DO PADAWAN COBOL
Todo iniciante chega no Db2 tentando programar como se estivesse lendo VSAM.
Faz:
loop
READ
IF
PERFORM
validação manual
cursor desnecessário
e transforma o Db2 num simples “arquivo sofisticado”.
🔥 Grave isso:
Db2 NÃO é VSAM.
Db2 é:
relacional
baseado em conjuntos
otimizado matematicamente
orientado a custo
controlado por estatísticas
🚀 O PROGRAMADOR MAINFRAME MODERNO NÃO PENSA EM LINHAS
Ele pensa em:
SETS
☕ PROCESSAMENTO RELACIONAL
O programador antigo pensa assim:
“Vou buscar linha por linha e processar.”
O programador Db2 sênior pensa:
“Como faço o Db2 processar tudo sozinho?”
Essa mudança mental vale OURO.
🔥 SQL NÃO É APENAS CONSULTA
O padawan acha que SQL é:
SELECT *
FROM CLIENTE
Mas Db2 é MUITO maior:
optimizer
locking
clustering
filter factors
parallelism
stage 1/stage 2
access paths
static SQL
dynamic SQL
utilities
EXPLAIN
E quando você entende isso…
você começa a dominar o ambiente bancário.
☕ O OPTIMIZER É O VERDADEIRO “CÉREBRO” DO Db2
No mainframe bancário:
ninguém lê bilhões de linhas “na força”
ninguém faz scan por diversão
ninguém quer CPU extra
O optimizer decide:
qual índice usar
qual join usar
se haverá sort
se haverá prefetch
se haverá paralelismo
🚀 E O QUE O OPTIMIZER USA?
Estatísticas.
RUNSTATS é praticamente:
“os olhos do optimizer”
Sem estatísticas:
access path piora
índice é ignorado
FF fica errado
CPU explode
☕ FILTER FACTOR — O SEGREDO QUE MUITOS IGNORAM
Pouca gente iniciante entende isso.
Mas FF muda TUDO.
🚀 Filter Factor
é:
a estimativa da porcentagem de linhas que satisfazem um predicado.
☕ Exemplo
WHERE DEPT = 'A00'
Se existem:
10 departamentos
Db2 estima:
1/10 = 0.1
Ou seja:
10% das linhas serão retornadas.
🔥 Quanto MENOR o FF:
MELHOR
Porque:
menos linhas
menos I/O
menos CPU
menos pages
menos lock
☕ O ERRO CLÁSSICO DO PADAWAN
WHERE COL <> 'X'
🔥 Péssimo FF.
Db2 entende:
“quase todas as linhas servem”
Então:
índice perde valor
scan aparece
CPU sobe
🚀 INDEX NÃO É MAGIA
Outro choque do iniciante.
Ter índice NÃO garante performance.
O optimizer escolhe:
usar
ignorar
combinar
fazer screening
fazer scan
dependendo:
FF
cardinalidade
clustering
custo estimado
☕ O MUNDO REAL DOS BANCOS
Em banco grande:
tabela pode ter bilhões de linhas
índice pode ter centenas de GB
um SQL ruim pode consumir milhares de MIPS
Por isso:
access path é assunto sagrado.
🔥 STAGE 1 vs STAGE 2
Esse conceito separa:
SQL eficiente
SQL sofrível
☕ Stage 1
Predicado processado cedo:
no Data Manager
usando índice
reduzindo linhas rapidamente
Mais rápido.
☕ Stage 2
Predicado processado depois:
mais CPU
mais linhas avaliadas
menos eficiência
🚀 Exemplo ruim
WHERE YEAR(DATA) = 2025
Função na coluna:
pode matar indexabilidade
virar stage 2
☕ Melhor abordagem
WHERE DATA BETWEEN '2025-01-01'
AND '2025-12-31'
🔥 LOCKING — O TERROR DOS BANCOS
Padawan geralmente aprende SELECT…
mas não aprende:
concorrência.
E no banco:
milhares de programas acessam a mesma tabela ao mesmo tempo.
☕ Lock errado gera:
timeout
deadlock
lentidão
aplicação travada
fila no CICS
caos operacional
🚀 LOCKSIZE
Db2 pode bloquear:
row
page
table space
☕ O perigo do PAGE LOCK
Uma página pode conter:
várias linhas
Então:
um lock pode bloquear muitos registros sem você perceber.
🔥 ISOLATION LEVEL
Outro tema CRÍTICO.
☕ CS — Cursor Stability
Mais comum no OLTP bancário.
Balanceia:
integridade
concorrência
☕ RR — Repeatable Read
Mais rígido.
Mais locks.
Mais contenção.
☕ UR — Uncommitted Read
O famoso:
dirty read
Excelente para:
relatórios
analytics
consultas não críticas
Péssimo para:
saldo bancário
movimentação financeira
😄
🚀 COMO EVITAR DEADLOCK
O curso mostrou algo IMPORTANTÍSSIMO:
Todos os programas devem atualizar na mesma sequência.
☕ Exemplo
Programa A:
CLIENTE → CONTA
Programa B:
CONTA → CLIENTE
🔥 Receita perfeita para deadlock.
🚀 ACCESS PATH — A ALMA DO Db2
Toda query possui um plano.
Db2 decide:
scan
index access
nested loop
merge scan
hybrid join
hash join
☕ TABLESPACE SCAN
Lê tudo.
Pode ser:
correto
ou desastre absoluto.
☕ INDEXED ACCESS
Busca seletiva.
Muito mais eficiente quando:
FF é baixo
índice é adequado
🚀 JOINS — O CAMPO DE BATALHA
Padawan normalmente só aprende:
INNER JOIN
Mas Db2 usa:
nested loop
merge scan
hybrid join
star join
dependendo:
tamanho
índices
cardinalidade
☕ MERGE SCAN JOIN
Excelente para:
tabelas grandes
sem índices úteis
dados ordenados
🔥 STATIC SQL vs DYNAMIC SQL
No banco:
isso é discussão séria.
☕ STATIC SQL
Pré-compilado.
Pré-otimizado.
Perfeito para:
CICS
OLTP
alta performance
☕ DYNAMIC SQL
Construído runtime.
Excelente para:
analytics
ferramentas
SQL variável
🚀 Por que bancos AMAM STATIC SQL?
Porque:
menos CPU
menos prepare
access path estável
melhor governança
☕ EXPLAIN — O RAIO-X DO OPTIMIZER
Se você não usa EXPLAIN…
você está programando no escuro.
🚀 EXPLAIN mostra:
índice usado
tipo de join
matching columns
prefetch
paralelismo
custo estimado
☕ PLAN_TABLE
É praticamente:
a Bíblia do tuning Db2.
🔥 UNION vs UNION ALL
Padawan frequentemente usa:
UNION
sem perceber:
Db2 faz SORT
remove duplicatas
aumenta CPU
🚀 UNION ALL
Muito mais rápido.
Use quando:
duplicatas não importam.
☕ FETCH FIRST
Outro segredo simples que salva CPU.
❌ Errado
SELECT *
FROM BIGTABLE
✅ Melhor
FETCH FIRST 10 ROWS ONLY
🚀 “PEÇA SOMENTE O NECESSÁRIO”
Essa é uma filosofia inteira do Db2.
☕ EVITE ESCREVER CÓDIGO
A aula falou algo brilhante:
“Avoid Writing Code”
🚀 O Db2 já sabe:
somar
converter
truncar
upper/lower
calcular datas
agregar
ordenar
paralelizar
Então:
use funções SQL
use set processing
use procedures
use triggers
☕ O COBOL NÃO DEVE FAZER O QUE O Db2 FAZ MELHOR
Essa frase muda carreiras.
🔥 O SEGREDO FINAL
No ambiente bancário:
o programador COBOL NÃO domina apenas COBOL.
Ele precisa entender:
SQL
optimizer
access path
locking
concurrency
CPU
I/O
clustering
statistics
utilities
Porque:
o verdadeiro programa executa dentro do Db2.
☕ O PADAWAN VIRA MESTRE QUANDO ENTENDE:
“SQL não é uma linguagem de acesso.
SQL é uma linguagem de processamento.”
🔥☕ Welcome to the real mainframe world, padawan.
