 |
| 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
| Status | Significado |
|---|---|
| RW | Read Write |
| RO | Read Only |
| STOP | Parado |
| UT | Utility ativa |
| RECP | Recovery Pending |
| CHKP | Check 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:
