Bellacosa Mainframe apresenta um checklist para analisar a performance e tuning em Mainframe

💥 🧠 CHECKLIST PROFISSIONAL — SAMPLING PERFORMANCE TUNING

---

🎯 1. IDENTIFICAÇÃO DO PROBLEMA

Antes de sair rodando ferramenta:

✔ CPU alto?
✔ Elapsed alto?
✔ Batch lento?
✔ CICS lento?

---

💡 Pergunta chave

“É CPU ou WAIT?”

---

⚙️ 2. DEFINIÇÃO DO ALVO (TARGET)

Escolha corretamente:

• Job batch
• Região CICS
• Address space DB2

---

🔥 Regra de ouro

✔ Comece amplo (job)
✔ Refinar depois (step / programa)

---

🔬 3. DEFINIR O NÍVEL DE ANÁLISE

🔹 Macro (primeiro passo)

• Job inteiro

🔸 Micro (diagnóstico)

• Step específico
• Programa específico

---

💣 Erro comum

❌ Ir direto para detalhe sem contexto

---

⏱️ 4. CONFIGURAR DURAÇÃO

✔ 15–30 minutos padrão
✔ Batch curto → ajustar

---

💡 Regra

Duração suficiente para capturar comportamento real

---

🔢 5. CONFIGURAR SAMPLES

✔ 1000–1500 samples/min

---

📊 Referência

Samples/min	Qualidade
< 500	ruim
1000	bom
1500+	excelente

---

💣 Erro crítico

❌ Poucos samples → diagnóstico errado
❌ Muitos → overhead desnecessário

---

🔁 6. ATIVAR “MEASURE TO STEP END”

✔ Sempre que possível

---

💡 Use quando:

• Batch imprevisível
• Jobs longos
• Problema intermitente

---

🔗 7. ATIVAR COLETORES CORRETOS

✔ DB2 → se houver SQL
✔ CICS → se for transação
✔ IMS → se aplicável

---

💣 Regra

Ative só o necessário

---

⚠️ Erro comum

❌ Ativar tudo → overhead alto

---

🚀 8. EXECUTAR A SESSÃO

✔ Monitorar status
✔ Aguardar finalizar
✔ Verificar número de samples

---

💣 Nunca faça

❌ Analisar sessão ativa
❌ Analisar com poucos samples

---

📊 9. VALIDAR QUALIDADE DO RELATÓRIO

Antes de confiar:

✔ Samples suficientes?
✔ Margem de erro baixa (<5%)?
✔ Duração adequada?

---

💡 Se não:

👉 Refaça a coleta

---

🔍 10. ANÁLISE PRINCIPAL (CPU vs WAIT)

📊 Interpretação

Situação	Diagnóstico
CPU alto	problema de código
WAIT alto	problema externo

---

🔥 11. IDENTIFICAR HOTSPOTS

Procurar:

• Módulo
• Offset
• Função

---

💡 Pergunta chave

“Quem está consumindo CPU de verdade?”

---

🧱 12. CLASSIFICAR O PROBLEMA

🔥 CPU-bound

• Loop
• Cálculo
• Algoritmo

---

🐢 WAIT-bound

• VSAM I/O
• DB2
• ENQ / lock
• MQ

---

🔬 13. DRILL-DOWN (INVESTIGAÇÃO)

Se CPU:

👉 Ir para código (COBOL / PL/I)

Se WAIT:

👉 Ir para:

• DB2 → SQL
• VSAM → dataset
• Sistema → ENQ

---

🛠️ 14. AÇÃO DE TUNING

🔥 CPU

✔ Reduzir loops
✔ Evitar processamento redundante
✔ Melhorar algoritmos

---

🐢 I/O

✔ Melhorar acesso VSAM
✔ Ajustar buffers
✔ Indexar DB2

---

🔐 LOCK

✔ Reduzir contenção
✔ Ajustar commit

---

🔁 15. VALIDAR RESULTADO

👉 Rodar nova sessão

Comparar:

• CPU antes/depois
• Tempo antes/depois

---

💣 Regra

Sem validação = tuning incompleto

---

📈 16. DOCUMENTAR

✔ Problema
✔ Diagnóstico
✔ Solução
✔ Ganho

---

💡 Isso vira:

• Base de conhecimento
• Aceleração futura

---

🔥 CHECKLIST RÁPIDO (versão bolso)

1. CPU ou WAIT?
2. Definir target
3. Configurar samples (1000/min)
4. Ativar step end
5. Executar sessão
6. Validar samples
7. Analisar CPU vs WAIT
8. Encontrar hotspot
9. Corrigir
10. Validar resultado

---

💣 ERROS QUE MATAM PERFORMANCE (e sua carreira 😅)

❌ Analisar sem dados suficientes
❌ Culpar DB2 sem prova
❌ Ignorar WAIT
❌ Não validar margem de erro
❌ Ajustar “no chute”

---

🧠 FRASE FINAL (nível arquiteto)

“Performance não se melhora com opinião.
Se melhora com evidência.”

 

 

Bellacosa Mainframe estudo do caso CPU Explodindo

💥 DB2 - CENÁRIO: CPU EXPLODINDO EM PRODUÇÃO

🧪 Situação

• Batch rodando há anos
• De repente: ⬆ CPU / ⬆ elapsed time
• Usuários reclamando
• SLA estourando

---

⚠️ QUERY PROBLEMÁTICA

SELECT *
FROM VAGNER.PEDIDOS P
JOIN VAGNER.CLIENTES C
  ON P.CLIENTE_ID = C.ID
WHERE C.CIDADE = 'SAO PAULO';

---

💣 SINTOMAS

• CPU alto 🔥
• Long elapsed time
• I/O elevado
• Threads presas

---

🔍 PASSO 1 — EXPLAIN (descobrindo o vilão)

👉 Você roda EXPLAIN e vê:

ACCESSTYPE = R (TABLE SCAN)
METHOD = 1 (Nested Loop)
MATCHCOLS = 0

---

🧠 DIAGNÓSTICO

💥 Problemas identificados:

1. Sem índice em C.CIDADE
2. Join usando nested loop pesado
3. Alto volume de leitura
4. SELECT * (puxa dados desnecessários)

---

🚨 CAUSA REAL DO CPU ALTO

👉 Db2 está:

• Varredura completa (scan)
• Fazendo join linha a linha
• Lendo MUITO mais dados que precisa

💡 Tradução:

Está trabalhando demais pra responder pouco

---

🚀 PASSO 2 — CORREÇÃO (TUNING REAL)

🔹 1. Criar índice estratégico

CREATE INDEX IDX_CLIENTES_CIDADE
ON VAGNER.CLIENTES (CIDADE);

---

🔹 2. Índice para JOIN

CREATE INDEX IDX_PEDIDOS_CLIENTE
ON VAGNER.PEDIDOS (CLIENTE_ID);

---

🔹 3. Evitar SELECT *

SELECT P.ID, C.NOME
FROM VAGNER.PEDIDOS P
JOIN VAGNER.CLIENTES C
  ON P.CLIENTE_ID = C.ID
WHERE C.CIDADE = 'SAO PAULO';

---

🔹 4. Atualizar estatísticas

RUNSTATS TABLESPACE VAGNER.TSCLIENTES;
RUNSTATS TABLESPACE VAGNER.TSPEDIDOS;

---

🔁 PASSO 3 — NOVO EXPLAIN

Agora você vê:

ACCESSTYPE = I
MATCHCOLS > 0
METHOD = melhor otimizado

---

📊 RESULTADO REAL

Métrica	Antes	Depois
CPU	🔥 Alto	⚡ Baixo
Tempo	🐢 Lento	🚀 Rápido
I/O	Alto	Reduzido

---

💣 OUTROS CENÁRIOS DE CPU ALTO (VIDA REAL)

⚠️ 1. Falta de filtro

SELECT * FROM PEDIDOS;

👉 Scan total = CPU alto

---

⚠️ 2. Função no WHERE

WHERE UPPER(NOME) = 'ANA'

👉 Índice ignorado 😬

---

⚠️ 3. OR mal usado

WHERE CIDADE = 'SP' OR CIDADE = 'RJ'

👉 Pode quebrar índice

---

⚠️ 4. RUNSTATS desatualizado

👉 Otimizador toma decisão ruim

---

⚠️ 5. Índice errado

👉 Existe… mas não ajuda

---

🧠 CHECKLIST DE INCIDENTE (use isso na guerra)

Quando CPU subir:

✔ Rodar EXPLAIN
✔ Ver ACCESSTYPE
✔ Checar índices
✔ Ver RUNSTATS
✔ Analisar SELECT *
✔ Avaliar volume de dados

---

🔥 FERRAMENTAS QUE AJUDAM

• EXPLAIN / PLAN_TABLE
• IFCID 316 (performance)
• Monitor tipo OMEGAMON
• Accounting traces

---

😎 FRASES DE QUEM RESOLVE INCIDENTE

• “Isso tá fazendo tablespace scan”
• “O access path mudou”
• “Faltou índice nesse predicado”
• “RUNSTATS tá velho”

---

💥 MENTALIDADE FINAL

👉 CPU alto no Db2 quase nunca é “o mainframe lento”

👉 Normalmente é:

✔ SQL ruim
✔ Índice errado
✔ Estatística desatualizada

 

Bellacosa Mainframe explique Explain e Access Path

💥 DB2 LAB: EXPLAIN + ACCESS PATH (na prática)

🎯 Objetivo

👉 Entender como o Db2 decide acessar os dados
👉 Identificar quando está lento
👉 Corrigir com índice + estatísticas

---

🧪 PARTE 1 — Criando o cenário (problema real)

🔹 Tabela sem índice

CREATE TABLE VAGNER.CLIENTES (
  ID        INTEGER,
  NOME      VARCHAR(50),
  CIDADE    VARCHAR(50)
);

---

🔹 Inserindo volume (simulação)

INSERT INTO VAGNER.CLIENTES VALUES (1,'ANA','SP');
INSERT INTO VAGNER.CLIENTES VALUES (2,'JOAO','RJ');
-- imagine milhares de registros...

---

🔹 Query problemática

SELECT * FROM VAGNER.CLIENTES
WHERE ID = 2;

💡 Parece simples… mas sem índice:

💥 TABLE SPACE SCAN (varre tudo)

---

🔍 PARTE 2 — Rodando EXPLAIN

🔹 Comando

EXPLAIN PLAN FOR
SELECT * FROM VAGNER.CLIENTES
WHERE ID = 2;

---

🔹 Consultando resultado

SELECT 
  PLANNO,
  METHOD,
  ACCESSTYPE,
  MATCHCOLS
FROM PLAN_TABLE;

---

💣 Interpretação

Campo	Significado
ACCESSTYPE = 'R'	Table scan 😬
ACCESSTYPE = 'I'	Index scan 😎
MATCHCOLS	Quantas colunas do índice usadas

---

⚠️ Resultado esperado (ruim)

ACCESSTYPE = R

👉 Tradução:

Db2 está varrendo a tabela inteira

---

🚀 PARTE 3 — Corrigindo (tuning real)

🔹 Criar índice

CREATE INDEX IDX_CLIENTES_ID
ON VAGNER.CLIENTES (ID);

---

🔹 Atualizar estatísticas

RUNSTATS TABLESPACE VAGNER.TSCLIENTES;

💡 Sem RUNSTATS:

O otimizador fica “cego”

---

🔁 PARTE 4 — Rodar EXPLAIN novamente

Mesmo comando:

EXPLAIN PLAN FOR
SELECT * FROM VAGNER.CLIENTES
WHERE ID = 2;

---

✅ Novo resultado

ACCESSTYPE = I
MATCHCOLS = 1

👉 Agora sim:

⚡ Usa índice
⚡ Muito mais rápido

---

💥 PARTE 5 — Comparação real

Antes	Depois
Table scan	Index scan
Lento 🐢	Rápido ⚡
Alto CPU	Baixo CPU

---

🧠 PARTE 6 — Entendendo o Access Path

👉 O otimizador decide baseado em:

• Estatísticas (RUNSTATS)
• Índices disponíveis
• Filtro (WHERE)
• Volume de dados

---

💣 CASOS REAIS DE PRODUÇÃO

⚠️ 1. Índice existe, mas não usa

👉 Possível causa:

• RUNSTATS desatualizado

---

⚠️ 2. MATCHCOLS = 0

👉 Índice não está sendo aproveitado

---

⚠️ 3. SELECT *

👉 Pode forçar acesso desnecessário

---

🔥 DICAS DE OURO

✔ Sempre rodar EXPLAIN antes de produção
✔ Criar índice baseado no WHERE
✔ Atualizar RUNSTATS regularmente
✔ Evitar SELECT *

---

🧠 MINI CHECKLIST (antes de subir código)

• EXPLAIN OK?
• ACCESSTYPE = I?
• MATCHCOLS > 0?
• RUNSTATS atualizado?

---

😎 FRASE DE SENIOR

“Sem EXPLAIN, você está programando no escuro.”

 

Bellacosa Mainframe apresenta Cheatsheet do DB2

💥 DB2 CHEATSHEET — COLA DE PROVA

---

🧠 🧩 FUNDAMENTOS

👉 Db2 = RDBMS (Relational Database Management System)
👉 Usa SQL
👉 Roda no z/OS (core banking, missão crítica)

---

⚙️ 📊 OBJETOS PRINCIPAIS

Objeto	Função
TABLE	Armazena dados
VIEW	Tabela lógica (SELECT)
INDEX	Performance
TABLESPACE	Armazenamento físico
SCHEMA	Organização

💡 Dica:

VIEW = não tem dados físicos

---

🧾 🔥 SQL NA VEIA

📌 DDL (estrutura)

CREATE TABLE T1 (ID INT);
ALTER TABLE T1 ADD COL1 CHAR(10);
DROP TABLE T1;

---

📌 DML (dados)

INSERT INTO T1 VALUES (1);
UPDATE T1 SET ID = 2;
DELETE FROM T1 WHERE ID = 2;
SELECT * FROM T1;

---

📌 DCL (segurança)

GRANT SELECT ON T1 TO USER1;
REVOKE SELECT ON T1 FROM USER1;

---

🚀 🔑 COMANDOS IMPORTANTES

👉 CREATE → cria objeto
👉 SELECT → consulta
👉 WHERE → filtra
👉 JOIN → relaciona tabelas
👉 ORDER BY → ordena

---

🔗 🧠 JOINS (CAI MUITO)

Tipo	Comportamento
INNER JOIN	Só registros iguais
LEFT JOIN	Tudo da esquerda
RIGHT JOIN	Tudo da direita
FULL JOIN	Tudo

---

⚡ 📈 PERFORMANCE

👉 INDEX melhora acesso
👉 WHERE + INDEX = 💥 rápido
👉 FULL TABLE SCAN = 🐢 lento

💡 Regra de ouro:

Sem índice = sofrimento

---

🔐 🔒 SEGURANÇA

👉 Integra com RACF
👉 Controle por:

• Usuário
• Grupo
• Permissão (GRANT/REVOKE)

---

💣 ⚠️ SQLCODE (ESSENCIAL!)

Código	Significado
0	Sucesso
+100	Sem dados
-104	Erro de sintaxe
-204	Objeto não existe
-911	Deadlock

💡 Dica:

SQLCODE negativo = erro

---

⚙️ 🧪 EXECUÇÃO

Ferramenta	Uso
SPUFI	Teste interativo
DSNTEP2	Batch
COBOL + EXEC SQL	Produção

---

📦 🧠 CONCEITOS IMPORTANTES

👉 Tablespace → onde dados vivem
👉 Buffer Pool → cache em memória
👉 Commit → grava transação
👉 Rollback → desfaz

---

🔄 🔥 TRANSAÇÕES

COMMIT;
ROLLBACK;

💡 Sem COMMIT:

Você acha que salvou… mas não salvou 😅

---

🧠 💡 CONTINUOUS DELIVERY

👉 Db2 13 usa modelo CD:

✔ Sem upgrade disruptivo
✔ Features liberadas aos poucos

---

📊 💣 PEGADINHAS DE PROVA

❌ Db2 NÃO é hierárquico
❌ NÃO é o mais popular do mundo
✔ É relacional
✔ Forte em missão crítica

---

🧬 🧠 ARQUITETURA RÁPIDA

• Subsystem (DB2P, DB2T…)
• Buffer Pool
• Logs (REDO/UNDO)
• Catalog (metadados)

---

💥 FRASES QUE PASSAM NA PROVA

👉 “Db2 is a relational database system”
👉 “Indexes improve performance”
👉 “SQL is used to manipulate and define data”
👉 “Db2 supports continuous delivery”

---

🚀 MINI MAPA MENTAL FINAL

👉 Db2 = Dados estruturados
👉 SQL = linguagem
👉 INDEX = performance
👉 RACF = segurança
👉 COMMIT = persistência
👉 SQLCODE = diagnóstico

---

😎 DICA FINAL (NÍVEL BELLACOSA)

Se travar na prova:

👉 Pense assim:

• Isso é estrutura? → DDL
• Isso é dados? → DML
• Isso é acesso? → DCL
• Isso é erro? → SQLCODE

👉 E elimina as alternativas absurdas (hierárquico, etc.)

💣 DB2 Troubleshotting

Bellacosa Mainframe Db2 Troubleshotting

💣 DB2 Troubleshotting

💣 1. DEADLOCK — “o abraço da morte”

🧪 Cenário real

Transação A:

UPDATE CLIENTES SET NOME='ANA' WHERE ID=1;

Transação B:

UPDATE CLIENTES SET NOME='JOAO' WHERE ID=2;

👉 Depois:

• A tenta atualizar ID=2
• B tenta atualizar ID=1

💥 BOOM → deadlock

---

🧠 O que aconteceu?

Cada transação:

• segura um lock
• espera o lock da outra

👉 Db2 detecta e mata uma delas

---

💥 Sintoma clássico

SQLCODE = -911
REASON CODE = 00C90088

---

🔍 Diagnóstico

• IFCID 172 (trace)
• DISPLAY DATABASE LOCKS
• Monitoramento (OMEGAMON)

---

🛠️ Soluções

✔ Acessar tabelas sempre na mesma ordem
✔ Reduzir tempo de transação
✔ Usar COMMIT mais frequente
✔ Evitar “holding locks” por muito tempo

💡 Regra de ouro:

Ordem consistente = evita deadlock

---

⚠️ 2. LOCK ESCALATION — “quando o Db2 perde a paciência”

🧪 Cenário real

Você roda:

UPDATE CLIENTES SET STATUS='A';

👉 Sem WHERE 😬

---

🧠 O que acontece?

• Começa com row locks
• Muitos locks acumulam
• Db2 sobe para table lock

💥 Resultado:

Ninguém mais acessa a tabela

---

💥 Sintoma

• Lentidão geral
• Jobs travados
• Reclamação do usuário 😅

---

🔍 Diagnóstico

• IFCID 196
• Monitoramento de locks
• DSNZPARM (NUMLKTS / NUMLKUS)

---

🛠️ Soluções

✔ Sempre usar WHERE
✔ Commit em blocos (batch)
✔ Ajustar parâmetros de lock
✔ Usar LOCKSIZE adequado

💡 Bellacosa insight:

UPDATE sem WHERE é pedido formal de incidente 🚨

---

🚀 3. ACCESS PATH — “o plano invisível que decide tudo”

🧪 Cenário real

SELECT * FROM CLIENTES WHERE ID = 1;

👉 Parece simples… mas:

• Usa índice? ⚡
• Ou faz table scan? 🐢

---

🧠 O que é Access Path?

👉 Caminho que o otimizador escolhe para acessar os dados

---

🔍 Como ver?

EXPLAIN PLAN FOR
SELECT * FROM CLIENTES WHERE ID = 1;

👉 Consulta tabela PLAN_TABLE

---

💥 Possibilidades

Tipo	Impacto
Index scan	Rápido ⚡
Table scan	Lento 🐢
Nested loop	Bom
Sort	Custo extra

---

🛠️ Otimização

✔ Criar índice correto
✔ Atualizar RUNSTATS
✔ Evitar SELECT *
✔ Filtrar bem no WHERE

---

💡 Exemplo prático

❌ Ruim:

SELECT * FROM CLIENTES;

✅ Melhor:

SELECT NOME FROM CLIENTES WHERE ID = 1;

---

🧠 VISÃO DE PRODUÇÃO (OURO!)

🔥 Deadlock

👉 Problema de concorrência

---

🔥 Lock escalation

👉 Problema de volume de locks

---

🔥 Access path

👉 Problema de performance

---

💣 CHECKLIST RÁPIDO (salva carreira)

Antes de subir para produção:

✔ Tem índice?
✔ Tem WHERE?
✔ Tem COMMIT?
✔ Rodou EXPLAIN?
✔ RUNSTATS atualizado?

---

😎 FRASES DE SENIOR (pra usar na daily)

• “Isso tá com cara de access path ruim”
• “Provavelmente lock escalation”
• “Vamos revisar o EXPLAIN antes de mexer”
• “Isso aí vai dar -911 em produção”