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 explorando o DB2

💥 DB2 A REGRA QUE MUDA TUDO

👉 O otimizador NÃO “ama índice”
👉 Ele escolhe o menor custo estimado

💡 Tradução Bellacosa:

Índice ruim pode ser pior que scan completo 😱

---

🧠 1. TABLESPACE SCAN vs INDEX SCAN

⚡ INDEX SCAN (ACCESSTYPE = 'I')

✔ Busca direta
✔ Poucas linhas retornadas
✔ Usa chave/index

👉 Ideal para:

WHERE ID = 100

---

🐢 TABLESPACE SCAN (ACCESSTYPE = 'R')

✔ Varre tudo
✔ Melhor quando retorna MUITAS linhas

👉 Ideal para:

SELECT * FROM CLIENTES

---

💣 CENÁRIO REAL 1 — “ÍNDICE IGNORADO”

🧪 Query

SELECT * 
FROM CLIENTES
WHERE CIDADE = 'SAO PAULO';

👉 Você criou índice em CIDADE… mas Db2 usa SCAN 😬

---

🧠 Por quê?

👉 Baixa seletividade

Se:

• 80% da tabela = “SAO PAULO”

Então:

Índice não compensa

---

🛠️ Solução

✔ Criar índice composto:

CREATE INDEX IDX1 
ON CLIENTES (CIDADE, ID);

✔ Ou melhorar filtro

---

💣 CENÁRIO REAL 2 — “MATCHCOLS BAIXO”

🧪 Índice:

CREATE INDEX IDX2 
ON CLIENTES (CIDADE, NOME);

🧪 Query:

SELECT * FROM CLIENTES
WHERE NOME = 'ANA';

---

😬 Resultado

👉 MATCHCOLS = 0

---

🧠 Por quê?

👉 Ordem do índice importa!

---

🛠️ Correção

✔ Criar índice correto:

CREATE INDEX IDX3 
ON CLIENTES (NOME);

---

💣 CENÁRIO REAL 3 — “SELECT * MATA PERFORMANCE”

🧪 Query

SELECT * FROM CLIENTES
WHERE ID = 10;

---

🧠 Problema

Mesmo com índice:

👉 Pode forçar acesso à tabela (data page)

---

🛠️ Otimização (Index Only Access)

SELECT ID FROM CLIENTES
WHERE ID = 10;

✔ Usa só o índice
✔ Muito mais rápido

---

💣 CENÁRIO REAL 4 — “RUNSTATS TE TRAIU”

🧪 Situação

• Índice existe
• Query boa
• Mesmo assim: SCAN 😡

---

🧠 Causa

👉 Estatísticas desatualizadas

---

🛠️ Solução

RUNSTATS TABLESPACE DB1.TS1;

💡 Sem isso:

Otimizador “chuta”

---

🚀 CENÁRIO REAL 5 — “RANGE SCAN”

🧪 Query

SELECT * FROM CLIENTES
WHERE ID BETWEEN 1 AND 100;

---

🧠 Possível acesso

✔ Index range scan
✔ Ou scan completo (depende do volume)

---

🧠 DECISÃO DO OTIMIZADOR

Ele avalia:

• Cardinalidade
• Seletividade
• Cluster ratio
• Número de páginas
• Estatísticas (RUNSTATS)

---

💥 GOLDEN RULES (nível expert)

🥇 1. Índice ≠ sempre melhor

🥇 2. Ordem do índice é tudo

🥇 3. RUNSTATS é obrigatório

🥇 4. SELECT * é inimigo

🥇 5. WHERE define performance

---

🔥 CHECKLIST DE GUERRA

Antes de subir:

✔ EXPLAIN rodado
✔ ACCESSTYPE correto
✔ MATCHCOLS adequado
✔ Índice alinhado ao WHERE
✔ RUNSTATS atualizado

---

😎 FRASES DE ARQUITETO

• “Isso tá com baixa seletividade”
• “Esse índice não casa com o predicado”
• “O access path tá custando caro”
• “Isso aí vai virar tablespace scan em produção”

---

Uma revisão das regras do Db2

💣 VISÃO FINAL (MENTALIDADE)

👉 Você não escreve SQL…
👉 Você negocia com o otimizador

 

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.”

💥 Db2 13 – Introduction (Guia Completo)

 

Bellacosa Mainframe apresenta Db2 13

💥 Db2 13 – Introduction (Guia Completo)

O IBM Db2 13 for z/OS não é só uma evolução… é praticamente um “upgrade de mentalidade” no mundo mainframe. Ele traz automação, performance absurda e inteligência embutida — e é exatamente isso que costuma cair nesse tipo de teste.

Vou te dar o mapa mental + respostas comentadas no estilo prova 👇

---

🧠 1. O que é o Db2 13?

👉 Resposta esperada:
Um sistema gerenciador de banco de dados relacional (RDBMS) para z/OS.

💡 Na prática:

• Armazena dados de forma estruturada (tabelas)
• Usa SQL como linguagem padrão
• Integra profundamente com CICS, batch, IMS

---

⚙️ 2. Principais melhorias do Db2 13

👉 Fique esperto — isso cai MUITO:

🔥 Destaques:

• AI-powered optimization (auto tuning)
• Melhor uso de CPU (redução de MIPS 💰)
• Maior throughput (mais transações por segundo)
• Melhor compressão de dados
• Processamento contínuo (menos downtime)

👉 Resposta típica:

Improved performance, scalability, and AI-driven optimization.

---

🧩 3. Continuous Delivery (CD)

👉 Conceito chave!

👉 Resposta:
Modelo de entrega contínua de funcionalidades sem precisar fazer upgrade completo.

💡 Tradução Bellacosa:

Você não precisa mais “parar o avião pra trocar o motor”.

---

📊 4. Tipos de objetos no Db2

👉 Isso aparece em matching / drag-and-drop:

• TABLE → armazena dados
• VIEW → visão lógica
• INDEX → melhora performance
• TABLESPACE → armazenamento físico
• SCHEMA → organização lógica

👉 Dica de prova:
Se falou “logical representation” → é VIEW

---

⚡ 5. SQL no Db2

👉 Clássico:

• DDL → CREATE, ALTER, DROP
• DML → INSERT, UPDATE, DELETE
• DCL → GRANT, REVOKE

👉 Pergunta comum:

CREATE é usado para quê?

✔️ Criar objetos

---

🔐 6. Segurança

👉 Db2 trabalha junto com o RACF

• Controle de acesso
• Autorização por usuário
• Proteção de dados sensíveis

---

🚀 7. Performance

👉 O Db2 13 brilha aqui:

• Buffer pools otimizados
• Melhor uso de memória
• Menos CPU por transação

👉 Resposta típica:

Improved efficiency and reduced resource consumption.

---

🧪 8. Perguntas clássicas de prova (com resposta)

❓ Db2 é:

✔️ Um RDBMS

---

❓ SQL é usado para:

✔️ Manipular e definir dados

---

❓ Continuous Delivery significa:

✔️ Entrega contínua de funcionalidades sem upgrade tradicional

---

❓ INDEX serve para:

✔️ Melhorar performance de acesso

---

❓ VIEW é:

✔️ Uma tabela lógica baseada em SELECT

---

❓ CREATE é:

✔️ Comando DDL

---

💣 Dica de OURO (nível sênior)

Se cair pergunta conceitual mais “maldosa”, pensa assim:

👉 Db2 13 =
Menos custo + mais performance + mais automação + menos intervenção humana

---

🧠 Mentalidade que passa na prova

Não decore só comando — entenda o porquê:

• Db2 não é só banco → é motor transacional do core banking
• Performance = dinheiro
• CPU = custo direto
• Índice mal feito = desastre silencioso

 

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.