Bellacosa Mainframe em tuning DB2

🔥☕ DB2 PERFORMANCE TUNING — O “MOTOR INVISÍVEL” DO MAINFRAME IBM Z

Como um SYSprog/DBA Padawan Aprende a Domar SQL, Buffer Pool, RID Pool, SORT e LOCKING no DB2 z/OS 💾🚀

No universo do DB2 for z/OS existe uma verdade brutal:

💣 “O problema quase nunca é o Mainframe.”

O IBM Z aguenta pancada absurda.
Quem normalmente destrói CPU, I/O e tempo de resposta é:

• SQL mal escrito

• Buffer pool mal dimensionado

• RID pool estourando

• SORT explodindo em WORKFILE

• Locking gerando contenção

O DB2 é praticamente uma cidade viva dentro do z/OS.
E tuning é aprender onde o trânsito trava. ☕🏛️

---

🔥 1. SQL TUNING — O VERDADEIRO REI DA PERFORMANCE

💣 Regra número 1:

“O SQL errado derruba até z17.”

---

☕ O que mais mata performance?

🚨 TABLESPACE SCAN (TBSCAN)

Quando o DB2 lê a tabela inteira.

Exemplo ruim:

SELECT *
FROM CLIENTES
WHERE NOME = 'JOAO'

Sem índice em NOME:

-> scan completo
-> milhões de linhas
-> CPU sobe
-> I/O explode

---

🔥 Como melhorar?

✅ Use índices corretos

CREATE INDEX IX1
ON CLIENTES (NOME)

---

🚀 Prefira Stage 1 Predicates

Predicados Stage 1 são processados cedo pelo DB2.

Bom:

WHERE DATA = '2026-05-14'

Ruim:

WHERE YEAR(DATA) = 2026

A função quebra o uso eficiente do índice.

---

💣 Evite SELECT *

Ruim:

SELECT *

Bom:

SELECT ID, NOME

Menos colunas:

• menos GETPAGE

• menos I/O

• menos CPU

---

🔥 Verifique o ACCESS PATH

Use:

EXPLAIN PLAN

Olhe:

• MATCHCOLS

• INDEX ONLY

• TBSCAN

• SORT

• RID LIST

---

🚨 Sinais perigosos no EXPLAIN

Problema	Impacto
TBSCAN	scan completo
SORT	uso pesado de workfile
Hybrid Join ruim	CPU explode
List Prefetch excessivo	RID pool sofre
Cartesian Join	caos absoluto

---

☕ Ferramentas clássicas

SPUFI

EXPLAIN YES

---

PLAN_TABLE

Tabela mágica do DBA.

---

Visual Explain

No Data Studio ou ferramentas IBM.

---

🔥 2. BUFFER POOL TUNING — O “CACHE SAGRADO” DO DB2

O Buffer Pool é onde páginas ficam em memória.

Quanto mais HIT:

• menos I/O

• menos disco

• mais velocidade

---

☕ Conceito simples

Sem buffer pool:

Programa -> Disco

Com buffer pool:

Programa -> Memória

Muito mais rápido.

---

🔥 Métricas importantes

Buffer Hit Ratio

Ideal:

> 90%

---

🚨 Sintomas de buffer pool ruim

• Sync I/O alto

• Read I/O excessivo

• CPU esperando disco

• Response time ruim

---

☕ Comandos úteis

Ver status

-DISPLAY BUFFERPOOL(BP0) DETAIL

---

🚀 Alterar tamanho

ALTER BUFFERPOOL BP0 VPSIZE 200000

---

💣 Mas cuidado…

Buffer pool gigante demais:

• rouba memória do z/OS

• aumenta paging

• piora tudo

Tuning é equilíbrio.

---

🔥 Estratégia clássica

Separar objetos críticos

Exemplo:

Buffer Pool	Uso
BP0	sistema
BP1	OLTP
BP2	batch
BP32K	LOB/XML

---

☕ Pagesize correta

Tipo	Page
OLTP	4K
Scan grande	32K

---

🔥 3. RID POOL TUNING — A GUERRA DAS RID LISTS

RID = Record ID.

DB2 usa RID LIST quando:

• vários índices participam

• list prefetch ocorre

---

💣 Quando RID pool estoura…

O DB2 muda estratégia:

RID LIST -> TABLESPACE SCAN

Resultado:
🔥 desastre de performance

---

☕ Verificar RID pool

-DISPLAY BUFFERPOOL

ou IFCID traces.

---

🚀 Ajustar tamanho

ZPARM:

MAXRBLK

---

🔥 Sintomas clássicos

Sintoma	Causa
RID overflow	pool pequeno
fallback para scan	RID cheio
CPU alta	excesso de leitura

---

☕ Soluções

Melhorar índices

Muitas vezes RID pool explode porque:

• índice ruim

• predicates ruins

• cardinalidade ruim

---

Atualizar RUNSTATS

Sem estatística:
DB2 toma decisões erradas.

RUNSTATS TABLESPACE ...

---

🔥 4. SORT TUNING — O BURACO NEGRO DO WORKFILE

SORT é caro.

Muito caro.

---

💣 O que gera SORT?

• ORDER BY

• GROUP BY

• DISTINCT

• UNION

• JOIN sem índice

---

☕ O perigo invisível

SORT -> WORKFILE -> I/O -> CPU -> contenção

---

🚀 Como reduzir SORT?

Criar índices compatíveis

Exemplo:

SELECT *
FROM VENDAS
ORDER BY DATA

Índice:

CREATE INDEX IXDATA
ON VENDAS(DATA)

O DB2 evita SORT.

---

🔥 Monitorar WORKFILE

Veja:

• DSNDB07

• utilização

• overflow

• spill

---

☕ ZPARMs importantes

Parâmetro	Função
SRTPOOL	memória do sort
MAXSORT_IN_MEMORY	sort em memória
DSMAX	datasets

---

🚨 Sintomas clássicos

• DSNDB07 lotado

• I/O absurdo

• elapsed alto

• batch lento

---

🔥 5. LOCKING TUNING — O INFERNO DAS CONTENÇÕES

O DB2 protege dados com locks.

Mas lock demais:
💣 trava o sistema inteiro.

---

☕ Tipos de lock

Tipo	Nível
Row	linha
Page	página
Table	tabela
Tablespace	tudo

---

🚨 Deadlock

Dois processos esperam um ao outro.

Resultado:

SQLCODE -911
ou
SQLCODE -913

---

🔥 Timeout

Um processo espera demais.

---

☕ Estratégias de tuning

✅ Commit frequente

Ruim:

COMMIT a cada 1 milhão

Bom:

COMMIT a cada 1000

---

🚀 Use LOCKSIZE ROW

LOCKSIZE ROW

Menos contenção.

---

💣 Evite lock escalation

Quando muitos locks viram lock maior.

Exemplo:

10000 row locks
-> table lock

Caos no OLTP.

---

☕ CURRENTDATA(NO)

Ajuda em consultas read-only.

---

🔥 ISOLATION LEVEL

Nível	Característica
UR	mais rápido
CS	comum
RS	consistente
RR	máximo lock

---

🚨 RR é perigoso

Repeatable Read

Pode prender milhares de locks.

---

☕ Comandos úteis

Ver locks

-DISPLAY DATABASE(*) LOCKS

---

Threads travadas

-DISPLAY THREAD(*)

---

🔥 O SEGREDO QUE TODO DBA MAINFRAME APRENDE

A maioria dos problemas NÃO é resolvida aumentando hardware.

O fluxo correto é:

1. SQL
2. Índice
3. RUNSTATS
4. Access Path
5. Buffer Pool
6. Sort
7. Locking
8. Só depois pensar em CPU

---

☕ A FILOSOFIA DO DB2 z/OS

O DB2 é como uma megacidade subterrânea.

Cada:

• página

• lock

• RID

• sort

• getpage

é trânsito acontecendo em tempo real.

E o DBA/Sysprog experiente aprende uma coisa:

🔥 “Performance não é força bruta.
É arquitetura inteligente.” 💾🚀

 

 

Bellacosa Mainframe mergulhando em performance e custo de query db2 no Mainframe

🔥☕ “O MAINFRAME NÃO ESTÁ LENTO — SEU SQL É QUE ESTÁ INCENDIANDO A CPU DO IBM Z” 💾🚨

A Verdade Brutal que Todo Sysprog Júnior Descobre Quando Entra no Mundo Real do DB2 for z/OS

Por Bellacosa Mainframe

---

Existe um momento na vida de todo sysprog júnior…

aquele instante mágico, traumático e inesquecível…

quando ele percebe que:

💣 O problema não era o CICS.

💣 Não era o z/OS.

💣 Não era o storage.

💣 Nem o “mainframe velho”.

Era um único SQL.

Sim.

Uma linha aparentemente inocente:

SELECT *
FROM CLIENTES
WHERE CPF = '12345678900'

…destruindo CPU, queimando MIPS, elevando MSU, congestionando buffer pool e transformando a LPAR num inferno termonuclear digital.

Bem-vindo ao mundo real do DB2 for z/OS.

---

☕ O DIA EM QUE O PADAWAN DESCOBRE QUE CPU NO MAINFRAME = DINHEIRO

No universo distribuído moderno, quando falta performance, a resposta costuma ser:

• sobe mais VM

• coloca Kubernetes

• aumenta cluster

• escala horizontalmente

No mainframe?

HAHAHAHA.

Aqui a conversa é outra.

Aqui:

CPU = LICENSING

CPU = MLC

CPU = 4HRA

CPU = FATURA MILIONÁRIA

Um SQL ruim não deixa apenas o sistema “mais lento”.

Ele:

• aumenta custo mensal

• afeta SLA

• derruba throughput

• impacta batch

• congestiona CICS

• aumenta I/O

• cria lock contention

• vira incidente de produção

E o mais assustador?

Muitas vezes tudo começa com um programador dizendo:

“Mas é só um SELECT…”

---

🏛️ O MAINFRAME NÃO PENSA COMO VOCÊ

O sysprog júnior normalmente imagina que o DB2 executa SQL exatamente como foi escrito.

Não.

O DB2 é muito mais sofisticado.

Quando você envia um SQL, o DB2 chama uma entidade quase mística:

🔥 O OPTIMIZER

Ele analisa:

• estatísticas

• cardinalidade

• índices

• distribuição de dados

• filtros

• joins

• sort

• predicates

• paralelismo

• buffer access

E então decide:

“Qual será o caminho menos custoso para encontrar esses dados?”

Esse caminho se chama:

☕ ACCESS PATH

E é aqui que nascem:

• os heróis

• os vilões

• os incêndios de CPU

• e os DBA traumatizados.

---

💣 O TABLESPACE SCAN — O DEMÔNIO QUE ASSOMBRA PRODUÇÃO

Imagine uma tabela com:

• 900 milhões de linhas

• 14 TB

• milhões de acessos diários

Agora imagine um SQL sem índice adequado:

SELECT *
FROM CLIENTES
WHERE CPF = '12345678900'

Sem índice…

o DB2 pode precisar ler:

• página por página

• bloco por bloco

• segmento por segmento

Isso se chama:

🚨 TABLESPACE SCAN

Ou seja:

o DB2 sai varrendo o oceano inteiro para encontrar um peixinho.

Resultado:

• GETPAGE explode

• CPU dispara

• synchronous I/O aumenta

• elapsed cresce

• batch atrasa

• CICS sofre

E o sysprog júnior começa a ouvir palavras assustadoras no war room:

• “buffer pool saturation”

• “RID failure”

• “class 2 CPU”

• “dynamic statement cache”

• “DSNZPARM”

• “DSNDB07 lotado”

---

☕ O PODER SOBRENATURAL DE UM ÍNDICE

Agora veja a mesma consulta com índice:

CREATE INDEX IXCPF
ON CLIENTES (CPF)

O cenário muda completamente.

Agora o DB2:

• acessa diretamente o valor

• evita scan massivo

• reduz GETPAGE

• diminui I/O

• baixa CPU

O que levava:

• 40 minutos

passa a levar:

• 2 segundos

Sem exagero.

No mundo IBM Z isso acontece TODOS OS DIAS.

---

🔥 O ERRO MAIS COMUM DOS PROGRAMADORES COBOL

Padawan…

grave isso na alma:

“O COBOL não mata CPU sozinho.”

“O SQL dentro dele mata.”

Um clássico infernal:

PERFORM VARYING WS-I FROM 1 BY 1
   EXEC SQL
      SELECT ...
   END-EXEC
END-PERFORM

Parabéns.

Você acabou de criar:

☠️ O APOCALIPSE DO ROW-BY-ROW PROCESSING

Também conhecido como:

• slow by slow

• chatty SQL

• cursor abuse

O programa funciona.

Mas em produção:

• executa milhões de SQLs

• congestiona DB2

• aumenta context switch

• explode CPU

O júnior acha:

“Funcionou no teste.”

O veterano olha e já sente dor física.

---

🧠 O MITO DO “SELECT *”

Outra heresia clássica:

SELECT *

Isso é praticamente um ritual proibido em ambientes críticos.

Porque talvez você precise:

• 2 colunas

Mas o DB2 entrega:

• 180 colunas

• LOBs

• dados inúteis

• mais I/O

• mais buffer

• mais sort

• mais CPU

O correto:

SELECT NOME, CPF

No mainframe:

eficiência é religião.

---

☕ RUNSTATS — O ALIMENTO DO OPTIMIZER

O optimizer do DB2 depende de estatísticas.

Sem elas:

ele fica cego.

RUNSTATS informa:

• quantidade de linhas

• distribuição

• cardinalidade

• clustering

• seletividade

Sem RUNSTATS atualizada…

o DB2 toma decisões absurdas.

Exemplo real:

Tabela cresceu de:

• 10 milhões
  para

• 800 milhões linhas

Mas estatística continua antiga.

O optimizer acredita que a tabela ainda é pequena.

Escolhe nested loop inadequado.

Resultado:

💣 CPU 100x maior

---

🔥 EXPLAIN — O RAIO-X DA ALMA DO SQL

Veterano de DB2 não confia em “achismo”.

Ele usa:

EXPLAIN PLAN

Porque EXPLAIN revela:

• índice usado

• join method

• scans

• sorts

• custo estimado

• stage 1 / stage 2

• parallelism

É literalmente:

a anatomia do pensamento do DB2.

---

☕ STAGE 2 — O CEMITÉRIO DA INDEXABILITY

Veja isso:

WHERE SUBSTR(NOME,1,3) = 'MAR'

Parece elegante.

Mas pode impedir uso eficiente de índice.

Outro clássico:

WHERE YEAR(DATA) = 2025

Muito bonito.

Muito moderno.

Muito destrutivo.

Melhor:

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

Porque agora:

• o índice pode respirar

• o optimizer consegue navegar melhor

---

🔥 GETPAGE — A PALAVRA QUE FAZ DBA SUAR FRIO

No DB2 z/OS:

GETPAGE = acesso à página de dados.

Muito GETPAGE:

• mais CPU

• mais latch

• mais memória

• mais I/O

Veteranos monitoram:

• GETPAGE

• sync read

• class 1

• class 2

• lock wait

• RID list

como cardiologista monitorando ECG.

---

☕ “RÁPIDO” NÃO SIGNIFICA “BARATO”

Essa é uma das maiores lições do mainframe.

Às vezes:

• elapsed time está ótimo

MAS:

• CPU está monstruosa.

O usuário acha:

“Nossa, ficou rápido!”

O financeiro vê:

💸🔥💸🔥💸🔥

Porque no IBM Z:

CPU custa dinheiro real.

---

🤖 A ERA DA IA NO TUNING DB2

Hoje ferramentas modernas analisam:

• SQLs problemáticos

• regressão de access path

• mudanças após REBIND

• índices ausentes

• scans perigosos

• CPU anomalies

E algumas usam IA para:

• prever degradação

• sugerir rewrite

• detectar padrões tóxicos

• identificar SQLs assassinos

O futuro do tuning DB2 já começou.

---

🏛️ O QUE O SYSprog JÚNIOR PRECISA ENTENDER URGENTEMENTE

Mainframe não é:

• “computador velho”

• “COBOL antigo”

• “legado ultrapassado”

Mainframe é:

engenharia extrema de throughput.

E DB2 for z/OS é:

um dos motores transacionais mais eficientes já criados pela humanidade.

Ele processa:

• bancos

• cartões

• bolsa

• aviação

• seguros

• governo

• PIX

• ATM

• clearing financeira

Em escala absurda.

---

☕ A GRANDE VERDADE FINAL

O mundo moderno fala:

• cloud

• containers

• microservices

• IA

Mas nos bastidores…

existe um IBM Z executando milhões de transações por segundo…

e um DBA desesperado tentando descobrir:

🔥 “QUAL SQL ESTÁ QUEIMANDO A CPU?” 🔥

Porque no fim…

o COBOL processa o negócio…

o CICS coordena as transações…

mas:

💾 É O ACCESS PATH DO DB2 QUE DECIDE QUANTO CUSTA MANTER O MUNDO FUNCIONANDO. ☕🔥

 

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 explique Explain e Access Path

💥 DB2 LAB: EXPLAIN + ACCESS PATH (na prática)

🎯 Objetivo

👉 Entender como o Db2 decide acessar os dados
👉 Identificar quando está lento
👉 Corrigir com índice + estatísticas

---

🧪 PARTE 1 — Criando o cenário (problema real)

🔹 Tabela sem índice

CREATE TABLE VAGNER.CLIENTES (
  ID        INTEGER,
  NOME      VARCHAR(50),
  CIDADE    VARCHAR(50)
);

---

🔹 Inserindo volume (simulação)

INSERT INTO VAGNER.CLIENTES VALUES (1,'ANA','SP');
INSERT INTO VAGNER.CLIENTES VALUES (2,'JOAO','RJ');
-- imagine milhares de registros...

---

🔹 Query problemática

SELECT * FROM VAGNER.CLIENTES
WHERE ID = 2;

💡 Parece simples… mas sem índice:

💥 TABLE SPACE SCAN (varre tudo)

---

🔍 PARTE 2 — Rodando EXPLAIN

🔹 Comando

EXPLAIN PLAN FOR
SELECT * FROM VAGNER.CLIENTES
WHERE ID = 2;

---

🔹 Consultando resultado

SELECT 
  PLANNO,
  METHOD,
  ACCESSTYPE,
  MATCHCOLS
FROM PLAN_TABLE;

---

💣 Interpretação

Campo	Significado
ACCESSTYPE = 'R'	Table scan 😬
ACCESSTYPE = 'I'	Index scan 😎
MATCHCOLS	Quantas colunas do índice usadas

---

⚠️ Resultado esperado (ruim)

ACCESSTYPE = R

👉 Tradução:

Db2 está varrendo a tabela inteira

---

🚀 PARTE 3 — Corrigindo (tuning real)

🔹 Criar índice

CREATE INDEX IDX_CLIENTES_ID
ON VAGNER.CLIENTES (ID);

---

🔹 Atualizar estatísticas

RUNSTATS TABLESPACE VAGNER.TSCLIENTES;

💡 Sem RUNSTATS:

O otimizador fica “cego”

---

🔁 PARTE 4 — Rodar EXPLAIN novamente

Mesmo comando:

EXPLAIN PLAN FOR
SELECT * FROM VAGNER.CLIENTES
WHERE ID = 2;

---

✅ Novo resultado

ACCESSTYPE = I
MATCHCOLS = 1

👉 Agora sim:

⚡ Usa índice
⚡ Muito mais rápido

---

💥 PARTE 5 — Comparação real

Antes	Depois
Table scan	Index scan
Lento 🐢	Rápido ⚡
Alto CPU	Baixo CPU

---

🧠 PARTE 6 — Entendendo o Access Path

👉 O otimizador decide baseado em:

• Estatísticas (RUNSTATS)
• Índices disponíveis
• Filtro (WHERE)
• Volume de dados

---

💣 CASOS REAIS DE PRODUÇÃO

⚠️ 1. Índice existe, mas não usa

👉 Possível causa:

• RUNSTATS desatualizado

---

⚠️ 2. MATCHCOLS = 0

👉 Índice não está sendo aproveitado

---

⚠️ 3. SELECT *

👉 Pode forçar acesso desnecessário

---

🔥 DICAS DE OURO

✔ Sempre rodar EXPLAIN antes de produção
✔ Criar índice baseado no WHERE
✔ Atualizar RUNSTATS regularmente
✔ Evitar SELECT *

---

🧠 MINI CHECKLIST (antes de subir código)

• EXPLAIN OK?
• ACCESSTYPE = I?
• MATCHCOLS > 0?
• RUNSTATS atualizado?

---

😎 FRASE DE SENIOR

“Sem EXPLAIN, você está programando no escuro.”

 

Bellacosa Mainframe apresenta Cheatsheet do DB2

💥 DB2 CHEATSHEET — COLA DE PROVA

---

🧠 🧩 FUNDAMENTOS

👉 Db2 = RDBMS (Relational Database Management System)
👉 Usa SQL
👉 Roda no z/OS (core banking, missão crítica)

---

⚙️ 📊 OBJETOS PRINCIPAIS

Objeto	Função
TABLE	Armazena dados
VIEW	Tabela lógica (SELECT)
INDEX	Performance
TABLESPACE	Armazenamento físico
SCHEMA	Organização

💡 Dica:

VIEW = não tem dados físicos

---

🧾 🔥 SQL NA VEIA

📌 DDL (estrutura)

CREATE TABLE T1 (ID INT);
ALTER TABLE T1 ADD COL1 CHAR(10);
DROP TABLE T1;

---

📌 DML (dados)

INSERT INTO T1 VALUES (1);
UPDATE T1 SET ID = 2;
DELETE FROM T1 WHERE ID = 2;
SELECT * FROM T1;

---

📌 DCL (segurança)

GRANT SELECT ON T1 TO USER1;
REVOKE SELECT ON T1 FROM USER1;

---

🚀 🔑 COMANDOS IMPORTANTES

👉 CREATE → cria objeto
👉 SELECT → consulta
👉 WHERE → filtra
👉 JOIN → relaciona tabelas
👉 ORDER BY → ordena

---

🔗 🧠 JOINS (CAI MUITO)

Tipo	Comportamento
INNER JOIN	Só registros iguais
LEFT JOIN	Tudo da esquerda
RIGHT JOIN	Tudo da direita
FULL JOIN	Tudo

---

⚡ 📈 PERFORMANCE

👉 INDEX melhora acesso
👉 WHERE + INDEX = 💥 rápido
👉 FULL TABLE SCAN = 🐢 lento

💡 Regra de ouro:

Sem índice = sofrimento

---

🔐 🔒 SEGURANÇA

👉 Integra com RACF
👉 Controle por:

• Usuário
• Grupo
• Permissão (GRANT/REVOKE)

---

💣 ⚠️ SQLCODE (ESSENCIAL!)

Código	Significado
0	Sucesso
+100	Sem dados
-104	Erro de sintaxe
-204	Objeto não existe
-911	Deadlock

💡 Dica:

SQLCODE negativo = erro

---

⚙️ 🧪 EXECUÇÃO

Ferramenta	Uso
SPUFI	Teste interativo
DSNTEP2	Batch
COBOL + EXEC SQL	Produção

---

📦 🧠 CONCEITOS IMPORTANTES

👉 Tablespace → onde dados vivem
👉 Buffer Pool → cache em memória
👉 Commit → grava transação
👉 Rollback → desfaz

---

🔄 🔥 TRANSAÇÕES

COMMIT;
ROLLBACK;

💡 Sem COMMIT:

Você acha que salvou… mas não salvou 😅

---

🧠 💡 CONTINUOUS DELIVERY

👉 Db2 13 usa modelo CD:

✔ Sem upgrade disruptivo
✔ Features liberadas aos poucos

---

📊 💣 PEGADINHAS DE PROVA

❌ Db2 NÃO é hierárquico
❌ NÃO é o mais popular do mundo
✔ É relacional
✔ Forte em missão crítica

---

🧬 🧠 ARQUITETURA RÁPIDA

• Subsystem (DB2P, DB2T…)
• Buffer Pool
• Logs (REDO/UNDO)
• Catalog (metadados)

---

💥 FRASES QUE PASSAM NA PROVA

👉 “Db2 is a relational database system”
👉 “Indexes improve performance”
👉 “SQL is used to manipulate and define data”
👉 “Db2 supports continuous delivery”

---

🚀 MINI MAPA MENTAL FINAL

👉 Db2 = Dados estruturados
👉 SQL = linguagem
👉 INDEX = performance
👉 RACF = segurança
👉 COMMIT = persistência
👉 SQLCODE = diagnóstico

---

😎 DICA FINAL (NÍVEL BELLACOSA)

Se travar na prova:

👉 Pense assim:

• Isso é estrutura? → DDL
• Isso é dados? → DML
• Isso é acesso? → DCL
• Isso é erro? → SQLCODE

👉 E elimina as alternativas absurdas (hierárquico, etc.)

☕💣 PADAWAN, SUA QUERY ACABOU DE DERRUBAR O CICS?

Bellacosa Mainframe e o padawan perigoso nas querys db2

☕💣 PADAWAN, SUA QUERY ACABOU DE DERRUBAR O CICS?

Como Escrever SELECTs Performáticos no DB2 for z/OS Sem Virar Inimigo do DBA

Existe um momento na vida de todo profissional Mainframe em que ele descobre uma verdade dolorosa:

A query funciona.

Mas a CPU não gosta dela.

O usuário não gosta dela.

O DBA não gosta dela.

E o gerente de produção definitivamente não gosta dela.

O iniciante normalmente pensa:

"Mas ela trouxe o resultado correto."

O DB2 pensa:

"Sim. Depois de ler 800 milhões de linhas."

É aí que nasce a diferença entre um programador SQL e um especialista em performance DB2.

Hoje vamos aprender como analisar uma consulta SQL antes que ela se transforme em um incidente de produção.

Prepare seu café.

Vamos conversar sobre CPU, índices, Access Path e sobrevivência corporativa.

---

O PRIMEIRO MANDAMENTO

Nunca confie numa query apenas porque ela funciona

Muitos iniciantes executam:

SELECT *
FROM CLIENTES
WHERE CPF='12345678900';

O resultado aparece instantaneamente no ambiente de testes.

Eles ficam felizes.

Mas esquecem que:

• Teste possui poucos registros

• Produção possui bilhões

• Teste tem poucos usuários

• Produção tem milhares

Uma query aparentemente inocente pode consumir milhares de segundos de CPU diariamente.

---

PASSO 1 — APRENDA A LER O EXPLAIN

O EXPLAIN é o raio-x da consulta.

Antes de colocar qualquer SQL importante em produção execute:

EXPLAIN PLAN SET QUERYNO = 1001
FOR
SELECT ...

O DB2 gravará informações em tabelas como:

• PLAN_TABLE

• DSN_STATEMNT_TABLE

• DSN_FUNCTION_TABLE

Ali está a verdade.

Não a opinião do desenvolvedor.

---

PASSO 2 — DESCUBRA O ACCESS PATH

O Access Path é a rota escolhida pelo otimizador.

Você quer ver algo parecido com:

MATCHCOLS = 3
ACCESS = I
INDEX ONLY = Y

Ou seja:

• usando índice

• poucas leituras

• acesso eficiente

Você NÃO quer encontrar:

ACCESS = R

ou

TABLESPACE SCAN

Isso significa:

"Vou ler tudo."

É como procurar um CPF lendo uma lista telefônica inteira.

---

PASSO 3 — OLHE O MATCHCOLS

Padawan, grave isso.

MATCHCOLS é uma das colunas mais importantes do EXPLAIN.

Suponha índice:

IX01

CPF
AGENCIA
CONTA

Consulta:

WHERE CPF = ?

MATCHCOLS = 1

Excelente.

---

Consulta:

WHERE CPF = ?
AND AGENCIA = ?

MATCHCOLS = 2

Melhor ainda.

---

Consulta:

WHERE AGENCIA = ?

MATCHCOLS = 0

Problema.

O DB2 não consegue aproveitar o início do índice.

---

PASSO 4 — ANALISE A FILTRAGEM

O índice deve reduzir o universo de dados.

Imagine:

Tabela:

100 milhões de linhas

Cláusula:

WHERE SEXO='M'

Se 50 milhões possuem M.

O filtro é ruim.

---

Agora:

WHERE CPF='12345678900'

Retorna uma linha.

Excelente seletividade.

Quanto mais seletivo, melhor.

---

PASSO 5 — CUIDADO COM O LIKE

Boa consulta:

WHERE NOME LIKE 'CARLOS%'

Pode utilizar índice.

---

Consulta perigosa:

WHERE NOME LIKE '%CARLOS%'

O DB2 normalmente perde o acesso direto.

Resultado:

CPU sobe.

GETPAGE sobe.

Tempo sobe.

O DBA chora.

---

PASSO 6 — EVITE FUNÇÕES NA COLUNA INDEXADA

Ruim:

WHERE YEAR(DATA_NASCIMENTO)=2025

O índice pode ser ignorado.

Melhor:

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

Agora o índice pode ser explorado.

---

PASSO 7 — NÃO USE SELECT *

Erro clássico:

SELECT *
FROM CLIENTES

O DB2 buscará tudo.

Inclusive colunas que você não precisa.

Melhor:

SELECT
CPF,
NOME,
LIMITE
FROM CLIENTES

Menos I/O.

Menos CPU.

Menos rede.

Menos buffer pool.

---

PASSO 8 — DESCUBRA SE O ÍNDICE É BOM

Pergunte:

Ele atende o WHERE?

Exemplo:

WHERE CPF=?

Índice:

CPF

Excelente.

---

Ele atende ORDER BY?

Consulta:

WHERE CPF=?
ORDER BY DATA

Índice:

CPF
DATA

Excelente.

Pode eliminar SORT.

---

Ele atende JOIN?

Consulta:

CLIENTE.ID
=
PEDIDO.ID_CLIENTE

A coluna do JOIN deveria estar indexada.

---

PASSO 9 — PROCURE SORTS DESNECESSÁRIOS

O SORT é um consumidor profissional de CPU.

Se aparecer:

SORTN_ORDERBY = Y

investigue.

Talvez um índice resolva.

---

PASSO 10 — ANALISE O CUSTO ESTIMADO

DB2 12 e DB2 13 fornecem estimativas importantes.

Observe principalmente:

TOTAL_COST
CPU_COST
IO_COST

Ferramentas como:

• Data Studio

• Optim Query Workload Tuner

• IBM Data Server Manager

mostram essas informações de forma amigável.

CPU_COST elevado é sinal de atenção.

---

PASSO 11 — OLHE OS GETPAGES

DBAs experientes adoram GETPAGE.

Porque ele mostra quantas páginas serão lidas.

Exemplo:

GETPAGE = 100

Ótimo.

---

GETPAGE = 8.000.000

Hora de revisar a query.

---

PASSO 12 — VERIFIQUE RUNSTATS

Às vezes a query é boa.

O índice é bom.

Mas as estatísticas são ruins.

Verifique:

RUNSTATS atualizado?

Sem estatísticas confiáveis o otimizador toma decisões erradas.

---

PASSO 13 — REORG IMPORTA

Um índice pode existir.

Mas estar fragmentado.

Nesse cenário:

• mais I/O

• mais CPU

• mais elapsed time

REORG continua sendo um dos melhores amigos da performance.

---

PASSO 14 — CUIDADO COM O ONLINE

Batch e Online são mundos diferentes.

No Batch:

5 segundos

Pode ser aceitável.

No Online:

5 segundos

Pode ser uma catástrofe.

Imagine:

1000 usuários simultâneos.

Cada um executando uma query de 5 segundos.

O gargalo nasce rapidamente.

---

PASSO 15 — A REGRA DE OURO DO PADAWAN

Antes de promover uma query para produção pergunte:

✅ Existe índice?

✅ O índice é utilizado?

✅ O MATCHCOLS é bom?

✅ Existe TABLESPACE SCAN?

✅ Existe SORT desnecessário?

✅ O filtro é seletivo?

✅ Os RUNSTATS estão atualizados?

✅ O GETPAGE está razoável?

✅ O CPU_COST parece aceitável?

✅ O tempo de resposta atende o SLA?

Se alguma resposta for não...

Volte para a oficina.

---

O SEGREDO DOS MESTRES DB2

Programadores iniciantes escrevem SQL.

Programadores experientes analisam EXPLAIN.

Especialistas DB2 pensam como o otimizador.

Quando você começa a prever qual índice será utilizado, qual access path será escolhido e qual será o impacto em CPU antes mesmo de executar a query, você deixa de ser apenas um desenvolvedor.

Você começa a enxergar o banco pelos olhos do DB2.

E é nesse momento que o Padawan se aproxima do nível Jedi Mainframe.

Porque no universo do DB2, o objetivo não é apenas retornar dados.

O objetivo é retornar dados rapidamente, consumindo o mínimo possível de CPU, evitando filas no CICS, gargalos no DDF, explosões de GETPAGE e telefonemas desesperados da equipe de produção às duas da manhã.

Que a Força do Access Path esteja com você.

 

Bellacosa Mainframe evoluindo da tela verde ao SQL no Db2

---

☕ Da Tela Verde ao SQL: A Jornada de um Profissional Mainframe

Muitos profissionais aprendem JCL, COBOL, SORT e CICS antes de entrar em contato com SQL.

Quando isso acontece, a primeira impressão costuma ser:

"Parece simples demais."

Mas o SQL possui uma característica única:

É simples para começar e complexo para dominar.

Você consegue escrever um SELECT em poucos minutos.

Pode levar anos para compreender completamente:

• Access Paths

• Indexes

• Buffer Pools

• Locking

• Concurrency

• RUNSTATS

• REORG

• Performance Tuning

Por isso cada objetivo dessa trilha merece ser explorado profundamente.

---

🎯 Objetivo 1: Compreender os Conceitos Básicos do SQL

O que realmente significa?

Entender SQL não é decorar comandos.

É compreender o Modelo Relacional.

Antes do SQL, sistemas trabalhavam diretamente com:

• Arquivos sequenciais

• VSAM KSDS

• VSAM ESDS

• VSAM RRDS

O programador precisava conhecer:

• Layout físico

• Chaves

• Organização dos dados

Com SQL ocorre uma revolução:

Você informa:

SELECT NOME
FROM CLIENTES

O banco decide:

• Como localizar

• Qual índice usar

• Quantas páginas acessar

• Qual estratégia é mais eficiente

Essa separação entre lógica e armazenamento foi uma das maiores inovações da computação.

---

Conceitos fundamentais

Tabela

Equivalente moderno de um arquivo lógico.

Linha

Registro.

Coluna

Campo.

Chave Primária

Identifica unicamente cada registro.

Índice

Estrutura que acelera pesquisas.

Relacionamento

Conexão entre tabelas.

---

🎯 Objetivo 2: Explorar a Sintaxe e Estruturas do SQL

Aqui começa a alfabetização do profissional SQL.

Toda instrução possui uma estrutura lógica.

Exemplo:

SELECT
    NOME,
    CIDADE
FROM CLIENTES
WHERE CIDADE = 'SANTOS'
ORDER BY NOME;

Observe a sequência:

1. SELECT

2. FROM

3. WHERE

4. ORDER BY

A ordem de escrita é simples.

Mas o DB2 executa internamente de forma diferente.

Ele primeiro localiza os dados.

Depois filtra.

Depois ordena.

Compreender isso ajuda a entender performance.

---

Boas práticas desde o início

Evite:

SELECT *
FROM CLIENTES;

Prefira:

SELECT
    ID_CLIENTE,
    NOME,
    CIDADE
FROM CLIENTES;

Essa pequena mudança já demonstra maturidade técnica.

---

🎯 Objetivo 3: Utilizar Comandos Básicos de SQL

Todo profissional precisa dominar quatro comandos fundamentais.

---

SELECT

Consulta informações.

SELECT *
FROM CLIENTES;

---

INSERT

Inclui registros.

INSERT INTO CLIENTES
(
 ID,
 NOME
)
VALUES
(
 1,
 'ANA'
);

---

UPDATE

Altera registros.

UPDATE CLIENTES
SET CIDADE = 'SANTOS'
WHERE ID = 1;

---

DELETE

Remove registros.

DELETE
FROM CLIENTES
WHERE ID = 1;

---

O erro que assombra os DBAs

Esquecer o WHERE.

Exemplo perigoso:

UPDATE CLIENTES
SET STATUS = 'ATIVO';

Resultado:

Toda a tabela será atualizada.

É um dos acidentes mais famosos da história dos bancos de dados.

---

🎯 Objetivo 4: Implementar Consultas Simples em SQL

Agora o aluno começa a transformar dados em informação.

---

Filtrando registros

SELECT
    NOME
FROM CLIENTES
WHERE CIDADE = 'SANTOS';

---

Filtrando intervalos

SELECT
    NOME
FROM CLIENTES
WHERE SALARIO
BETWEEN 5000 AND 10000;

---

Utilizando listas

SELECT *
FROM CLIENTES
WHERE ESTADO IN
(
 'SP',
 'RJ',
 'MG'
);

---

Pesquisando padrões

SELECT *
FROM CLIENTES
WHERE NOME LIKE 'MAR%';

Retorna:

• MARIA

• MARCOS

• MARCELO

---

Ordenando resultados

SELECT
 NOME,
 SALARIO
FROM FUNCIONARIOS
ORDER BY SALARIO DESC;

---

🎯 Objetivo 5: Criar Suas Primeiras Consultas em SQL

Aqui nasce o verdadeiro analista de dados.

Não basta consultar.

É necessário responder perguntas do negócio.

---

Quantos clientes existem?

SELECT COUNT(*)
FROM CLIENTES;

---

Qual o maior salário?

SELECT MAX(SALARIO)
FROM FUNCIONARIOS;

---

Qual a média salarial?

SELECT AVG(SALARIO)
FROM FUNCIONARIOS;

---

Quantos clientes existem por cidade?

SELECT
    CIDADE,
    COUNT(*)
FROM CLIENTES
GROUP BY CIDADE;

Agora estamos produzindo inteligência.

Não apenas listando registros.

---

🚀 O Próximo Passo no DB2 13

Após dominar esses cinco objetivos, o profissional estará pronto para estudar temas mais avançados:

JOINs

SELECT
 C.NOME,
 P.NUMERO_PEDIDO
FROM CLIENTES C
INNER JOIN PEDIDOS P
ON C.ID = P.ID_CLIENTE;

---

Subqueries

SELECT *
FROM FUNCIONARIOS
WHERE SALARIO >
(
 SELECT AVG(SALARIO)
 FROM FUNCIONARIOS
);

---

Índices

CREATE INDEX IX_CLIENTE_NOME
ON CLIENTES
(
 NOME
);

---

EXPLAIN

Análise do plano de acesso.

Ferramenta essencial para DBAs e desenvolvedores DB2.

---

SQL Embedded em COBOL

EXEC SQL
   SELECT NOME
   INTO :WS-NOME
   FROM CLIENTES
   WHERE ID = :WS-ID
END-EXEC.

Aqui começa o verdadeiro universo Mainframe.

---

☕ Conclusão Bellacosa Mainframe

Os cinco objetivos apresentados na imagem parecem simples à primeira vista.

Mas eles representam a fundação de praticamente todo o ecossistema corporativo moderno.

Cada PIX processado.

Cada compra no cartão.

Cada transferência bancária.

Cada consulta de seguro.

Cada reserva aérea.

Em algum momento passa por um comando SQL.

No DB2 13, aprender SQL significa muito mais do que aprender uma linguagem. Significa compreender como os dados fluem dentro de alguns dos maiores sistemas do planeta.

O primeiro passo é escrever:

SELECT *
FROM CLIENTES;

O passo seguinte é entender por que essa consulta funciona.

O passo que diferencia um especialista é compreender por que ela pode ser lenta, como o DB2 a executa, quais índices utiliza e como transformá-la em uma consulta capaz de processar bilhões de registros com eficiência.

E é exatamente nesse momento que o estudante deixa de apenas aprender SQL e começa a pensar como um verdadeiro profissional de Mainframe. ☕🚀💾

Descubra como profissionais de Mainframe evoluem da programação em JCL, COBOL, SORT e CICS para o domínio do SQL no DB2 13 for z/OS. Entenda modelo relacional, consultas SQL, índices, joins, subqueries, EXPLAIN, access paths e técnicas de otimização utilizadas nos maiores ambientes corporativos do mundo.

 

Bellacosa Mainframe e o SQL no Mainframe muito alem do select

---

☕ SQL NO MAINFRAME: MUITO ALÉM DO SELECT

Como Dominar os Fundamentos de SQL no DB2 13 for z/OS

Quando alguém abre o SPUFI, Data Studio, DBeaver ou qualquer ferramenta SQL pela primeira vez, normalmente executa algo simples:

SELECT *
FROM CLIENTES;

A consulta retorna dados.

O usuário sorri.

Acredita que aprendeu SQL.

Mas na realidade acabou de dar apenas o primeiro passo de uma longa jornada.

No universo Mainframe, SQL é a língua falada entre:

• COBOL

• CICS

• IMS

• Java

• Web Services

• APIs REST

• z/OS Connect

• Analytics

• Inteligência Artificial

Todo sistema corporativo moderno passa por SQL em algum momento.

E o DB2 13 elevou ainda mais essa importância.

---

A HISTÓRIA QUE TODO PROFISSIONAL DE MAINFRAME DEVERIA CONHECER

Antes do SQL, bancos relacionais eram apenas uma teoria.

Em 1970, Edgar F. Codd publicou um artigo revolucionário na IBM:

A Relational Model of Data for Large Shared Data Banks

Esse trabalho mudou a computação.

A ideia era simples:

Ao invés de navegar registros fisicamente, os usuários deveriam dizer:

"Quero estes dados."

E o banco decidiria:

"Eu descubro a melhor forma de encontrá-los."

Nascia o conceito de SQL.

Décadas depois, essa filosofia continua viva dentro do DB2 13.

---

O QUE É SQL?

SQL significa:

Structured Query Language

Ou:

Linguagem Estruturada de Consulta

Ela permite:

• Consultar dados

• Inserir dados

• Alterar dados

• Excluir dados

• Criar estruturas

• Gerenciar segurança

Praticamente tudo que fazemos no DB2 passa por SQL.

---

OS QUATRO GRANDES GRUPOS DE COMANDOS SQL

DQL – Data Query Language

Consulta de dados.

Exemplo:

SELECT *
FROM FUNCIONARIOS;

---

DML – Data Manipulation Language

Manipulação de registros.

INSERT INTO FUNCIONARIOS
VALUES
(100,'CARLOS');

UPDATE FUNCIONARIOS
SET SALARIO = 5000
WHERE MATRICULA = 100;

DELETE
FROM FUNCIONARIOS
WHERE MATRICULA = 100;

---

DDL – Data Definition Language

Definição das estruturas.

CREATE TABLE CLIENTES
(
 ID INTEGER,
 NOME VARCHAR(50)
);

---

DCL – Data Control Language

Controle de segurança.

GRANT SELECT
ON CLIENTES
TO USER01;

---

A TABELA É O CORAÇÃO DO DB2

Imagine um arquivo VSAM KSDS.

Agora imagine esse conceito evoluído.

Uma tabela é composta por:

• Linhas

• Colunas

• Relacionamentos

• Índices

• Constraints

Exemplo:

ID	NOME	CIDADE
1	ANA	SÃO PAULO
2	JOÃO	SANTOS
3	MARIA	RIO

Essa simplicidade aparente esconde uma enorme complexidade de armazenamento.

---

SUA PRIMEIRA CONSULTA DE VERDADE

O erro mais comum é usar:

SELECT *
FROM CLIENTES;

Em produção isso costuma ser um desastre.

O profissional experiente utiliza:

SELECT
    ID,
    NOME,
    CIDADE
FROM CLIENTES;

Por quê?

Porque reduz:

• I/O

• CPU

• Network Traffic

• Uso de buffer pools

No DB2 13 isso continua sendo uma das melhores práticas.

---

APRENDENDO A FILTRAR DADOS

O poder real surge com o WHERE.

SELECT
    NOME
FROM CLIENTES
WHERE CIDADE = 'SANTOS';

Sem WHERE:

SCAN TOTAL

Com WHERE:

BUSCA DIRECIONADA

Diferença gigantesca.

Principalmente em tabelas com bilhões de linhas.

---

OPERADORES MAIS UTILIZADOS

Igualdade

WHERE ID = 100

Diferente

WHERE ID <> 100

Maior

WHERE SALARIO > 10000

Menor

WHERE SALARIO < 5000

Intervalo

WHERE SALARIO
BETWEEN 5000 AND 10000

Lista

WHERE CIDADE
IN ('SANTOS','CAMPINAS')

---

LIKE: A ARMA SECRETA DOS ANALISTAS

SELECT *
FROM CLIENTES
WHERE NOME LIKE 'MAR%';

Retorna:

• MARIA

• MARCOS

• MARCELO

Mas atenção.

LIKE mal utilizado pode destruir a performance.

Exemplo ruim:

LIKE '%MAR%'

O otimizador normalmente perde a possibilidade de usar índices eficientemente.

---

ORDER BY

Organizando resultados.

SELECT
NOME,
SALARIO
FROM FUNCIONARIOS
ORDER BY SALARIO DESC;

Maior salário primeiro.

Muito simples.

Muito poderoso.

Muito custoso quando mal utilizado.

---

DISTINCT

Eliminando duplicidades.

SELECT DISTINCT
CIDADE
FROM CLIENTES;

Resultado:

SANTOS
CAMPINAS
RIO

Sem repetições.

---

CONTANDO REGISTROS

Todo DBA utiliza:

SELECT COUNT(*)
FROM CLIENTES;

Mas poucos iniciantes sabem que em tabelas gigantes isso pode gerar leituras enormes.

Por isso estatísticas e catálogos do DB2 também são utilizados para estimativas.

---

FUNÇÕES DE AGREGAÇÃO

Soma

SELECT SUM(VALOR)
FROM VENDAS;

---

Média

SELECT AVG(SALARIO)
FROM FUNCIONARIOS;

---

Máximo

SELECT MAX(SALARIO)
FROM FUNCIONARIOS;

---

Mínimo

SELECT MIN(SALARIO)
FROM FUNCIONARIOS;

---

GROUP BY: ONDE O SQL COMEÇA A FICAR INTERESSANTE

Exemplo:

SELECT
CIDADE,
COUNT(*)
FROM CLIENTES
GROUP BY CIDADE;

Resultado:

Cidade	Quantidade
Santos	1200
São Paulo	5800
Campinas	900

Aqui começamos a transformar dados em informação.

---

HAVING

Filtrando grupos.

SELECT
CIDADE,
COUNT(*)
FROM CLIENTES
GROUP BY CIDADE
HAVING COUNT(*) > 1000;

Somente cidades relevantes aparecem.

---

JOINS: O SUPERPODER DO SQL

Aqui nasce o verdadeiro banco relacional.

Tabela CLIENTES:

ID	NOME
1	ANA

Tabela PEDIDOS:

PEDIDO	ID_CLIENTE
100	1

Consulta:

SELECT
C.NOME,
P.PEDIDO
FROM CLIENTES C
INNER JOIN PEDIDOS P
ON C.ID = P.ID_CLIENTE;

Resultado:

ANA 100

Magia?

Não.

Modelo relacional.

---

INNER JOIN

Retorna apenas correspondências.

INNER JOIN

É o JOIN mais utilizado do mundo.

---

LEFT JOIN

Mantém todos os registros da esquerda.

LEFT JOIN

Mesmo sem correspondência.

Muito usado em auditorias.

---

SUBSELECTS

Uma consulta dentro da outra.

SELECT *
FROM FUNCIONARIOS
WHERE SALARIO >
(
SELECT AVG(SALARIO)
FROM FUNCIONARIOS
);

Funcionários acima da média.

Excelente exemplo de lógica relacional.

---

SQL E COBOL: UMA DUPLA IMBATÍVEL

Em Mainframe o SQL raramente vive sozinho.

Exemplo Embedded SQL:

EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE ID = :WS-ID
END-EXEC.

Esse padrão movimenta bancos, seguradoras, governos e bolsas de valores há décadas.

---

O PAPEL DO BIND

Iniciantes aprendem SQL.

Profissionais Mainframe aprendem:

• Pré-compilação

• DBRM

• PACKAGE

• PLAN

• BIND

Sem isso o SQL não chega à produção.

---

O OTIMIZADOR: O CÉREBRO DO DB2

O usuário escreve:

SELECT *
FROM CLIENTES
WHERE ID = 100;

O DB2 pergunta:

• Uso índice?

• Faço scan?

• Quantas páginas?

• Quanto CPU?

Esse processo é chamado:

Access Path Selection

É aqui que a mágica acontece.

---

EXPLAIN: O RAIO-X DA CONSULTA

Nunca confie apenas porque uma consulta funciona.

Verifique o plano.

EXPLAIN PLAN FOR
SELECT *
FROM CLIENTES;

O DB2 mostrará:

• Índices usados

• Custo estimado

• Estratégias de acesso

DBAs vivem nessa análise.

---

O QUE MUDA NO DB2 13?

O DB2 13 trouxe avanços importantes:

Melhor exploração de estatísticas

O otimizador toma decisões mais inteligentes.

Melhor uso de CPU

Redução de consumo em workloads intensos.

Aprimoramentos em SQL Analytics

Funções analíticas mais eficientes.

Melhor integração híbrida

Conectividade moderna com APIs e aplicações distribuídas.

Evolução contínua do Machine Learning para otimização

Capacidade crescente de melhorar decisões de acesso com base em padrões observados.

---

ERROS CLÁSSICOS DOS INICIANTES

SELECT *

Evite.

---

Falta de índice

Performance despenca.

---

WHERE inadequado

Full table scan.

---

JOIN sem critério

Explosão de registros.

---

UPDATE sem WHERE

O terror dos DBAs.

UPDATE CLIENTES
SET STATUS='A';

Toda tabela alterada.

Acidente clássico.

---

O CAMINHO PARA VIRAR ESPECIALISTA

Etapa 1

Dominar SELECT.

---

Etapa 2

Dominar filtros.

---

Etapa 3

Dominar JOINs.

---

Etapa 4

Entender índices.

---

Etapa 5

Aprender EXPLAIN.

---

Etapa 6

Estudar catálogo DB2.

---

Etapa 7

Entender RUNSTATS.

---

Etapa 8

Compreender Access Paths.

---

Etapa 9

SQL embarcado em COBOL.

---

Etapa 10

Otimização avançada.

---

CONCLUSÃO: SQL É A NOVA LINGUAGEM UNIVERSAL DO MAINFRAME

Muitos profissionais acreditam que dominar COBOL é suficiente para trabalhar em Mainframe.

Não é.

O mercado moderno exige uma combinação poderosa:

• COBOL

• JCL

• CICS

• RACF

• DB2

• SQL

E dentro desse conjunto, SQL ocupa uma posição privilegiada.

Toda aplicação corporativa depende dele.

Toda API consulta dados através dele.

Toda IA corporativa precisa dele.

Todo analista precisa entendê-lo.

O segredo não é decorar comandos.

O segredo é compreender o que acontece por trás deles.

Quando você entende como o DB2 13 interpreta uma consulta, escolhe índices, calcula custos, acessa páginas e otimiza recursos, deixa de ser apenas alguém que escreve SQL.

Você passa a pensar como o próprio banco de dados.

E, no universo Bellacosa Mainframe, é exatamente aí que começa a verdadeira jornada: não em aprender comandos, mas em aprender a conversar com um dos sistemas mais sofisticados já construídos pela engenharia da computação.

☕🚀 Bem-vindo ao mundo do DB2 13. O primeiro SELECT é simples. O desafio real é transformar consultas em performance, conhecimento e valor para o negócio.