Translate

Mostrar mensagens com a etiqueta db2 z/os. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta db2 z/os. Mostrar todas as mensagens

quarta-feira, 13 de maio de 2026

🔥☕ DB2 COMMANDS NO IBM Z — A “SALA DE CONTROLE” DO MAINFRAME QUE QUASE NINGUÉM DOMINA 💾🚨

 

Bellacosa Mainframe apresenta o Db2 Commands

🔥☕ DB2 COMMANDS NO IBM Z — A “SALA DE CONTROLE” DO MAINFRAME QUE QUASE NINGUÉM DOMINA 💾🚨

Existe uma enorme diferença entre:

  • usar DB2,
    e

  • controlar o DB2.

A maioria dos profissionais conhece:

  • SQL,

  • SELECT,

  • tabelas,

  • índices,

  • packages.

Mas poucos realmente entendem o universo dos:

🔥 DB2 COMMANDS

E é exatamente aí que mora o verdadeiro poder operacional do IBM Z.

Porque quando:

  • o online trava,

  • o batch explode,

  • o CPU dispara,

  • o lock congela produção,

  • o DDF enlouquece,

  • o bufferpool satura,

não é o SQL que salva o ambiente.

É o operador que conhece:

-DISPLAY
-START
-STOP
-RECOVER
-MODIFY
-TRACE

E consegue enxergar o subsystem “por dentro”.


💾 O QUE SÃO DB2 COMMANDS?

Os DB2 Commands são comandos operacionais do Db2 for z/OS usados para:

  • monitoramento,

  • administração,

  • recovery,

  • troubleshooting,

  • tuning,

  • automação,

  • controle do subsystem.

Eles podem ser executados:

  • no SDSF,

  • DB2I,

  • console z/OS,

  • batch,

  • CICS,

  • IMS,

  • TSO,

  • programas autorizados.


🔥 A GRANDE VERDADE

O DB2 no Mainframe não é apenas:

SELECT * FROM CLIENTES

Ele é:

  • locking engine,

  • recovery engine,

  • log manager,

  • memory manager,

  • distributed server,

  • transaction coordinator,

  • storage subsystem.

E os comandos são o “painel de engenharia” desse motor gigantesco.


🚨 O COMANDO MAIS IMPORTANTE: DISPLAY

Quase tudo começa com:

-DISPLAY

ou forma curta:

-DIS

Esse comando possui dezenas de variações.

Cada uma revela uma parte diferente da “anatomia” do DB2.


🔥 DISPLAY THREAD — O ECG DO DB2

Comando

-DIS THREAD(*)

💾 O QUE ELE MOSTRA?

Threads ativas:

  • CICS,

  • batch,

  • DDF,

  • TSO,

  • IMS,

  • utilities.


🧠 O QUE É UMA THREAD?

É uma unidade ativa de execução DB2.

Pense como:

“uma conversa acontecendo agora com o banco”.


🚨 O QUE O DBA ANALISA?

WAIT

Pode indicar:

  • lock,

  • I/O lento,

  • deadlock.


CPU ALTÍSSIMA

Uma única thread pode:

  • consumir MSU,

  • destruir zIIP,

  • travar subsystem.


THREADS ZUMBI

Conexões:

  • abertas,

  • sem commit,

  • esquecidas pela aplicação.


💥 CENÁRIO REAL

Aplicação Java:

  • abre milhares de conexões DDF,

  • não fecha corretamente.

Resultado:

-DIS THREAD(*)

mostra:

  • avalanche de threads,

  • consumo absurdo,

  • risco subsystem.


🔥 DISPLAY DATABASE — A RADIOGRAFIA DO STORAGE LÓGICO

Comando

-DIS DB(*)

ou:

-DIS DATABASE(DBPROD)

💾 O QUE ELE ENTREGA?

Mostra:

  • tablespaces,

  • status,

  • pendências,

  • utilities,

  • recovery,

  • states críticos.


🚨 ESTADOS MAIS IMPORTANTES

EstadoSignificado
RWRead/Write
STOPParado
RORead Only
UTUtility rodando
COPYBackup pendente
CHKPCheck pending
RECPRecovery pending

💣 RECP — O PESADELO

Recovery Pending significa:

o objeto não pode ser usado.

Pode ocorrer após:

  • LOAD falho,

  • recover incompleto,

  • corrupção.


🔥 DISPLAY BUFFERPOOL — O RAIO-X DA MEMÓRIA

Comando

-DIS BPOOL(*)

💾 O QUE É BUFFERPOOL?

É o cache inteligente do DB2.

Armazena:

  • páginas,

  • índices,

  • dados acessados recentemente.


🚨 O QUE O SYSPOG OBSERVA?

HIT RATIO

Baixo hit ratio:

  • mais I/O,

  • mais disco,

  • mais CPU.


PGFIX(NO)

Pode gerar:

  • paging,

  • overhead CPU.


VPSIZE PEQUENO

Causa:

  • sync I/O,

  • gargalo físico.


💥 A VERDADE INCÔMODA

Muitos problemas “de SQL” são:

problemas de bufferpool.


🔥 DISPLAY DDF — O PULMÃO DISTRIBUÍDO

Comando

-DIS DDF

💾 O QUE É DDF?

Distributed Data Facility.

Responsável por:

  • JDBC,

  • APIs,

  • microservices,

  • Linux,

  • cloud,

  • aplicações externas.


🚨 O QUE PODE DAR ERRADO?

CONDBAT ESGOTADO

Muitas conexões simultâneas.


THREADS DISTRIBUÍDAS PRESAS

Pode indicar:

  • problema TCP/IP,

  • timeout,

  • Java pool ruim.


DDF STOPPED

🔥 desastre moderno.

APIs param imediatamente.


🔥 DISPLAY LOCKS — O DETETIVE DO CRIME

Comando

-DIS LOCKS

💾 O QUE ELE REVELA?

  • locks,

  • waits,

  • deadlocks,

  • recursos presos.


💥 CENÁRIO CLÁSSICO

Batch:

UPDATE CLIENTES

sem commit adequado.

Resultado:

  • CICS trava,

  • PIX para,

  • ATM congela.

DBA roda:

-DIS LOCKS

e encontra:

  • o “assassino” da produção 😄


🔥 DISPLAY UTILITY — O CENTRO CIRÚRGICO

Comando

-DIS UTIL(*)

💾 UTILITIES IMPORTANTES

UtilityFunção
REORGReorganização
COPYBackup
LOADCarga
RUNSTATSEstatísticas
RECOVERRecovery

🚨 O QUE O DBA PROCURA?

Utility parada

Pode indicar:

  • falta espaço,

  • lock,

  • erro I/O.


REORG ETERNA

Talvez:

  • tablespace gigantesca,

  • SORT insuficiente,

  • disco saturado.


🔥 DISPLAY LOG — O DNA DO DB2

Comando

-DIS LOG

💾 O QUE ANALISAR?

  • active logs,

  • archive logs,

  • checkpoints,

  • offload,

  • dual logging.


🚨 QUANDO O LOG SOFRE…

O subsystem inteiro sofre:

  • commits lentos,

  • rollback lento,

  • recover piora,

  • throughput cai.


💣 O LOG É O “SISTEMA NERVOSO” DO DB2

Sem log saudável:

não existe integridade transacional.


🔥 ADVISORY STATES — O DB2 TENTANDO TE AVISAR

Comando

-DIS DB(*) SPACENAM(*) ADVISORY

💾 O QUE É ADVISORY?

O DB2 dizendo:

“isso ainda funciona… mas vai piorar.”


🚨 AREO*

Advisory REORG Pending.

O DB2 recomenda:

REORG

🚨 ARBDP

Advisory Rebuild Pending.

Índice precisa rebuild.


💥 O QUE ACONTECE SE IGNORAR?

  • access path degrada,

  • CPU sobe,

  • scans aumentam,

  • overflow explode.


🔥 LPL — QUANDO O DB2 ENTRA EM MODO SOBREVIVÊNCIA

Comando

-DIS DB(DBPROD) SPACENAM(*) LPL

💾 LPL = LOGICAL PAGE LIST

Lista páginas:

  • danificadas,

  • inconsistentes,

  • problemáticas.


🚨 COMO ISSO ACONTECE?

  • falha I/O,

  • corrupção,

  • queda sistema,

  • escrita interrompida.


💥 IMPACTO

  • SQLCODE,

  • abends,

  • indisponibilidade,

  • recover obrigatório.


🔥 START E STOP — O “PODER ABSOLUTO”

START DATABASE

-START DB(DBPROD)

Disponibiliza objeto.


STOP DATABASE

-STOP DB(DBPROD)

Indisponibiliza objeto.


🚨 USADO EM:

  • maintenance,

  • recovery,

  • migração,

  • REORG,

  • troubleshooting.


💣 UM STOP ERRADO EM PRODUÇÃO…

…vira reunião de crise 😄


🔥 CANCEL THREAD — O BOTÃO VERMELHO

Comando

-CANCEL THREAD(token)

💾 PARA QUE SERVE?

Mata:

  • thread travada,

  • SQL infinito,

  • aplicação congelada.


🚨 RISCO

Cancelar thread:

  • pode gerar rollback gigante,

  • lock storm,

  • pressão de log.


🔥 TRACE — O MODO CSI DO DB2

Comando

-START TRACE

💾 O QUE É TRACE?

Captura:

  • eventos internos,

  • IFCIDs,

  • waits,

  • SQL,

  • locking,

  • performance.


🚨 PROBLEMA

Trace excessivo:

  • consome CPU,

  • gera overhead,

  • pode piorar produção.


🔥 DSN — A PORTA DE ENTRADA DO DB2

Comando

DSN SYSTEM(DB9G)

💾 O QUE ELE FAZ?

Inicia sessão DB2 sob TSO.


🚨 SE DER ERRO

IKJ56500I COMMAND DSN NOT FOUND

normalmente:

  • SDSNLOAD ausente,

  • STEPLIB errada.


💾 SDSNLOAD — O “CORAÇÃO” DO DB2 BATCH

Contém:

  • DSN,

  • utilities,

  • runtime,

  • SPUFI,

  • módulos DB2.

Sem SDSNLOAD:

não existe DB2 batch.


🔥 IKJEFT01 — O CANIVETE SUÍÇO

Programa clássico usado para:

  • batch DB2,

  • SPUFI,

  • RUN,

  • BIND,

  • REBIND,

  • comandos DISPLAY.


💥 EXEMPLO REAL

//STEP1 EXEC PGM=IKJEFT01
//STEPLIB DD DISP=SHR,DSN=DSN910.SDSNLOAD
//SYSTSIN DD *
 DSN SYSTEM(DB9G)
 -DIS THREAD(*)
 END
/*

🔥 O QUE SEPARA O OPERADOR COMUM DO VETERANO

O iniciante:

  • olha dashboard.

O veterano:

  • olha threads,

  • logs,

  • locks,

  • utilities,

  • bufferpools,

  • advisory states,

  • DDF,

  • recovery.

Porque ele sabe:

o DB2 SEMPRE avisa antes do desastre.


☕ O VERDADEIRO PODER DO MAINFRAME

No mundo distribuído:

  • reiniciam servidor.

No IBM Z:

  • analisam causa raiz.

E os DB2 Commands continuam sendo:

  • rápidos,

  • leves,

  • resilientes,

  • precisos,

  • praticamente eternos.

Décadas depois…
o terminal 3270 ainda continua revelando tudo para quem sabe ler os sinais do subsystem DB2 💾🔥

terça-feira, 12 de maio de 2026

🔥☕ DB2 COMMANDS AVANÇADOS NO IBM Z — O QUE ESSES COMANDOS REALMENTE REVELAM SOBRE A SAÚDE DO MAINFRAME 💾🚨

 

Bellacosa Mainframe Db2 avançado para um sysprog

🔥☕ DB2 COMMANDS AVANÇADOS NO IBM Z — O QUE ESSES COMANDOS REALMENTE REVELAM SOBRE A SAÚDE DO MAINFRAME 💾🚨

A tela que você mostrou agora já entra em um nível MUITO mais avançado do DB2 z/OS.

Aqui não estamos mais falando apenas de:

-DIS THREAD(*)

Agora estamos entrando no território de:

  • troubleshooting pesado,

  • análise recovery,

  • pending states,

  • advisory states,

  • limbo pages,

  • tablespaces problemáticas,

  • diagnóstico profundo de storage DB2.

Esses são comandos típicos de:

  • DBA senior,

  • Sysprog,

  • suporte de produção crítica,

  • recovery team,

  • performance specialists.


🔥 CMD 1 — O “RAIO-X GLOBAL” DAS DATABASES

Comando

-DIS DB(*) SP(*) RESTRICT LIMIT(*)

💾 O QUE ELE FAZ?

Esse comando:

  • percorre TODAS as databases,

  • mostra TODOS os spaces,

  • filtra objetos em estado RESTRICT,

  • sem limite de quantidade.


🧠 EXPLICAÇÃO DOS PARÂMETROS

ParâmetroSignificado
DB(*)Todas as databases
SP(*)Todos os spaces
RESTRICTMostra objetos restritos
LIMIT(*)Sem limite de retorno

🚨 O QUE É RESTRICT?

Estados RESTRICT indicam:

  • objeto parcialmente indisponível,

  • utility incompleta,

  • recovery necessário,

  • inconsistência operacional.


💥 CENÁRIOS REAIS

Após falha de REORG

Você pode encontrar:

RESTRICT

indicando:

  • tablespace inconsistente.


Após falha LOAD

O objeto pode:

  • aceitar leitura,

  • mas bloquear update.


🔥 O QUE O SYSPOG PROCURA?

  • objetos presos,

  • utilities abandonadas,

  • estados recovery,

  • pendências ocultas.


🔥 CMD 2 — DISPLAY THREAD

Comando

-DIS THREAD(*)

💾 O COMANDO MAIS IMPORTANTE DO DB2

Esse comando mostra:

  • threads ativas,

  • conexões CICS,

  • batch,

  • TSO,

  • DDF,

  • waits,

  • CPU.


🚨 O QUE ANALISAR?

WAIT

Pode indicar:

  • lock,

  • I/O lento,

  • deadlock.


THREAD ZUMBI

Thread ativa sem progresso:

  • aplicação travada,

  • commit preso,

  • problema rede DDF.


THREAD MASSIVA

Uma única thread:

  • consumindo CPU absurda,

  • SQL ruim,

  • tablescan gigante.


🔥 CMD 3 — DISPLAY DATABASE OVERVIEW

Comando

-DISPLAY DATABASE(DSN8D13A) SPACE(*) OVERVIEW

💾 O QUE É OVERVIEW?

Mostra uma visão resumida:

  • status,

  • pendências,

  • utilities,

  • estados críticos.

Sem detalhar cada partição profundamente.


🎯 OBJETIVO

Obter diagnóstico rápido.

Muito usado em:

  • incidentes,

  • bridge call,

  • troubleshooting urgente.


💥 O QUE APARECE?

CampoSignificado
RWRead Write
RORead Only
STOPParado
UTUtility
CHKPCheck Pending

🚨 EXEMPLO REAL

Se aparecer:

UTRO

pode indicar:

  • utility rodando,

  • objeto somente leitura.


🔥 CMD 4 — LIST TABLESPACES SHOW DETAIL

Comando

-LIST TABLESPACES SHOW DETAIL

💾 O QUE ELE FAZ?

Lista:

  • tablespaces,

  • atributos,

  • detalhes físicos,

  • status internos.


🧠 INFORMAÇÕES IMPORTANTES

Pode mostrar:

  • DSSIZE,

  • PRIQTY,

  • SECQTY,

  • SEGSIZE,

  • bufferpool,

  • locksize,

  • partitioning.


🚨 MUITO USADO PARA

  • capacity planning,

  • tuning,

  • growth analysis,

  • storage troubleshooting.


💥 O DBA PROCURA

Tablespace gigante

Pode exigir:

  • reparticionamento,

  • compressão,

  • REORG.


Bufferpool inadequado

Pode gerar:

  • I/O excessivo,

  • CPU alta.


🔥 CMD 5 — DISPLAY DATABASE COM ADVISORY

Comando

-DISPLAY DATABASE(DSN8D13A) SPACENAM(*) LIMIT(*) ADVISORY(ARBDP,AREO*)

💾 ESSE É PESADO 😄

Aqui entramos em:

estados advisory.


🧠 O QUE É ADVISORY?

Não significa falha imediata.

Significa:

  • DB2 recomenda ação corretiva.


🚨 ARBDP

Advisory Rebuild Pending

Indica:

  • índice precisa rebuild.

Pode ocorrer:

  • após recover,

  • após falha,

  • inconsistência index.


🚨 AREO*

Advisory REORG Pending

O DB2 recomenda:

REORG

💥 POR QUE ISSO IMPORTA?

Mesmo funcionando:

  • performance degrada,

  • overflow aumenta,

  • access path piora,

  • CPU sobe.


🔥 SINTOMA CLÁSSICO

Aplicação:

“está ficando lenta”

DBA roda:

-DISPLAY DATABASE ... ADVISORY

e encontra:

AREO*

🔥 CMD 6 — DISPLAY DATABASE GLOBAL ADVISORY

Comando

-DISPLAY DATABASE(*) SPACENAM(*) LIMIT(*) ADVISORY

💾 O “CAÇA-PROBLEMAS” GLOBAL

Esse comando varre:

TODO o subsystem DB2.


🚨 O QUE ELE PROCURA?

  • AREO

  • ARBDP

  • RBDP

  • CHKP

  • COPY

  • pending states


💥 MUITO USADO EM:

  • health checks,

  • automação,

  • auditoria,

  • pré-manutenção,

  • pré-upgrade.


🔥 EM GRANDES BANCOS

Esse comando roda:

  • automaticamente,

  • várias vezes ao dia.


🔥 CMD 7 — LPL (Logical Page List)

Comando

-DISPLAY DATABASE(DSN8D13A) SPACENAM(*) LIMIT(*) LPL

💾 AGORA ENTRAMOS NO MODO “CIRURGIA CARDÍACA” 😄

LPL =

Logical Page List.


🚨 O QUE É LPL?

Lista páginas:

  • danificadas,

  • inconsistentes,

  • com problema recovery.


💥 COMO UMA PÁGINA ENTRA EM LPL?

  • falha I/O,

  • corrupção,

  • abend,

  • falha hardware,

  • escrita incompleta,

  • recover interrompido.


🚨 IMPACTO

Objetos em LPL:

  • podem ficar indisponíveis,

  • gerar SQLCODE,

  • causar abends,

  • travar aplicações.


🔥 O DBA PROCURA

Quantidade de páginas afetadas

Se poucas:

  • recover localizado.

Se muitas:

  • desastre potencial.


💣 COMANDOS ASSOCIADOS

Após detectar LPL:

Pode ser necessário:

-RECOVER
-START DB(...)
-STOP DB(...)

🔥 O QUE ESSA TELA ENSINA?

Essa tela é praticamente:

um mapa de sobrevivência do DB2.

Ela mostra:

  • diagnóstico,

  • recovery,

  • saúde,

  • inconsistência,

  • tuning,

  • pending states,

  • gargalos ocultos.


☕ A GRANDE VERDADE DO DB2 z/OS

O DB2 raramente “morre do nada”.

Antes do desastre ele:

  • avisa,

  • marca pending,

  • cria advisory,

  • registra utility,

  • sinaliza REORG,

  • aponta rebuild,

  • mostra waits,

  • denuncia locks.

O problema é:

pouca gente olha os comandos 😄


🚀 O QUE UM SYSPOG VETERANO FARIA?

Sequência clássica:

-DIS THREAD(*)
-DIS DB(*) SP(*) RESTRICT
-DIS UTIL(*)
-DIS LOG
-DIS BPOOL(*)
-DIS DATABASE(*) ADVISORY

Em poucos minutos ele consegue enxergar:

  • saúde do subsystem,

  • pressão operacional,

  • risco recovery,

  • gargalos,

  • objetos degradados,

  • ameaças à produção.

E isso…
diretamente do velho terminal 3270 💾🔥

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

 

quarta-feira, 6 de maio de 2026

🔥☕ COUPLING FACILITY — O “CÉREBRO COLETIVO” DOS MAINFRAMES IBM z/OS ☕🔥

Bellacosa Mainframe mergulha no sysplex e comenta sobre CF coupling facility

🔥☕ COUPLING FACILITY — O “CÉREBRO COLETIVO” DOS MAINFRAMES IBM z/OS ☕🔥

O QUE TODO PROGRAMADOR COBOL PADAWAN PRECISA ENTENDER SOBRE O CORAÇÃO DO SYSPLEX

Imagine o seguinte cenário, jovem Padawan do COBOL:

Você possui:

  • vários mainframes IBM zSeries
  • executando o mesmo sistema z/OS
  • compartilhando banco Db2
  • compartilhando filas CICS
  • compartilhando cache
  • compartilhando locks
  • compartilhando discos DASD

…e todos precisam conversar em tempo real sem virar caos.

🔥 É aí que nasce a Coupling Facility (CF).


☕ O QUE É A COUPLING FACILITY?

A Coupling Facility é um componente especializado do ambiente IBM Parallel Sysplex.

Ela funciona como:

  • memória compartilhada ultra rápida
  • coordenador de sincronismo
  • gerenciador de locks
  • cache compartilhado
  • controlador de estruturas compartilhadas

Pense nela como:

“o cérebro central que sincroniza vários mainframes ao mesmo tempo.”


🏛 ORIGEM HISTÓRICA

A IBM criou o conceito nos anos 90 para resolver um problema gigantesco:

❌ Problema antigo

Antes do Parallel Sysplex:

  • cada mainframe era praticamente isolado
  • escalabilidade era limitada
  • failover era complicado
  • compartilhamento de dados era lento

✅ Solução IBM

Criaram:

IBM Parallel Sysplex

com:

  • múltiplos LPARs
  • múltiplos z/OS
  • múltiplos CICS
  • múltiplos Db2
  • tudo operando como “um único supercomputador”.

E a Coupling Facility virou o coração disso tudo.


🧠 ANALOGIA ESTILO BELLACOSA

Imagine:

ElementoMundo Real
z/OSpessoas trabalhando
Db2arquivos/documentos
CICSatendentes
Coupling Facilitycentral de coordenação
Lock Structuresemáforo
Cache Structurememória compartilhada
List Structurefila organizada

🔥 O QUE A COUPLING FACILITY FAZ?

Ela trabalha principalmente com:

EstruturaFunção
Lock Structurecontrole de locks
Cache Structurecache compartilhado
List Structurefilas/listas
Serializationsincronismo
Signalingcomunicação entre sistemas

🔷 TIPOS DE ESTRUTURA

1️⃣ LOCK STRUCTURE

Usada por:

  • Db2
  • GRS
  • CICS

Ela evita:

  • deadlock
  • update simultâneo
  • corrupção de dados

2️⃣ CACHE STRUCTURE

Mantém dados em memória compartilhada.

Exemplo:

  • buffer pools do Db2
  • cache CICS
  • VSAM RLS

Isso reduz I/O em disco absurdamente.


3️⃣ LIST STRUCTURE

Funciona como fila compartilhada.

Muito usada em:

  • WebSphere MQ
  • CICS TS Queue
  • Workload balancing

⚡ COMO FUNCIONA NA PRÁTICA

Imagine dois Db2:

SistemaAção
DB2Aatualiza cliente
DB2Btenta ler mesmo cliente

A CF entra no meio:

  1. DB2A pega lock
  2. CF registra lock
  3. DB2B consulta CF
  4. CF responde:
    • “registro bloqueado”
  5. DB2B espera

🔥 Resultado:
consistência total.


🏗 COMPONENTES IMPORTANTES

ComponenteDescrição
CFRMCoupling Facility Resource Management
XCFCross-system Coupling Facility
IXLCONNconecta aplicações
IXLLISTmanipula listas
IXLCACHEcache compartilhado
IXLLOCKlock manager

🔥 XCF — O “WHATSAPP” DOS MAINFRAMES

O XCF:

  • conecta sistemas do sysplex
  • troca mensagens
  • detecta falhas
  • coordena membros

Sem XCF:
❌ não existe sysplex moderno.


📦 ONDE A CF EXISTE?

Pode existir:

TipoDescrição
Internal CFdentro do próprio CPC
External CFmáquina dedicada
Integrated CF (ICF)processador especializado

🧩 COMO O COBOL JÚNIOR “SENTE” A CF?

Mesmo sem perceber…

você usa CF quando:

  • roda Db2 Data Sharing
  • acessa CICS em sysplex
  • usa VSAM RLS
  • usa MQ Shared Queue

Ou seja:

🔥 praticamente todo ambiente enterprise moderno.


🔎 COMO VER INFORMAÇÕES DA CF?

COMANDO D XCF

D XCF,CF

Mostra:

  • CFs ativas
  • status
  • conectividade
  • estruturas

🔎 LISTAR ESTRUTURAS

D XCF,STR

🔎 VER SYSLEX

D XCF,SYSPLEX

🔎 NO SDSF

Painéis:

PainelUso
RMFperformance
SDSF LOGmensagens
DAdevices
ENCenclosures

📊 MONITORAMENTO

Ferramentas clássicas:

FerramentaUso
RMF Monitor IIIperformance CF
OMEGAMONanálise avançada
IBM Tivolimonitoramento
SMF 74métricas da CF

🔥 SMF 74 — O TESOURO ESCONDIDO

O record:

SMF Type 74

guarda:

  • uso de estruturas
  • tempo de resposta
  • lock contention
  • taxa de requests
  • rebuilds

Subtipos importantes:

SubtypeUso
74-4CF Activity
74-5CF Cache
74-7Lock info

🔥 COMANDOS IMPORTANTES

VER DETALHES

D XCF,CF,CFNAME=CF01

VER ESTRUTURA

D XCF,STR,STRNAME=DB2LOCK1

REBUILD

SETXCF START,REBUILD,STRNAME=DB2LOCK1

⚠️ ERROS CLÁSSICOS

1️⃣ STRUCTURE FULL

Mensagem:

IXL015I STRUCTURE FULL

Significa:

  • estrutura sem espaço
  • excesso de locks/cache/lista

COMO ANALISAR

Ver:

D XCF,STR

Checar:

  • INITSIZE
  • SIZE
  • uso %

CORREÇÃO

Aumentar no CFRM Policy:

SIZE(50000)

2️⃣ REBUILD PENDING

Estrutura precisa rebuild.

Causas:

  • falha CF
  • perda conectividade
  • overload

CORREÇÃO

SETXCF START,REBUILD

3️⃣ PATH FAILURE

Links ICA/IFB falhando.

Pode causar:

  • degradação
  • perda de sincronismo

VERIFICAR

D XCF,PATH

4️⃣ LOCK CONTENTION

Db2 “travando tudo”.

Sintomas:

  • timeout
  • deadlock
  • lentidão

ANALISAR

  • IFCID 172
  • IFCID 196
  • RMF
  • DISPLAY DATABASE LOCKS

🧠 COMO INTERPRETAR PERFORMANCE

Indicadores importantes

MétricaSignificado
Request Raterequisições
Service Timelatência
Lock Contentiondisputa
Rebuild Countrebuilds
CF CPUuso CPU

🔥 LATÊNCIA É TUDO

No sysplex:

microsegundos importam.

Porque:

  • Db2 faz milhões de requests
  • CICS faz milhares por segundo
  • MQ sincroniza filas

Se a CF atrasar:
🔥 o sysplex inteiro sofre.


⚡ CURIOSIDADES ABSURDAS

🔥 A CF NÃO RODA z/OS

Ela roda firmware especializado.

É quase um “mini sistema operacional secreto IBM”.


🔥 UMA CF PODE CONTROLAR VÁRIOS MAINFRAMES

Grandes bancos possuem:

  • dezenas de LPARs
  • múltiplas CFs
  • sysplex gigantescos

🔥 EXISTE FAILOVER DE CF

Se uma CF morrer:

outra assume.

Isso é chamado:

Duplexing / Rebuild


🥚 EASTER EGGS MAINFRAME

🥚 O nome “Coupling”

Vem da engenharia mecânica:

coupling = acoplamento

Ela “acopla” sistemas.


🥚 O sysplex já foi considerado “cloud antes da cloud”

Porque:

  • compartilhava recursos
  • balanceava carga
  • permitia failover automático

Anos antes da computação em nuvem moderna.


🔥 EXEMPLO REAL — DB2 DATA SHARING

Imagine:

SistemaTransações
DB2Ainternet banking
DB2BPIX
DB2CATM
DB2Dcartão

Todos compartilham:

  • mesmos dados
  • mesmos locks
  • mesmo cache

Tudo coordenado pela CF.

Sem ela:
💥 corrupção total.


🛠 PASSO A PASSO PARA INVESTIGAR PROBLEMAS

ETAPA 1 — Verificar estruturas

D XCF,STR

ETAPA 2 — Verificar CF

D XCF,CF

ETAPA 3 — Verificar paths

D XCF,PATH

ETAPA 4 — Analisar RMF

Ver:

  • latency
  • request rate
  • rebuild

ETAPA 5 — Verificar mensagens

No SDSF LOG:

Procure:

IXL
IXC
CF

ETAPA 6 — Verificar Db2

Comandos:

-DISPLAY GROUP
-DISPLAY DATABASE LOCKS

☕ RESUMO BELLACOSA MAINFRAME

Coupling Facility é:

✅ o coração do Parallel Sysplex
✅ sincronismo ultra rápido
✅ lock manager distribuído
✅ cache compartilhado
✅ coordenador do Db2 Data Sharing
✅ base do CICS moderno
✅ peça crítica da alta disponibilidade IBM


🔥 FRASE FINAL DO PADAWAN MAINFRAME

“Quando vários mainframes parecem um só…
existe uma Coupling Facility trabalhando silenciosamente nos bastidores.” ☕🔥

sábado, 11 de outubro de 2025

🔥☕ DSN COMMAND E SUBCOMMANDS NO DB2 z/OS — A PORTA DE ENTRADA DO UNIVERSO DB2 NO MAINFRAME IBM Z 💾🚨

 

Bellacosa Mainframe configurado o Db2

🔥☕ DSN COMMAND E SUBCOMMANDS NO DB2 z/OS — A PORTA DE ENTRADA DO UNIVERSO DB2 NO MAINFRAME IBM Z 💾🚨

Se existe um comando que praticamente todo programador COBOL/DB2, DBA ou sysprog encontra cedo ou tarde no Mainframe, esse comando é:

DSN

O DSN é o processador de comandos do Db2 no z/OS e funciona como um processador TSO.
Em outras palavras:

ele abre uma sessão de comunicação direta com o DB2.

É a partir dele que:

  • executamos SQL,

  • fazemos BIND,

  • REBIND,

  • RUN,

  • SPUFI,

  • administramos packages,

  • executamos programas DB2,

  • controlamos aplicações.


🔥 O QUE É O COMANDO DSN?

Tradução

O comando TSO DSN inicia uma sessão DSN.


💾 EXEMPLO BÁSICO

No prompt TSO:

READY

digite:

DSN SYSTEM(DB9G)

🚀 O QUE ACONTECE?

Você entra no ambiente DB2:

DSN

Agora:

  • comandos DB2,

  • SQL,

  • BIND,

  • RUN

podem ser executados.


🧪 LABORATÓRIO 1 — ENTRANDO NO DB2

Passo 1

No TSO:

DSN SYSTEM(DB9G)

Passo 2

Você verá:

DSN

Passo 3

Teste um comando:

-DIS THREAD(*)

Passo 4

Saia da sessão:

END

🔥 END COMMAND

“Saindo do universo DB2”

Tradução

O subcomando END termina a sessão DSN e retorna ao TSO.


💾 EXEMPLO

END

🚀 RESULTADO

Você volta ao:

READY

🔥 IMPORTANTE — FOREGROUND E BACKGROUND

Os subcomandos DSN podem rodar:

  • foreground (interativo),

  • background (batch JCL).

Exceto:

SPUFI

que roda apenas no foreground ISPF.


🔥 ABEND

“Forçar um crash controlado”

Tradução

O subcomando ABEND termina a sessão DSN com abend X'04E'.


🚨 IMPORTANTE

IBM diz claramente:

use apenas sob orientação do suporte IBM.


💾 PARA QUE SERVE?

Diagnóstico profundo:

  • dumps,

  • análise interna,

  • debugging DB2.


🚨 EXEMPLO

ABEND

💥 RESULTADO

Gera:

  • dump,

  • encerramento anormal,

  • diagnóstico técnico.


🔥 BIND PACKAGE

“Criando o package executável do DB2”

Tradução

Constrói um package de aplicação.

O DB2:

  • registra descrição no catálogo,

  • salva package no directory,

  • remove versões antigas.


💾 O QUE É PACKAGE?

Package contém:

  • SQL compilado,

  • access path,

  • metadata otimizada.


🧪 LABORATÓRIO 2 — BIND PACKAGE

Passo 1 — Pré-compilar COBOL DB2

Gerar DBRM.


Passo 2 — Entrar no DSN

DSN SYSTEM(DB9G)

Passo 3 — Executar bind

BIND PACKAGE(MYCOLL) MEMBER(PROG1)
      ACTION(REPLACE)
      VALIDATE(BIND)

🚀 RESULTADO

DB2 cria:

  • package executável,

  • access path SQL.


🚨 ERROS COMUNS

SQLCODE -805

Package não encontrado.


AUTH FAILURE

Sem privilégio BIND.


🔥 BIND PLAN

“Criando o plano de execução da aplicação”

Tradução

Constrói um application plan.

Todo programa DB2 precisa de um PLAN para:

  • alocar recursos,

  • executar SQL.


💾 RELAÇÃO PACKAGE vs PLAN

ItemFunção
PACKAGESQL compilado
PLANEstrutura execução

🧪 LABORATÓRIO 3 — BIND PLAN

Passo 1

DSN SYSTEM(DB9G)

Passo 2

BIND PLAN(PLAN1)
     PKLIST(MYCOLL.*)

🚀 RESULTADO

Plano criado associando packages.


🔥 BIND QUERY

“Congelando access paths”

Tradução

Lê informações da:

DSN_USERQUERY_TABLE

e controla bind options/access paths.


💾 PARA QUE SERVE?

Estabilizar performance SQL.

Muito usado para:

  • evitar regressão,

  • preservar access path.


💥 CENÁRIO REAL

Após upgrade DB2:

  • SQL ficou pior.

DBA usa:

BIND QUERY

para manter plano antigo.


🔥 BIND SERVICE

“Criando REST Services no DB2”

Tradução

Cria package representando REST Service DB2.


💾 IMPORTÂNCIA MODERNA

Permite:

  • APIs REST,

  • integração cloud,

  • microservices,

  • mobile.


🧪 EXEMPLO

BIND SERVICE(MYREST)

🔥 DCLGEN

“O gerador mágico de estruturas COBOL”

Tradução

Produz:

  • DECLARE TABLE SQL,

  • estrutura COBOL/PL1/C.


💾 O QUE ELE GERA?

Exemplo:

01 CLIENTE.
   05 CLI-ID       PIC S9(9) COMP.
   05 CLI-NOME     PIC X(30).

🧪 LABORATÓRIO 4 — DCLGEN

Passo 1

DSN SYSTEM(DB9G)

Passo 2

DCLGEN TABLE(CLIENTES)
       LIBRARY('USER.COPYLIB')
       ACTION(REPLACE)

🚀 RESULTADO

DB2 gera:

  • copybook COBOL,

  • DECLARE TABLE.


🔥 FREE PACKAGE

“Apagando packages antigos”

Tradução

Remove:

  • versões específicas,

  • collections inteiras,

  • packages antigos.


🧪 EXEMPLO

FREE PACKAGE(MYCOLL.PROG1)

🚨 CUIDADO

Se apagar package em produção:

SQLCODE -805

🔥 FREE PLAN

“Removendo plans”

Tradução

Apaga application plans do DB2.


🧪 EXEMPLO

FREE PLAN(PLANOLD)

🚨 IMPACTO

Aplicações associadas:

  • param imediatamente.


🔥 REBIND PACKAGE

“Reotimizando SQL sem recompilar”

Tradução

Rebind package após mudanças que afetam package sem alterar SQL.


💾 PARA QUE SERVE?

Muito usado após:

  • RUNSTATS,

  • upgrade DB2,

  • mudança índice,

  • tuning.


🧪 LABORATÓRIO 5 — REBIND PACKAGE

Passo 1

REBIND PACKAGE(MYCOLL.PROG1)

🚀 RESULTADO

DB2:

  • recalcula access path,

  • reotimiza SQL.


🚨 PERIGO

Às vezes:

  • performance piora 😄


🔥 REBIND PLAN

“Atualizando plans sem recriar”

Tradução

Rebind application plan após alterações atributos.


🧪 EXEMPLO

REBIND PLAN(PLAN1)

🔥 RUN

“Executando programa DB2”

Tradução

Executa aplicação contendo SQL.


🧪 LABORATÓRIO 6 — RUN COBOL DB2

Passo 1

DSN SYSTEM(DB9G)

Passo 2

RUN PROGRAM(PROGCOB)
    PLAN(PLAN1)
    LIB('USER.LOADLIB')

🚀 RESULTADO

Programa COBOL executado sob DB2.


🔥 SPUFI

“O SQL interativo clássico do Mainframe”

Tradução

Executa SQL usando entrada arquivo.


💾 O QUE É SPUFI?

SQL Processor Using File Input.

Ferramenta clássica DB2.


🧪 LABORATÓRIO 7 — SPUFI

Passo 1

Entrar no DB2I.


Passo 2

Selecionar:

SPUFI

Passo 3

Executar:

SELECT *
FROM SYSIBM.SYSTABLES
FETCH FIRST 10 ROWS ONLY;

🚀 RESULTADO

DB2 retorna linhas SQL.


🔥 O QUE SEPARA O PROGRAMADOR COBOL DO ESPECIALISTA DB2?

O iniciante:

  • escreve SQL.

O especialista:

  • entende:

    • BIND,

    • PLAN,

    • PACKAGE,

    • REBIND,

    • RUN,

    • DCLGEN,

    • access path,

    • runtime DB2.


💣 A GRANDE VERDADE DO DB2

O SQL é apenas:

a superfície.

O verdadeiro motor do DB2 vive:

  • nos packages,

  • nos plans,

  • nos binds,

  • nos traces,

  • no optimizer,

  • no runtime DSN.

E entender os subcomandos DSN é praticamente:

aprender a conversar diretamente com o coração do DB2 no IBM Z 💾🔥