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. ☕🔥

☕💣 PADAWAN, SUA QUERY ACABOU DE DERRUBAR O CICS?

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

 

Bellacosa Mainframe evoluindo da tela verde ao SQL no Db2

---

☕ Da Tela Verde ao SQL: A Jornada de um Profissional Mainframe

Muitos profissionais aprendem JCL, COBOL, SORT e CICS antes de entrar em contato com SQL.

Quando isso acontece, a primeira impressão costuma ser:

"Parece simples demais."

Mas o SQL possui uma característica única:

É simples para começar e complexo para dominar.

Você consegue escrever um SELECT em poucos minutos.

Pode levar anos para compreender completamente:

• Access Paths

• Indexes

• Buffer Pools

• Locking

• Concurrency

• RUNSTATS

• REORG

• Performance Tuning

Por isso cada objetivo dessa trilha merece ser explorado profundamente.

---

🎯 Objetivo 1: Compreender os Conceitos Básicos do SQL

O que realmente significa?

Entender SQL não é decorar comandos.

É compreender o Modelo Relacional.

Antes do SQL, sistemas trabalhavam diretamente com:

• Arquivos sequenciais

• VSAM KSDS

• VSAM ESDS

• VSAM RRDS

O programador precisava conhecer:

• Layout físico

• Chaves

• Organização dos dados

Com SQL ocorre uma revolução:

Você informa:

SELECT NOME
FROM CLIENTES

O banco decide:

• Como localizar

• Qual índice usar

• Quantas páginas acessar

• Qual estratégia é mais eficiente

Essa separação entre lógica e armazenamento foi uma das maiores inovações da computação.

---

Conceitos fundamentais

Tabela

Equivalente moderno de um arquivo lógico.

Linha

Registro.

Coluna

Campo.

Chave Primária

Identifica unicamente cada registro.

Índice

Estrutura que acelera pesquisas.

Relacionamento

Conexão entre tabelas.

---

🎯 Objetivo 2: Explorar a Sintaxe e Estruturas do SQL

Aqui começa a alfabetização do profissional SQL.

Toda instrução possui uma estrutura lógica.

Exemplo:

SELECT
    NOME,
    CIDADE
FROM CLIENTES
WHERE CIDADE = 'SANTOS'
ORDER BY NOME;

Observe a sequência:

1. SELECT

2. FROM

3. WHERE

4. ORDER BY

A ordem de escrita é simples.

Mas o DB2 executa internamente de forma diferente.

Ele primeiro localiza os dados.

Depois filtra.

Depois ordena.

Compreender isso ajuda a entender performance.

---

Boas práticas desde o início

Evite:

SELECT *
FROM CLIENTES;

Prefira:

SELECT
    ID_CLIENTE,
    NOME,
    CIDADE
FROM CLIENTES;

Essa pequena mudança já demonstra maturidade técnica.

---

🎯 Objetivo 3: Utilizar Comandos Básicos de SQL

Todo profissional precisa dominar quatro comandos fundamentais.

---

SELECT

Consulta informações.

SELECT *
FROM CLIENTES;

---

INSERT

Inclui registros.

INSERT INTO CLIENTES
(
 ID,
 NOME
)
VALUES
(
 1,
 'ANA'
);

---

UPDATE

Altera registros.

UPDATE CLIENTES
SET CIDADE = 'SANTOS'
WHERE ID = 1;

---

DELETE

Remove registros.

DELETE
FROM CLIENTES
WHERE ID = 1;

---

O erro que assombra os DBAs

Esquecer o WHERE.

Exemplo perigoso:

UPDATE CLIENTES
SET STATUS = 'ATIVO';

Resultado:

Toda a tabela será atualizada.

É um dos acidentes mais famosos da história dos bancos de dados.

---

🎯 Objetivo 4: Implementar Consultas Simples em SQL

Agora o aluno começa a transformar dados em informação.

---

Filtrando registros

SELECT
    NOME
FROM CLIENTES
WHERE CIDADE = 'SANTOS';

---

Filtrando intervalos

SELECT
    NOME
FROM CLIENTES
WHERE SALARIO
BETWEEN 5000 AND 10000;

---

Utilizando listas

SELECT *
FROM CLIENTES
WHERE ESTADO IN
(
 'SP',
 'RJ',
 'MG'
);

---

Pesquisando padrões

SELECT *
FROM CLIENTES
WHERE NOME LIKE 'MAR%';

Retorna:

• MARIA

• MARCOS

• MARCELO

---

Ordenando resultados

SELECT
 NOME,
 SALARIO
FROM FUNCIONARIOS
ORDER BY SALARIO DESC;

---

🎯 Objetivo 5: Criar Suas Primeiras Consultas em SQL

Aqui nasce o verdadeiro analista de dados.

Não basta consultar.

É necessário responder perguntas do negócio.

---

Quantos clientes existem?

SELECT COUNT(*)
FROM CLIENTES;

---

Qual o maior salário?

SELECT MAX(SALARIO)
FROM FUNCIONARIOS;

---

Qual a média salarial?

SELECT AVG(SALARIO)
FROM FUNCIONARIOS;

---

Quantos clientes existem por cidade?

SELECT
    CIDADE,
    COUNT(*)
FROM CLIENTES
GROUP BY CIDADE;

Agora estamos produzindo inteligência.

Não apenas listando registros.

---

🚀 O Próximo Passo no DB2 13

Após dominar esses cinco objetivos, o profissional estará pronto para estudar temas mais avançados:

JOINs

SELECT
 C.NOME,
 P.NUMERO_PEDIDO
FROM CLIENTES C
INNER JOIN PEDIDOS P
ON C.ID = P.ID_CLIENTE;

---

Subqueries

SELECT *
FROM FUNCIONARIOS
WHERE SALARIO >
(
 SELECT AVG(SALARIO)
 FROM FUNCIONARIOS
);

---

Índices

CREATE INDEX IX_CLIENTE_NOME
ON CLIENTES
(
 NOME
);

---

EXPLAIN

Análise do plano de acesso.

Ferramenta essencial para DBAs e desenvolvedores DB2.

---

SQL Embedded em COBOL

EXEC SQL
   SELECT NOME
   INTO :WS-NOME
   FROM CLIENTES
   WHERE ID = :WS-ID
END-EXEC.

Aqui começa o verdadeiro universo Mainframe.

---

☕ Conclusão Bellacosa Mainframe

Os cinco objetivos apresentados na imagem parecem simples à primeira vista.

Mas eles representam a fundação de praticamente todo o ecossistema corporativo moderno.

Cada PIX processado.

Cada compra no cartão.

Cada transferência bancária.

Cada consulta de seguro.

Cada reserva aérea.

Em algum momento passa por um comando SQL.

No DB2 13, aprender SQL significa muito mais do que aprender uma linguagem. Significa compreender como os dados fluem dentro de alguns dos maiores sistemas do planeta.

O primeiro passo é escrever:

SELECT *
FROM CLIENTES;

O passo seguinte é entender por que essa consulta funciona.

O passo que diferencia um especialista é compreender por que ela pode ser lenta, como o DB2 a executa, quais índices utiliza e como transformá-la em uma consulta capaz de processar bilhões de registros com eficiência.

E é exatamente nesse momento que o estudante deixa de apenas aprender SQL e começa a pensar como um verdadeiro profissional de Mainframe. ☕🚀💾

Descubra como profissionais de Mainframe evoluem da programação em JCL, COBOL, SORT e CICS para o domínio do SQL no DB2 13 for z/OS. Entenda modelo relacional, consultas SQL, índices, joins, subqueries, EXPLAIN, access paths e técnicas de otimização utilizadas nos maiores ambientes corporativos do mundo.

Bellacosa Mainframe apresenta Laboratorio de incidentes no Db2

🔥☕ LABORATÓRIO DB2 UTILITIES z/OS — 20 INCIDENTES REAIS DE PRODUÇÃO ☕🔥

“Quando o DBA entra na sala de máquinas do mainframe”

Este laboratório é baseado no menu DB2 UTILITIES da sua tela:

• REBUILD
• COPY
• RECOVER
• REORG
• RUNSTATS
• LOAD
• CHECK
• REPAIR
• UNLOAD
• QUIESCE

Aqui você vai encontrar:

• 🚨 problemas reais
• 🔍 investigação
• 💣 diagnóstico
• ✅ solução
• 🧠 análise operacional

---

🔥 LAB 01 — REBUILD PENDING

🚨 Problema

Aplicação começou a falhar.

SQLCODE:

-904 RESOURCE UNAVAILABLE

---

🔍 Investigação

-DIS DATABASE(ESCOLA)

---

💣 Resultado

INDEXSPACE IXALUNO
STATUS RBDP

---

✅ Solução

Executar:

//STEP1 EXEC DSNUPROC,SYSTEM=DB9G
//SYSIN DD *
 REBUILD INDEX(ESCOLA.IXALUNO)
/*

---

🧠 Explicação

Índice inválido.

O optimizer não consegue utilizá-lo.

---

🔥 LAB 02 — COPY PENDING

🚨 Problema

INSERT falhando após LOAD.

---

🔍 Investigação

-DIS DATABASE(FINANCE)

---

💣 Resultado

COPY PENDING

---

✅ Solução

COPY TABLESPACE FINANCE.CLIENTE

---

🧠 Explicação

Objeto exige backup válido.

---

🔥 LAB 03 — SQL MUITO LENTO

🚨 Problema

Queries demorando minutos.

---

🔍 Investigação

RUNSTATS não executa há meses.

---

💣 Diagnóstico

Optimizer usando access path ruim.

---

✅ Solução

RUNSTATS TABLESPACE FINANCE.CLIENTE

---

🧠 Explicação

Sem estatísticas atualizadas:

• DB2 escolhe índices ruins
• pode fazer full tablescan

---

🔥 LAB 04 — TABELA FRAGMENTADA

🚨 Problema

I/O elevadíssimo.

---

🔍 Investigação

AREO*

---

💣 Diagnóstico

Fragmentação pesada.

---

✅ Solução

REORG TABLESPACE FINANCE.CLIENTE

---

🧠 Explicação

Páginas desorganizadas.

---

🔥 LAB 05 — LOAD QUEBROU ÍNDICES

🚨 Problema

Após LOAD REPLACE:

• índices sumiram
• SQL lento

---

🔍 Investigação

RBDP

---

✅ Solução

REBUILD INDEX

---

🧠 Explicação

LOAD REPLACE invalida índices.

---

🔥 LAB 06 — UTILITY PRESA

🚨 Problema

REORG nunca termina.

---

🔍 Investigação

-DIS UTIL(*)

---

💣 Resultado

Utility em WAIT.

---

✅ Solução

-TERM UTIL(REORG01)

---

🧠 Explicação

Utility aguardando drain/lock.

---

🔥 LAB 07 — RECOVER NECESSÁRIO

🚨 Problema

Disco falhou.

---

🔍 Investigação

Objeto inacessível.

---

✅ Solução

RECOVER TABLESPACE FINANCE.CLIENTE

---

🧠 Explicação

Restauração via image copy + logs.

---

🔥 LAB 08 — INDEX CORROMPIDO

🚨 Problema

Abends em SQL.

---

🔍 Investigação

CHECK INDEX INDEXSPACE IXCLI01

---

💣 Resultado

Corrupção detectada.

---

✅ Solução

REBUILD INDEX

---

🧠 Explicação

Estrutura B-tree inconsistente.

---

🔥 LAB 09 — ORPHAN ROWS

🚨 Problema

Violação referencial.

---

🔍 Investigação

CHECK DATA TABLESPACE FINANCE.CLIENTE

---

💣 Resultado

Orphan rows encontradas.

---

✅ Solução

Corrigir dados.

Executar CHECK novamente.

---

🧠 Explicação

Foreign key inconsistente.

---

🔥 LAB 10 — BUFFERPOOL EXPLODINDO

🚨 Problema

REORG causando pressão memória.

---

🔍 Investigação

-DIS BUFFERPOOL(*)

---

💣 Resultado

Page stealing elevado.

---

✅ Solução

• aumentar BP
• reduzir concorrência utilities

---

🧠 Explicação

REORG consome memória intensamente.

---

🔥 LAB 11 — LOG FULL

🚨 Problema

Batch travado.

---

🔍 Investigação

-DIS LOG

---

💣 Resultado

Logs quase esgotados.

---

✅ Solução

• aumentar commits
• acelerar archive
• reduzir transações longas

---

🧠 Explicação

LOAD/REORG podem gerar muito log.

---

🔥 LAB 12 — UNLOAD GIGANTE

🚨 Problema

Necessidade de exportar bilhões de linhas.

---

✅ Solução

UNLOAD TABLESPACE BIGDB.TRANSAC

---

🧠 Explicação

UNLOAD é muito mais rápido que SELECT tradicional.

---

🔥 LAB 13 — REORG BLOQUEANDO ONLINE

🚨 Problema

Usuários reclamam indisponibilidade.

---

🔍 Investigação

REORG executado SHRLEVEL NONE.

---

✅ Solução

REORG SHRLEVEL CHANGE

---

🧠 Explicação

Permite acesso concorrente.

---

🔥 LAB 14 — QUIESCE ANTES DE DEPLOY

🚨 Problema

Necessidade de rollback seguro.

---

✅ Solução

QUIESCE TABLESPACESET FINANCE

---

🧠 Explicação

Cria ponto consistente recuperação.

---

🔥 LAB 15 — REPAIR MAL UTILIZADO

🚨 Problema

DBA júnior removeu pendência errada.

---

💣 Resultado

Objeto inconsistente.

---

🧠 Explicação

REPAIR ignora validações normais DB2.

---

🚨 Moral

REPAIR é bisturi nuclear.

---

🔥 LAB 16 — RUNSTATS ESQUECIDO

🚨 Problema

Plano SQL mudou drasticamente.

---

🔍 Investigação

Stats desatualizadas.

---

✅ Solução

RUNSTATS TABLESPACE FINANCE.PEDIDOS

---

🧠 Explicação

Optimizer “envelheceu”.

---

🔥 LAB 17 — TEMPLATE ERRADO

🚨 Problema

COPY falhando.

---

🔍 Investigação

Dataset template inválido.

---

💣 Resultado

Allocation errors.

---

✅ Solução

Corrigir TEMPLATE.

---

🧠 Explicação

Naming padrão incorreto.

---

🔥 LAB 18 — LISTDEF MAL DEFINIDO

🚨 Problema

REORG atingiu tablespaces errados.

---

🔍 Investigação

LISTDEF genérico demais.

---

✅ Solução

Restringir INCLUDE.

---

🧠 Explicação

Automação perigosa.

---

🔥 LAB 19 — LOAD MASSIVO SEM SORT

🚨 Problema

LOAD extremamente lento.

---

🔍 Investigação

Sem SORT adequado.

---

✅ Solução

Adicionar SORTDEVT/SORTNUM.

---

🧠 Explicação

LOAD depende muito de sort eficiente.

---

🔥 LAB 20 — O COLAPSO DA JANELA BATCH

🚨 Problema

Batch noturno explodiu.

---

🔍 Investigação

Rodando simultaneamente:

• COPY
• REORG
• RUNSTATS
• LOAD

---

💣 Resultado

• lock contention
• log saturation
• I/O overload
• CPU spike

---

✅ Solução

Separar scheduling utilities.

---

🧠 Explicação

Utilities competem brutalmente por:

• disco
• bufferpool
• log
• CPU

---

🔥 DESAFIO EXTRA — COMANDOS PARA TREINAR

Ver utilities

-DIS UTIL(*)

---

Terminar utility

-TERM UTIL(utilid)

---

Ver status objetos

-DIS DATABASE(DB1)

---

Ver logs

-DIS LOG

---

🔥 EXERCÍCIO AVANÇADO

Monte um fluxo completo:

COPY
REORG
RUNSTATS
CHECK INDEX
CHECK DATA

E explique:

• por que essa sequência existe,
• quais riscos evita,
• e como impacta performance.

---

☕ VISÃO “BELLACOSA MAINFRAME”

As DB2 Utilities são os “robôs industriais” do z/OS.

Elas:

• reconstruem,
• reorganizam,
• restauram,
• limpam,
• validam,
• e mantêm vivo o banco mais crítico da empresa.

No mundo distribuído muita gente reinicia serviço.

No mainframe…
o DBA conversa diretamente com os mecanismos internos do banco. ☕💣

 

Bellacosa Mainframe e a saude do Db2

☕🔥 DB2 z/OS — COMO IDENTIFICAR PROBLEMAS EM ÍNDICES, ANALISAR A SAÚDE E CRIAR ÍNDICES EFICIENTES

No Db2 for z/OS, índices são literalmente o “GPS” do otimizador.
Quando um índice está ruim, fragmentado, mal desenhado ou inconsistente, os sintomas aparecem rapidamente:

• CPU alta

• GETPAGE excessivo

• LOCKS maiores

• Deadlocks

• Elapsed Time absurdo

• SORT desnecessário

• RUNSTATS inconsistentes

• ACCESS PATH inesperado

• Tablespace em CHECK/RBDP/RECP

• RID List Overflow

• REORG frequente

---

🔥 COMO IDENTIFICAR PROBLEMAS EM ÍNDICES

1 — Verificando Fragmentação do Índice

Um dos principais indicadores.

Consultas importantes

SELECT
    NAME,
    CLUSTERING,
    CLUSTERRATIOF,
    LEAFDIST,
    NLEVELS,
    FULLKEYCARDF,
    FIRSTKEYCARDF
FROM SYSIBM.SYSINDEXES
WHERE CREATOR = 'SEU_SCHEMA'
AND TBNAME = 'SUA_TABELA';

---

🔎 O QUE OBSERVAR

CLUSTERRATIOF

Mostra o quanto os dados seguem a sequência do índice clustering.

Valores

Valor	Situação
> 95	Excelente
80–95	Aceitável
< 80	Fragmentação séria

Baixo CLUSTERRATIO gera:

• Mais I/O

• Mais Sync Read

• Mais Random Access

• Mais CPU

---

LEAFDIST

Distância média entre páginas leaf.

Quanto maior:

• pior a localidade física

• mais page split ocorreu

---

NLEVELS

Quantidade de níveis B-Tree.

Nível	Interpretação
2-3	Normal
4+	Índice muito grande ou mal estruturado

Mais níveis = mais GETPAGE.

---

🔥 PAGE SPLIT — O GRANDE VILÃO

Quando páginas do índice enchem:

• Db2 divide páginas

• reorganiza ponteiros

• aumenta fragmentação

Sintomas:

• CPU cresce

• bufferpool sofre

• random I/O aumenta

---

🔎 COMO IDENTIFICAR PAGE SPLIT

SELECT
    NAME,
    SPACEF,
    STATSTIME
FROM SYSIBM.SYSINDEXSPACESTATS
WHERE DBNAME = 'SEU_DB';

---

🔥 REORGCHECK — O TESTE CLÁSSICO

No Db2 LUW existe REORGCHK.

No z/OS normalmente usamos:

• RUNSTATS

• REORG TABLESPACE/INDEX

• Estatísticas catalogadas

• RTS (Real Time Statistics)

---

🔥 REAL TIME STATISTICS (RTS)

Tabela importantíssima:

SYSIBM.SYSINDEXSPACESTATS

Campos críticos:

Campo	Significado
REORGINSERTS	Inserts desde último REORG
REORGDELETES	Deletes
REORGUPDATES	Updates
LEAFDIST	Fragmentação
FARINDREF	Referência distante
NEARINDREF	Referência próxima

---

🔥 FARINDREF — UM DOS MELHORES INDICADORES

Mostra quantos acessos ao índice apontam para linhas longe fisicamente.

Quanto maior:

• pior clustering

• pior cache

• pior bufferpool hit ratio

---

🔥 COMO SABER SE O ÍNDICE NÃO ESTÁ SENDO USADO

Pacotes e explain.

---

EXPLAIN

EXPLAIN PLAN SET QUERYNO = 100
FOR
SELECT *
FROM CLIENTES
WHERE CPF = ?;

Depois consulte:

SELECT
    ACCESSNAME,
    ACCESSTYPE,
    MATCHCOLS
FROM PLAN_TABLE
WHERE QUERYNO = 100;

---

🔎 INTERPRETAÇÃO

Campo	Significado
ACCESSTYPE='I'	Uso de índice
MATCHCOLS	Quantas colunas casaram
ACCESSNAME	Índice usado

---

🔥 INDICADORES DE ÍNDICE RUIM

1 — MATCHCOLS baixo

Índice composto mal desenhado.

---

2 — ACCESSTYPE = 'R'

Tablespace Scan.

Ruim para tabelas grandes.

---

3 — RID LIST PROCESSING

Pode indicar:

• excesso de índices

• índices ruins

• baixa seletividade

---

🔥 COMO DESENHAR UM ÍNDICE FORTE

REGRA #1 — COLUNA MAIS SELETIVA PRIMEIRO

Exemplo ruim:

CREATE INDEX IX1
ON CLIENTES
(SEXO, ESTADO);

Baixa cardinalidade.

---

Melhor:

CREATE INDEX IX1
ON CLIENTES
(CPF, ESTADO);

---

🔥 REGRA #2 — RESPEITAR O PREDICATE

Db2 usa LEFTMOST MATCHING.

Exemplo:

INDEX(A,B,C)

Funciona bem para:

WHERE A=?
WHERE A=? AND B=?
WHERE A=? AND B=? AND C=?

Ruim para:

WHERE B=?
WHERE C=?

---

🔥 REGRA #3 — EVITAR ÍNDICES DEMAIS

Cada índice:

• aumenta INSERT

• aumenta UPDATE

• aumenta DELETE

• aumenta LOG

• aumenta LOCKING

• aumenta CPU

---

🔥 QUANTOS ÍNDICES UMA TABELA DEVE TER?

Não existe número mágico.

Mas no mundo real:

Tipo	Recomendação
OLTP	3–7
Tabelas críticas	10–15 máximo
Acima de 20	normalmente problema de modelagem

Já vi tabelas com:

• 80 índices

• 120 índices

Resultado:

• INSERT sofrendo

• Deadlock

• log monstruoso

• CPU absurda

---

🔥 ÍNDICE CLUSTERING

Muito importante.

CREATE INDEX IXCLI1
ON CLIENTES (CPF)
CLUSTER;

Só pode existir UM clustering index por tabela.

Ele influencia:

• ordem física

• prefetch

• sequential detection

• range scan

---

🔥 RUNSTATS — FUNDAMENTAL

Sem RUNSTATS:

• optimizer fica “cego”

• access path piora

---

Exemplo

RUNSTATS TABLESPACE DB1.TSCLI
TABLE(ALL)
INDEX(ALL)
KEYCARD
FREQVAL
HISTOGRAM
UPDATE ALL

---

🔥 O QUE O RUNSTATS FAZ

Atualiza:

• cardinalidade

• clustering

• distribuição

• frequência

• histogramas

• seletividade

---

🔥 RUNSTATS COM SHRLEVEL CHANGE

Permite online.

SHRLEVEL CHANGE

Muito usado em produção.

---

🔥 REORG INDEX

Quando usar:

• fragmentação

• page split

• baixa cluster ratio

---

Exemplo

REORG INDEX (ALL) TABLESPACE DB1.TSCLI
SHRLEVEL CHANGE

---

🔥 REBUILD INDEX

Mais pesado.

Usado quando:

• índice corrompido

• recover

• inconsistency

• rebuild pós LOAD REPLACE

---

🔥 RUNSTATS x REORG

Utilitário	Função
RUNSTATS	Atualiza estatísticas
REORG	Reorganiza fisicamente
REBUILD INDEX	Reconstrói índice

---

🔥 RUNSTATUS / RESTRICTIVE STATES

Estados importantes no Db2.

---

🔴 CHECK PENDING (CHKP)

Db2 exige CHECK DATA.

Exemplo:

-904 RESOURCE UNAVAILABLE

Resolver:

CHECK DATA TABLESPACE DB1.TS1

---

🔴 REORG PENDING (REORP)

Db2 exige REORG.

Muito comum após:

• ALTER

• compress

• partition change

Resolver:

REORG TABLESPACE DB1.TS1

---

🔴 RECOVER PENDING (RECP)

Objeto precisa RECOVER.

---

🔴 AUX CHECK PENDING

LOB inconsistente.

---

🔴 ADVISORY REORG PENDING (AREO*)

Db2 recomenda REORG.

Não bloqueia uso.

---

🔥 QUIESCE — O “PONTO DE RESTORE”

Cria ponto consistente para recover coordenado.

---

Exemplo

QUIESCE TABLESPACE DB1.TS1
WRITE YES

---

🔎 O QUE ELE FAZ

Sincroniza:

• logs

• páginas

• buffers

Muito usado antes de:

• LOAD

• grandes mudanças

• backup crítico

---

🔥 DISPLAY DATABASE

Comando essencial.

-DISPLAY DATABASE(DB1) SPACENAM(TS1) RESTRICT

Mostra:

• REORP

• CHKP

• AREO*

• COPY pending

• advisory states

---

🔥 DISPLAY INDEX

-DISPLAY DATABASE(DB1) SPACENAM(TS1) USE

---

🔥 IFCID E MONITORAMENTO

Sysprog geralmente usa:

• IFCID 199

• IFCID 376

• IFCID 389

• OMEGAMON

• MainView

• Query Monitor

Para detectar:

• index scan ruim

• getpages altos

• synchronous I/O

• random read

• RID overflow

---

🔥 SINAIS CLÁSSICOS DE ÍNDICE PROBLEMÁTICO

Sintoma	Possível causa
CPU alta	Índice ruim
Tablespace Scan	falta índice
GETPAGE alto	excesso de níveis
Sync I/O alto	fragmentação
Deadlock	excesso índices
INSERT lento	muitos índices
REORG frequente	page split
Bufferpool ruim	clustering baixo

---

☕ MELHOR ESTRATÉGIA ENTERPRISE

Fluxo saudável

RUNSTATS
   ↓
EXPLAIN
   ↓
ANÁLISE RTS
   ↓
REORG
   ↓
MONITORAMENTO IFCID
   ↓
AJUSTE DE ACCESS PATH

---

🔥 RESUMO ENTERPRISE

Índice saudável:

✅ Alta seletividade
✅ Baixo NLEVELS
✅ CLUSTERRATIO alto
✅ Poucos page splits
✅ MATCHCOLS alto
✅ Bom clustering
✅ Estatísticas atualizadas
✅ Poucos índices redundantes

---

☕ REGRA DE OURO NO Db2 z/OS

“Índice demais mata INSERT.
Índice de menos mata SELECT.
Índice ruim mata os dois.”