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 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 evoluindo skills em db2 

☕🔥 SQL QUERYING SKILL NO DB2 MAINFRAME — O FAROL QUE SEPARA “QUEM ESCREVE SQL” DE QUEM DOMINA O SISTEMA

Existe uma enorme diferença entre:

SELECT * FROM CLIENTE;

e realmente entender:

🔥 como o DB2 pensa.

E essa diferença muda completamente:

• performance

• custo

• CPU

• locking

• concorrência

• disponibilidade

• tempo de resposta

Porque no universo IBM Mainframe…

SQL não é apenas linguagem.

🔥 SQL é engenharia operacional.

E a imagem do “farol SQL” mostra isso perfeitamente.

Ela representa uma jornada:

• iniciante

• intermediário

• avançado

que no mundo DB2 for z/OS pode literalmente separar:

• sistemas estáveis
  de

• ambientes entrando em colapso silenciosamente.

---

☕🔥 O FAROL É UMA ANALOGIA PERFEITA PARA O DB2

Pouca gente percebe isso.

Mas DB2 em Mainframe funciona exatamente como um grande sistema de navegação corporativa.

---

☕ O DB2 precisa guiar:

• milhões de queries

• milhares de transações

• workloads concorrentes

• aplicações CICS

• batch COBOL

• APIs

• analytics

sem falhar.

---

☕ Bellacosa Mainframe Analysis™

O SQL Developer não escreve apenas consultas.

🔥 Ele influencia diretamente a saúde do ambiente z/OS inteiro.

---

☕🔥 NÍVEL BEGINNER — “APRENDENDO A FALAR COM O DB2”

Aqui nasce a maioria dos desenvolvedores.

---

☕ Conceitos básicos:

• SELECT

• INSERT

• UPDATE

• DELETE

• GROUP BY

• ORDER BY

• JOINs

---

☕ Parece simples…

mas já existem armadilhas perigosas.

---

☕ Exemplo clássico

SELECT *
FROM CLIENTES

---

☕ Em tabela pequena?

Ok.

---

☕ Em tabela DB2 corporativa com bilhões de linhas?

🔥 desastre potencial.

---

☕ O MAINFRAME ENSINA UMA LIÇÃO BRUTAL

Toda query custa recursos.

---

☕ Recursos significam:

• CPU

• I/O

• bufferpool

• locks

• sort

• memória

---

☕🔥 QUERY WRITING — O “COBOL MENTAL” DO SQL

Aqui começa a maturidade.

---

☕ Bons desenvolvedores aprendem:

✅ evitar SELECT *
✅ filtrar corretamente
✅ usar índices
✅ reduzir scans
✅ controlar joins

---

☕ Porque DB2 NÃO “adivinha intenção”.

Ele segue:
🔥 access paths.

---

☕🔥 DATA UNDERSTANDING — O SEGREDO QUE MUITA GENTE IGNORA

Essa talvez seja a parte mais importante da imagem.

---

☕ O problema raramente é apenas SQL.

Frequentemente é:

🔥 modelo de dados ruim.

---

☕ Exemplo clássico

Campos:

CHAR(500)

para dados minúsculos.

---

☕ Resultado?

• desperdício

• I/O maior

• cache pior

• performance degradada

---

☕ Bellacosa Mainframe Analysis™

Modelagem ruim no DB2 vira:
🔥 dívida técnica por décadas.

---

☕🔥 INTERMEDIATE — QUANDO O SQL COMEÇA A VIRAR ENGENHARIA

Agora entramos no território dos profissionais perigosos.

---

☕ Execution Model

Pouca gente entende o pipeline interno do DB2.

---

☕ Uma query passa por:

PARSING
 ↓
OTIMIZAÇÃO
 ↓
ACCESS PATH
 ↓
EXECUÇÃO

---

☕ O otimizador DB2 é extremamente sofisticado.

---

☕ Mas depende de:

• estatísticas

• índices

• cardinalidade

• distribuição de dados

---

☕🔥 RUNSTATS — O “ALIMENTO” DO OTIMIZADOR

Sem estatísticas boas:

🔥 o optimizer fica “cego”.

---

☕ Resultado?

• table scans gigantes

• CPU absurda

• planos ruins

---

☕ Isso derruba produção REAL.

---

☕🔥 SYNCHRONISATION — O “TRÂNSITO” DAS TRANSAÇÕES

Agora entramos numa das áreas mais críticas do DB2.

---

☕ Concorrência.

---

☕ Milhares de usuários acessando simultaneamente.

---

☕ Problemas clássicos:

• deadlocks

• lock escalation

• timeout

• contenção

---

☕ Bellacosa Mainframe Analysis™

DB2 é praticamente:
🔥 controle aéreo de transações financeiras.

---

☕ Tudo precisa coexistir sem colisão.

---

☕🔥 LOCKING — O “RACF” DOS DADOS

O DB2 protege integridade via locking.

---

☕ Exemplo:

UPDATE CONTA
SET SALDO = SALDO - 100

---

☕ Enquanto isso outro processo pode tentar alterar a mesma linha.

---

☕ Sem controle?

🔥 corrupção de dados.

---

☕ O DB2 leva ACID MUITO a sério.

---

☕🔥 VIEWS, CTEs E STORED PROCEDURES — O “ABSTRACTION LAYER”

Agora chegamos no SQL mais sofisticado.

---

☕ Views

Abstração lógica.

---

☕ CTEs

Queries organizadas e reutilizáveis.

---

☕ Stored Procedures

Lógica próxima do banco.

---

☕ Isso reduz:

• tráfego

• latência

• complexidade

---

☕ Mainframe sempre valorizou:

🔥 processamento perto dos dados.

---

☕🔥 ADVANCED — O NÍVEL “DB2 WHISPERER”

Agora entramos na elite.

---

☕ Aqui o profissional entende:

• EXPLAIN PLAN

• access path

• index strategy

• partitioning

• concurrency

• internals

---

☕ Ele para de perguntar:

“a query funciona?”

e começa perguntar:

“quanto ela custa?”

---

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

Ferramenta obrigatória.

---

☕ Ela mostra:

• scans

• joins

• sorts

• index usage

• estimated cost

---

☕ Bellacosa Mainframe Analysis™

EXPLAIN é como:
🔥 um IPCS da query.

---

☕🔥 INDEXING — A ARTE QUE SALVA OU DESTRÓI PERFORMANCE

Índice é maravilhoso…

até virar excesso.

---

☕ Muitos índices causam:

• INSERT lento

• UPDATE pesado

• manutenção absurda

---

☕ Poucos índices causam:

🔥 scans infernais.

---

☕ O segredo é equilíbrio.

---

☕🔥 CONCURRENCY ISSUES — O “INFERNO INVISÍVEL”

Sistemas não caem apenas por CPU.

---

☕ Muitas vezes o problema é:

🔥 contenção.

---

☕ Exemplo:

10 mil usuários esperando lock.

---

☕ O ambiente parece “lento”…

mas na verdade está:

• bloqueado

• serializado

• congestionado

---

☕🔥 MODEL & SYSTEM THINKING — O NÍVEL ARQUITETO

Aqui mora o verdadeiro especialista.

---

☕ Ele entende:

talvez o problema não seja SQL.

---

☕ Talvez seja:

• arquitetura

• modelagem

• distribuição

• workflow

• volume

• design transacional

---

☕ Isso é MUITO Bellacosa Mainframe.

Porque Mainframe sempre pensou:
🔥 sistema inteiro.

---

☕🔥 O DB2 NÃO É “SÓ BANCO”

Ele é:

• plataforma transacional

• motor financeiro

• sistema crítico

• infraestrutura operacional

---

☕ Grandes bancos dependem disso diariamente.

---

☕ PIX.

☕ Cartão.
☕ Bolsa.
☕ Seguros.
☕ Governo.

Tudo passa por bancos de dados extremamente sofisticados.

---

☕🔥 O MAIOR ERRO DOS DESENVOLVEDORES MODERNOS

Achar que:

hardware resolve tudo

---

☕ Mainframe ensina exatamente o contrário.

---

☕ Eficiência importa.

Muito.

---

☕ Porque escala real é brutal.

---

☕🔥 CONCLUSÃO — SQL NÃO É SOBRE CONSULTAS… É SOBRE ENTENDER O COMPORTAMENTO DO SISTEMA

Qualquer pessoa aprende SELECT.

Mas poucos realmente entendem:

• optimizer

• locking

• access path

• cardinalidade

• modelagem

• concorrência

• custo operacional

E talvez essa seja a maior verdade do DB2 for z/OS:

o melhor programador SQL não é o que escreve queries mais “bonitas”.

🔥 É o que consegue fazer bilhões de transações coexistirem sem o sistema sentir dor.