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 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 e a introdução a performance no mainframe

Introdução aos Conceitos de Performance em Mainframe

Quando falamos em Performance em Mainframe, estamos falando da arte e da ciência de fazer com que aplicações, bancos de dados, transações online e processos batch executem com máxima eficiência, consumindo o mínimo possível de recursos computacionais.

No universo IBM Z, performance não significa apenas velocidade. Ela envolve:

✅ Tempo de resposta

✅ Consumo de CPU

✅ Uso de memória

✅ Acesso a disco

✅ Tráfego de rede

✅ Custos de licenciamento

✅ Capacidade futura do ambiente

---

O Que é Performance?

De forma simples:

Performance =
Quantidade de trabalho realizado
÷
Recursos consumidos

Um sistema é considerado eficiente quando consegue processar mais transações utilizando menos recursos.

---

Por Que Performance é Tão Importante?

Em ambientes Mainframe, pequenas melhorias podem representar economias enormes.

Exemplo:

1% de redução de CPU
↓
Menos consumo de MSU
↓
Redução de custos
↓
Economia anual significativa

Por isso, grandes bancos possuem equipes dedicadas exclusivamente à performance.

---

Os Quatro Pilares da Performance

CPU

É o cérebro do Mainframe.

Responsável por executar:

• COBOL

• PL/I

• Java

• CICS

• IMS

• DB2

Exemplo:

CPU = 90%

Pode indicar gargalo.

---

Memória

Armazena programas e dados em execução.

Analisa-se:

• Frames

• Real Storage

• Paging

• Cache

Problemas comuns:

Pouca memória
↓
Paging excessivo
↓
Lentidão

---

I/O (Entrada e Saída)

Envolve:

• Discos

• Storages

• FICON

• VSAM

• DB2

Muitas vezes o gargalo não está na CPU, mas no acesso aos dados.

---

Rede

Hoje os Mainframes estão conectados a:

• APIs

• Cloud

• Mobile

• Open Banking

Logo, performance também envolve:

TCP/IP
OSA
HiperSockets
TLS

---

Conceitos Fundamentais

Tempo de Resposta

Quanto tempo o usuário espera.

Exemplo:

Consulta Saldo
↓
0,3 segundos

Excelente.

---

Throughput

Quantidade de trabalho processado.

Exemplo:

50.000 transações/segundo

---

Latência

Tempo necessário para iniciar uma operação.

Exemplo:

Aplicação
↓
DB2
↓
Resposta

Quanto menor, melhor.

---

Utilização

Percentual de uso de um recurso.

Exemplo:

CPU = 40%

---

Capacidade

Quanto o ambiente suporta antes de saturar.

---

Performance em Batch

Muito importante em Mainframe.

Exemplo:

JOB NOTURNO

Início: 22:00
Fim:    04:00

Objetivo:

22:00
↓
01:30

Menor janela batch.

---

Performance em CICS

Em ambiente online analisa-se:

• Tempo de resposta

• Número de transações

• Esperas

• Locks

Fluxo:

Terminal
↓
CICS
↓
COBOL
↓
DB2

Cada etapa é medida.

---

Performance em DB2

Grande parte dos problemas de performance está no SQL.

Exemplo ruim:

SELECT *
FROM CLIENTES

---

Melhor:

SELECT NOME
FROM CLIENTES
WHERE CPF = ?

---

Aspectos analisados:

• Índices

• Buffer Pools

• Access Path

• Tablespaces

---

Performance em COBOL

Algumas boas práticas:

Evitar Leitura Desnecessária

Ruim:

READ ARQUIVO

milhões de vezes.

---

Carregar Tabelas em Memória

Melhor:

READ UMA VEZ
↓
WORKING-STORAGE

---

Utilizar SEARCH ALL

Mais eficiente que busca sequencial.

---

Reduzir Chamadas ao Banco

Menos SQL significa:

Menos I/O
↓
Mais Performance

---

Principais Gargalos

CPU

Uso excessivo

---

Disco

I/O elevado

---

SQL

Full Table Scan

---

Rede

Latência

---

Aplicação

Loops ineficientes

---

Ferramentas de Performance

RMF

Resource Measurement Facility

Ferramenta nativa do z/OS.

Monitora:

• CPU

• Memória

• I/O

• Rede

---

SMF

System Management Facility

Gera registros estatísticos.

Exemplo:

SMF Type 30
SMF Type 110
SMF Type 101

---

OMEGAMON

Monitoramento em tempo real.

Muito utilizado para:

• CICS

• DB2

• IMS

• z/OS

---

MainView

Solução Broadcom.

---

Capacity Planning

Não basta analisar o presente.

É necessário prever o futuro.

Perguntas comuns:

O ambiente suporta
o crescimento do próximo ano?

---

Avalia:

• CPU

• Memória

• Storage

• Rede

---

MIPS e MSU

MIPS

Million Instructions Per Second

Métrica histórica.

---

MSU

Million Service Units

Mais utilizada atualmente.

---

zIIP e Performance

Os processadores zIIP ajudam a reduzir carga dos CPs.

Executam:

• Java

• XML

• JSON

• DB2

• Analytics

---

Fluxo:

CP
↓
zIIP
↓
Menos CPU

---

Workload Manager (WLM)

Controla prioridades.

Exemplo:

PIX
↓
Alta Prioridade

Relatório
↓
Baixa Prioridade

---

Performance e Cloud

Hoje também envolve:

APIs
OpenShift
Containers
z/OS Connect
LinuxONE

---

O Papel do Analista de Performance

Ele atua como um "médico do Mainframe".

Analisa:

• Sintomas

• Gargalos

• Tendências

• Crescimento

E propõe otimizações.

---

Curiosidade

Muitas das técnicas modernas de observabilidade utilizadas em Cloud Computing possuem origem em conceitos que os profissionais de Mainframe já utilizavam desde as décadas de 1970 e 1980 através de ferramentas como RMF, SMF e monitores de desempenho.

---

Resumo Rápido

Conceito	Objetivo
CPU	Processamento
Memória	Armazenamento temporário
I/O	Acesso a dados
Rede	Comunicação
Throughput	Volume processado
Latência	Tempo de espera
RMF	Monitoramento
SMF	Estatísticas
OMEGAMON	Tempo real
WLM	Priorização
zIIP	Offload de processamento
Capacity Planning	Planejamento futuro

---

Conclusão

Performance em Mainframe é uma disciplina estratégica que busca maximizar a eficiência dos recursos do IBM Z. Ela envolve monitoramento, análise, tuning e planejamento de CPU, memória, I/O, rede, aplicações COBOL, CICS, IMS e DB2. Dominar esses conceitos é fundamental para garantir que ambientes críticos continuem processando milhões de transações com rapidez, estabilidade e o menor custo possível.