Bellacosa Mainframe em um pequeno bate papo sobre segurança racf saf

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

A Verdade Crua da Segurança no z/OS (Do RACF ao Crypto Express)

---

☕ Introdução — Um Café com a Realidade

Se você acha que segurança no mainframe é “coisa do passado”, deixa eu te dar um choque de realidade:

O z/OS é um dos ambientes mais seguros do planeta — mas só quando bem configurado.

Porque na prática?

👉 O problema nunca foi a tecnologia
👉 O problema sempre foi quem configura

E é exatamente aqui que começa nossa jornada.

---

🕰️ Um pouco de história (e por que isso importa)

Nos anos 70, quando surgiram os primeiros sistemas corporativos massivos, a IBM percebeu algo:

“Se todo mundo acessa tudo… uma hora dá ruim.”

Nasce então o conceito de controle centralizado de acesso, que evolui para:

• RACF
• SAF
• E todo o ecossistema de segurança do z/OS

Enquanto o mundo distribuído ainda estava descobrindo autenticação…

👉 O mainframe já tinha segurança granular por recurso

---

🧠 O Coração da Segurança: SAF + RACF

Pensa nisso como um fluxo batch:

Usuário → SAF → RACF → decisão (ALLOW / DENY)

🧩 Quem faz o quê?

• SAF → interface (o “porteiro”)
• RACF → decisão (o “juiz”)

💡 Easter egg Bellacosa:

SAF nunca decide nada… ele só “encaminha o problema” 😄

---

🔐 O Mandamento Supremo: Least Privilege

Se você tiver que lembrar de UMA coisa:

“Dê o mínimo necessário — nunca o máximo possível.”

Exemplo clássico:

• Admin RACF → gerencia segurança
• Storage admin → só mexe em dataset

👉 Separação + privilégio mínimo = sistema saudável

---

💣 O ERRO QUE MAIS DERRUBA AMBIENTE

❌ PROTECTALL desligado

Sem isso:

Dataset sem perfil → acesso liberado 😱

👉 Simples assim.
👉 Sem perfil = sem segurança

💡 Curiosidade:
Muitos incidentes em mainframe não são ataques…
São configuração mal feita.

---

🔥 Criptografia no z/OS: Outro nível

Enquanto muita gente ainda “liga TLS”, o z/OS já faz:

🔐 Pervasive Encryption

• Dados em disco
• Dados em trânsito
• Dados protegidos sem mudar aplicação

---

🧬 A Hierarquia das Chaves (isso cai MUITO!)

Master Key → protege → Operational Key → protege → Data

Tipos importantes:

• Master Keys → topo da cadeia
• Symmetric → performance
• Asymmetric → troca segura
• Operational → uso diário

💡 Easter egg:

Se perder a master key… acabou o jogo.

---

⚙️ ICSF — O Tradutor da Criptografia

Aplicação nunca fala direto com hardware.

Ela fala com:

👉 ICSF

Que fala com:

👉 CPACF / Crypto Express

---

🛡️ Níveis de proteção (isso é ouro de prova)

Nível	Segurança
Clear Key	😬
Protected Key	👍
Secure Key	🔥🔥🔥

👉 Secure Key = dentro do hardware (Crypto Express)

---

💻 APF — Quem pode ser “superpoderoso”

Nem todo programa pode rodar com privilégio.

👉 Só quem está no APF

Programa fora do APF → sem privilégio
Programa no APF → modo supervisor

💡 Isso evita:

• código malicioso
• erro catastrófico

---

🌐 Rede no z/OS — Não é só TCP/IP

z/OS Communications Server

• TCP/IP (moderno)
• SNA (legado que ainda vive 😄)

Segurança:

• TLS → camada transporte
• IPSec → VPN (nível rede)

---

📊 SMF — O “log que conta tudo”

Se algo aconteceu:

👉 O SMF sabe

Mas atenção:

Nada é logado automaticamente se você não configurar

---

🧪 Caso real (estilo Bellacosa)

Empresa com:

• RACF instalado
• Criptografia ativa
• Auditoria configurada

Mas…

❌ PROTECTALL desligado
❌ UACC READ em datasets críticos

Resultado?

👉 Vazamento interno
👉 Sem ataque externo

💡 Moral:

Segurança não é tecnologia — é configuração.

---

🧠 Mentalidade Mainframe

Enquanto no mundo distribuído se fala:

“vamos adicionar segurança”

No mainframe é:

“vamos NÃO remover a segurança”

---

🔥 Frases pra tatuar no cérebro

• “SAF conecta, RACF decide”
• “Sem PROTECTALL, está exposto”
• “Sem chave, não há segurança”
• “ALL = mostra tudo”
• “SPECIAL = poder total (cuidado!)”

---

🏁 Conclusão — A Verdade Final

O z/OS não é seguro por acaso.

Ele é seguro porque:

• Foi projetado assim
• Evoluiu assim
• Exige disciplina

Mas…

Um mainframe mal configurado é tão vulnerável quanto qualquer outro sistema.

---

☕ Fechamento estilo Bellacosa

Segurança no mainframe não é só técnica.

É filosofia.

É controle.

É respeito ao sistema.

E principalmente:

É saber que o perigo não está fora… está dentro da configuração.

 

Bellacosa Mainframe experimentos reisiliencia em IBM Z

💥 APERTA O ENTER E DERRUBA O DATA CENTER: SOBREVIVA AO LAB DE RESILIÊNCIA IBM Z

🧪 Laboratório prático — do ABEND ao FAILOVER sem perder um byte

---

🎯 OBJETIVO DO LAB

Você vai simular:

• 💣 Falha de aplicação (ABEND)
• ⚙️ Restart automático (ARM)
• 🧩 Continuidade (Sysplex mental model)
• 🌍 Disaster Recovery (simulado estilo GDPS)
• 📊 Validação de RPO/RTO

👉 Resultado esperado:
Sistema continua — usuário nem percebe

---

🧠 CENÁRIO (VIDA REAL)

Você é dev COBOL em um banco:

• Batch crítico processa pagamentos
• Roda em z/OS
• Usa Db2
• Integra com CICS

💥 E claro… algo vai dar errado.

---

🧪 LAB 1 — “PROVOQUE O CAOS” (ABEND CONTROLADO)

🎯 Objetivo:

Gerar uma falha real

---

📄 Passo 1 — Programa COBOL com erro

IDENTIFICATION DIVISION.
PROGRAM-ID. LABFAIL.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NUM PIC 9(3) VALUE ZEROS.
01 WS-VAL PIC 9(3).

PROCEDURE DIVISION.
    MOVE 100 TO WS-VAL
    DIVIDE WS-VAL BY WS-NUM GIVING WS-VAL
    DISPLAY 'PROCESSO FINALIZADO'
    STOP RUN.

👉 Resultado esperado:

S0C7 ou S0CB (divisão por zero)

---

💡 Comentário Bellacosa

“Se você nunca causou um ABEND de propósito… você ainda não domina o sistema.”

---

⚙️ LAB 2 — “DEIXA O SISTEMA SE VIRAR” (ARM)

🎯 Objetivo:

Simular restart automático

---

🧠 Conceito

ARM = Automatic Restart Manager

👉 Ele reinicia automaticamente o que caiu

---

📄 Passo 2 — Simulação lógica

JOB FAIL → ABEND
ARM detecta → restart automático
JOB reinicia → continua fluxo

---

🧪 Teste

1. Execute o programa com erro
2. Corrija o erro (WS-NUM ≠ 0)
3. Reexecute

👉 Agora imagine:

• ARM faria isso sozinho
• Sem operador

---

💡 Insight

“ARM é o operador que nunca dorme.”

---

🧩 LAB 3 — “NÃO PARE O SISTEMA” (MENTALIDADE SYSPLEX)

🎯 Objetivo:

Entender continuidade

---

🧠 Simulação conceitual

Imagine:

• LPAR A → falha
• LPAR B → assume

---

📄 Fluxo

Transação → LPAR A
Falha → redireciona → LPAR B
Usuário continua

---

💡 Easter Egg 🔥

“Sysplex não é cluster…
é cluster que não te deixa na mão.”

---

🌍 LAB 4 — “PERDEMOS O DATA CENTER” (DR SIMULADO)

🎯 Objetivo:

Simular desastre total

---

🧠 Cenário

• Site A caiu 💥
• Site B assume

---

📄 Exercício

1. Imagine seu sistema rodando
2. “Desligue” mentalmente o ambiente
3. Suba outro ambiente

👉 Perguntas:

• Quanto tempo levou? (RTO)
• Perdeu dados? (RPO)

---

💡 Resposta ideal

• RTO → segundos/minutos
• RPO → zero

---

🔥 Insight

“Se você precisa pensar muito no DR… ele já falhou.”

---

🧨 LAB 5 — “DESCUBRA SEU SPOF”

🎯 Objetivo:

Encontrar ponto único de falha

---

📄 Checklist

• Um único job crítico?
• Um único DB?
• Um único operador? 😅

---

💡 Easter Egg

SPOF mais comum:
👉 Interface Teclado-Cadeira

---

🤖 LAB 6 — “AUTOMA OU MORRE”

🎯 Objetivo:

Entender automação

---

📄 Cenário

Sem automação:

• detectar
• analisar
• agir

👉 minutos ou horas

---

Com automação:

• detectar
• agir

👉 segundos

---

💡 Insight brutal

“Sem automação, seu RTO é humano.”

---

🧪 LAB 7 — DR TEST (O GRANDE FINAL)

🎯 Objetivo:

Validar tudo

---

📄 Simulação

1. Derrube o “ambiente”
2. Ative backup
3. Valide sistema

---

📊 Checklist

• Sistema subiu?
• Dados íntegros?
• Tempo aceitável?

---

💡 Regra de ouro

“DR não testado = DR inexistente”

---

🧠 CONSOLIDAÇÃO FINAL

---

🔗 RELAÇÃO DOS CONCEITOS

• RAS → evita impacto
• Models → define arquitetura
• Planning → garante execução

---

💥 Fluxo completo

Falha pequena → ARM resolve
Falha média → Sysplex resolve
Desastre total → DR/GDPS resolve

---

🏁 MISSÃO FINAL DO LAB

👉 Você não está testando sistema
👉 Você está testando sobrevivência do negócio

---

🔥 FRASE FINAL

“No mainframe, o erro não é falhar…
é deixar o usuário perceber.”

 

 

Bellacosa Mainframe indica um lab para troubleshooting no Z/os SMP/E

🧪 LAB SMP/E — “Do APPLY sem CHECK ao RESTORE salvador”

🎯 Objetivo

Você vai:

• Executar RECEIVE → APPLY → ACCEPT → RESTORE
• Simular um erro real
• Diagnosticar via relatórios
• Recuperar o sistema corretamente

👉 Traduzindo:

você vai errar com segurança para aprender de verdade

---

🧱 Cenário do LAB

🖥️ Ambiente

• z/OS (real ou Hercules TK5)
• SMP/E configurado
• CSI existente
• Zonas:
  • GLOBAL
  • TARGET
  • DLIB

---

📦 Dados do exercício

• FMID: HXYZ123
• PTFs:
  • UQ00001 (base)
  • UQ00002 (dependente)
  • UQ00003 (com problema 💀)

---

🔄 FASE 1 — RECEIVE

🎯 Objetivo

Carregar SYSMODs no SMP/E

---

🧾 JCL

//RECEIVE JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPPTFIN DD DISP=SHR,DSN=SEU.PTF.INPUT
//SMPCNTL  DD *
 SET BDY(GLOBAL).
 RECEIVE SYSMODS.
/*

---

✅ Esperado

• SYSMODs no SMPPTS
• GLOBAL ZONE atualizada

---

🔍 Validar

• SMPRPT
• LIST SYSMODS

---

💣 FASE 2 — ERRO PROPOSITAL (APPLY SEM CHECK)

🎯 Objetivo

Simular erro real de produção

---

🧾 JCL (errado propositalmente)

//APPLY JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 APPLY SELECT(UQ00003).
/*

---

💥 Resultado esperado

• Aplicação incompleta OU
• Sistema inconsistente

---

🧠 O que você fez

💀 ignorou dependências + não usou CHECK

---

🔍 FASE 3 — DIAGNÓSTICO

🎯 Objetivo

Descobrir o problema

---

📄 Analisar:

• SMPOUT
• SMPRPT
• Causer Report

---

💡 Encontrar:

• Dependência faltando (UQ00002)
• Possível HOLD

---

🧠 Insight

SMP/E não falha — ele te avisa

---

🔁 FASE 4 — APPLY CORRETO

🎯 Objetivo

Corrigir com CHECK

---

🧾 JCL

//APPLY JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 APPLY CHECK SELECT(UQ00003) GROUPEXTEND.
/*

---

✅ Resultado

• Lista completa de dependências
• Nenhuma alteração real

---

🔥 Agora aplicar certo:

 APPLY SELECT(UQ00003) GROUPEXTEND.

---

📦 FASE 5 — ACCEPT

🎯 Objetivo

Consolidar mudança

---

🧾 JCL

//ACCEPT JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(DLIB).
 ACCEPT CHECK.
/*

---

⚠️ Depois:

 ACCEPT.

---

💀 Agora você não volta fácil…

---

🚨 FASE 6 — INCIDENTE

🎯 Simular problema pós-APPLY

👉 Imagine:

• Programa começa a falhar
• Load module inconsistente

---

🔄 FASE 7 — RESTORE

🎯 Objetivo

Reverter mudança

---

🧾 JCL

//RESTORE JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 RESTORE SELECT(UQ00003) GROUP CHECK.
/*

---

🔍 Ajustar dependências

Depois:

 RESTORE SELECT(UQ00003) GROUP.

---

✅ Resultado

• TARGET revertido
• Sistema estável

---

💣 VARIAÇÃO AVANÇADA (nível sênior)

😈 Faça isso:

1. APPLY
2. ACCEPT
3. Tente RESTORE

---

💥 Resultado:

RESTORE não resolve

---

🧠 Aprendizado:

ACCEPT muda o jogo completamente

---

📊 CHECKLIST DO LAB

Etapa	Status
RECEIVE executado	☐
APPLY sem CHECK (erro)	☐
Diagnóstico feito	☐
APPLY correto	☐
ACCEPT realizado	☐
RESTORE executado	☐

---

🧠 LIÇÕES DO LAB

🔥 1. RECEIVE define o futuro

🔥 2. APPLY muda o presente

🔥 3. ACCEPT congela o sistema

🔥 4. RESTORE depende do passado

---

☕ FRASE FINAL

💀 “O erro não está no SMP/E… está em quem pula etapas.”

 

Bellacosa Mainframe falando sobre SMP/E 

💀🔥 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE REESCREVEU O MUNDO AO REDOR”

O guia que todo dev sênior precisa ler antes de culpar o programa

---

Você já viveu isso:

💣 “rodava ontem… hoje ABENDOU… ninguém mexeu no código”

👉 Então deixa eu te contar a verdade que poucos falam no mainframe:

💀 o código raramente muda… o ambiente muda o tempo todo

E quem controla isso?

🔥 SMP/E — System Modification Program / Extended

---

🕰️ UM POUCO DE HISTÓRIA (POR QUE ISSO EXISTE)

Antes do SMP/E:

• sysprog copiava módulo na mão
• sobrescrevia biblioteca sem controle
• não existia rastreabilidade

Resultado?

💣 ambiente inconsistente
💣 bugs “fantasmas”
💣 caos operacional

O SMP nasceu pra resolver isso… e evoluiu para o SMP/E:

👉 controle
👉 consistência
👉 governança

---

🧠 SMP/E NA PRÁTICA (SEM ROMANTIZAR)

Pensa assim:

seu programa = ponta do iceberg
smp/e = quem controla o oceano inteiro

Ele decide:

• qual versão roda
• quais dependências são válidas
• o que entra no sistema
• o que quebra silenciosamente

---

🔠 ACRÔNIMOS (TRADUÇÃO DE VERDADE)

🔥 SMP/E

👉 System Modification Program / Extended
👉 gerenciador de instalação e manutenção

---

📦 SYSMOD

👉 pacote de mudança

Tipos:

• FUNCTION → instala produto
• PTF → correção oficial
• APAR → problema reportado
• USERMOD → customização local

💣 Easter egg:

USERMOD mal feito vira dívida técnica eterna

---

🧬 CSI

👉 Consolidated Software Inventory

👉 banco VSAM onde tudo é registrado:

• versões
• dependências
• histórico

💀 sem CSI consistente:

você não tem ambiente… tem sorte

---

🧠 FMID / RMID / UMID

• FMID → origem (quem criou)
• RMID → última substituição
• UMID → updates incrementais

👉 isso é controle de versão REAL (muito antes do Git 😄)

---

🧱 COMO FUNCIONA O ARMAZENAMENTO

📦 O coração: CSI (VSAM)

👉 dataset VSAM KSDS

Contém:

• ZONES
• entradas de elementos
• relações entre bibliotecas

---

🧩 ZONES (ARQUITETURA LÓGICA)

Zone	Função
GLOBAL	índice e controle
TARGET	o que está rodando
DLIB	base confiável

---

💡 Insight de sênior:

🔥 TARGET mente
🔥 DLIB não mente

---

📁 TIPOS DE DATASETS DO SMP/E

🔹 SMPCSI

👉 o banco (VSAM)

---

🔹 SMPPTS

👉 staging dos SYSMODs (RECEIVE)

---

🔹 SMPLOG / SMPOUT

👉 logs e mensagens (onde está a verdade)

---

🔹 TARGET LIBRARIES

👉 executáveis (load modules)

---

🔹 DISTRIBUTION LIBRARIES (DLIB)

👉 base confiável (source, macros, objetos)

---

💣 Curiosidade:

DLIB geralmente NÃO é executável
e mesmo assim é mais importante que TARGET

---

⚙️ COMO O SMP/E FUNCIONA (O FLUXO QUE MANDA EM TUDO)

RECEIVE → APPLY → ACCEPT

---

🔹 RECEIVE

• carrega SYSMOD
• não altera sistema

---

🔹 APPLY

• altera TARGET
• muda runtime

💀 aqui nasce o problema

---

🔹 ACCEPT

• atualiza DLIB
• vira baseline

---

💣 Easter egg:

APPLY muda o presente
ACCEPT muda o futuro

---

🖥️ SMP/E NO ISPF (TELA VERDE RAIZ)

Acesso típico:

TSO SMPE

Menu clássico:

• RECEIVE
• APPLY
• ACCEPT
• RESTORE
• LIST / REPORT

---

💡 Dica de sênior:

ISPF é interface…
mas quem manda é o JCL

---

⚙️ SMP/E VIA BATCH (MUNDO REAL)

Execução padrão:

//SMPE EXEC PGM=GIMSMP
//SMPCSI DD ...
//SYSIN  DD *
  SET BDY(TZONE).
  APPLY CHECK.
/*

---

💣 Curiosidade:

todo clique no ISPF vira JCL por baixo

---

🧩 MCS — A LINGUAGEM DO SMP/E

Tudo começa com:

++PTF
++VER
++MOD

---

🔥 ++VER (O MAIS IMPORTANTE)

Define:

• FMID
• dependências
• aplicabilidade

💀 erro aqui = APPLY FAIL

---

🔗 DEPENDÊNCIAS (ONDE O BICHO PEGA)

• PRE → precisa antes
• REQ → precisa junto
• SUP → substitui

---

💣 80% dos erros de SMP/E:

👉 dependência não resolvida

---

🏗️ JCLIN — O SEGREDO QUE NINGUÉM TE CONTA

👉 não executa
👉 descreve o link-edit

💡 SMP/E aprende como montar o sistema

---

💀 erro clássico:

código certo… montagem errada

---

🧬 TRACKING (O NÍVEL QUE DIFERENCIA)

SMP/E sabe:

FMID → origem
RMID → substituição
UMID → updates

---

💡 Insight:

• 1 RMID por elemento
• vários UMIDs

👉 isso explica comportamento estranho

---

💣 CASO REAL (VOCÊ JÁ VIU ISSO)

👉 programa mudou comportamento

Causa:

• novo PTF
• RMID alterado
• runtime atualizado

💀 não foi o código

---

⚠️ TROUBLESHOOTING RÁPIDO

Se der erro:

1. leia SMPOUT
2. verifique dependência
3. cheque HOLDDATA
4. valide zone
5. rode APPLY CHECK

---

🍛 A PENSAR NA HORA DO ALMOÇO

👉 quantos bugs você debugou…

…que eram:

• mudança de load module
• alteração de ambiente
• PTF aplicado

---

🚀 CONCLUSÃO (NÍVEL SÊNIOR)

💀 SMP/E não instala software
🔥 ele governa o estado do sistema

---

🔥 FRASE FINAL (ASSINATURA)

💣 “Seu código não mudou…
o mundo ao redor dele mudou — e você não viu.”

 

☕💥 Seu DB2 não é lento… você que não está ouvindo ele: Um guia de Database Management para COBOListas raiz (com história, bastidores e prática real)

 

Bellacosa Mainframe fala sobre db2 database management

☕💥 Seu DB2 não é lento… você que não está ouvindo ele

Um guia de Database Management para COBOListas raiz (com história, bastidores e prática real)

---

🧠 Introdução — o erro clássico do dev COBOL experiente

Se você já escreveu toneladas de código em COBOL, rodou JCL de olhos fechados e fez commit no IBM Db2 como quem toma café…

👉 deixa eu te provocar:

Você domina DB2… ou só usa ele?

Porque existe uma diferença brutal entre:

• quem usa SELECT
• e quem entende o comportamento do banco em produção

Esse artigo é pra te levar do segundo nível ao terceiro 😈

---

🏛️ Origem — quando o banco virou protagonista

Antes do relacional:

• dados eram hierárquicos (tipo IBM IMS)
• dependência total da aplicação

Então veio Edgar F. Codd (1970) com o modelo relacional.

👉 Resultado:

• nasce SQL
• nasce o DB2
• nasce o conceito de independência de dados

💡 Easter egg histórico:

DB2 foi um dos primeiros DBMS comerciais a implementar o modelo relacional de forma prática em larga escala.

---

🧩 O que é Database Management (na prática real)

Você já viu no módulo:

Criar banco é fácil.
Manter banco é o jogo.

---

🔥 O DBA mindset que você precisa absorver

Criar → Carregar → Monitorar → Proteger → Otimizar → Evoluir

---

🏗️ PARTE 1 — CRIAÇÃO (onde tudo começa… ou dá errado)

🧠 Modelagem (não pule isso)

🔹 Conceitual

• negócio (cliente, pedido)

🔹 Lógico

• tabelas e relacionamentos

🔹 Físico

• DB2 real (tablespace, index, etc)

💡 Insight:

COBOL sem modelagem vira gambiarra persistente

---

💻 Exemplo (estilo produção)

CREATE TABLE CLIENTES (
  ID INTEGER NOT NULL,
  NOME VARCHAR(100) NOT NULL,
  SALDO DECIMAL(10,2),
  PRIMARY KEY (ID)
);

👉 Aqui você definiu:

• estrutura
• tipo
• integridade

---

⚙️ PARTE 2 — FIELD ATTRIBUTES (onde mora o perigo silencioso)

💥 Escolhas erradas que você já viu:

• PIC X(100) pra tudo 😬
• DECIMAL mal definido
• campos NULL sem controle

---

💡 Regra de ouro

Tipo correto = performance + qualidade + economia

---

🧠 Exemplo clássico

❌ errado:

SALDO VARCHAR(50)

✅ correto:

SALDO DECIMAL(10,2)

---

💾 PARTE 3 — BACKUP (ou como sobreviver)

💡 Verdade dura:

Backup não testado = backup inexistente

---

🔧 No mundo real

• full backup
• incremental
• logs

👉 DB2 usa logs pra recovery fino

---

💥 Cenário real:

00:00 backup
10:32 falha

👉 Recovery:

• restore backup
• aplicar logs até 10:31

---

🧾 PARTE 4 — LOGGING (a caixa preta do sistema)

Logs registram:

• INSERT
• UPDATE
• DELETE
• erros

💡 Easter egg:

Sem log, DB2 vira só um arquivo caro

---

⚡ PARTE 5 — PERFORMANCE (onde o bicho pega)

🔍 O erro clássico do COBOLista

SELECT * FROM CLIENTES;

👉 sem índice
👉 sem filtro
👉 sem plano

---

💥 Ferramenta essencial

EXPLAIN PLAN FOR ...

👉 mostra:

• table scan
• index usage
• custo

---

🧠 Insight de produção

Query lenta não é azar
👉 é falta de análise

---

🛠️ PARTE 6 — PROBLEM DETERMINATION

🧨 Situações reais

• deadlock
• tabela bloqueada
• job travado
• programa COBOL falhando

---

🔍 Ferramentas

• logs
• return codes (SQLCODE 👀)
• traces

---

💡 Easter egg COBOL:

IF SQLCODE NOT = 0

👉 esse é o grito silencioso do DB2

---

🔁 PARTE 7 — REPLICATION (escala nível banco)

👉 cópia do banco:

• leitura distribuída
• alta disponibilidade

---

💡 Exemplo

• DB2 PROD → DB2 READ ONLY

---

🔄 PARTE 8 — ETL (o mundo além do transacional)

Fluxo:

• Extract → DB2
• Transform → regras
• Load → Data Warehouse

---

💡 Insight:

DB2 alimenta o negócio invisível

---

🗄️ PARTE 9 — ARCHIVING (o segredo da performance)

💥 Problema:

Tabela cresce sem controle

✅ Solução:

• arquivar dados antigos

---

💡 Exemplo:

• transações > 5 anos → archive

---

🧹 PARTE 10 — DATA QUALITY (o mais negligenciado)

💡 Pergunta brutal:

Você confia nos dados?

---

🔧 Técnicas:

• validação
• constraints
• scripts

---

💥 Exemplo

saldo negativo indevido
data inválida
cliente duplicado

---

📊 PARTE 11 — REPORTING (onde o dinheiro aparece)

👉 Dados → Informação → Decisão

---

🚀 RESUMO FINAL (nível senior)

DB2 não é banco…
é sistema crítico de negócio

---

☕ INSIGHT FINAL ESTILO BELLACOSA

Você pode escrever COBOL perfeito…
👉 mas se o DB2 estiver errado, tudo está errado 😈

---

🎯 FECHAMENTO

Se você chegou até aqui:

👉 você não é mais só dev COBOL
👉 você começou a pensar como DBA