Bellacosa Mainframe e a alta performance no mainframe

☕🔥 “O SEGREDO SUJO DA PERFORMANCE NO MAINFRAME” — POR QUE CACHE VALE MAIS QUE CPU NO MUNDO COBOL/CICS

Quando alguém fala em performance, a maioria pensa imediatamente em:

• CPU,

• MIPS,

• zIIP,

• upgrade de hardware.

Mas no mundo IBM Mainframe existe uma verdade brutal:

☕ O MAIOR INIMIGO DA PERFORMANCE É O I/O.

E por isso:

CACHE É UMA DAS COISAS MAIS IMPORTANTES DO UNIVERSO z/OS.

A imagem mostra 9 estratégias modernas de caching.

Agora vamos traduzir isso para:

• COBOL,

• CICS,

• DB2,

• VSAM,

• MQ,

• Batch,

• Sysplex,

no puro estilo Bellacosa Mainframe.

---

☕ 1. CACHE-ASIDE — “BUSQUE SÓ QUANDO PRECISAR”

Na imagem:

• aplicação procura primeiro no cache,

• se não encontrar, busca no banco.

---

🔥 Isso é praticamente a filosofia clássica do CICS

Exemplo:

Programa COBOL/CICS

EXEC CICS READQ TS
END-EXEC.

Se o dado:

• já estiver em TSQ,

• COMMAREA,

• ou memória temporária,

não precisa acessar:

• DB2,

• VSAM,

• disco físico.

---

☕ Exemplo real

Consulta de cliente VIP:

• primeira busca → DB2,

• próximas buscas → memória CICS.

---

🔥 Resultado

Menos:

• EXCP,

• lock,

• espera,

• canal I/O.

Mais:

• TPS,

• resposta rápida,

• estabilidade.

---

☕ 2. READ-THROUGH — “O CACHE BUSCA AUTOMATICAMENTE”

---

🔥 No mainframe isso aparece muito em DB2 Buffer Pool

O programa COBOL:

nem sabe se o dado veio da memória ou do disco

O DB2 decide.

---

☕ Fluxo real

SELECT → Buffer Pool → se miss → DASD

---

🔥 O detalhe importante

Boa parte da má performance em DB2:

NÃO é SQL ruim

mas:

• buffer pool inadequado,

• hit ratio baixo,

• excesso de I/O físico.

---

☕ Frase clássica de performance analyst

“Seu SELECT talvez esteja ótimo.

Seu disco é que está sofrendo.”

---

☕ 3. WRITE-THROUGH — “GRAVAR NO CACHE E NO BANCO AO MESMO TEMPO”

---

🔥 Aqui entra o lado paranoico do mainframe

O IBM Z odeia inconsistência.

---

☕ Exemplo bancário

PIX:

• atualiza saldo,

• atualiza log,

• atualiza auditoria,

• confirma persistência.

Tudo sincronizado.

---

☕ No DB2 isso lembra:

• commit controlado,

• logging,

• buffer synchronization.

---

🔥 Benefício

Maior consistência.

---

☕ Problema

Mais latência.

---

🔥 Mainframe frequentemente escolhe:

CONSISTÊNCIA > VELOCIDADE

porque banco prefere:

“mais lento”

a:

“saldo corrompido”.

---

☕ 4. WRITE-BEHIND (WRITE-BACK) — “GRAVA DEPOIS”

---

🔥 Estratégia perigosamente poderosa

Primeiro:

• grava em memória,

• depois persiste assíncrono.

---

☕ No Mainframe aparece em:

• buffers VSAM,

• deferred write,

• MQ persistence strategies,

• DFSORT spill optimization.

---

☕ Benefício monstruoso

Reduz I/O físico.

---

🔥 Risco brutal

Se houver falha antes da persistência:

dado pode sumir.

---

☕ Por isso no mundo financeiro:

• write-back é cuidadosamente controlado,

• logging vira obrigatório,

• recovery é crítico.

---

☕ 5. REFRESH-AHEAD — “ATUALIZE ANTES DE EXPIRAR”

---

🔥 Mainframe faz isso há décadas

Exemplo:

DB2 Prefetch

O sistema prevê páginas futuras.

---

☕ Outro exemplo

Batch COBOL:

• pré-carrega tabelas,

• carrega parâmetros em memória,

• evita lookup repetitivo.

---

🔥 Filosofia do z/OS

“Se você SABE que vai precisar…

carregue antes.”

---

☕ 6. INVALIDATION — “JOGUE FORA O QUE FICOU VELHO”

---

🔥 Aqui mora um dos maiores pesadelos corporativos

DADO STALE

---

☕ Exemplo real

Usuário altera endereço.

Mas:

• cache ainda possui dado antigo.

Resultado:

• sistema A mostra endereço novo,

• sistema B mostra antigo.

---

🔥 No Mainframe isso é gravíssimo

Porque:

• múltiplos sistemas compartilham informação,

• inconsistência pode virar problema legal.

---

☕ Técnicas usadas

• cache invalidation,

• commit synchronization,

• DB2 coherency,

• Sysplex cache coherence.

---

☕ 7. CACHE WARMING — “ESQUENTAR O CACHE”

---

🔥 Todo operador experiente conhece isso

Após IPL:

• tudo está “frio”.

---

☕ Resultado clássico

Primeiros minutos:

• I/O explode,

• disco sofre,

• response time piora.

---

🔥 Então muitos ambientes:

• executam jobs de preload,

• aquecem buffer pools,

• pré-carregam tabelas críticas.

---

☕ Exemplo Bellacosa

Banco antes da abertura:

pré-carrega contas mais acessadas.

---

☕ 8. CACHE SHARDING — “DIVIDIR O CACHE”

---

🔥 Aqui entra Parallel Sysplex

Vários nós:

• compartilham workload,

• dividem memória,

• reduzem contenção.

---

☕ Exemplo real

Cada região CICS:

• mantém cache local,

• mas sincroniza estado global.

---

🔥 Benefício

Escalabilidade monstruosa.

---

☕ Desafio

Coerência.

---

🔥 Porque o pesadelo é:

nó A sabe algo
nó B não sabe

---

☕ 9. TTL (TIME TO LIVE) — “TUDO TEM PRAZO DE VALIDADE”

---

🔥 No Mainframe isso é filosofia operacional

Nem todo dado pode viver eternamente no cache.

---

☕ Exemplos

Taxa de câmbio

TTL pequeno.

---

Tabela de estados brasileiros

TTL enorme.

---

🔥 O segredo

Equilibrar:

• frescor,

• performance,

• consistência.

---

☕ O ERRO CLÁSSICO DOS INICIANTES

Pensar:

“Mais cache = sempre melhor”

---

🔥 NÃO.

Cache ruim pode gerar:

• inconsistência,

• stale data,

• contenção,

• explosão de memória,

• recovery complexo.

---

☕ O QUE O MAINFRAME ENSINA SOBRE CACHE

Cache não é só velocidade.

É:

• engenharia de previsibilidade,

• redução de I/O,

• estabilidade operacional,

• proteção contra gargalos.

---

🔥 Porque no IBM Z:

DISCO É O INIMIGO NATURAL DA PERFORMANCE.

---

☕ RESUMO BELLACOSA MAINFRAME

Estratégia	No IBM Mainframe
Cache-Aside	TSQ/COMMAREA/lookup local
Read-Through	DB2 Buffer Pool
Write-Through	Commit síncrono
Write-Behind	Deferred write
Refresh-Ahead	Prefetch
Invalidation	Cache coherency
Cache Warming	Preload pós IPL
Cache Sharding	Sysplex distribution
TTL	Expiração controlada

---

☕🔥 Frase final no estilo Bellacosa Mainframe

“Muita gente acha que Mainframe é rápido por causa da CPU.

Veterano de z/OS sabe:

o segredo quase sempre está em evitar I/O.”

 

 

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

💣🔥 “10 MIL SEGUNDOS ROUBADOS POR DIA: O ASSASSINO SILENCIOSO DO SEU MAINFRAME” 🔥💣 Por que cada milissegundo no z/OS pode ser a diferença entre lucro e caos 🧠 Tradução + Expansão (na veia, sem anestesia) No mundo do processamento de transações em alto volume, “rápido o suficiente” é uma mentira confortável. Quando você roda milhões (ou bilhões) de transações por dia em um ambiente como z/OS, qualquer ineficiência — mesmo microscópica — vira um monstro financeiro. Não importa se você escreve em COBOL, PL/I ou Java. Se o seu código desperdiça tempo, o mainframe cobra — e cobra caro. 👉 Performance tuning não é “nice to have”. 👉 É sobrevivência corporativa. ⚙️ O Efeito Multiplicador (ou: como 10ms viram uma conta absurda) Vamos ao ponto crítico: Você otimiza um trecho e economiza 10 milissegundos. Agora multiplica isso: 1.000.000 execuções por dia Resultado: 👉 10.000 segundos economizados/dia (~2h46min de CPU) Agora entra o mundo real: Menos CPU → menos consumo de MSU Menos MSU → menor custo de licenciamento Menos contenção → mais throughput Mais throughput → mais negócio rodando 💣 Resumo estilo Bellacosa: “Você não economizou milissegundos… você salvou dinheiro REAL.” 🧨 Onde isso explode na prática 💥 Cenário clássico (batch assassino) Um JOB COBOL com loop: PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I > 1000000 EXEC SQL SELECT * INTO :HOST-VAR FROM CLIENTES WHERE ID = :WS-I END-EXEC END-PERFORM 💀 Problemas: SELECT * (crime hediondo) 1 milhão de chamadas SQL Possível table scan 🔧 Cirurgia de performance (passo a passo) 1️⃣ Reduzir dados (SQL cirúrgico) SELECT NOME, STATUS FROM CLIENTES WHERE ID = ? ✔ Menos I/O ✔ Menos CPU ✔ Menos transporte de dados 2️⃣ Garantir acesso via índice Use EXPLAIN no DB2: Evite: TABLE SCAN 😱 Busque: INDEX SEEK 😎 3️⃣ Trocar loop por processamento em bloco 💡 Em vez de 1 milhão de SELECTs: Use cursor Ou fetch em lote 4️⃣ Buffer Pool tuning (ouro puro) Se seu dado é acessado frequentemente: Ajuste buffer pools Evite I/O físico 💣 Easter Egg: Em muitos ambientes, só ajustar buffer pool já deu ganho de 30%+ sem mexer em uma linha de código. 🚀 Quick Wins que parecem pequenos… mas NÃO são 🧩 1. SQL eficiente Nunca use SELECT * Sempre valide acesso via índice Use EXPLAIN como religião ⚡ 2. Compiler moderno (COBOL v6+) Se você ainda usa compilador antigo: 💀 Você está ignorando otimizações do hardware moderno Ganhos comuns: Melhor uso de CPU Otimização automática de loops Instruções mais eficientes 💾 3. Movimento de dados (I/O mata performance) Regra de ouro: “Disco é lento. Memória é rei.” Faça: Cache inteligente Sort interno (quando adequado) Evite leituras repetidas 🧠 Curiosidade de guerra (história real de bastidor) Em um banco: Um único SELECT mal indexado Executado milhões de vezes/dia Resultado após correção: 👉 Redução de MSU suficiente para economizar dezenas de milhares por mês 💣 O código tinha 10 anos em produção 💣 Ninguém questionava 💣 Até alguém olhar com lupa 🔍 Análise profunda (nível arquiteto) Performance no mainframe não é só código. É um ecossistema: CPU (MIPS/MSU) I/O (disco vs memória) Locking (DB2) Concorrência (CICS) Batch window 👉 Uma otimização local pode gerar ganho global 👉 Ou causar efeito colateral (cuidado!) 🧨 Anti-patterns que destroem performance SELECT * Loop com SQL dentro Falta de índice Reprocessamento de dados Leitura repetida de VSAM/DB2 Uso de compilador legado 🏆 O verdadeiro “modernizar o mainframe” Não é só: API Cloud Microservices 💣 Isso é maquiagem se o core estiver ineficiente Modernizar de verdade é: ✔ Código otimizado ✔ Banco bem indexado ✔ CPU bem utilizada ✔ I/O sob controle 🔥 Conclusão (estilo Bellacosa raiz) “Mainframe não é lento. Código ruim é.” Um sistema bem ajustado não é só estável — 👉 Ele vira vantagem competitiva. 🛠️ Provocação final Qual foi aquele “fix ridiculamente simples” que você fez e: Derrubou consumo de CPU? Salvou batch window? Ou evitou um caos em produção? Se cavar… todo ambiente tem um “vilão escondido” esperando alguém enxergar. E quando você acha… 💣 o ganho vem em escala industrial.

 

Bellacosa Mainframe falando sobre performance e custo de processamento

💣🔥 10 MIL SEGUNDOS ROUBADOS POR DIA: O ASSASSINO SILENCIOSO DO SEU MAINFRAME 🔥💣

Por que cada milissegundo no z/OS pode ser a diferença entre lucro e caos

---

🧠 Performance na veia, sem anestesia

No mundo do processamento de transações em alto volume, “rápido o suficiente” é uma mentira confortável.

Quando você roda milhões (ou bilhões) de transações por dia em um ambiente como z/OS, qualquer ineficiência — mesmo microscópica — vira um monstro financeiro.

Não importa se você escreve em COBOL, PL/I ou Java.
Se o seu código desperdiça tempo, o mainframe cobra — e cobra caro.

👉 Performance tuning não é “nice to have”.
👉 É sobrevivência corporativa.

---

⚙️ O Efeito Multiplicador (ou: como 10ms viram uma conta absurda)

Vamos ao ponto crítico:

Você otimiza um trecho e economiza 10 milissegundos.

Agora multiplica isso:

• 1.000.000 execuções por dia
• Resultado:
  👉 10.000 segundos economizados/dia (~2h46min de CPU)

Agora entra o mundo real:

• Menos CPU → menos consumo de MSU
• Menos MSU → menor custo de licenciamento
• Menos contenção → mais throughput
• Mais throughput → mais negócio rodando

💣 Resumo estilo Bellacosa:

“Você não economizou milissegundos… você salvou dinheiro REAL.”

---

🧨 Onde isso explode na prática

💥 Cenário clássico (batch assassino)

Um JOB COBOL com loop:

PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I > 1000000
   EXEC SQL
      SELECT * INTO :HOST-VAR
      FROM CLIENTES
      WHERE ID = :WS-I
   END-EXEC
END-PERFORM

💀 Problemas:

• SELECT * (crime hediondo)
• 1 milhão de chamadas SQL
• Possível table scan

---

🔧 Cirurgia de performance (passo a passo)

1️⃣ Reduzir dados (SQL cirúrgico)

SELECT NOME, STATUS
FROM CLIENTES
WHERE ID = ?

✔ Menos I/O
✔ Menos CPU
✔ Menos transporte de dados

---

2️⃣ Garantir acesso via índice

Use EXPLAIN no DB2:

• Evite:
  • TABLE SCAN 😱
• Busque:
  • INDEX SEEK 😎

---

3️⃣ Trocar loop por processamento em bloco

💡 Em vez de 1 milhão de SELECTs:

• Use cursor
• Ou fetch em lote

---

4️⃣ Buffer Pool tuning (ouro puro)

Se seu dado é acessado frequentemente:

• Ajuste buffer pools
• Evite I/O físico

💣 Easter Egg:

Em muitos ambientes, só ajustar buffer pool já deu ganho de 30%+ sem mexer em uma linha de código.

---

🚀 Quick Wins que parecem pequenos… mas NÃO são

🧩 1. SQL eficiente

• Nunca use SELECT *
• Sempre valide acesso via índice
• Use EXPLAIN como religião

---

⚡ 2. Compiler moderno (COBOL v6+)

Se você ainda usa compilador antigo:

💀 Você está ignorando otimizações do hardware moderno

Ganhos comuns:

• Melhor uso de CPU
• Otimização automática de loops
• Instruções mais eficientes

---

💾 3. Movimento de dados (I/O mata performance)

Regra de ouro:

“Disco é lento. Memória é rei.”

Faça:

• Cache inteligente
• Sort interno (quando adequado)
• Evite leituras repetidas

---

🧠 Curiosidade de guerra (história real de bastidor)

Em um banco:

• Um único SELECT mal indexado
• Executado milhões de vezes/dia

Resultado após correção:

👉 Redução de MSU suficiente para economizar dezenas de milhares por mês

💣 O código tinha 10 anos em produção
💣 Ninguém questionava
💣 Até alguém olhar com lupa

---

🔍 Análise profunda (nível arquiteto)

Performance no mainframe não é só código.

É um ecossistema:

• CPU (MIPS/MSU)
• I/O (disco vs memória)
• Locking (DB2)
• Concorrência (CICS)
• Batch window

👉 Uma otimização local pode gerar ganho global
👉 Ou causar efeito colateral (cuidado!)

---

🧨 Anti-patterns que destroem performance

• SELECT *
• Loop com SQL dentro
• Falta de índice
• Reprocessamento de dados
• Leitura repetida de VSAM/DB2
• Uso de compilador legado

---

🏆 O verdadeiro “modernizar o mainframe”

Não é só:

• API
• Cloud
• Microservices

💣 Isso é maquiagem se o core estiver ineficiente

Modernizar de verdade é:

✔ Código otimizado
✔ Banco bem indexado
✔ CPU bem utilizada
✔ I/O sob controle

---

🔥 Conclusão (estilo Bellacosa raiz)

“Mainframe não é lento.
Código ruim é.”

Um sistema bem ajustado não é só estável —
👉 Ele vira vantagem competitiva.

---

🛠️ Provocação final

Qual foi aquele “fix ridiculamente simples” que você fez e:

• Derrubou consumo de CPU?
• Salvou batch window?
• Ou evitou um caos em produção?

Se cavar… todo ambiente tem um “vilão escondido” esperando alguém enxergar.

E quando você acha…

💣 o ganho vem em escala industrial.