Translate

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

domingo, 18 de janeiro de 2026

💣 DB2 Troubleshotting

Bellacosa Mainframe Db2 Troubleshotting

💣 DB2 Troubleshotting

💣 1. DEADLOCK — “o abraço da morte”

🧪 Cenário real

Transação A:

UPDATE CLIENTES SET NOME='ANA' WHERE ID=1;

Transação B:

UPDATE CLIENTES SET NOME='JOAO' WHERE ID=2;

👉 Depois:

  • A tenta atualizar ID=2
  • B tenta atualizar ID=1

💥 BOOM → deadlock


🧠 O que aconteceu?

Cada transação:

  • segura um lock
  • espera o lock da outra

👉 Db2 detecta e mata uma delas


💥 Sintoma clássico

SQLCODE = -911
REASON CODE = 00C90088

🔍 Diagnóstico

  • IFCID 172 (trace)
  • DISPLAY DATABASE LOCKS
  • Monitoramento (OMEGAMON)

🛠️ Soluções

✔ Acessar tabelas sempre na mesma ordem
✔ Reduzir tempo de transação
✔ Usar COMMIT mais frequente
✔ Evitar “holding locks” por muito tempo

💡 Regra de ouro:

Ordem consistente = evita deadlock


⚠️ 2. LOCK ESCALATION — “quando o Db2 perde a paciência”

🧪 Cenário real

Você roda:

UPDATE CLIENTES SET STATUS='A';

👉 Sem WHERE 😬


🧠 O que acontece?

  • Começa com row locks
  • Muitos locks acumulam
  • Db2 sobe para table lock

💥 Resultado:

Ninguém mais acessa a tabela


💥 Sintoma

  • Lentidão geral
  • Jobs travados
  • Reclamação do usuário 😅

🔍 Diagnóstico

  • IFCID 196
  • Monitoramento de locks
  • DSNZPARM (NUMLKTS / NUMLKUS)

🛠️ Soluções

✔ Sempre usar WHERE
✔ Commit em blocos (batch)
✔ Ajustar parâmetros de lock
✔ Usar LOCKSIZE adequado

💡 Bellacosa insight:

UPDATE sem WHERE é pedido formal de incidente 🚨


🚀 3. ACCESS PATH — “o plano invisível que decide tudo”

🧪 Cenário real

SELECT * FROM CLIENTES WHERE ID = 1;

👉 Parece simples… mas:

  • Usa índice? ⚡
  • Ou faz table scan? 🐢

🧠 O que é Access Path?

👉 Caminho que o otimizador escolhe para acessar os dados


🔍 Como ver?

EXPLAIN PLAN FOR
SELECT * FROM CLIENTES WHERE ID = 1;

👉 Consulta tabela PLAN_TABLE


💥 Possibilidades

TipoImpacto
Index scanRápido ⚡
Table scanLento 🐢
Nested loopBom
SortCusto extra

🛠️ Otimização

✔ Criar índice correto
✔ Atualizar RUNSTATS
✔ Evitar SELECT *
✔ Filtrar bem no WHERE


💡 Exemplo prático

❌ Ruim:

SELECT * FROM CLIENTES;

✅ Melhor:

SELECT NOME FROM CLIENTES WHERE ID = 1;

🧠 VISÃO DE PRODUÇÃO (OURO!)

🔥 Deadlock

👉 Problema de concorrência


🔥 Lock escalation

👉 Problema de volume de locks


🔥 Access path

👉 Problema de performance


💣 CHECKLIST RÁPIDO (salva carreira)

Antes de subir para produção:

✔ Tem índice?
✔ Tem WHERE?
✔ Tem COMMIT?
✔ Rodou EXPLAIN?
✔ RUNSTATS atualizado?


😎 FRASES DE SENIOR (pra usar na daily)

  • “Isso tá com cara de access path ruim”
  • “Provavelmente lock escalation”
  • “Vamos revisar o EXPLAIN antes de mexer”
  • “Isso aí vai dar -911 em produção”

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

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

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.” ☕💣