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 explorando o DB2

💥 DB2 A REGRA QUE MUDA TUDO

👉 O otimizador NÃO “ama índice”
👉 Ele escolhe o menor custo estimado

💡 Tradução Bellacosa:

Índice ruim pode ser pior que scan completo 😱

---

🧠 1. TABLESPACE SCAN vs INDEX SCAN

⚡ INDEX SCAN (ACCESSTYPE = 'I')

✔ Busca direta
✔ Poucas linhas retornadas
✔ Usa chave/index

👉 Ideal para:

WHERE ID = 100

---

🐢 TABLESPACE SCAN (ACCESSTYPE = 'R')

✔ Varre tudo
✔ Melhor quando retorna MUITAS linhas

👉 Ideal para:

SELECT * FROM CLIENTES

---

💣 CENÁRIO REAL 1 — “ÍNDICE IGNORADO”

🧪 Query

SELECT * 
FROM CLIENTES
WHERE CIDADE = 'SAO PAULO';

👉 Você criou índice em CIDADE… mas Db2 usa SCAN 😬

---

🧠 Por quê?

👉 Baixa seletividade

Se:

• 80% da tabela = “SAO PAULO”

Então:

Índice não compensa

---

🛠️ Solução

✔ Criar índice composto:

CREATE INDEX IDX1 
ON CLIENTES (CIDADE, ID);

✔ Ou melhorar filtro

---

💣 CENÁRIO REAL 2 — “MATCHCOLS BAIXO”

🧪 Índice:

CREATE INDEX IDX2 
ON CLIENTES (CIDADE, NOME);

🧪 Query:

SELECT * FROM CLIENTES
WHERE NOME = 'ANA';

---

😬 Resultado

👉 MATCHCOLS = 0

---

🧠 Por quê?

👉 Ordem do índice importa!

---

🛠️ Correção

✔ Criar índice correto:

CREATE INDEX IDX3 
ON CLIENTES (NOME);

---

💣 CENÁRIO REAL 3 — “SELECT * MATA PERFORMANCE”

🧪 Query

SELECT * FROM CLIENTES
WHERE ID = 10;

---

🧠 Problema

Mesmo com índice:

👉 Pode forçar acesso à tabela (data page)

---

🛠️ Otimização (Index Only Access)

SELECT ID FROM CLIENTES
WHERE ID = 10;

✔ Usa só o índice
✔ Muito mais rápido

---

💣 CENÁRIO REAL 4 — “RUNSTATS TE TRAIU”

🧪 Situação

• Índice existe
• Query boa
• Mesmo assim: SCAN 😡

---

🧠 Causa

👉 Estatísticas desatualizadas

---

🛠️ Solução

RUNSTATS TABLESPACE DB1.TS1;

💡 Sem isso:

Otimizador “chuta”

---

🚀 CENÁRIO REAL 5 — “RANGE SCAN”

🧪 Query

SELECT * FROM CLIENTES
WHERE ID BETWEEN 1 AND 100;

---

🧠 Possível acesso

✔ Index range scan
✔ Ou scan completo (depende do volume)

---

🧠 DECISÃO DO OTIMIZADOR

Ele avalia:

• Cardinalidade
• Seletividade
• Cluster ratio
• Número de páginas
• Estatísticas (RUNSTATS)

---

💥 GOLDEN RULES (nível expert)

🥇 1. Índice ≠ sempre melhor

🥇 2. Ordem do índice é tudo

🥇 3. RUNSTATS é obrigatório

🥇 4. SELECT * é inimigo

🥇 5. WHERE define performance

---

🔥 CHECKLIST DE GUERRA

Antes de subir:

✔ EXPLAIN rodado
✔ ACCESSTYPE correto
✔ MATCHCOLS adequado
✔ Índice alinhado ao WHERE
✔ RUNSTATS atualizado

---

😎 FRASES DE ARQUITETO

• “Isso tá com baixa seletividade”
• “Esse índice não casa com o predicado”
• “O access path tá custando caro”
• “Isso aí vai virar tablespace scan em produção”

---

Uma revisão das regras do Db2

💣 VISÃO FINAL (MENTALIDADE)

👉 Você não escreve SQL…
👉 Você negocia com o otimizador

 

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.)