 |
| Bellacosa Mainframe em tuning DB2 |
🔥☕ DB2 PERFORMANCE TUNING — O “MOTOR INVISÍVEL” DO MAINFRAME IBM Z
Como um SYSprog/DBA Padawan Aprende a Domar SQL, Buffer Pool, RID Pool, SORT e LOCKING no DB2 z/OS 💾🚀
No universo do DB2 for z/OS existe uma verdade brutal:
💣 “O problema quase nunca é o Mainframe.”
O IBM Z aguenta pancada absurda.
Quem normalmente destrói CPU, I/O e tempo de resposta é:
SQL mal escrito
Buffer pool mal dimensionado
RID pool estourando
SORT explodindo em WORKFILE
Locking gerando contenção
O DB2 é praticamente uma cidade viva dentro do z/OS.
E tuning é aprender onde o trânsito trava. ☕🏛️
🔥 1. SQL TUNING — O VERDADEIRO REI DA PERFORMANCE
💣 Regra número 1:
“O SQL errado derruba até z17.”
☕ O que mais mata performance?
🚨 TABLESPACE SCAN (TBSCAN)
Quando o DB2 lê a tabela inteira.
Exemplo ruim:
SELECT *
FROM CLIENTES
WHERE NOME = 'JOAO'
Sem índice em NOME:
-> scan completo
-> milhões de linhas
-> CPU sobe
-> I/O explode
🔥 Como melhorar?
✅ Use índices corretos
CREATE INDEX IX1
ON CLIENTES (NOME)
🚀 Prefira Stage 1 Predicates
Predicados Stage 1 são processados cedo pelo DB2.
Bom:
WHERE DATA = '2026-05-14'
Ruim:
WHERE YEAR(DATA) = 2026
A função quebra o uso eficiente do índice.
💣 Evite SELECT *
Ruim:
SELECT *
Bom:
SELECT ID, NOME
Menos colunas:
menos GETPAGE
menos I/O
menos CPU
🔥 Verifique o ACCESS PATH
Use:
EXPLAIN PLAN
Olhe:
MATCHCOLS
INDEX ONLY
TBSCAN
SORT
RID LIST
🚨 Sinais perigosos no EXPLAIN
| Problema | Impacto |
|---|---|
| TBSCAN | scan completo |
| SORT | uso pesado de workfile |
| Hybrid Join ruim | CPU explode |
| List Prefetch excessivo | RID pool sofre |
| Cartesian Join | caos absoluto |
☕ Ferramentas clássicas
SPUFI
EXPLAIN YES
PLAN_TABLE
Tabela mágica do DBA.
Visual Explain
No Data Studio ou ferramentas IBM.
🔥 2. BUFFER POOL TUNING — O “CACHE SAGRADO” DO DB2
O Buffer Pool é onde páginas ficam em memória.
Quanto mais HIT:
menos I/O
menos disco
mais velocidade
☕ Conceito simples
Sem buffer pool:
Programa -> Disco
Com buffer pool:
Programa -> Memória
Muito mais rápido.
🔥 Métricas importantes
Buffer Hit Ratio
Ideal:
> 90%
🚨 Sintomas de buffer pool ruim
Sync I/O alto
Read I/O excessivo
CPU esperando disco
Response time ruim
☕ Comandos úteis
Ver status
-DISPLAY BUFFERPOOL(BP0) DETAIL
🚀 Alterar tamanho
ALTER BUFFERPOOL BP0 VPSIZE 200000
💣 Mas cuidado…
Buffer pool gigante demais:
rouba memória do z/OS
aumenta paging
piora tudo
Tuning é equilíbrio.
🔥 Estratégia clássica
Separar objetos críticos
Exemplo:
| Buffer Pool | Uso |
|---|---|
| BP0 | sistema |
| BP1 | OLTP |
| BP2 | batch |
| BP32K | LOB/XML |
☕ Pagesize correta
| Tipo | Page |
|---|---|
| OLTP | 4K |
| Scan grande | 32K |
🔥 3. RID POOL TUNING — A GUERRA DAS RID LISTS
RID = Record ID.
DB2 usa RID LIST quando:
vários índices participam
list prefetch ocorre
💣 Quando RID pool estoura…
O DB2 muda estratégia:
RID LIST -> TABLESPACE SCAN
Resultado:
🔥 desastre de performance
☕ Verificar RID pool
-DISPLAY BUFFERPOOL
ou IFCID traces.
🚀 Ajustar tamanho
ZPARM:
MAXRBLK
🔥 Sintomas clássicos
| Sintoma | Causa |
|---|---|
| RID overflow | pool pequeno |
| fallback para scan | RID cheio |
| CPU alta | excesso de leitura |
☕ Soluções
Melhorar índices
Muitas vezes RID pool explode porque:
índice ruim
predicates ruins
cardinalidade ruim
Atualizar RUNSTATS
Sem estatística:
DB2 toma decisões erradas.
RUNSTATS TABLESPACE ...
🔥 4. SORT TUNING — O BURACO NEGRO DO WORKFILE
SORT é caro.
Muito caro.
💣 O que gera SORT?
ORDER BY
GROUP BY
DISTINCT
UNION
JOIN sem índice
☕ O perigo invisível
SORT -> WORKFILE -> I/O -> CPU -> contenção
🚀 Como reduzir SORT?
Criar índices compatíveis
Exemplo:
SELECT *
FROM VENDAS
ORDER BY DATA
Índice:
CREATE INDEX IXDATA
ON VENDAS(DATA)
O DB2 evita SORT.
🔥 Monitorar WORKFILE
Veja:
DSNDB07
utilização
overflow
spill
☕ ZPARMs importantes
| Parâmetro | Função |
|---|---|
| SRTPOOL | memória do sort |
| MAXSORT_IN_MEMORY | sort em memória |
| DSMAX | datasets |
🚨 Sintomas clássicos
DSNDB07 lotado
I/O absurdo
elapsed alto
batch lento
🔥 5. LOCKING TUNING — O INFERNO DAS CONTENÇÕES
O DB2 protege dados com locks.
Mas lock demais:
💣 trava o sistema inteiro.
☕ Tipos de lock
| Tipo | Nível |
|---|---|
| Row | linha |
| Page | página |
| Table | tabela |
| Tablespace | tudo |
🚨 Deadlock
Dois processos esperam um ao outro.
Resultado:
SQLCODE -911
ou
SQLCODE -913
🔥 Timeout
Um processo espera demais.
☕ Estratégias de tuning
✅ Commit frequente
Ruim:
COMMIT a cada 1 milhão
Bom:
COMMIT a cada 1000
🚀 Use LOCKSIZE ROW
LOCKSIZE ROW
Menos contenção.
💣 Evite lock escalation
Quando muitos locks viram lock maior.
Exemplo:
10000 row locks
-> table lock
Caos no OLTP.
☕ CURRENTDATA(NO)
Ajuda em consultas read-only.
🔥 ISOLATION LEVEL
| Nível | Característica |
|---|---|
| UR | mais rápido |
| CS | comum |
| RS | consistente |
| RR | máximo lock |
🚨 RR é perigoso
Repeatable Read
Pode prender milhares de locks.
☕ Comandos úteis
Ver locks
-DISPLAY DATABASE(*) LOCKS
Threads travadas
-DISPLAY THREAD(*)
🔥 O SEGREDO QUE TODO DBA MAINFRAME APRENDE
A maioria dos problemas NÃO é resolvida aumentando hardware.
O fluxo correto é:
1. SQL
2. Índice
3. RUNSTATS
4. Access Path
5. Buffer Pool
6. Sort
7. Locking
8. Só depois pensar em CPU
☕ A FILOSOFIA DO DB2 z/OS
O DB2 é como uma megacidade subterrânea.
Cada:
página
lock
RID
sort
getpage
é trânsito acontecendo em tempo real.
E o DBA/Sysprog experiente aprende uma coisa:
🔥 “Performance não é força bruta.
É arquitetura inteligente.” 💾🚀
