Bellacosa Mainframe com dicas para padawan cobol dominar o db2

🔥☕ O CAMINHO DO PADAWAN Db2 — COMO UM PROGRAMADOR COBOL JÚNIOR SOBREVIVE AO MUNDO REAL DOS BANCOS NO MAINFRAME ☕🔥

Tem uma coisa que quase nenhum curso ensina direito.

O problema de aprender Db2 no mainframe NÃO é decorar:

• SELECT

• FETCH

• CURSOR

• JOIN

Isso qualquer apostila faz.

O verdadeiro desafio é entender:

🚀 COMO O Db2 “PENSA”

Porque no ambiente bancário:

• performance é dinheiro

• CPU custa milhões

• lock errado derruba sistema

• SQL ruim gera guerra entre desenvolvimento e DBA

• um tablespace scan pode parar um banco inteiro

E é aqui que nasce a diferença entre:

• um programador COBOL comum

• e um verdadeiro guerreiro do z/OS.

---

☕ O MAIOR ERRO DO PADAWAN COBOL

Todo iniciante chega no Db2 tentando programar como se estivesse lendo VSAM.

Faz:

• loop

• READ

• IF

• PERFORM

• validação manual

• cursor desnecessário

e transforma o Db2 num simples “arquivo sofisticado”.

🔥 Grave isso:

Db2 NÃO é VSAM.

Db2 é:

• relacional

• baseado em conjuntos

• otimizado matematicamente

• orientado a custo

• controlado por estatísticas

---

🚀 O PROGRAMADOR MAINFRAME MODERNO NÃO PENSA EM LINHAS

Ele pensa em:

SETS

---

☕ PROCESSAMENTO RELACIONAL

O programador antigo pensa assim:

“Vou buscar linha por linha e processar.”

O programador Db2 sênior pensa:

“Como faço o Db2 processar tudo sozinho?”

Essa mudança mental vale OURO.

---

🔥 SQL NÃO É APENAS CONSULTA

O padawan acha que SQL é:

SELECT *
FROM CLIENTE

Mas Db2 é MUITO maior:

• optimizer

• locking

• clustering

• filter factors

• parallelism

• stage 1/stage 2

• access paths

• static SQL

• dynamic SQL

• utilities

• EXPLAIN

E quando você entende isso…
você começa a dominar o ambiente bancário.

---

☕ O OPTIMIZER É O VERDADEIRO “CÉREBRO” DO Db2

No mainframe bancário:

• ninguém lê bilhões de linhas “na força”

• ninguém faz scan por diversão

• ninguém quer CPU extra

O optimizer decide:

• qual índice usar

• qual join usar

• se haverá sort

• se haverá prefetch

• se haverá paralelismo

---

🚀 E O QUE O OPTIMIZER USA?

Estatísticas.

RUNSTATS é praticamente:

“os olhos do optimizer”

Sem estatísticas:

• access path piora

• índice é ignorado

• FF fica errado

• CPU explode

---

☕ FILTER FACTOR — O SEGREDO QUE MUITOS IGNORAM

Pouca gente iniciante entende isso.

Mas FF muda TUDO.

🚀 Filter Factor

é:

• a estimativa da porcentagem de linhas que satisfazem um predicado.

---

☕ Exemplo

WHERE DEPT = 'A00'

Se existem:

• 10 departamentos

Db2 estima:

1/10 = 0.1

Ou seja:

• 10% das linhas serão retornadas.

---

🔥 Quanto MENOR o FF:

MELHOR

Porque:

• menos linhas

• menos I/O

• menos CPU

• menos pages

• menos lock

---

☕ O ERRO CLÁSSICO DO PADAWAN

WHERE COL <> 'X'

🔥 Péssimo FF.

Db2 entende:

“quase todas as linhas servem”

Então:

• índice perde valor

• scan aparece

• CPU sobe

---

🚀 INDEX NÃO É MAGIA

Outro choque do iniciante.

Ter índice NÃO garante performance.

O optimizer escolhe:

• usar

• ignorar

• combinar

• fazer screening

• fazer scan

dependendo:

• FF

• cardinalidade

• clustering

• custo estimado

---

☕ O MUNDO REAL DOS BANCOS

Em banco grande:

• tabela pode ter bilhões de linhas

• índice pode ter centenas de GB

• um SQL ruim pode consumir milhares de MIPS

Por isso:

access path é assunto sagrado.

---

🔥 STAGE 1 vs STAGE 2

Esse conceito separa:

• SQL eficiente

• SQL sofrível

---

☕ Stage 1

Predicado processado cedo:

• no Data Manager

• usando índice

• reduzindo linhas rapidamente

Mais rápido.

---

☕ Stage 2

Predicado processado depois:

• mais CPU

• mais linhas avaliadas

• menos eficiência

---

🚀 Exemplo ruim

WHERE YEAR(DATA) = 2025

Função na coluna:

• pode matar indexabilidade

• virar stage 2

---

☕ Melhor abordagem

WHERE DATA BETWEEN '2025-01-01'
AND '2025-12-31'

---

🔥 LOCKING — O TERROR DOS BANCOS

Padawan geralmente aprende SELECT…

mas não aprende:

concorrência.

E no banco:

• milhares de programas acessam a mesma tabela ao mesmo tempo.

---

☕ Lock errado gera:

• timeout

• deadlock

• lentidão

• aplicação travada

• fila no CICS

• caos operacional

---

🚀 LOCKSIZE

Db2 pode bloquear:

• row

• page

• table space

---

☕ O perigo do PAGE LOCK

Uma página pode conter:

• várias linhas

Então:

• um lock pode bloquear muitos registros sem você perceber.

---

🔥 ISOLATION LEVEL

Outro tema CRÍTICO.

---

☕ CS — Cursor Stability

Mais comum no OLTP bancário.

Balanceia:

• integridade

• concorrência

---

☕ RR — Repeatable Read

Mais rígido.
Mais locks.
Mais contenção.

---

☕ UR — Uncommitted Read

O famoso:

dirty read

Excelente para:

• relatórios

• analytics

• consultas não críticas

Péssimo para:

• saldo bancário

• movimentação financeira

😄

---

🚀 COMO EVITAR DEADLOCK

O curso mostrou algo IMPORTANTÍSSIMO:

Todos os programas devem atualizar na mesma sequência.

---

☕ Exemplo

Programa A:

CLIENTE → CONTA

Programa B:

CONTA → CLIENTE

🔥 Receita perfeita para deadlock.

---

🚀 ACCESS PATH — A ALMA DO Db2

Toda query possui um plano.

Db2 decide:

• scan

• index access

• nested loop

• merge scan

• hybrid join

• hash join

---

☕ TABLESPACE SCAN

Lê tudo.

Pode ser:

• correto

• ou desastre absoluto.

---

☕ INDEXED ACCESS

Busca seletiva.

Muito mais eficiente quando:

• FF é baixo

• índice é adequado

---

🚀 JOINS — O CAMPO DE BATALHA

Padawan normalmente só aprende:

INNER JOIN

Mas Db2 usa:

• nested loop

• merge scan

• hybrid join

• star join

dependendo:

• tamanho

• índices

• cardinalidade

---

☕ MERGE SCAN JOIN

Excelente para:

• tabelas grandes

• sem índices úteis

• dados ordenados

---

🔥 STATIC SQL vs DYNAMIC SQL

No banco:
isso é discussão séria.

---

☕ STATIC SQL

Pré-compilado.
Pré-otimizado.

Perfeito para:

• CICS

• OLTP

• alta performance

---

☕ DYNAMIC SQL

Construído runtime.

Excelente para:

• analytics

• ferramentas

• SQL variável

---

🚀 Por que bancos AMAM STATIC SQL?

Porque:

• menos CPU

• menos prepare

• access path estável

• melhor governança

---

☕ EXPLAIN — O RAIO-X DO OPTIMIZER

Se você não usa EXPLAIN…
você está programando no escuro.

---

🚀 EXPLAIN mostra:

• índice usado

• tipo de join

• matching columns

• prefetch

• paralelismo

• custo estimado

---

☕ PLAN_TABLE

É praticamente:

a Bíblia do tuning Db2.

---

🔥 UNION vs UNION ALL

Padawan frequentemente usa:

UNION

sem perceber:

• Db2 faz SORT

• remove duplicatas

• aumenta CPU

---

🚀 UNION ALL

Muito mais rápido.

Use quando:

• duplicatas não importam.

---

☕ FETCH FIRST

Outro segredo simples que salva CPU.

---

❌ Errado

SELECT *
FROM BIGTABLE

---

✅ Melhor

FETCH FIRST 10 ROWS ONLY

---

🚀 “PEÇA SOMENTE O NECESSÁRIO”

Essa é uma filosofia inteira do Db2.

---

☕ EVITE ESCREVER CÓDIGO

A aula falou algo brilhante:

“Avoid Writing Code”

---

🚀 O Db2 já sabe:

• somar

• converter

• truncar

• upper/lower

• calcular datas

• agregar

• ordenar

• paralelizar

Então:

• use funções SQL

• use set processing

• use procedures

• use triggers

---

☕ O COBOL NÃO DEVE FAZER O QUE O Db2 FAZ MELHOR

Essa frase muda carreiras.

---

🔥 O SEGREDO FINAL

No ambiente bancário:
o programador COBOL NÃO domina apenas COBOL.

Ele precisa entender:

• SQL

• optimizer

• access path

• locking

• concurrency

• CPU

• I/O

• clustering

• statistics

• utilities

Porque:

o verdadeiro programa executa dentro do Db2.

---

☕ O PADAWAN VIRA MESTRE QUANDO ENTENDE:

“SQL não é uma linguagem de acesso.
SQL é uma linguagem de processamento.”

🔥☕ Welcome to the real mainframe world, padawan.

 

Bellacosa Mainframe estudo do caso CPU Explodindo

💥 DB2 - CENÁRIO: CPU EXPLODINDO EM PRODUÇÃO

🧪 Situação

• Batch rodando há anos
• De repente: ⬆ CPU / ⬆ elapsed time
• Usuários reclamando
• SLA estourando

---

⚠️ QUERY PROBLEMÁTICA

SELECT *
FROM VAGNER.PEDIDOS P
JOIN VAGNER.CLIENTES C
  ON P.CLIENTE_ID = C.ID
WHERE C.CIDADE = 'SAO PAULO';

---

💣 SINTOMAS

• CPU alto 🔥
• Long elapsed time
• I/O elevado
• Threads presas

---

🔍 PASSO 1 — EXPLAIN (descobrindo o vilão)

👉 Você roda EXPLAIN e vê:

ACCESSTYPE = R (TABLE SCAN)
METHOD = 1 (Nested Loop)
MATCHCOLS = 0

---

🧠 DIAGNÓSTICO

💥 Problemas identificados:

1. Sem índice em C.CIDADE
2. Join usando nested loop pesado
3. Alto volume de leitura
4. SELECT * (puxa dados desnecessários)

---

🚨 CAUSA REAL DO CPU ALTO

👉 Db2 está:

• Varredura completa (scan)
• Fazendo join linha a linha
• Lendo MUITO mais dados que precisa

💡 Tradução:

Está trabalhando demais pra responder pouco

---

🚀 PASSO 2 — CORREÇÃO (TUNING REAL)

🔹 1. Criar índice estratégico

CREATE INDEX IDX_CLIENTES_CIDADE
ON VAGNER.CLIENTES (CIDADE);

---

🔹 2. Índice para JOIN

CREATE INDEX IDX_PEDIDOS_CLIENTE
ON VAGNER.PEDIDOS (CLIENTE_ID);

---

🔹 3. Evitar SELECT *

SELECT P.ID, C.NOME
FROM VAGNER.PEDIDOS P
JOIN VAGNER.CLIENTES C
  ON P.CLIENTE_ID = C.ID
WHERE C.CIDADE = 'SAO PAULO';

---

🔹 4. Atualizar estatísticas

RUNSTATS TABLESPACE VAGNER.TSCLIENTES;
RUNSTATS TABLESPACE VAGNER.TSPEDIDOS;

---

🔁 PASSO 3 — NOVO EXPLAIN

Agora você vê:

ACCESSTYPE = I
MATCHCOLS > 0
METHOD = melhor otimizado

---

📊 RESULTADO REAL

Métrica	Antes	Depois
CPU	🔥 Alto	⚡ Baixo
Tempo	🐢 Lento	🚀 Rápido
I/O	Alto	Reduzido

---

💣 OUTROS CENÁRIOS DE CPU ALTO (VIDA REAL)

⚠️ 1. Falta de filtro

SELECT * FROM PEDIDOS;

👉 Scan total = CPU alto

---

⚠️ 2. Função no WHERE

WHERE UPPER(NOME) = 'ANA'

👉 Índice ignorado 😬

---

⚠️ 3. OR mal usado

WHERE CIDADE = 'SP' OR CIDADE = 'RJ'

👉 Pode quebrar índice

---

⚠️ 4. RUNSTATS desatualizado

👉 Otimizador toma decisão ruim

---

⚠️ 5. Índice errado

👉 Existe… mas não ajuda

---

🧠 CHECKLIST DE INCIDENTE (use isso na guerra)

Quando CPU subir:

✔ Rodar EXPLAIN
✔ Ver ACCESSTYPE
✔ Checar índices
✔ Ver RUNSTATS
✔ Analisar SELECT *
✔ Avaliar volume de dados

---

🔥 FERRAMENTAS QUE AJUDAM

• EXPLAIN / PLAN_TABLE
• IFCID 316 (performance)
• Monitor tipo OMEGAMON
• Accounting traces

---

😎 FRASES DE QUEM RESOLVE INCIDENTE

• “Isso tá fazendo tablespace scan”
• “O access path mudou”
• “Faltou índice nesse predicado”
• “RUNSTATS tá velho”

---

💥 MENTALIDADE FINAL

👉 CPU alto no Db2 quase nunca é “o mainframe lento”

👉 Normalmente é:

✔ SQL ruim
✔ Índice errado
✔ Estatística desatualizada

 

Bellacosa Mainframe numa visao dos sql joins em db2

☕🔥 SQL JOINs NO DB2 MAINFRAME — A ARTE PERIGOSA DE UNIR TABELAS SEM DERRUBAR A PRODUÇÃO

Existe um momento em que todo desenvolvedor SQL descobre uma verdade assustadora:

👉 Consultar uma tabela é fácil.

🔥 Difícil é unir múltiplas tabelas em ambiente corporativo REAL sem destruir performance.

E no IBM Mainframe DB2 isso ganha outra dimensão.

Porque JOIN no z/OS não é apenas sintaxe.

É:

• engenharia de acesso

• matemática de performance

• estratégia de índices

• controle de I/O

• sobrevivência operacional

---

☕ O QUE MUITA GENTE NÃO ENTENDE SOBRE JOIN

Nos cursos básicos aparece algo assim:

SELECT *
FROM A
INNER JOIN B
ON A.ID = B.ID

Parece simples.

Mas no DB2 Mainframe essa query pode gerar:

🔥 milhões de GETPAGE
🔥 SORTs monstruosos
🔥 CPU elevada
🔥 lock contention
🔥 access path desastroso

---

☕ NO MAINFRAME, JOIN É CIRURGIA

Porque estamos falando de tabelas com:

• bilhões de registros

• múltiplos índices

• concorrência extrema

• milhares de usuários simultâneos

---

☕🔥 INNER JOIN — O “CASAMENTO OBRIGATÓRIO” DO DB2

O INNER JOIN retorna apenas registros que existem nos dois lados.

---

☕ Exemplo clássico

Tabela EMPLOYEE

E001  AKHIL
E002  NIKITA
E003  NIL

Tabela JOIN_DATE

E002  2016-04-18
E003  2016-04-19

---

☕ Query

SELECT
   E.EMP_ID,
   E.FIRST_NAME,
   J.JOINING_DATE
FROM EMPLOYEE E
INNER JOIN JOIN_DATE J
ON E.EMP_ID = J.EMP_ID

---

☕ Resultado

Somente:

E002
E003

Porque apenas esses possuem correspondência.

---

☕ Bellacosa Mainframe Analysis™

INNER JOIN é como:

INTERSEÇÃO DE DATASETS CORPORATIVOS

Só sobrevive quem existe nos dois lados.

---

☕🔥 O ACCESS PATH É O VERDADEIRO REI

O iniciante olha a query.

O DBA Mainframe olha:

🔥 o plano de execução.

---

☕ O DB2 precisa decidir:

• qual tabela acessar primeiro

• qual índice usar

• qual JOIN METHOD aplicar

• se haverá SORT

• se haverá PREFETCH

---

☕ E aqui nasce a magia (ou o desastre)

---

☕🔥 NESTED LOOP JOIN — O “LOOP DENTRO DE LOOP”

Estratégia clássica.

---

☕ Como funciona?

PARA CADA LINHA DA TABELA A
   PROCURE NA TABELA B

---

☕ Excelente para:

✅ pequenos volumes
✅ índices eficientes
✅ buscas seletivas

---

☕ Horrível para:

🔥 tabelas gigantes sem índice.

---

☕ Exemplo mental

É como procurar:

um CPF específico no arquivo do banco.

---

☕🔥 MERGE SCAN JOIN — O MESTRE DOS GRANDES VOLUMES

Agora entramos no território corporativo pesado.

---

☕ Funciona melhor quando:

• dados estão ordenados

• índices ajudam

• clustering está correto

---

☕ O DB2 faz:

TABELA A → ordenada
TABELA B → ordenada

E “caminha” simultaneamente pelas duas.

---

☕ Isso reduz brutalmente:

• I/O

• CPU

• leitura aleatória

---

☕ DBA Mainframe AMA Merge Scan.

---

☕🔥 HYBRID JOIN — O “FRANKENSTEIN” DO OTIMIZADOR

O DB2 mistura estratégias dependendo do cenário.

---

☕ Porque no z/OS:

🔥 performance é dinâmica.

---

☕ O que muda?

• cardinalidade

• RUNSTATS

• distribuição

• volume

• filtro

• índice

---

☕ Mesma query.

☕ Performance completamente diferente.

---

☕🔥 LEFT JOIN — O “TRAGA TUDO DA ESQUERDA”

Agora chegamos numa armadilha clássica.

---

☕ Query

SELECT
   E.NAME,
   J.JOIN_DATE
FROM EMPLOYEE E
LEFT JOIN JOIN_DATE J
ON E.ID = J.ID

---

☕ O que acontece?

Todos os registros da esquerda aparecem.

Mesmo sem correspondência.

---

☕ Resultado possível

AKHIL   NULL
NIKITA  2016

---

☕ Isso é MUITO usado em:

• auditoria

• relatórios

• detecção de ausência

• reconciliação financeira

---

☕🔥 NULL — O FANTASMA CORPORATIVO

Pouca coisa gera mais bugs que NULL.

---

☕ NULL não significa:

ZERO
VAZIO
ESPAÇO

---

☕ NULL significa:

🔥 “valor desconhecido”.

---

☕ E isso muda toda a lógica SQL.

---

☕ Exemplo perigoso

WHERE CAMPO = NULL

ERRADO.

---

☕ Correto:

WHERE CAMPO IS NULL

---

☕🔥 RIGHT JOIN — O “PRIMO ESQUECIDO”

Tecnicamente útil.

Praticamente raro.

---

☕ A maioria dos DBAs prefere:

LEFT JOIN

por legibilidade.

---

☕ Em grandes empresas padronização importa muito.

---

☕🔥 FULL OUTER JOIN — O “CAOS CONTROLADO”

Agora entramos numa operação pesada.

---

☕ FULL JOIN retorna:

✅ registros dos dois lados
✅ combinados ou não

---

☕ Isso é excelente para:

• reconciliação

• comparação

• migração

• auditoria

---

☕ Exemplo clássico bancário

SISTEMA A
vs
SISTEMA B

Detectar:

• faltantes

• inconsistências

• divergências

---

☕🔥 O VERDADEIRO PROBLEMA DOS JOINs

Não é a sintaxe.

É:

🔥 volume.

---

☕ Uma query inocente pode fazer:

JOIN 5 tabelas gigantes

E gerar:

• milhões de linhas intermediárias

• SORTs monstruosos

• WORKFILES enormes

---

☕ Resultado?

Batch explode.

---

☕🔥 WORKFILE — O “INFERNO INVISÍVEL”

Quando DB2 precisa ordenar ou materializar dados:

👉 usa WORKFILE DATABASE.

---

☕ JOIN ruim pode lotar WORKFILE rapidamente.

E aí começa o sofrimento:

• slowdown

• timeout

• degradação

• contenção

---

☕🔥 O SEGREDO DOS DBAs MAINFRAME

O DBA experiente NÃO começa pela query.

Ele começa perguntando:

TEM ÍNDICE?
TEM RUNSTATS?
QUAL A CARDINALIDADE?
QUAL O CLUSTERING?

---

☕ Porque tuning de JOIN é ciência.

---

☕🔥 EXPLAIN — O “RAIO-X” DO DB2

Ferramenta absolutamente crítica.

---

☕ O EXPLAIN mostra:

• access path

• join order

• join method

• índice usado

• custo estimado

---

☕ Sem EXPLAIN…

🔥 você está voando cego no Mainframe.

---

☕🔥 JOIN + COBOL — O CASAMENTO CORPORATIVO

Grande parte do mundo financeiro funciona assim:

COBOL
 ↓
DB2 JOIN
 ↓
CICS / Batch
 ↓
Transação financeira

---

☕ O SQL faz o “trabalho pesado”.

O COBOL orquestra.

---

☕🔥 O QUE O MAINFRAME ENSINA SOBRE SQL

JOIN não é apenas:

ON A.ID = B.ID

JOIN é:

• arquitetura

• performance

• estatística

• engenharia operacional

---

☕ Porque em ambientes críticos:

🔥 uma query mal otimizada pode custar milhões.

---

☕🔥 CONCLUSÃO — SQL JOIN NO DB2 É UMA GUERRA SILENCIOSA

O mundo moderno acha que SQL é apenas linguagem.

O Mainframe sabe que SQL é:

infraestrutura crítica.

E talvez essa seja a maior diferença entre:

• aprender JOIN
  e

• sobreviver ao DB2 z/OS em produção.

Porque no fim…

🔥 unir tabelas é fácil.
Difícil é fazer isso sem derrubar o sistema bancário.

 

Belalcosa Mainframe e o sql matador de db2

☕🔥 SQL NO DB2 MAINFRAME — O “SELECT *” QUE PODE DERRUBAR UM BANCO INTEIRO

Todo iniciante em SQL aprende algo assim:

SELECT * FROM CLIENTES;

E pensa:

“Pronto. Sei SQL.”

Mas no universo IBM Mainframe + DB2…

isso é apenas o começo da guerra.

Porque no mundo corporativo REAL:

🔥 SQL não é apenas consulta.
SQL é sobrevivência operacional.

Cada comando pode impactar:

• CPU

• I/O

• Buffer Pool

• Locks

• Access Path

• Throughput

• Batch Window

• SLA bancário

E é aí que o DB2 z/OS entra em outro nível de engenharia.

---

☕ O DB2 NÃO FOI FEITO PARA “PROJETINHOS”

O DB2 Mainframe nasceu para:

• bancos globais

• bolsas financeiras

• cartões

• telecom

• seguradoras

• governo

• processamento massivo

Enquanto bancos menores pensam em simplicidade…

o DB2 pensa em:

🔥 bilhões de linhas simultaneamente.

---

☕🔥 1. SELECT ALL RECORDS — O COMANDO MAIS PERIGOSO PARA INICIANTES

A famosa query:

SELECT *
FROM EMPLOYEES;

parece inocente.

No DB2 z/OS?

Pode virar tragédia.

---

☕ O PROBLEMA DO SELECT *

Ele traz:

• todas as colunas

• dados desnecessários

• mais I/O

• mais GETPAGE

• mais CPU

• mais tráfego

---

☕ Em produção isso custa dinheiro REAL

O profissional Mainframe aprende cedo:

“Nunca peça ao DB2 mais do que você realmente precisa.”

---

☕ Forma correta:

SELECT
    NAME,
    SALARY
FROM EMPLOYEES;

---

☕ Por quê?

Porque no Mainframe:

🔥 performance é cultura.

---

☕ Bellacosa Mainframe Analysis™

SELECT * em produção é como:

COPIAR TODOS OS DATASETS DA EMPRESA
PARA LER APENAS UMA LINHA

---

☕🔥 2. SELECT SPECIFIC COLUMNS — O PENSAMENTO MAINFRAME

Agora começamos a entrar na mentalidade correta.

---

☕ Query:

SELECT
    NAME,
    SALARY
FROM EMPLOYEES;

---

☕ O que o DB2 gosta?

• menos páginas lidas

• menos movimentação

• menos memória

• menos sorting

• menos rede

---

☕ Isso melhora:

✅ cache
✅ buffer pool
✅ response time
✅ throughput

---

☕ Em APIs REST isso é ainda mais importante

Porque hoje:

APP MOBILE
   ↓
API REST
   ↓
DB2 z/OS

Cada byte importa.

---

☕🔥 3. WHERE CLAUSE — O VERDADEIRO CAMPO DE BATALHA

Aqui nasce a diferença entre:

🧠 “quem escreve SQL”
e
🔥 “quem entende DB2”.

---

☕ Exemplo:

SELECT *
FROM EMPLOYEES
WHERE SALARY > 50000;

---

☕ Parece simples.

Mas o DB2 analisa:

• índice

• cardinalidade

• filter factor

• clustering

• access path

• stage 1/stage 2

---

☕🔥 STAGE 1 vs STAGE 2

Conceito clássico do DB2 z/OS.

---

☕ Stage 1

Mais rápido.

Executado próximo ao Data Manager.

---

☕ Stage 2

Mais CPU.

Mais custo.

Mais sofrimento operacional.

---

☕ Exemplo RUIM:

WHERE YEAR(DATAADM) = 2025

Pode inutilizar índice.

---

☕ Melhor:

WHERE DATAADM >= '2025-01-01'
AND DATAADM <  '2026-01-01'

Agora o índice pode respirar.

---

☕🔥 4. ORDER BY — O SORT INVISÍVEL QUE DEVORA CPU

Agora chegamos numa armadilha clássica.

---

☕ Query:

SELECT *
FROM EMPLOYEES
ORDER BY SALARY DESC;

---

☕ O que isso significa internamente?

Possivelmente:

🔥 SORT.

E SORT custa caro.

---

☕ O DB2 tenta evitar isso usando:

• índices

• clustering

• ordering natural

---

☕ Exemplo inteligente

Índice:

SALARY DESC

O DB2 pode evitar sort completamente.

---

☕ DBA Mainframe AMA isso

Porque reduz:

• tempo batch

• consumo CPU

• workfiles

---

☕🔥 5. GROUP BY — O NASCIMENTO DA INTELIGÊNCIA CORPORATIVA

Agora o SQL começa a virar BI.

---

☕ Exemplo:

SELECT
    DEPARTMENT,
    COUNT(*)
FROM EMPLOYEES
GROUP BY DEPARTMENT;

---

☕ Isso parece simples…

Mas alimenta:

• relatórios financeiros

• dashboards

• analytics

• auditoria

• compliance

---

☕ O perigo oculto

GROUP BY pode gerar:

🔥 SORT massivo.

---

☕ E no DB2 isso significa:

• WORKFILES

• TEMP DATABASE

• I/O pesado

• CPU alta

---

☕🔥 O OTIMIZADOR DO DB2 — A ENTIDADE “MISTERIOSA”

Pouca gente entende o poder disso.

O DB2 Optimizer decide:

• qual índice usar

• qual join executar

• qual caminho custa menos

---

☕ E ele faz isso baseado em:

• RUNSTATS

• cardinalidade

• histogramas

• distribuição de dados

---

☕ Sem RUNSTATS atualizado?

🔥 O access path pode virar desastre.

---

☕ Por isso DBA Mainframe é tão valorizado

Porque tuning em DB2 é quase arte.

---

☕🔥 LOCKS — O TERROR SILENCIOSO

Aqui começa a engenharia pesada.

---

☕ Uma query ruim pode causar:

• lock escalation

• deadlock

• timeout

• contention

---

☕ Exemplo clássico

SELECT *
FROM CONTAS
FOR UPDATE

Sem critério?

🔥 caos operacional.

---

☕ No Mainframe milhares acessam simultaneamente

Então concorrência é assunto sagrado.

---

☕🔥 COMMIT — O DETALHE QUE SALVA PRODUÇÃO

Em batch COBOL + DB2:

EXEC SQL
   COMMIT
END-EXEC

não é detalhe.

É sobrevivência.

---

☕ Sem COMMIT correto:

• locks persistem

• logs crescem

• rollback explode

• performance cai

---

☕🔥 O DB2 NÃO PENSA COMO BANCO “COMUM”

Ele pensa como:

um sistema operacional de dados corporativos.

---

☕ Porque ele precisa garantir:

✅ integridade
✅ recuperação
✅ disponibilidade
✅ paralelismo
✅ auditoria
✅ performance

24x7.

---

☕🔥 O QUE O MAINFRAME ENSINA SOBRE SQL

SQL no notebook do estudante:

SELECT *
FROM TESTE;

---

☕ SQL no Mainframe:

QUAL O IMPACTO DISSO NO BUFFER POOL?
VAI GERAR SORT?
USA ÍNDICE?
QUAL O ACCESS PATH?
VAI CAUSAR LOCK?
TEM RUNSTATS?

---

☕ É outro universo.

---

☕🔥 O VERDADEIRO PODER DO DB2

O DB2 não ficou vivo por décadas por acaso.

Ele sobreviveu porque consegue:

🔥 processar absurdos de dados sem parar.

---

☕ PIX.

☕ cartões.
☕ bolsas financeiras.
☕ reservas aéreas.
☕ telecom.
☕ bancos globais.

Tudo isso continua dependendo de SQL rodando em z/OS.

---

☕🔥 CONCLUSÃO — SQL NO MAINFRAME NÃO É “LINGUAGEM”

É engenharia de missão crítica.

E talvez essa seja a maior diferença entre:

• aprender SQL
  e

• entender DB2 Mainframe.

Porque no fim:

🔥 uma query mal escrita pode custar milhões.