Translate

Mostrar mensagens com a etiqueta buffer pool. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta buffer pool. Mostrar todas as mensagens

sábado, 23 de maio de 2026

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

 

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égiaNo IBM Mainframe
Cache-AsideTSQ/COMMAREA/lookup local
Read-ThroughDB2 Buffer Pool
Write-ThroughCommit síncrono
Write-BehindDeferred write
Refresh-AheadPrefetch
InvalidationCache coherency
Cache WarmingPreload pós IPL
Cache ShardingSysplex distribution
TTLExpiraçã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.”

 

domingo, 10 de maio de 2026

🔥☕ DB2 PERFORMANCE TUNING — O “MOTOR INVISÍVEL” DO MAINFRAME IBM Z

 

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

ProblemaImpacto
TBSCANscan completo
SORTuso pesado de workfile
Hybrid Join ruimCPU explode
List Prefetch excessivoRID pool sofre
Cartesian Joincaos 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 PoolUso
BP0sistema
BP1OLTP
BP2batch
BP32KLOB/XML

☕ Pagesize correta

TipoPage
OLTP4K
Scan grande32K

🔥 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

SintomaCausa
RID overflowpool pequeno
fallback para scanRID cheio
CPU altaexcesso 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âmetroFunção
SRTPOOLmemória do sort
MAXSORT_IN_MEMORYsort em memória
DSMAXdatasets

🚨 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

TipoNível
Rowlinha
Pagepágina
Tabletabela
Tablespacetudo

🚨 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ívelCaracterística
URmais rápido
CScomum
RSconsistente
RRmá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.” 💾🚀

 

sábado, 9 de maio de 2026

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

 

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

sexta-feira, 23 de janeiro de 2026

💥 DB2 - CENÁRIO: CPU EXPLODINDO EM PRODUÇÃO

 

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étricaAntesDepois
CPU🔥 Alto⚡ Baixo
Tempo🐢 Lento🚀 Rápido
I/OAltoReduzido

💣 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

sábado, 29 de novembro de 2025

💣🔥 “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.


terça-feira, 20 de setembro de 2022

Os 50 Comandos do Subsistema Db2 sem Mistérios

 

Bellacosa Mainframe e uma lista de 50 comandos do subsistema db2 sem misterios

☕ Um Café no Bellacosa Mainframe

Os 50 Comandos do Subsistema Db2 sem Mistérios

O guia operacional para o programador COBOL padawan conversar com o coração do Db2 for z/OS

Imagine o seguinte cenário: você terminou seu programa COBOL, passou pelo pré-compilador, compilou, linkeditou, executou o BIND e finalmente colocou o módulo em produção.

Então chega uma mensagem:

DSNT500I RESOURCE UNAVAILABLE

O programa está correto. O SQL está correto. A tabela existe. Mas o tablespace está parado.

Em outro momento, o programa fica esperando durante vários minutos. Não há abend, não há SQLCODE negativo e ninguém sabe exatamente o que está acontecendo. Depois de alguma investigação, descobre-se que uma thread está segurando um lock e bloqueando dezenas de transações.

É nesse ponto que entramos no mundo dos comandos do subsistema Db2.

Esses comandos não são comandos SQL. Eles são ordens operacionais enviadas diretamente ao mecanismo do Db2 for z/OS para consultar, iniciar, parar, alterar, recuperar ou controlar componentes do subsistema.

A IBM define esses comandos como recursos usados para controlar grande parte do ambiente operacional do Db2. Eles podem ser emitidos pelo console do z/OS, pelo SDSF, por uma sessão DSN no TSO, pelo painel DB2 Commands do DB2I e, dependendo da configuração, por terminais IMS, CICS ou aplicações autorizadas. A exceção mais importante é -START DB2, que normalmente precisa ser emitido pelo console do z/OS ou pelo TSO/SDSF. (IBM)


Bellacosa Mainframe e o DB2 na intimidade

1. Antes de começar: SQL não é comando Db2

Um iniciante frequentemente mistura quatro coisas diferentes:

SELECT * FROM CLIENTES;

Isso é uma instrução SQL.

RUNSTATS TABLESPACE DBVENDAS.TSVENDAS;

Isso é uma utility control statement, normalmente executada pelo utilitário DSNUTILB.

BIND PACKAGE(COLLID) MEMBER(PROGRAMA);

Isso é um subcomando do processador DSN.

-DISPLAY DATABASE(DBVENDAS)

Isso é um comando operacional do subsistema Db2.

O hífen inicial é uma pista fundamental:

-DISPLAY
-START
-STOP
-ALTER
-CANCEL
-SET
-RECOVER

Nos exemplos deste artigo, considere que o subsistema se chama DB2P, embora o prefixo usado no console dependa da instalação.

No console, você poderá encontrar algo como:

-DB2P DISPLAY DATABASE(DBVENDAS)

No painel DB2 Commands do DB2I, normalmente será digitado apenas:

-DISPLAY DATABASE(DBVENDAS)

2. Regra de ouro do operador Jedi

Antes de executar qualquer comando que modifique o ambiente:

  1. Execute um DISPLAY.

  2. Leia todas as mensagens retornadas.

  3. Confirme o nome do subsistema.

  4. Confirme o nome do objeto.

  5. Verifique se está em desenvolvimento, homologação ou produção.

  6. Registre o motivo da intervenção.

  7. Tenha um comando de retorno preparado.

  8. Nunca copie comandos cegamente de outra instalação.

O Db2 costuma retornar DSN9022I quando o processamento do comando termina normalmente e DSN9023I quando termina de forma anormal. Porém, não basta procurar apenas a última mensagem: as mensagens anteriores explicam o que realmente aconteceu. (IBM)


Parte I — Comandos de diagnóstico e observação

1. -DISPLAY DATABASE

Para que serve

Exibe o estado de databases, tablespaces, indexspaces e partições.

É provavelmente o comando operacional mais importante para o programador COBOL.

Exemplo

-DISPLAY DATABASE(DBVENDAS)

Para um tablespace específico:

-DISPLAY DATABASE(DBVENDAS) SPACENAM(TSVENDAS)

Para obter informações adicionais:

-DISPLAY DATABASE(DBVENDAS) SPACENAM(TSVENDAS) RESTRICT

Passo a passo

  1. Identifique o database.

  2. Informe opcionalmente o nome do espaço.

  3. Execute o comando.

  4. Procure estados restritivos.

  5. Investigue situações como STOP, COPY, RECP, REORP, RBDP, UTRO ou UTRW.

Vantagem

Permite verificar rapidamente por que uma aplicação não consegue acessar um objeto.

Perigo

Usar curingas muito abrangentes pode produzir uma enorme quantidade de mensagens no console.

-DISPLAY DATABASE(*) SPACENAM(*)

Em produção, isso pode transformar o console em uma cachoeira de mensagens.

A IBM documenta que o comando apresenta informações de status sobre databases Db2 e possui escopo de grupo em ambientes data sharing. (IBM)


2. -DISPLAY THREAD

Para que serve

Mostra as threads que estão conectadas ao Db2.

Uma thread representa o contexto de uma conexão ou unidade de trabalho de uma aplicação. Pode ser uma aplicação TSO, CICS, IMS, batch, stored procedure ou uma conexão distribuída.

Exemplos

-DISPLAY THREAD(*)
-DISPLAY THREAD(*) TYPE(ACTIVE)
-DISPLAY THREAD(*) DETAIL

O que observar

  • authorization ID;

  • plan;

  • correlation ID;

  • connection name;

  • token;

  • status;

  • LUWID;

  • atividade local ou distribuída.

Dica COBOL

Em um job batch, o correlation ID frequentemente ajuda a relacionar a thread ao job ou à aplicação.

Perigo

Não confunda uma thread aparentemente parada com uma thread inútil. Ela pode estar esperando I/O, lock, resposta de rede ou trabalho de outra região.

O comando mostra informações sobre allied threads, database access threads e tarefas paralelas, que podem estar ativas, inativas, indoubt ou postponed. (IBM)


3. -DISPLAY BLOCKERS

Para que serve

Mostra locks e claims mantidos por threads que estão bloqueando determinados objetos.

Exemplo

-DISPLAY BLOCKERS DATABASE(DBVENDAS)
-DISPLAY BLOCKERS DATABASE(DBVENDAS) SPACENAM(TSVENDAS)

Quando usar

  • jobs esperando recursos;

  • SQLCODE -911 ou -913;

  • utility sem conseguir realizar drain;

  • transações CICS acumulando;

  • tablespace que não consegue parar.

Vantagem

Reduz o tempo de investigação de contenção.

Ponto de atenção

O bloqueador nem sempre é o culpado. Pode ser apenas uma aplicação legítima executando uma longa unidade de trabalho.

O comando mostra locks e claims mantidos por threads ativas contra databases, tabelas, índices ou espaços especificados. (IBM)


4. -DISPLAY DDF

Para que serve

Exibe o estado da Distributed Data Facility, responsável pelas conexões distribuídas com o Db2.

Exemplo

-DISPLAY DDF
-DISPLAY DDF DETAIL

Pode mostrar

  • status do DDF;

  • endereço TCP/IP;

  • porta DRDA;

  • número de conexões;

  • número de DBATs;

  • parâmetros de conexão;

  • filas relacionadas a limites.

Uso típico

Uma aplicação Java, API, ferramenta externa ou outro Db2 não consegue conectar-se ao subsistema.

Atenção

DDF ativo não significa que toda conexão funcionará. Ainda podem existir problemas de TCP/IP, RACF, certificados, AT-TLS, location, package ou autorização.

A IBM descreve -DISPLAY DDF como o comando que mostra configuração, status e estatísticas das conexões e threads controladas pelo DDF. (IBM)


5. -DISPLAY GROUP

Para que serve

Exibe informações sobre o data sharing group ou, mesmo fora de um grupo ativo, dados importantes sobre níveis do Db2.

Exemplo

-DISPLAY GROUP
-DISPLAY GROUP DETAIL

Mostra informações como

  • membros;

  • status dos membros;

  • code level;

  • catalog level;

  • function level;

  • coexistência e compatibilidade.

Curiosidade

É um dos primeiros comandos que um especialista executa para descobrir “em que Db2 estou pisando”.

O Db2 pode ter código em um nível, catálogo em outro e function level em outro. A versão comercial isoladamente não conta toda a história.


6. -DISPLAY BUFFERPOOL

Para que serve

Mostra status e características dos buffer pools.

Exemplo

-DISPLAY BUFFERPOOL(BP0)
-DISPLAY BUFFERPOOL(*)
-DISPLAY BUFFERPOOL(BP8K0) DETAIL

O que investigar

  • tamanho atual;

  • page size;

  • thresholds;

  • parâmetros de escrita;

  • situação ativa ou inativa;

  • frames alocados.

Vantagem

Ajuda a verificar se uma alteração de buffer pool foi realmente aplicada.

Desvantagem

O comando não substitui RMF, Statistics Trace ou ferramentas de performance. Ele mostra estado operacional, não toda a história de desempenho.


7. -DISPLAY GROUPBUFFERPOOL

Para que serve

Mostra o estado dos group buffer pools em data sharing.

Exemplo

-DISPLAY GROUPBUFFERPOOL(GBP0)
-DISPLAY GROUPBUFFERPOOL(*) TYPE(GCONN)

Quando é importante

  • problemas de data sharing;

  • falhas de coupling facility;

  • rebuild de GBP;

  • objetos em GBP-dependent;

  • inconsistências entre membros.

Atenção

Este comando pertence ao reino do sysprog e do DBA de infraestrutura. Um programador deve conhecê-lo, mas não alterar um GBP sem um procedimento formal.


8. -DISPLAY LOG

Para que serve

Mostra informações sobre active logs, offload, checkpoints e situação do processo de logging.

Exemplo

-DISPLAY LOG

Pode ajudar a identificar

  • active log corrente;

  • progresso de offload;

  • parâmetros de checkpoint;

  • ocupação ou indisponibilidade de logs;

  • risco de aplicações pararem por falta de espaço de log.

Easter egg operacional

O log é a máquina do tempo do Db2. Sem ele, rollback, restart e recuperação deixam de ser operações confiáveis.

A IBM explica que, quando o Db2 preenche um active log, precisa descarregá-lo para um archive log. Se as aplicações alcançarem o processo de offload, elas podem ser suspensas até que haja espaço disponível. (IBM)


9. -DISPLAY ARCHIVE

Para que serve

Mostra informações sobre archive logs usados como entrada e sobre a atividade de arquivamento.

Exemplo

-DISPLAY ARCHIVE

Ponto de atenção em data sharing

O comando mostra informações do membro no qual foi executado. Para visualizar todos os membros, pode ser necessário executá-lo individualmente em cada um. (IBM)


10. -DISPLAY UTILITY

Para que serve

Mostra o estado das utilities registradas no Db2.

Exemplos

-DISPLAY UTILITY(*)
-DISPLAY UTILITY(UTIL1234)

Pode revelar

  • utility ID;

  • nome da utility;

  • fase atual;

  • objeto processado;

  • contagem de registros;

  • situação parada ou ativa;

  • membro do data sharing group.

Uso típico

Um REORG aparentemente não avança. Antes de cancelar o job, execute DISPLAY UTILITY.

Perigo

A utility pode estar em uma fase crítica ou aguardando drain. Interrompê-la sem entender o estado pode deixar o objeto restrito.


11. -DISPLAY TRACE

Para que serve

Lista traces ativos no Db2.

Exemplo

-DISPLAY TRACE(*)
-DISPLAY TRACE(P)

Tipos comuns

  • statistics;

  • accounting;

  • audit;

  • performance;

  • monitor;

  • global.

Atenção

Tracing custa recursos. Um trace excessivamente detalhado pode aumentar CPU, geração de SMF e volume de dados.


12. -DISPLAY STATS

Para que serve

Exibe estatísticas de uso de determinados recursos e processos internos do Db2.

Exemplo

-DISPLAY STATS

Utilidade

É usado em diagnósticos operacionais específicos, geralmente por DBAs e suporte.

Limitação

Não deve ser confundido com RUNSTATS. DISPLAY STATS consulta estatísticas operacionais; RUNSTATS coleta estatísticas de objetos para catálogo e otimizador.


13. -DISPLAY LOCATION

Para que serve

Mostra informações sobre locations remotas conhecidas pelo Db2.

Exemplo

-DISPLAY LOCATION(*)
-DISPLAY LOCATION(DSNREM01)

Quando usar

  • falha em conexão remota;

  • aplicações DRDA;

  • aliases e locations incorretas;

  • investigação de comunicação entre subsistemas.


14. -DISPLAY PROFILE

Para que serve

Mostra se a função de profiles está ativa.

Exemplo

-DISPLAY PROFILE

O que são profiles

As profile tables permitem aplicar controles e comportamentos a conexões e threads, incluindo limites e regras para aplicações distribuídas.

Atenção

Uma aplicação pode funcionar em homologação e ser limitada em produção por causa de um profile específico.


15. -DISPLAY RLIMIT

Para que serve

Mostra o estado do Resource Limit Facility, tradicionalmente conhecido como governor.

Exemplo

-DISPLAY RLIMIT

Para que serve o governor

Pode limitar ou controlar o consumo estimado de recursos por instruções SQL dinâmicas.

Pegadinha

Um SQL pode estar sintaticamente correto e ter um bom access path, mas ser bloqueado por política de resource limit.


16. -DISPLAY PROCEDURE

Para que serve

Mostra informações e estatísticas sobre stored procedures externas acessadas pelas aplicações.

Exemplo

-DISPLAY PROCEDURE(*)
-DISPLAY PROCEDURE(MEU_SCHEMA.MINHA_PROC)

Uso típico

  • stored procedure não inicia;

  • excesso de chamadas;

  • procedure parada;

  • comportamento inesperado no WLM application environment.


17. -DISPLAY FUNCTION SPECIFIC

Para que serve

Mostra estatísticas sobre funções externas definidas pelo usuário.

Exemplo conceitual

-DISPLAY FUNCTION SPECIFIC(MEU_SCHEMA.MINHA_FUNCAO)

Atenção

O nome específico pode ser diferente do nome SQL usado para chamar a função.


18. -DISPLAY RESTSVC

Para que serve

Mostra o estado dos serviços REST definidos no Db2.

Exemplo

-DISPLAY RESTSVC(*)

Curiosidade

O mesmo Db2 tradicionalmente acessado por COBOL, CICS e batch pode expor operações como serviços REST.

É a velha fortaleza do mainframe abrindo portões controlados para o mundo das APIs.


19. -DISPLAY ACCEL

Para que serve

Mostra informações sobre servidores aceleradores associados ao Db2, como ambientes IBM Db2 Analytics Accelerator.

Exemplo

-DISPLAY ACCEL(*)

Ponto de atenção

Uma query elegível para aceleração pode deixar de ser executada no accelerator quando o servidor está indisponível, dependendo da configuração e do comportamento definido.


20. -DISPLAY ML

Para que serve

Mostra o estado de funções relacionadas ao IBM Db2 AI for z/OS ou ao IBM Z Database Assistant.

Exemplo

-DISPLAY ML

Curiosidade

É um exemplo de como a lista de comandos do Db2 evolui. O velho painel verde agora também conversa com recursos de inteligência artificial.


21. -DISPLAY OTEL

Para que serve

Exibe o estado da integração OpenTelemetry do Db2.

Exemplo

-DISPLAY OTEL

Ponto de atenção

Esse comando depende do nível de código, manutenção e function level aplicáveis ao ambiente. Ele pode não existir em instalações mais antigas.

O catálogo atual do Db2 13 inclui comandos para exibir, iniciar e parar funções OpenTelemetry. (IBM)


22. -DISPLAY DYNQUERYCAPTURE

Para que serve

Mostra monitores ativos de captura de queries dinâmicas.

Exemplo

-DISPLAY DYNQUERYCAPTURE

Utilidade

Ajuda em processos de estabilização de access paths para SQL dinâmico.

Atenção

Isso não é a mesma coisa que olhar o dynamic statement cache. O comando está relacionado aos monitores de captura configurados.


Parte II — Comandos para iniciar componentes

23. -START DB2

Para que serve

Inicializa o subsistema Db2.

Exemplo no console

-DB2P START DB2

Passo a passo simplificado

  1. O z/OS inicia as started tasks do Db2.

  2. O Db2 conecta-se ao IRLM.

  3. Abre BSDS e logs.

  4. Executa restart processing quando necessário.

  5. Recupera unidades de trabalho.

  6. Disponibiliza serviços internos.

  7. Permite conexões de TSO e subsistemas anexados.

Perigo

Não é um simples “ligar banco de dados”. Um restart pode envolver recuperação, backout e resolução de unidades de trabalho.


24. -START DATABASE

Para que serve

Torna um database ou espaço novamente disponível.

Exemplos

-START DATABASE(DBVENDAS)
-START DATABASE(DBVENDAS) SPACENAM(TSVENDAS)
-START DATABASE(DBVENDAS) SPACENAM(TSVENDAS) ACCESS(RW)

Modos de acesso comuns

  • RW: leitura e escrita;

  • RO: somente leitura;

  • UT: acesso para utilities;

  • modos específicos dependem da situação e da sintaxe suportada.

Atenção

Dar START não remove magicamente todos os estados restritivos. Um objeto em RECP, RBDP ou COPY pode exigir uma utility apropriada.

A IBM define esse comando como a forma de tornar o database especificado disponível para uso. (IBM)


25. -START DDF

Para que serve

Inicia a Distributed Data Facility.

Exemplo

-START DDF

Antes de usar

  1. Execute -DISPLAY DDF.

  2. Confirme que o DDF está parado.

  3. Verifique TCP/IP e segurança.

  4. Inicie.

  5. Execute outro -DISPLAY DDF.

Perigo

Iniciar o DDF pode reabrir imediatamente o acesso de centenas de clientes externos.


26. -START TRACE

Para que serve

Inicia traces do Db2.

Exemplo conceitual

-START TRACE(P) CLASS(1,2,3) DEST(SMF)

Atenção máxima

Classes de trace devem ser escolhidas conscientemente. Ativar classes em excesso pode gerar alto volume de SMF e overhead.

Boa prática

Defina antecipadamente:

  • por que o trace será iniciado;

  • qual classe é necessária;

  • qual destino será utilizado;

  • quanto tempo ficará ativo;

  • quem irá pará-lo;

  • como os registros serão analisados.


27. -START PROFILE

Para que serve

Carrega ou recarrega as profile tables para a memória do Db2.

Exemplo

-START PROFILE

Pegadinha

Alterar as tabelas de profile não significa necessariamente que o Db2 já esteja usando a nova configuração. O reload pode ser necessário.


28. -START RLIMIT

Para que serve

Inicia o Resource Limit Facility.

Exemplo conceitual

-START RLIMIT ID=RLST01

Atenção

A sintaxe exata e a tabela utilizada dependem da configuração da instalação.


29. -START PROCEDURE

Para que serve

Ativa ou atualiza a definição de uma stored procedure no cache.

Exemplo

-START PROCEDURE(MEU_SCHEMA.MINHA_PROC)

Uso interessante

Depois de uma alteração autorizada na definição ou no programa externo, o DBA pode usar o comando para atualizar o estado da procedure.


30. -START FUNCTION SPECIFIC

Para que serve

Inicia uma função externa que foi anteriormente parada.

Exemplo conceitual

-START FUNCTION SPECIFIC(MEU_SCHEMA.FUNCAO01)

Limitação

Aplica-se a funções externas suportadas pelo comando, não a qualquer função built-in do Db2.


31. -START RESTSVC

Para que serve

Inicia um serviço REST que estava parado.

Exemplo

-START RESTSVC(COLLECTION.SERVICO)

Ponto de atenção

Iniciar o serviço não corrige problemas de package, autorização, endpoint, certificado ou SQL interno.


32. -START ACCEL

Para que serve

Notifica o Db2 para utilizar determinado servidor acelerador.

Exemplo conceitual

-START ACCEL(*)

Atenção

Deve fazer parte de um procedimento de administração do accelerator, não de uma tentativa aleatória de “fazer query correr mais rápido”.


33. -START ML

Para que serve

Inicia funções ligadas ao Db2 AI for z/OS ou IBM Z Database Assistant.

Exemplo

-START ML

Dependências

O produto correspondente precisa estar instalado e corretamente configurado.


34. -START OTEL

Para que serve

Inicia as funções OpenTelemetry do Db2.

Exemplo

-START OTEL

Uso

Pode fazer parte de uma estratégia moderna de observabilidade distribuída, correlacionando aplicações externas com processamento dentro do Db2.


35. -START DYNQUERYCAPTURE

Para que serve

Inicia captura e monitoramento de SQL dinâmico qualificado para estabilização de access paths.

Exemplo conceitual

-START DYNQUERYCAPTURE

Vantagem

Ajuda a tornar determinados comportamentos de SQL dinâmico mais previsíveis.

Desvantagem

Introduz administração adicional e exige entendimento sobre quais queries estão sendo capturadas.


Parte III — Comandos para parar componentes

36. -STOP DATABASE

Para que serve

Torna databases ou espaços indisponíveis e fecha seus data sets.

Exemplos

-STOP DATABASE(DBVENDAS)
-STOP DATABASE(DBVENDAS) SPACENAM(TSVENDAS)
-STOP DATABASE(DBVENDAS) SPACENAM(TSVENDAS) MODE(QUIESCE)

Passo a passo seguro

  1. Execute DISPLAY DATABASE.

  2. Identifique aplicações usando o objeto.

  3. Verifique blockers e claims.

  4. Escolha o modo adequado.

  5. Execute o STOP.

  6. Confirme o estado.

  7. Execute a manutenção planejada.

  8. Use START DATABASE para restaurar o acesso.

Perigo

Parar um objeto em produção pode causar:

  • SQLCODE -904;

  • transações CICS falhando;

  • jobs batch interrompidos;

  • filas e reprocessamentos;

  • indisponibilidade de APIs.

Nunca use MODE(FORCE) apenas porque MODE(QUIESCE) está demorando.


37. -STOP DB2

Para que serve

Encerra o subsistema Db2.

Exemplo

-STOP DB2 MODE(QUIESCE)

Modos importantes

MODE(QUIESCE) tenta realizar uma parada organizada.

MODE(FORCE) força o encerramento e pode exigir maior processamento de restart posteriormente.

Regra Jedi

FORCE não significa “mais rápido e melhor”. Significa “aceito as consequências operacionais de não esperar”.


38. -STOP DDF

Para que serve

Interrompe a interface distribuída do Db2 com TCP/IP ou VTAM.

Exemplo

-STOP DDF

Efeito

As aplicações locais podem continuar funcionando, mas novas conexões distribuídas serão afetadas e conexões existentes dependerão do modo usado.

Perigo

Pode derrubar acesso de APIs, servidores Java, ferramentas de dados e outros subsistemas.


39. -STOP TRACE

Para que serve

Interrompe traces.

Exemplo conceitual

-STOP TRACE(P) TNO(03)

Boa prática

Sempre guarde o identificador do trace retornado no START TRACE.

O erro clássico é começar um trace e depois ninguém saber qual trace deve ser encerrado.


40. -STOP PROFILE

Para que serve

Desativa a função de profiles.

Exemplo

-STOP PROFILE

Atenção

Desativar profiles pode remover proteções, limites ou comportamentos definidos para várias conexões. Não é apenas uma ação técnica neutra.


41. -STOP RLIMIT

Para que serve

Interrompe o Resource Limit Facility.

Exemplo

-STOP RLIMIT

Risco

SQLs que antes eram controlados pelo governor podem passar a executar sem aquela limitação.


42. -STOP PROCEDURE

Para que serve

Impede que o Db2 aceite novas chamadas para uma ou mais stored procedures.

Exemplo

-STOP PROCEDURE(MEU_SCHEMA.MINHA_PROC)

Uso típico

  • manutenção;

  • correção emergencial;

  • stored procedure causando falhas;

  • preparação para atualização do módulo.


43. -STOP RESTSVC

Para que serve

Impede novas solicitações de descoberta ou invocação de um serviço REST.

Exemplo

-STOP RESTSVC(COLLECTION.SERVICO)

Vantagem

Permite isolar uma API sem necessariamente parar todo o DDF.


Parte IV — Comandos de alteração e controle

44. -ALTER BUFFERPOOL

Para que serve

Altera atributos de buffer pools ativos ou inativos.

Exemplo conceitual

-ALTER BUFFERPOOL(BP8K0) VPSIZE(20000)

Passos recomendados

  1. Execute DISPLAY BUFFERPOOL.

  2. Analise a necessidade.

  3. Avalie memória real e impacto.

  4. Aplique a alteração.

  5. Execute novo DISPLAY.

  6. Monitore paging, hit ratio, I/O e desempenho.

Vantagem

Certos parâmetros podem ser ajustados dinamicamente.

Desvantagem

Aumentar buffer pool indiscriminadamente pode pressionar a memória do sistema e prejudicar o conjunto, mesmo que um objeto isolado pareça melhorar.


45. -ALTER GROUPBUFFERPOOL

Para que serve

Altera atributos de group buffer pools em data sharing.

Exemplo conceitual

-ALTER GROUPBUFFERPOOL(GBP0) ...

Atenção máxima

Mudanças em GBP podem afetar todos os membros e milhares de objetos compartilhados. É território de change control, capacity planning e especialistas em Parallel Sysplex.


46. -ALTER UTILITY

Para que serve

Altera certos parâmetros de uma utility que já está em execução.

Pode ser usado em algumas execuções de:

  • REORG SHRLEVEL REFERENCE;

  • REORG SHRLEVEL CHANGE;

  • REBUILD SHRLEVEL CHANGE.

Exemplo conceitual

-ALTER UTILITY(UTIL1234) ...

Vantagem

Permite ajustar determinados comportamentos sem terminar e reiniciar toda a utility.

Limitação

Não é possível alterar qualquer parâmetro. Somente opções explicitamente suportadas pela utility e pela fase atual.


47. -MODIFY DDF

Para que serve

Modifica configurações e comportamentos operacionais do DDF.

Exemplo conceitual

-MODIFY DDF PKGREL(BNDOPT)

Possíveis usos

  • ajustar comportamento de packages;

  • controlar determinadas características das conexões;

  • resetar estatísticas;

  • modificar parâmetros suportados dinamicamente.

Perigo

Uma alteração aparentemente pequena pode afetar milhares de conexões distribuídas.


48. -SET SYSPARM

Para que serve

Altera parâmetros do subsistema que podem ser atualizados online.

Exemplo conceitual

-SET SYSPARM ...

Importante

Nem todo ZPARM é dinâmico.

Alguns parâmetros:

  • aceitam alteração online;

  • exigem restart;

  • dependem de function level;

  • possuem relacionamentos com outros parâmetros.

Boa prática

Registre tanto a mudança dinâmica quanto a atualização permanente nos parâmetros de instalação. Caso contrário, o valor pode retornar ao anterior no próximo restart.


49. -SET LOG

Para que serve

Controla aspectos críticos do logging.

Pode ser usado para:

  • alterar frequência de checkpoint;

  • suspender logging;

  • retomar logging;

  • adicionar active log;

  • remover active log.

A IBM confirma essas funções na documentação do comando. (IBM)

Exemplos conceituais

-SET LOG LOGLOAD(500000)
-SET LOG SUSPEND
-SET LOG RESUME

Perigo extremo

SET LOG SUSPEND não é um botão de pausa casual. Ele participa de procedimentos específicos, frequentemente relacionados a cópias consistentes e operações de storage.

Uma suspensão indevida pode paralisar atualizações e causar um incidente de grandes proporções.


Parte V — Comandos de intervenção, emergência e recuperação

50. -CANCEL THREAD

Para que serve

Cancela o processamento de uma thread local ou distribuída específica.

Procedimento correto

Primeiro localize a thread:

-DISPLAY THREAD(*) TYPE(ACTIVE) DETAIL

Identifique o token.

Depois, somente com autorização:

-CANCEL THREAD(token)

Para determinados casos distribuídos, pode ser usado:

-CANCEL DDF THREAD(token)

A IBM recomenda usar o DISPLAY THREAD DETAIL para identificar uma thread distribuída problemática antes do cancelamento. (IBM)

O que pode acontecer

  • rollback da unidade de trabalho;

  • liberação de locks;

  • abend ou erro na aplicação;

  • mensagens para CICS, IMS ou cliente remoto;

  • recuperação de recursos;

  • aumento temporário de logging pelo backout.

Perigo

Cancelar a thread errada pode derrubar:

  • fechamento contábil;

  • processamento de folha;

  • transferência financeira;

  • utility;

  • stored procedure;

  • transação crítica;

  • aplicação de outro usuário.

Regra de ouro

CANCEL THREAD não é ferramenta de performance. É uma intervenção operacional.


Seis comandos extras que você precisa conhecer

Embora a lista principal tenha cinquenta comandos, existem comandos que não podem ficar fora do seu radar.

-ARCHIVE LOG

Fecha o active log atual, passa para o próximo e inicia o processo de offload conforme a configuração.

-ARCHIVE LOG

Com quiesce:

-ARCHIVE LOG MODE(QUIESCE)

MODE(QUIESCE) tenta fazer com que as unidades de atualização alcancem commit, criando um ponto consistente antes do arquivamento. Isso pode suspender temporariamente atividades de atualização e deve ser utilizado com planejamento. (IBM)


-TERM UTILITY

Termina uma utility registrada e libera os recursos associados.

-TERM UTILITY(UTIL1234)

Antes:

-DISPLAY UTILITY(UTIL1234)

Perigo

O job pode ter terminado no JES, mas a utility continuar registrada no Db2. Por outro lado, terminar uma utility no momento errado pode deixar objetos em estados restritivos.


-RECOVER INDOUBT

Resolve threads que ficaram indoubt porque Db2 e o coordenador da transação não conseguiram determinar automaticamente se a unidade deveria receber commit ou rollback.

-RECOVER INDOUBT ...

Perigo extremo

Escolher incorretamente entre commit e abort pode gerar inconsistência lógica entre sistemas participantes.

Esse comando exige evidência, coordenação e procedimento de recuperação.


-RECOVER POSTPONED

Completa backout de unidades de recuperação que ficaram como postponed abort durante um restart anterior.

-RECOVER POSTPONED

É um comando de recuperação do subsistema, não um substituto da utility RECOVER.


-RECOVER BSDS

Reestabelece o dual BSDS quando uma das cópias foi desabilitada por erro de data set.

-RECOVER BSDS

O BSDS contém informações vitais sobre logs, checkpoints e restart. Mexer nele sem conhecimento especializado equivale a abrir o painel de navegação da nave durante uma tempestade hyperspace.


-ACCESS DATABASE

Pode forçar a abertura física de espaços, remover certos estados relacionados a GBP ou externalizar informações mantidas em memória, dependendo do MODE.

-ACCESS DATABASE(DBVENDAS) SPACENAM(TSVENDAS) MODE(OPEN)

A sintaxe e os modos devem ser confirmados para o nível específico do Db2.


Um roteiro prático para investigar “RESOURCE UNAVAILABLE”

Considere o erro:

DSNT500I
RESOURCE UNAVAILABLE
REASON 00C90081
TYPE 00000200
NAME DBVENDAS.TSVENDAS

Passo 1 — Não chute

Leia:

  • reason code;

  • resource type;

  • resource name;

  • horário;

  • job ou transação afetada.

Passo 2 — Verifique o objeto

-DISPLAY DATABASE(DBVENDAS) SPACENAM(TSVENDAS) RESTRICT

Passo 3 — Procure utility

-DISPLAY UTILITY(*)

Passo 4 — Procure bloqueadores

-DISPLAY BLOCKERS DATABASE(DBVENDAS) SPACENAM(TSVENDAS)

Passo 5 — Verifique threads

-DISPLAY THREAD(*) TYPE(ACTIVE) DETAIL

Passo 6 — Descubra a causa

O objeto pode estar:

  • parado administrativamente;

  • aguardando recovery;

  • esperando COPY;

  • esperando REORG;

  • em uso por utility;

  • bloqueado por aplicação;

  • restrito por falha anterior.

Passo 7 — Aplique a solução correta

Somente se o objeto estiver apenas parado e houver autorização:

-START DATABASE(DBVENDAS) SPACENAM(TSVENDAS) ACCESS(RW)

Se estiver em RECP, por exemplo, dar START não substitui a recuperação necessária.


Exemplo de execução por JCL

Comandos Db2 podem ser enviados em batch por meio do processador DSN, dependendo das autorizações e da configuração da instalação.

//DB2CMD  JOB (ACCT),'DB2 COMMAND',
//             CLASS=A,
//             MSGCLASS=X,
//             NOTIFY=&SYSUID
//*
//CMDSTEP  EXEC PGM=IKJEFT01,DYNAMNBR=20
//STEPLIB  DD DISP=SHR,DSN=DB2P.SDSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN  DD *
  DSN SYSTEM(DB2P)
  -DISPLAY DATABASE(DBVENDAS) SPACENAM(TSVENDAS)
  -DISPLAY DDF
  -DISPLAY LOG
  END
/*

Explicação linha por linha

PGM=IKJEFT01

Executa o Terminal Monitor Program do TSO em batch.

DYNAMNBR=20

Reserva alocações dinâmicas para a execução.

STEPLIB

Aponta para a biblioteca de load modules do Db2. O nome varia em cada instalação.

SYSTSPRT

Recebe a saída produzida pela sessão TSO e pelo processador DSN.

SYSPRINT

Recebe mensagens adicionais de programas executados.

SYSUDUMP

Recebe dump em caso de abend.

SYSTSIN

Contém os comandos de entrada para a sessão TSO batch.

DSN SYSTEM(DB2P)

Abre uma sessão com o subsistema indicado.

-DISPLAY ...

Envia o comando operacional ao Db2.

END

Encerra a sessão DSN.

Atenção

Não coloque comandos destrutivos em um JCL genérico deixado em uma biblioteca compartilhada. Um simples submit acidental pode transformar um exemplo didático em incidente.


Tabela de bolso do programador COBOL padawan

SintomaPrimeiro comando
Objeto indisponível-DISPLAY DATABASE
Programa esperando-DISPLAY THREAD
Suspeita de lock-DISPLAY BLOCKERS
API não conecta-DISPLAY DDF
Utility travada-DISPLAY UTILITY
Problema de logging-DISPLAY LOG
Dúvida sobre nível do Db2-DISPLAY GROUP
Stored procedure parada-DISPLAY PROCEDURE
Serviço REST indisponível-DISPLAY RESTSVC
Suspeita de trace esquecido-DISPLAY TRACE

Erros clássicos de iniciantes

1. Executar START DATABASE para qualquer estado restritivo

Nem todo estado é resolvido por START. Alguns exigem COPY, RECOVER, REORG, REBUILD INDEX, CHECK DATA ou outra utility.

2. Usar CANCEL THREAD sem identificar o dono

O token é apenas o identificador técnico. Você também precisa saber:

  • qual aplicação;

  • qual unidade de negócio;

  • qual transação;

  • qual impacto;

  • qual rollback será provocado.

3. Confundir job cancelado com utility terminada

Cancelar o job no JES não garante que todos os recursos e registros da utility foram eliminados do Db2.

4. Usar STOP DATABASE(*)

Curingas são poderosos. Em produção, poder sem escopo é perigo.

5. Usar MODE(FORCE) por impaciência

Se o quiesce não termina, existe uma razão: claims, threads, units of work ou aplicações ainda estão utilizando o recurso.

6. Olhar apenas DSN9022I

O comando pode ter terminado normalmente, mas cada objeto solicitado pode apresentar estado diferente. Leia a resposta completa.

7. Copiar sintaxe de outra versão

Comandos, opções e comportamentos podem variar conforme:

  • versão;

  • function level;

  • APARs e PTFs;

  • modo data sharing;

  • parâmetros locais;

  • produtos adicionais instalados.

O Db2 13 recebe capacidades por function levels e manutenção contínua; portanto, “é Db2 13” não define sozinho todas as funções disponíveis. (IBM)


Vantagens dos comandos do subsistema

  • resposta operacional imediata;

  • integração com console e automação;

  • grande capacidade de diagnóstico;

  • controle granular de componentes;

  • suporte a ambientes data sharing;

  • possibilidade de operação por TSO, SDSF, DB2I e batch;

  • manutenção sem restart para diversas configurações;

  • visibilidade sobre threads, locks, logs e utilities.

Desvantagens e riscos

  • exigem autoridade elevada;

  • alguns comandos têm impacto sistêmico;

  • mensagens podem ser complexas;

  • sintaxe muda conforme o comando;

  • curingas podem ampliar demais o escopo;

  • ações forçadas podem gerar longos rollbacks;

  • alterações dinâmicas podem ser perdidas após restart;

  • um comando correto no subsistema errado continua sendo um comando perigoso;

  • data sharing exige atenção ao escopo de membro ou grupo.


O easter egg final: o hífen que separa dois mundos

Para o programador COBOL, o Db2 costuma parecer uma caixa onde entram instruções SQL:

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CONTA
    WHERE NUM_CONTA = :WS-CONTA
END-EXEC.

Mas, por trás dessa consulta, existe uma cidade inteira:

  • threads sendo criadas;

  • locks sendo negociados;

  • pages entrando em buffer pools;

  • logs registrando mudanças;

  • checkpoints delimitando recuperação;

  • utilities reorganizando objetos;

  • DDF conversando com clientes externos;

  • IRLM controlando concorrência;

  • data sharing coordenando membros;

  • stored procedures executando em ambientes WLM;

  • traces registrando o caminho percorrido.

Os comandos do subsistema são as janelas da torre de controle dessa cidade.

O programador iniciante não precisa ter autoridade para executar todos eles. Precisa, porém, saber que existem, compreender suas respostas e conversar com operadores, DBAs e sysprogs usando a linguagem correta.

Quando alguém disser:

“A aplicação está travada, vamos cancelar o job.”

O padawan treinado perguntará:

“Já verificamos a thread, o blocker, o estado do tablespace e a utility registrada?”

Nesse instante, ele deixa de ser apenas alguém que escreve EXEC SQL.

Ele começa a compreender o Db2 como subsistema operacional — e dá seu primeiro passo para se tornar um verdadeiro Jedi do mainframe.

A lista segue a referência atual do Db2 13 for z/OS, mas exemplos que alteram o ambiente devem ser ajustados às autorizações, function level e padrões operacionais da instalação. (IBM)