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.” 💾🚀

 

 

Bellacosa Mainframe mergulhando em performance e custo de query db2 no Mainframe

🔥☕ “O MAINFRAME NÃO ESTÁ LENTO — SEU SQL É QUE ESTÁ INCENDIANDO A CPU DO IBM Z” 💾🚨

A Verdade Brutal que Todo Sysprog Júnior Descobre Quando Entra no Mundo Real do DB2 for z/OS

Por Bellacosa Mainframe

---

Existe um momento na vida de todo sysprog júnior…

aquele instante mágico, traumático e inesquecível…

quando ele percebe que:

💣 O problema não era o CICS.

💣 Não era o z/OS.

💣 Não era o storage.

💣 Nem o “mainframe velho”.

Era um único SQL.

Sim.

Uma linha aparentemente inocente:

SELECT *
FROM CLIENTES
WHERE CPF = '12345678900'

…destruindo CPU, queimando MIPS, elevando MSU, congestionando buffer pool e transformando a LPAR num inferno termonuclear digital.

Bem-vindo ao mundo real do DB2 for z/OS.

---

☕ O DIA EM QUE O PADAWAN DESCOBRE QUE CPU NO MAINFRAME = DINHEIRO

No universo distribuído moderno, quando falta performance, a resposta costuma ser:

• sobe mais VM

• coloca Kubernetes

• aumenta cluster

• escala horizontalmente

No mainframe?

HAHAHAHA.

Aqui a conversa é outra.

Aqui:

CPU = LICENSING

CPU = MLC

CPU = 4HRA

CPU = FATURA MILIONÁRIA

Um SQL ruim não deixa apenas o sistema “mais lento”.

Ele:

• aumenta custo mensal

• afeta SLA

• derruba throughput

• impacta batch

• congestiona CICS

• aumenta I/O

• cria lock contention

• vira incidente de produção

E o mais assustador?

Muitas vezes tudo começa com um programador dizendo:

“Mas é só um SELECT…”

---

🏛️ O MAINFRAME NÃO PENSA COMO VOCÊ

O sysprog júnior normalmente imagina que o DB2 executa SQL exatamente como foi escrito.

Não.

O DB2 é muito mais sofisticado.

Quando você envia um SQL, o DB2 chama uma entidade quase mística:

🔥 O OPTIMIZER

Ele analisa:

• estatísticas

• cardinalidade

• índices

• distribuição de dados

• filtros

• joins

• sort

• predicates

• paralelismo

• buffer access

E então decide:

“Qual será o caminho menos custoso para encontrar esses dados?”

Esse caminho se chama:

☕ ACCESS PATH

E é aqui que nascem:

• os heróis

• os vilões

• os incêndios de CPU

• e os DBA traumatizados.

---

💣 O TABLESPACE SCAN — O DEMÔNIO QUE ASSOMBRA PRODUÇÃO

Imagine uma tabela com:

• 900 milhões de linhas

• 14 TB

• milhões de acessos diários

Agora imagine um SQL sem índice adequado:

SELECT *
FROM CLIENTES
WHERE CPF = '12345678900'

Sem índice…

o DB2 pode precisar ler:

• página por página

• bloco por bloco

• segmento por segmento

Isso se chama:

🚨 TABLESPACE SCAN

Ou seja:

o DB2 sai varrendo o oceano inteiro para encontrar um peixinho.

Resultado:

• GETPAGE explode

• CPU dispara

• synchronous I/O aumenta

• elapsed cresce

• batch atrasa

• CICS sofre

E o sysprog júnior começa a ouvir palavras assustadoras no war room:

• “buffer pool saturation”

• “RID failure”

• “class 2 CPU”

• “dynamic statement cache”

• “DSNZPARM”

• “DSNDB07 lotado”

---

☕ O PODER SOBRENATURAL DE UM ÍNDICE

Agora veja a mesma consulta com índice:

CREATE INDEX IXCPF
ON CLIENTES (CPF)

O cenário muda completamente.

Agora o DB2:

• acessa diretamente o valor

• evita scan massivo

• reduz GETPAGE

• diminui I/O

• baixa CPU

O que levava:

• 40 minutos

passa a levar:

• 2 segundos

Sem exagero.

No mundo IBM Z isso acontece TODOS OS DIAS.

---

🔥 O ERRO MAIS COMUM DOS PROGRAMADORES COBOL

Padawan…

grave isso na alma:

“O COBOL não mata CPU sozinho.”

“O SQL dentro dele mata.”

Um clássico infernal:

PERFORM VARYING WS-I FROM 1 BY 1
   EXEC SQL
      SELECT ...
   END-EXEC
END-PERFORM

Parabéns.

Você acabou de criar:

☠️ O APOCALIPSE DO ROW-BY-ROW PROCESSING

Também conhecido como:

• slow by slow

• chatty SQL

• cursor abuse

O programa funciona.

Mas em produção:

• executa milhões de SQLs

• congestiona DB2

• aumenta context switch

• explode CPU

O júnior acha:

“Funcionou no teste.”

O veterano olha e já sente dor física.

---

🧠 O MITO DO “SELECT *”

Outra heresia clássica:

SELECT *

Isso é praticamente um ritual proibido em ambientes críticos.

Porque talvez você precise:

• 2 colunas

Mas o DB2 entrega:

• 180 colunas

• LOBs

• dados inúteis

• mais I/O

• mais buffer

• mais sort

• mais CPU

O correto:

SELECT NOME, CPF

No mainframe:

eficiência é religião.

---

☕ RUNSTATS — O ALIMENTO DO OPTIMIZER

O optimizer do DB2 depende de estatísticas.

Sem elas:

ele fica cego.

RUNSTATS informa:

• quantidade de linhas

• distribuição

• cardinalidade

• clustering

• seletividade

Sem RUNSTATS atualizada…

o DB2 toma decisões absurdas.

Exemplo real:

Tabela cresceu de:

• 10 milhões
  para

• 800 milhões linhas

Mas estatística continua antiga.

O optimizer acredita que a tabela ainda é pequena.

Escolhe nested loop inadequado.

Resultado:

💣 CPU 100x maior

---

🔥 EXPLAIN — O RAIO-X DA ALMA DO SQL

Veterano de DB2 não confia em “achismo”.

Ele usa:

EXPLAIN PLAN

Porque EXPLAIN revela:

• índice usado

• join method

• scans

• sorts

• custo estimado

• stage 1 / stage 2

• parallelism

É literalmente:

a anatomia do pensamento do DB2.

---

☕ STAGE 2 — O CEMITÉRIO DA INDEXABILITY

Veja isso:

WHERE SUBSTR(NOME,1,3) = 'MAR'

Parece elegante.

Mas pode impedir uso eficiente de índice.

Outro clássico:

WHERE YEAR(DATA) = 2025

Muito bonito.

Muito moderno.

Muito destrutivo.

Melhor:

WHERE DATA BETWEEN '2025-01-01'
              AND '2025-12-31'

Porque agora:

• o índice pode respirar

• o optimizer consegue navegar melhor

---

🔥 GETPAGE — A PALAVRA QUE FAZ DBA SUAR FRIO

No DB2 z/OS:

GETPAGE = acesso à página de dados.

Muito GETPAGE:

• mais CPU

• mais latch

• mais memória

• mais I/O

Veteranos monitoram:

• GETPAGE

• sync read

• class 1

• class 2

• lock wait

• RID list

como cardiologista monitorando ECG.

---

☕ “RÁPIDO” NÃO SIGNIFICA “BARATO”

Essa é uma das maiores lições do mainframe.

Às vezes:

• elapsed time está ótimo

MAS:

• CPU está monstruosa.

O usuário acha:

“Nossa, ficou rápido!”

O financeiro vê:

💸🔥💸🔥💸🔥

Porque no IBM Z:

CPU custa dinheiro real.

---

🤖 A ERA DA IA NO TUNING DB2

Hoje ferramentas modernas analisam:

• SQLs problemáticos

• regressão de access path

• mudanças após REBIND

• índices ausentes

• scans perigosos

• CPU anomalies

E algumas usam IA para:

• prever degradação

• sugerir rewrite

• detectar padrões tóxicos

• identificar SQLs assassinos

O futuro do tuning DB2 já começou.

---

🏛️ O QUE O SYSprog JÚNIOR PRECISA ENTENDER URGENTEMENTE

Mainframe não é:

• “computador velho”

• “COBOL antigo”

• “legado ultrapassado”

Mainframe é:

engenharia extrema de throughput.

E DB2 for z/OS é:

um dos motores transacionais mais eficientes já criados pela humanidade.

Ele processa:

• bancos

• cartões

• bolsa

• aviação

• seguros

• governo

• PIX

• ATM

• clearing financeira

Em escala absurda.

---

☕ A GRANDE VERDADE FINAL

O mundo moderno fala:

• cloud

• containers

• microservices

• IA

Mas nos bastidores…

existe um IBM Z executando milhões de transações por segundo…

e um DBA desesperado tentando descobrir:

🔥 “QUAL SQL ESTÁ QUEIMANDO A CPU?” 🔥

Porque no fim…

o COBOL processa o negócio…

o CICS coordena as transações…

mas:

💾 É O ACCESS PATH DO DB2 QUE DECIDE QUANTO CUSTA MANTER O MUNDO FUNCIONANDO. ☕🔥

 

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