Translate

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

sexta-feira, 3 de outubro de 2025

☕💾 Laboratório Prático 03 — Comandos DISPLAY no DB2 z/OS 💾☕

 

Bellacosa Mainframe Laboratorio pratico Db2

☕💾 Laboratório Prático 03 — Comandos DISPLAY no DB2 z/OS 💾☕

🎯 Objetivo do Laboratório

Aprender na prática como utilizar os principais comandos DISPLAY do DB2 para:

  • Monitoramento
  • Troubleshooting
  • Verificação de objetos
  • Consulta de threads
  • Acompanhamento de utilities
  • Diagnóstico básico de ambiente

📘 Cenário

Você é um Sysprog Júnior responsável por acompanhar o ambiente DB2 DB2P.

Usuários reclamam que:

  • aplicações estão lentas,
  • alguns objetos parecem indisponíveis,
  • e existe suspeita de utility em execução.

Seu trabalho será investigar usando comandos DISPLAY.


🧪 LAB 1 — Verificando Status de Database

Objetivo

Consultar o status de um database.

Comando

-DISPLAY DATABASE(DBTEST)

Exemplo de Saída

DSNT360I  -DB2P DISPLAY DATABASE SUMMARY

DATABASE = DBTEST
STATUS = RW

Perguntas

1) O que significa STATUS = RW?

A) Read Wrong
B) Read/Write
C) Recovery Waiting
D) Restart Work

✅ Resposta: B


Explicação

RW significa que o objeto está:

  • disponível,
  • online,
  • aceitando leitura e gravação.

🧪 LAB 2 — Verificando Tablespaces

Comando

-DISPLAY DATABASE(DBTEST) SPACENAM(*)

Saída Simulada

SPACENAM = TSCLI001
STATUS = RW

SPACENAM = TSCLI002
STATUS = STOP

Exercício

Qual tablespace apresenta problema?

✅ Resposta:
TSCLI002


Explicação

Status STOP indica objeto indisponível.

Possíveis causas:

  • utility ativa,
  • problema operacional,
  • recover pendente,
  • intervenção administrativa.

🧪 LAB 3 — Verificando Threads Ativas

Objetivo

Identificar aplicações conectadas.

Comando

-DISPLAY THREAD(*)

Saída Simulada

THREAD INFO

AUTHID = APPUSER
PLAN = DSNACLI
STATUS = ACTIVE

Perguntas

1) Quem está conectado?

✅ APPUSER


2) Qual PLAN está sendo utilizado?

✅ DSNACLI


3) O que significa STATUS ACTIVE?

A) Thread executando
B) Thread cancelada
C) DB2 parado
D) Utility ativa

✅ Resposta: A


🧪 LAB 4 — Investigando Utilities

Objetivo

Verificar utilities em execução.

Comando

-DISPLAY UTILITY(*)

Saída Simulada

UTILITY = REORG
STATUS = ACTIVE
DBNAME = DBTEST

Exercício

Qual utility está rodando?

✅ REORG


Pergunta

Qual possível impacto?

A) Nenhum
B) Pode haver lock ou degradação de performance
C) Reinício do z/OS
D) Exclusão automática de tabelas

✅ Resposta: B


🧪 LAB 5 — Verificando Bufferpools

Comando

-DISPLAY BUFFERPOOL(BP0)

Saída Simulada

BUFFERPOOL BP0
VPSEQT = 80
STATUS = ACTIVE

Exercício

O bufferpool está ativo?

✅ Sim


Explicação

O comando ajuda:

  • monitoramento,
  • análise de cache,
  • troubleshooting de performance.

🧪 LAB 6 — Verificando Logs

Comando

-DISPLAY LOG

Saída Simulada

CURRENT ACTIVE LOG DATA SET
COPY1 = DSNDB2.LOGCOPY1.DS01
COPY2 = DSNDB2.LOGCOPY2.DS01

Exercício

O DB2 utiliza quantas cópias de log ativo?

✅ 2 cópias


Explicação

O DB2 mantém redundância para recuperação e segurança.


🧪 LAB 7 — Troubleshooting Real

Cenário

Usuários reportam lentidão extrema.

Você executa:

-DISPLAY THREAD(*)

Resultado

AUTHID = BATCH01
STATUS = ACTIVE
TIME = 99999

Perguntas

1) O que pode indicar TIME muito alto?

A) Thread presa ou longa execução
B) DB2 desligado
C) Falha RACF
D) Problema JES2

✅ Resposta: A


2) Qual comando poderia ser usado em emergência?

-CANCEL THREAD(...)

✅ Correto


☕💀 DESAFIO FINAL — O Erro Clássico 💀☕

Cenário

Um operador executou:

-STOP DATABASE(DBTEST)

em produção sem validar impacto.


Pergunta

O que pode acontecer?

A) Nada
B) Aplicações ficam indisponíveis
C) Apenas SPUFI para
D) O DB2 corrige sozinho

✅ Resposta: B 😅


📘 Resumo dos Principais DISPLAY

ComandoFunção
DISPLAY DATABASEStatus de databases
DISPLAY THREADThreads/conexões
DISPLAY UTILITYUtilities ativas
DISPLAY BUFFERPOOLStatus de bufferpool
DISPLAY LOGInformações de log
DISPLAY GROUPData sharing
DISPLAY LOCATIONConexões distribuídas

☕🔥 Dica Bellacosa Mainframe 🔥☕

Sysprog experiente NÃO sai cancelando thread ou dando STOP em produção sem:

  • investigar,
  • validar impacto,
  • verificar utilities,
  • e entender quem está conectado.

No Mainframe…
“um DISPLAY bem feito evita um incidente gigantesco.” ☕💾