 |
| Bellacosa Mainframe em uma visão sobre o LOG do DB2 |
🔥☕ O SUBMUNDO DO Db2 z/OS — LOGS, RECOVERY E O QUE ACONTECE QUANDO O BANCO “MORRE” ☕🔥
Existe um momento na vida de todo programador COBOL/Db2 em que ele descobre uma verdade assustadora:
O Db2 nunca esquece nada.
Cada:
- INSERT,
- UPDATE,
- DELETE,
- COMMIT,
- ROLLBACK,
- ALTER,
- REORG,
deixa rastros.
E esses rastros vivem dentro de uma das estruturas mais importantes do ecossistema mainframe:
🔥 O LOG DO Db2.
Se você é programador COBOL pleno e acha que recovery é “coisa de DBA”, cuidado.
Porque no dia em que um:
-904
-911
-803
00C90084
RESOURCE UNAVAILABLE
explodir produção às 3h da manhã…
você vai descobrir que entender o log do Db2 muda completamente sua carreira.
☕ O QUE É O LOG DO Db2?
O log do Db2 é o “diário transacional” do banco.
Tudo que altera dados gera registros de log.
O Db2 escreve:
- before image,
- after image,
- controle transacional,
- checkpoints,
- unidades de recuperação.
Basicamente:
ALTERAÇÃO → LOG → DISCO
Antes mesmo da página ser gravada no tablespace.
🔥 ACTIVE LOGS vs ARCHIVE LOGS
Aqui começa uma das maiores confusões dos iniciantes.
🔹 Active Logs
São os logs online e ativos.
Ficam sendo usados continuamente.
Eles armazenam:
- alterações recentes,
- transações em andamento,
- recovery imediato.
São críticos.
Perder active log é pesadelo nível apocalipse.
🔹 Archive Logs
Quando active logs ficam cheios:
- Db2 descarrega,
- copia,
- arquiva.
Esses logs históricos viram:
ARCHIVE LOGS
Eles são usados para:
- PIT recovery,
- auditoria,
- rollback histórico,
- disaster recovery.
☕ COMO O Db2 ESCREVE NO LOG?
Muita gente acha que Db2 grava direto no disco.
Não.
Primeiro ele grava em:
🔥 LOG BUFFERS
na memória.
Depois:
- COMMIT,
- checkpoint,
- buffer cheio,
- sync I/O,
forçam gravação nos:
ACTIVE LOG DATASETS
🔥 WRITE AHEAD LOGGING (WAL)
Aqui está o segredo do recovery moderno.
O Db2 segue:
🔥 WAL — Write Ahead Logging
Regra:
“O log precisa ser gravado ANTES da página do banco.”
Isso garante:
- rollback,
- redo,
- recuperação consistente.
Sem isso:
💀 corrupção.
☕ O QUE ACONTECE NUM COMMIT?
Quando o programa COBOL faz:
EXEC SQL COMMIT END-EXEC
o Db2:
- sincroniza logs,
- confirma UOW,
- libera locks,
- torna alterações permanentes.
O COMMIT é basicamente:
🔥 “Agora isso virou verdade oficial.”
☕ E NUM ABEND?
Aqui entra o terror psicológico do DBA.
Se ocorre:
- S0C7,
- S878,
- timeout,
- deadlock,
- cancel,
- crash,
- queda de LPAR,
o Db2 usa os logs para:
🔥 ROLLBACK
Ele desfaz tudo desde o último COMMIT.
🔥 TIPOS DE ERRO MAIS COMUNS
⚠️ SQLCODE -911 / -913
Deadlock ou timeout
Dois programas querem recursos incompatíveis.
Exemplo clássico:
- batch segurando tabela,
- online tentando atualizar.
DBA/Sysprog:
- analisar locking,
- IFCID,
- traces,
- IRLM,
- timeout values.
Programador COBOL:
- reduzir tempo entre commits,
- melhorar SQL,
- evitar scan gigante.
⚠️ SQLCODE -904
Resource unavailable
Tablespace parado.
Utility rodando.
Objeto indisponível.
DBA:
- verificar STOP status,
- utilities,
- claim/drain,
- locks.
Sysprog:
- investigar subsystem,
- storage,
- I/O,
- coupling facility.
⚠️ SQLCODE -803
Duplicate key
Programador tentou inserir chave já existente.
Programador:
- validar lógica,
- tratar concorrência,
- revisar sequence/identity.
DBA:
- verificar índice,
- constraints,
- integridade.
⚠️ SQLCODE -805
Package não encontrado
Clássico inferno de deploy.
DBA:
- verificar BIND,
- PLAN/PACKAGE,
- consistency token.
Sysprog:
- SDSNLOAD,
- STEPLIB,
- DBRM libraries.
Programador:
- garantir promote correto.
⚠️ 00C90084
Log full
Aqui o DBA começa a envelhecer rapidamente.
O active log lotou.
Possíveis causas:
- UOW gigante,
- commit inexistente,
- archive parado.
DBA:
- verificar ARCHIVE process,
- aumentar logs,
- cancelar job problemático.
Programador:
- COMMIT frequente,
- evitar transação monstruosa.
☕ COMO FUNCIONA O RECOVERY?
Aqui mora a mágica do Db2.
🔥 FORWARD RECOVERY
Db2:
- restaura image copy,
- reaplica logs.
Resultado:
✅ banco volta até ponto desejado.
🔥 BACKOUT / ROLLBACK
Db2 usa:
- before images,
- undo records.
E desfaz alterações.
🔥 RESTART RECOVERY
Após crash do subsystem:
Db2:
- lê logs,
- identifica UOW incompletas,
- faz undo/redo automático.
Muitas vezes o usuário nem percebe.
☕ O PAPEL DO DBA
O DBA é o “cirurgião do banco”.
Ele:
- monitora logs,
- executa RECOVER,
- controla utilities,
- administra image copies,
- resolve locking,
- acompanha catalog,
- analisa performance.
Ferramentas clássicas:
- DSN1LOGP,
- RECOVER,
- COPY,
- REORG,
- DISPLAY DATABASE,
- DISPLAY LOG.
☕ O PAPEL DO SYSPROG
O Sysprog atua na infraestrutura pesada.
Ele cuida:
- do subsystem Db2,
- IRLM,
- z/OS,
- JES,
- storage,
- coupling facility,
- datasets de log,
- BSDS,
- bootstrap datasets.
Se o DBA é cirurgião…
o Sysprog é engenheiro nuclear.
☕ O QUE O PROGRAMADOR COBOL PRECISA ENTENDER?
Muito mais do que imaginam.
Porque SQL ruim gera:
- lock,
- timeout,
- log storm,
- escalation,
- crash recovery lento.
🔥 Um bom programador Db2:
✅ faz commit racional
✅ evita cursor infinito
✅ reduz scans
✅ trata SQLCODE corretamente
✅ entende UOW
✅ sabe impacto do rollback
✅ evita transações gigantes
☕ O MAIOR ERRO DOS INICIANTES
Achar que:
COMMIT é só “salvar”.
Não.
COMMIT é:
- sincronização,
- liberação de lock,
- persistência,
- checkpoint lógico,
- controle de recovery.
É o coração do Db2 transacional.
🔥 CONCLUSÃO
O log do Db2 é praticamente:
🔥 a memória do banco.
Sem ele:
- não existe rollback,
- recovery,
- integridade,
- restart,
- consistência.
Quando você entende:
- active log,
- archive log,
- WAL,
- UOW,
- rollback,
- recovery,
você deixa de ser apenas “quem escreve SELECT”.
E começa a pensar como:
- DBA,
- sysprog,
- arquiteto transacional.
E no universo mainframe…
isso muda tudo. ☕🔥
Sem comentários:
Enviar um comentário