 |
| Bellacosa Mainframe e o padawan perigoso nas querys db2 |
☕💣 PADAWAN, SUA QUERY ACABOU DE DERRUBAR O CICS?
Como Escrever SELECTs Performáticos no DB2 for z/OS Sem Virar Inimigo do DBA
Existe um momento na vida de todo profissional Mainframe em que ele descobre uma verdade dolorosa:
A query funciona.
Mas a CPU não gosta dela.
O usuário não gosta dela.
O DBA não gosta dela.
E o gerente de produção definitivamente não gosta dela.
O iniciante normalmente pensa:
"Mas ela trouxe o resultado correto."
O DB2 pensa:
"Sim. Depois de ler 800 milhões de linhas."
É aí que nasce a diferença entre um programador SQL e um especialista em performance DB2.
Hoje vamos aprender como analisar uma consulta SQL antes que ela se transforme em um incidente de produção.
Prepare seu café.
Vamos conversar sobre CPU, índices, Access Path e sobrevivência corporativa.
O PRIMEIRO MANDAMENTO
Nunca confie numa query apenas porque ela funciona
Muitos iniciantes executam:
SELECT *
FROM CLIENTES
WHERE CPF='12345678900';
O resultado aparece instantaneamente no ambiente de testes.
Eles ficam felizes.
Mas esquecem que:
Teste possui poucos registros
Produção possui bilhões
Teste tem poucos usuários
Produção tem milhares
Uma query aparentemente inocente pode consumir milhares de segundos de CPU diariamente.
PASSO 1 — APRENDA A LER O EXPLAIN
O EXPLAIN é o raio-x da consulta.
Antes de colocar qualquer SQL importante em produção execute:
EXPLAIN PLAN SET QUERYNO = 1001
FOR
SELECT ...
O DB2 gravará informações em tabelas como:
PLAN_TABLE
DSN_STATEMNT_TABLE
DSN_FUNCTION_TABLE
Ali está a verdade.
Não a opinião do desenvolvedor.
PASSO 2 — DESCUBRA O ACCESS PATH
O Access Path é a rota escolhida pelo otimizador.
Você quer ver algo parecido com:
MATCHCOLS = 3
ACCESS = I
INDEX ONLY = Y
Ou seja:
usando índice
poucas leituras
acesso eficiente
Você NÃO quer encontrar:
ACCESS = R
ou
TABLESPACE SCAN
Isso significa:
"Vou ler tudo."
É como procurar um CPF lendo uma lista telefônica inteira.
PASSO 3 — OLHE O MATCHCOLS
Padawan, grave isso.
MATCHCOLS é uma das colunas mais importantes do EXPLAIN.
Suponha índice:
IX01
CPF
AGENCIA
CONTA
Consulta:
WHERE CPF = ?
MATCHCOLS = 1
Excelente.
Consulta:
WHERE CPF = ?
AND AGENCIA = ?
MATCHCOLS = 2
Melhor ainda.
Consulta:
WHERE AGENCIA = ?
MATCHCOLS = 0
Problema.
O DB2 não consegue aproveitar o início do índice.
PASSO 4 — ANALISE A FILTRAGEM
O índice deve reduzir o universo de dados.
Imagine:
Tabela:
100 milhões de linhas
Cláusula:
WHERE SEXO='M'
Se 50 milhões possuem M.
O filtro é ruim.
Agora:
WHERE CPF='12345678900'
Retorna uma linha.
Excelente seletividade.
Quanto mais seletivo, melhor.
PASSO 5 — CUIDADO COM O LIKE
Boa consulta:
WHERE NOME LIKE 'CARLOS%'
Pode utilizar índice.
Consulta perigosa:
WHERE NOME LIKE '%CARLOS%'
O DB2 normalmente perde o acesso direto.
Resultado:
CPU sobe.
GETPAGE sobe.
Tempo sobe.
O DBA chora.
PASSO 6 — EVITE FUNÇÕES NA COLUNA INDEXADA
Ruim:
WHERE YEAR(DATA_NASCIMENTO)=2025
O índice pode ser ignorado.
Melhor:
WHERE DATA_NASCIMENTO
BETWEEN '2025-01-01'
AND '2025-12-31'
Agora o índice pode ser explorado.
PASSO 7 — NÃO USE SELECT *
Erro clássico:
SELECT *
FROM CLIENTES
O DB2 buscará tudo.
Inclusive colunas que você não precisa.
Melhor:
SELECT
CPF,
NOME,
LIMITE
FROM CLIENTES
Menos I/O.
Menos CPU.
Menos rede.
Menos buffer pool.
PASSO 8 — DESCUBRA SE O ÍNDICE É BOM
Pergunte:
Ele atende o WHERE?
Exemplo:
WHERE CPF=?
Índice:
CPF
Excelente.
Ele atende ORDER BY?
Consulta:
WHERE CPF=?
ORDER BY DATA
Índice:
CPF
DATA
Excelente.
Pode eliminar SORT.
Ele atende JOIN?
Consulta:
CLIENTE.ID
=
PEDIDO.ID_CLIENTE
A coluna do JOIN deveria estar indexada.
PASSO 9 — PROCURE SORTS DESNECESSÁRIOS
O SORT é um consumidor profissional de CPU.
Se aparecer:
SORTN_ORDERBY = Y
investigue.
Talvez um índice resolva.
PASSO 10 — ANALISE O CUSTO ESTIMADO
DB2 12 e DB2 13 fornecem estimativas importantes.
Observe principalmente:
TOTAL_COST
CPU_COST
IO_COST
Ferramentas como:
Data Studio
Optim Query Workload Tuner
IBM Data Server Manager
mostram essas informações de forma amigável.
CPU_COST elevado é sinal de atenção.
PASSO 11 — OLHE OS GETPAGES
DBAs experientes adoram GETPAGE.
Porque ele mostra quantas páginas serão lidas.
Exemplo:
GETPAGE = 100
Ótimo.
GETPAGE = 8.000.000
Hora de revisar a query.
PASSO 12 — VERIFIQUE RUNSTATS
Às vezes a query é boa.
O índice é bom.
Mas as estatísticas são ruins.
Verifique:
RUNSTATS atualizado?
Sem estatísticas confiáveis o otimizador toma decisões erradas.
PASSO 13 — REORG IMPORTA
Um índice pode existir.
Mas estar fragmentado.
Nesse cenário:
mais I/O
mais CPU
mais elapsed time
REORG continua sendo um dos melhores amigos da performance.
PASSO 14 — CUIDADO COM O ONLINE
Batch e Online são mundos diferentes.
No Batch:
5 segundos
Pode ser aceitável.
No Online:
5 segundos
Pode ser uma catástrofe.
Imagine:
1000 usuários simultâneos.
Cada um executando uma query de 5 segundos.
O gargalo nasce rapidamente.
PASSO 15 — A REGRA DE OURO DO PADAWAN
Antes de promover uma query para produção pergunte:
✅ Existe índice?
✅ O índice é utilizado?
✅ O MATCHCOLS é bom?
✅ Existe TABLESPACE SCAN?
✅ Existe SORT desnecessário?
✅ O filtro é seletivo?
✅ Os RUNSTATS estão atualizados?
✅ O GETPAGE está razoável?
✅ O CPU_COST parece aceitável?
✅ O tempo de resposta atende o SLA?
Se alguma resposta for não...
Volte para a oficina.
O SEGREDO DOS MESTRES DB2
Programadores iniciantes escrevem SQL.
Programadores experientes analisam EXPLAIN.
Especialistas DB2 pensam como o otimizador.
Quando você começa a prever qual índice será utilizado, qual access path será escolhido e qual será o impacto em CPU antes mesmo de executar a query, você deixa de ser apenas um desenvolvedor.
Você começa a enxergar o banco pelos olhos do DB2.
E é nesse momento que o Padawan se aproxima do nível Jedi Mainframe.
Porque no universo do DB2, o objetivo não é apenas retornar dados.
O objetivo é retornar dados rapidamente, consumindo o mínimo possível de CPU, evitando filas no CICS, gargalos no DDF, explosões de GETPAGE e telefonemas desesperados da equipe de produção às duas da manhã.
Que a Força do Access Path esteja com você.
