Translate

Mostrar mensagens com a etiqueta DBA Mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta DBA Mainframe. 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 💾🔥

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

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 💾🔥


quinta-feira, 9 de outubro de 2025

🔥☕ DB2 COMMANDS AVANÇADOS NO IBM Z — TRADUÇÃO, EXPLICAÇÃO E LABORATÓRIO PASSO A PASSO PARA SYSPOGS E DBAs 💾🚨

 

Bellacosa Mainframe mergulhas em comandos avançados do Db2

🔥☕ DB2 COMMANDS AVANÇADOS NO IBM Z — TRADUÇÃO, EXPLICAÇÃO E LABORATÓRIO PASSO A PASSO PARA SYSPOGS E DBAs 💾🚨

Os comandos DB2 são usados para controlar praticamente todo o ambiente operacional do Db2 for z/OS. Eles podem ser executados via:

  • console z/OS,

  • TSO,

  • SDSF,

  • DB2I,

  • CICS,

  • IMS,

  • batch JCL,

  • programas autorizados.

Mas a grande verdade é:

esses comandos são muito mais do que “comandos”.

Eles são:

  • sensores,

  • diagnósticos,

  • controles cirúrgicos,

  • mecanismos de sobrevivência do subsystem.


🔥 -DISPLAY THREAD

“Mostre quem está vivo dentro do DB2”

Tradução

Exibe informações sobre threads ativas do Db2.


💾 O QUE É UMA THREAD?

Thread é:

  • uma conexão ativa,

  • uma unidade de execução,

  • uma conversa em andamento com o DB2.

Pode vir de:

  • CICS,

  • batch,

  • DDF,

  • Java,

  • IMS,

  • TSO.


🧪 PASSO A PASSO

Passo 1 — Entrar no painel DB2

Digite:

DSN SYSTEM(DB9G)

Passo 2 — Executar comando

-DIS THREAD(*)

Passo 3 — Analisar saída

Você verá:

  • THREADID

  • STATUS

  • PLAN

  • AUTHID

  • CPU

  • WAIT


🚨 O QUE OBSERVAR?

WAIT

Pode indicar:

  • lock,

  • I/O lento,

  • deadlock.


CPU muito alta

Pode indicar:

  • SQL ruim,

  • scan massivo,

  • aplicação travada.


💥 EXEMPLO REAL

Sistema PIX lento.

Você executa:

-DIS THREAD(*)

e encontra:

  • thread Java com milhões de gets,

  • CPU disparando,

  • WAIT=LCK.

Resultado:

lock contention distribuído.


🔥 -DISPLAY DATABASE

“A radiografia do storage lógico”

Tradução

Exibe informações de status das databases Db2.


🧪 PASSO A PASSO

Passo 1

-DIS DB(DBPROD)

Passo 2 — Expandir spaces

-DIS DB(DBPROD) SPACENAM(*)

💾 O QUE APARECE?

  • tablespaces,

  • indexspaces,

  • status,

  • pendências,

  • utilities,

  • recovery states.


🚨 STATUS IMPORTANTES

StatusSignificado
RWRead Write
RORead Only
STOPParado
UTUtility ativa
RECPRecovery Pending
CHKPCheck Pending

💥 EXEMPLO REAL

Após LOAD falho:

STATUS=RECP

O objeto:

  • não aceita acesso,

  • exige recovery.


🔥 -DISPLAY BUFFERPOOL

“O raio-x da memória do DB2”

Tradução

Exibe o status atual dos buffer pools ativos ou inativos.


💾 O QUE É BUFFERPOOL?

Cache inteligente do DB2.

Armazena:

  • páginas,

  • índices,

  • dados frequentemente acessados.


🧪 PASSO A PASSO

Mostrar todos

-DIS BPOOL(*)

Mostrar detalhe

-DIS BPOOL(BP0) DETAIL

🚨 O QUE ANALISAR?

HIT RATIO

Baixo:

  • excesso de disco,

  • I/O alto,

  • CPU alta.


VPSIZE

Muito pequeno:

  • gargalo memória.


PGFIX(NO)

Pode gerar:

  • paging,

  • overhead CPU.


💥 EXEMPLO REAL

Batch lento.

DBA executa:

-DIS BPOOL(*)

e descobre:

  • hit ratio despencando,

  • BP saturado.


🔥 -DISPLAY DDF

“O pulmão das conexões distribuídas”

Tradução

Exibe informações sobre o status e configuração do DDF.


💾 O QUE É DDF?

Distributed Data Facility.

Responsável pelas conexões:

  • JDBC,

  • APIs,

  • Linux,

  • cloud,

  • microservices.


🧪 PASSO A PASSO

Passo 1

-DIS DDF

Passo 2 — Verificar

  • STATUS

  • CONDBAT

  • threads distribuídas

  • localização remota


🚨 ALERTAS

CONDBAT saturado

Excesso conexões.


DDF STOPPED

APIs param imediatamente.


💥 EXEMPLO REAL

Aplicação Java:

  • abre milhares de conexões.

Resultado:

DDF THREAD LIMIT REACHED

🔥 -DISPLAY LOCKS

“O detetive do crime em produção”

Tradução

Exibe locks e claims mantidos por threads ativas.


🧪 PASSO A PASSO

Passo 1

-DIS LOCKS

Passo 2 — Procurar

  • lock owner,

  • waiting threads,

  • lock type.


🚨 CENÁRIO CLÁSSICO

Batch:

UPDATE MASSIVO

sem commit.

Resultado:

  • online trava,

  • CICS para.


💥 O DBA ENCONTRA

WAIT=LCK

🔥 -DISPLAY LOG

“O DNA transacional do DB2”

Tradução

Exibe informações sobre active logs e checkpoints.


🧪 PASSO A PASSO

Passo 1

-DIS LOG

Passo 2 — Analisar

  • active logs,

  • archive logs,

  • offload,

  • checkpoints.


🚨 RISCOS

Log cheio

Pode:

  • parar commits,

  • travar subsystem,

  • gerar degradação severa.


💥 EXEMPLO REAL

Sistema:

  • commits lentos,

  • rollback gigante.

DBA verifica:

-DIS LOG

e encontra:

  • pressão de active logs.


🔥 -DISPLAY UTILITY

“O centro cirúrgico do DB2”

Tradução

Exibe status das utilities Db2.


🧪 PASSO A PASSO

Passo 1

-DIS UTIL(*)

Passo 2 — Procurar

  • REORG,

  • COPY,

  • LOAD,

  • RUNSTATS,

  • RECOVER.


🚨 O QUE PODE DAR ERRADO?

REORG presa

Pode indicar:

  • lock,

  • I/O lento,

  • SORT insuficiente.


🔥 -CANCEL THREAD

“O botão vermelho do DBA”

Tradução

Cancela processamento de threads locais ou distribuídas.


🧪 PASSO A PASSO

Passo 1 — Identificar thread

-DIS THREAD(*)

Passo 2 — Cancelar

-CANCEL THREAD(token)

🚨 CUIDADO

Cancelar thread:

  • pode gerar rollback gigantesco,

  • pressão de log,

  • lock storm.


🔥 -START DATABASE

“Trazer o objeto de volta à vida”

Tradução

Torna a database disponível para uso.


🧪 PASSO A PASSO

Passo 1

-START DB(DBPROD)

Passo 2 — Confirmar

-DIS DB(DBPROD)

🔥 -STOP DATABASE

“Parar o coração do objeto”

Tradução

Torna objetos indisponíveis para aplicações.


🧪 PASSO A PASSO

Passo 1

-STOP DB(DBPROD)

Passo 2 — Validar

STATUS=STOP

🚨 IMPACTO REAL

Se parar database crítica:

  • PIX para,

  • ATM trava,

  • APIs falham.


🔥 -ARCHIVE LOG

“Forçar rotação do log”

Tradução

Fecha active log atual e abre próximo disponível.


🧪 EXEMPLO

-ARCHIVE LOG

💾 USO REAL

Muito usado:

  • antes backup,

  • antes maintenance,

  • troubleshooting log.


🔥 -START TRACE

“Modo CSI do DB2”

Tradução

Inicia traces Db2.


🧪 EXEMPLO

-START TRACE(PERFM)

🚨 RISCO

Trace excessivo:

  • aumenta CPU,

  • gera overhead.


🔥 -MODIFY DDF

“Alterar DDF online”

Tradução

Modifica status/configuração do DDF.


🧪 EXEMPLO

-MODIFY DDF PKGREL(COMMIT)

💾 USO

Ajuste:

  • threads distribuídas,

  • comportamento JDBC,

  • tuning online.


🔥 O QUE UM SYSPOG VETERANO FAZ?

Sequência clássica:

-DIS THREAD(*)
-DIS DB(*)
-DIS LOCKS
-DIS BPOOL(*)
-DIS DDF
-DIS LOG
-DIS UTIL(*)

💣 O QUE ELE CONSEGUE VER?

  • gargalos,

  • locks,

  • CPU,

  • memória,

  • recovery,

  • corrupção,

  • pressão DDF,

  • degradação,

  • risco subsystem.


☕ O GRANDE SEGREDO DO IBM Z

No Mainframe:

  • tudo deixa rastros,

  • tudo gera sinais,

  • tudo pode ser analisado.

O verdadeiro especialista não é quem sabe apenas SQL.

É quem consegue olhar um:

-DISPLAY THREAD

e entender:

a saúde inteira do negócio em produção 💾🔥

segunda-feira, 28 de setembro de 2020

🔥☕ LABORATÓRIO DB2 z/OS — 20 PROBLEMAS REAIS DE PRODUÇÃO COM SOLUÇÕES ☕🔥

 

Bellacosa Mainframe te coloca a prova no uso do DB2 com labs praticos


🔥☕ LABORATÓRIO DB2 z/OS — 20 PROBLEMAS REAIS DE PRODUÇÃO COM SOLUÇÕES ☕🔥

“O DIA EM QUE O OPERADOR VIROU DETETIVE DO DB2”

Este laboratório foi inspirado no menu DB2 COMMANDS da sua tela SDSF/DB2I.

A ideia aqui é simular:

  • incidentes reais,
  • troubleshooting,
  • crises de produção,
  • panes de batch,
  • locks,
  • bufferpool,
  • utilities,
  • recovery,
  • gargalos,
  • runaway SQL.

Cada cenário possui:

  • 🚨 Problema
  • 🔍 Investigação
  • 💣 Diagnóstico
  • ✅ Solução
  • 🧠 Explicação técnica

🔥 LAB 01 — TABLESPACE PAROU

🚨 Problema

Aplicação CICS começou a falhar:

SQLCODE -904
RESOURCE UNAVAILABLE

🔍 Investigação

-DIS DATABASE(ESCOLA)

💣 Resultado

SPACENAM ALUNOS
STATUS STOP

✅ Solução

-START DATABASE(ESCOLA) SPACENAM(ALUNOS)

🧠 Explicação

O tablespace estava parado.

Pode ocorrer após:

  • utility abortada
  • falha de recovery
  • intervenção operacional

🔥 LAB 02 — LOCK GIGANTE

🚨 Problema

Usuários reclamam:

“Sistema congelou”


🔍 Investigação

-DIS THREAD(*) LOCKS

💣 Resultado

Uma thread batch segurando lock exclusivo.


✅ Solução

-CANCEL THREAD(token)

🧠 Explicação

A thread travou milhares de registros.

O cancel provoca rollback.


🔥 LAB 03 — BUFFERPOOL SATURADO

🚨 Problema

DB2 lento.

Muito I/O.


🔍 Investigação

-DIS BUFFERPOOL(BP0) DETAIL

💣 Resultado

HIT RATIO = 62%

✅ Solução

Aumentar VPSIZE.


🧠 Explicação

Cache pequeno.

DB2 lendo disco excessivamente.


🔥 LAB 04 — REORG PENDENTE

🚨 Problema

Performance degradada.


🔍 Investigação

-DIS DATABASE(FINANCE)

💣 Resultado

AREO*

✅ Solução

Executar REORG.


🧠 Explicação

Tabela fragmentada.

DB2 recomenda reorganização.


🔥 LAB 05 — COPY PENDING

🚨 Problema

INSERT falhando.


🔍 Investigação

-DIS DATABASE(PAGTO)

💣 Resultado

COPY PENDING

✅ Solução

Executar COPY utility.


🧠 Explicação

Objeto precisa backup válido.


🔥 LAB 06 — REBUILD PENDING

🚨 Problema

Índice corrompido.


🔍 Investigação

-DIS DATABASE(CLIENTE)

💣 Resultado

REBUILD PENDING

✅ Solução

REBUILD INDEX

🧠 Explicação

Indexspace precisa reconstrução.


🔥 LAB 07 — UTILITY TRAVADA

🚨 Problema

REORG nunca termina.


🔍 Investigação

-DIS UTIL(*)

💣 Resultado

Utility em WAIT.


✅ Solução

-TERM UTIL(utilid)

Reexecutar utility.


🧠 Explicação

Utility ficou presa aguardando recurso.


🔥 LAB 08 — LOG QUASE CHEIO

🚨 Problema

DB2 emitindo alertas.


🔍 Investigação

-DIS LOG

💣 Resultado

Active logs quase esgotados.


✅ Solução

  • aumentar logs
  • acelerar archive
  • reduzir commits longos

🧠 Explicação

Transações segurando log excessivamente.


🔥 LAB 09 — THREAD ZUMBI

🚨 Problema

Sessões antigas nunca encerram.


🔍 Investigação

-DIS THREAD(*) TYPE(INACTIVE)

💣 Resultado

Centenas de conexões JDBC abandonadas.


✅ Solução

Cancelar threads.

Ajustar timeout DDF.


🧠 Explicação

Pooling mal configurado.


🔥 LAB 10 — DDF FORA

🚨 Problema

Aplicações distribuídas não conectam.


🔍 Investigação

-DIS DDF

💣 Resultado

DDF STOPPED

✅ Solução

-START DDF

🧠 Explicação

DRDA estava parado.


🔥 LAB 11 — DEADLOCK

🚨 Problema

SQLCODE -911.


🔍 Investigação

-DIS THREAD(*) LOCKS

💣 Resultado

Duas aplicações disputando recursos.


✅ Solução

Identificar offender.

Cancelar thread problemática.


🧠 Explicação

Deadlock clássico de concorrência.


🔥 LAB 12 — RUNAWAY SQL

🚨 Problema

CPU do LPAR explodiu.


🔍 Investigação

-DIS THREAD(*) SERVICE(WAIT)

💣 Resultado

SELECT sem índice.


✅ Solução

Cancelar thread.

Criar índice.


🧠 Explicação

Full tablescan monstruoso.


🔥 LAB 13 — CLAIMERS SEGURANDO OBJETO

🚨 Problema

REORG não inicia.


🔍 Investigação

-DIS DATABASE(DB1) CLAIMERS

💣 Resultado

Aplicações usando objeto.


✅ Solução

Encerrar aplicações.


🧠 Explicação

Claims impedem drains.


🔥 LAB 14 — BUFFERPOOL ERRADO

🚨 Problema

Objeto crítico lento.


🔍 Investigação

-DIS BUFFERPOOL(*)

💣 Resultado

Objeto em BP inadequado.


✅ Solução

Mover para bufferpool maior.


🧠 Explicação

Pool incompatível com workload.


🔥 LAB 15 — MASSIVE ARCHIVE

🚨 Problema

Milhares de archive logs.


🔍 Investigação

-DIS ARCHIVE

💣 Resultado

Archive atrasado.


✅ Solução

Verificar HSM/tape/storage.


🧠 Explicação

Offload congestionado.


🔥 LAB 16 — START READ ONLY

🚨 Problema

Necessidade de manutenção.


✅ Solução

-START DATABASE(FINANCE) ACCESS(RO)

🧠 Explicação

Permite leitura sem updates.


🔥 LAB 17 — INDEX INDISPONÍVEL

🚨 Problema

Queries lentas.


🔍 Investigação

-DIS DATABASE(DB2PRD)

💣 Resultado

Indexspace STOPPED.


✅ Solução

-START DATABASE(DB2PRD)

🧠 Explicação

Optimizer perdeu acesso ao índice.


🔥 LAB 18 — UTILITIES CONCORRENTES

🚨 Problema

COPY e REORG competindo.


🔍 Investigação

-DIS UTIL(*)

💣 Resultado

Conflito operacional.


✅ Solução

Replanejar janela batch.


🧠 Explicação

Utilities disputam recursos físicos.


🔥 LAB 19 — DB2 EM RECOVER

🚨 Problema

Objeto indisponível.


🔍 Investigação

-DIS DATABASE(SEGURADORA)

💣 Resultado

STATUS RECOVER

✅ Solução

Executar RECOVER utility.


🧠 Explicação

Objeto inconsistente.


🔥 LAB 20 — O “FANTASMA” DO MAINFRAME

🚨 Problema

Sistema lento apenas à noite.


🔍 Investigação

-DIS THREAD(*)
-DIS UTIL(*)
-DIS LOG
-DIS BUFFERPOOL(*)

💣 Resultado

Batch gigantesco executando RUNSTATS + REORG + COPY simultaneamente.


✅ Solução

Separar janela batch.

Priorizar workloads.


🧠 Explicação

Concorrência destrutiva:

  • I/O
  • CPU
  • log
  • bufferpool
  • locks

🔥 DESAFIO EXTRA — COMANDOS PARA TREINAR

Diagnóstico rápido

-DIS THREAD(*)
-DIS UTIL(*)
-DIS LOG
-DIS BUFFERPOOL(*)
-DIS DATABASE(*)

Administração

-START DATABASE(DB1)
-STOP DATABASE(DB1)

Emergência

-CANCEL THREAD(token)
-TERM UTIL(utilid)

☕ O QUE ESSE LAB ENSINA

Esse tipo de troubleshooting desenvolve:

  • visão operacional
  • raciocínio rápido
  • análise de sintomas
  • entendimento interno do DB2
  • troubleshooting de produção
  • mentalidade de DBA z/OS

🔥 FRASE FINAL DO LAB

“No mundo distribuído você abre dashboards.
No mainframe você conversa diretamente com o coração do banco.” ☕💣