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

 

Aprenda COBOL com DB2 ao estilo Bellacosa Mainframe

🔥 Aprender COBOL com DB2 — o caminho do programador mainframer de verdade

---

🧠 Introdução: por que COBOL + DB2 ainda manda no jogo

Se você quer ser programador mainframe COBOL com DB2, precisa entender uma verdade simples:

COBOL processa.
DB2 guarda.
SQL conecta o cérebro à memória do negócio.

Não estamos falando de tecnologia “antiga”.
Estamos falando da infraestrutura que processa bilhões por dia, com ACID, consistência e auditoria que muita stack moderna ainda tenta copiar.

Esse artigo é um mapa de estrada, do zero até o código profissional, misturando:

• técnica

• história

• prática

• fofoca de data center

• e aquela sabedoria que só mainframer velho passa no café ☕

---

DB2 o banco de dados do Mainframe

🧱 PARTE 1 — Conhecendo o DB2 (o coração dos dados)

📜 Um pouco de história

O DB2 nasce na IBM nos anos 80, baseado no modelo relacional proposto por Edgar F. Codd.

👉 Conceito revolucionário:

• dados em tabelas

• relações lógicas

• SQL como linguagem declarativa

Enquanto o mundo brigava com arquivos VSAM:

“Me diga o que você quer, não como buscar.”

---

🧩 Modelo Relacional (base de tudo)

• Tabela → entidade de negócio

• Linha (row) → registro

• Coluna (column) → atributo

• Primary Key → identidade

• Foreign Key → relacionamento

💬 Bellacosa comenta:

“Se você não entende modelo relacional, não adianta saber COBOL.”

---

🧾 Tipos de Dados DB2 (o casamento com COBOL)

DB2	COBOL
CHAR / VARCHAR	PIC X
INTEGER	PIC S9
DECIMAL	PIC S9V
DATE	PIC X(10)
TIMESTAMP	PIC X(26)

🥚 Easter egg:
DB2 guarda DECIMAL melhor do que muito banco moderno guarda FLOAT 😏

---

Queries SQL no DB2 

🧑‍💻 PARTE 2 — Linguagem SQL no DB2

🗣️ SQL: a língua franca dos dados

SQL não é procedural.
SQL é declarativa.

🔹 DDL — Data Definition Language

CREATE TABLE CLIENTE (
  ID_CLIENTE INTEGER NOT NULL,
  NOME       VARCHAR(50),
  SALDO      DECIMAL(9,2),
  PRIMARY KEY (ID_CLIENTE)
);

• CREATE

• DROP

• ALTER

---

🔹 DCL — Data Control Language

GRANT SELECT ON CLIENTE TO USER01;

Controle de acesso.
Segurança raiz de banco.

---

🔹 DML — Data Manipulation Language

INSERT INTO CLIENTE VALUES (1, 'JOÃO', 1500.00);

SELECT * FROM CLIENTE;

UPDATE CLIENTE
SET SALDO = SALDO + 100
WHERE ID_CLIENTE = 1;

DELETE FROM CLIENTE
WHERE ID_CLIENTE = 1;

💬 Bellacosa:

“DELETE sem WHERE é como RM -RF /”

---

🔍 SELECT, JOIN e afins (onde o bicho pega)

SELECT C.NOME, P.VALOR
FROM CLIENTE C
JOIN PEDIDO P
  ON C.ID_CLIENTE = P.ID_CLIENTE;

👉 JOIN mal feito = batch lento = gente te ligando às 3 da manhã.

---

🛠️ SPUFI e QMF

• SPUFI → SQL direto no TSO

• QMF → consultas, relatórios, análise

💡 Dica Bellacosa:

“Todo mundo começa no SPUFI.
Quem fica bom, aprende QMF.”

---

🧩 PARTE 3 — COBOL com DB2 (onde nasce o profissional)

🏛️ História rápida do COBOL

• Criado em 1959

• Foco: negócio

• Legibilidade

• Estabilidade

👉 Não é bonito.
👉 É confiável.

---

🧠 Estrutura de um programa COBOL

• IDENTIFICATION DIVISION

• ENVIRONMENT DIVISION

• DATA DIVISION

• PROCEDURE DIVISION

📌 Árvore programática é fundamental para não virar macarrão lógico.

---

🔗 Host Variables (a ponte COBOL ↔ DB2)

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CLIENTE
    WHERE ID_CLIENTE = :WS-ID
END-EXEC.

• Sempre com :

• Tipagem correta

• Conversão consciente

---

📊 SQLCA — seu melhor amigo

IF SQLCODE = 0
   CONTINUE
ELSE
   DISPLAY 'ERRO DB2 ' SQLCODE
END-IF

SQLCODE	Significado
0	OK
+100	NOT FOUND
< 0	ERRO

💬 Bellacosa:

“Quem ignora SQLCODE vira operador sem saber.”

---

📚 DCLGEN — o BOOK sagrado

• Gera layout da tabela

• Gera host variables

• Evita erro humano

//STEP01 EXEC PGM=DSNTEP2

👉 Nunca escreva layout DB2 na mão. Nunca.

---

Consulta pagina via cursor no DB2

🌀 PARTE 4 — Cursores (nível profissional)

🔄 Cursor para leitura

EXEC SQL
   DECLARE C1 CURSOR FOR
   SELECT ID_CLIENTE, NOME
     FROM CLIENTE
END-EXEC.

EXEC SQL
   FETCH C1 INTO :WS-ID, :WS-NOME
END-EXEC.

📌 Sempre:

• OPEN

• FETCH

• CLOSE

---

✍️ Inserindo, alterando e excluindo via COBOL

• INSERT → novo registro

• UPDATE → alteração controlada

• DELETE → cuidado máximo

💡 Boa prática:

“Nunca DELETE direto sem histórico.”

---

🧠 PARTE 5 — Boas práticas Bellacosa Mainframe

✔ Use DCLGEN
✔ Sempre trate SQLCODE
✔ Evite SELECT *
✔ Documente regra de negócio
✔ Separe lógica de acesso a dados
✔ Teste com volume real
✔ Pense em performance desde o SELECT

🥚 Easter egg clássico:

“O batch estava lento porque alguém esqueceu o índice.”

---

🧪 Exercícios de fixação (mentalidade correta)

1. Criar tabela DB2

2. Gerar DCLGEN

3. Programa COBOL com:

   • INSERT

   • SELECT

   • UPDATE

   • DELETE

4. Programa com CURSOR

5. Programa com JOIN

6. Analisar SQLCODE

7. Ajustar performance

👉 Isso forma programador, não copiador de código.

---

🧠 Comentário final Bellacosa

Aprender COBOL com DB2 não é aprender uma linguagem.
É aprender:

• como dados movem o mundo

• como sistemas críticos pensam

• como escrever código que não pode falhar

🔥 COBOL + DB2 não é passado.
É o núcleo silencioso do presente.

Enquanto modas passam,
o batch fecha o dia.

 

 

Bellacosa Mainframe apresenta IBM Mainframe DB2 Inner Join

🔷 INNER JOIN no IBM DB2 Mainframe – A Arte de Relacionar Tabelas

Se você trabalha com IBM Mainframe, provavelmente já precisou combinar dados de diferentes tabelas. E para isso existe o INNER JOIN, que é o clássico entre os joins em SQL.

Mas antes de entrar nos detalhes, vamos à história…

---

🕰️ História e Origem

O conceito de INNER JOIN vem diretamente do Modelo Relacional de Codd (1970), criado dentro da IBM.

• Edgar F. Codd, um cientista da IBM, imaginou que dados deveriam ser armazenados em tabelas relacionais e manipulados por álgebra relacional.

• Ele não inventou “INNER JOIN” como conhecemos hoje, mas a ideia de combinar tabelas via chaves comuns nasceu com ele.

• SQL evoluiu nos anos 80 para suportar explicitamente joins:

  • Sintaxe implícita: FROM A, B WHERE A.key = B.key

  • Sintaxe explícita: FROM A INNER JOIN B ON A.key = B.key

No DB2 para Mainframe, o INNER JOIN é altamente otimizado para lidar com milhões de linhas em transações batch ou OLTP, mantendo a performance crítica.

---

⚙️ O que é INNER JOIN?

INNER JOIN é a operação que retorna somente as linhas onde existe correspondência em ambas as tabelas, baseado em uma chave comum.

🔹 Sintaxe padrão DB2

-- Explicit INNER JOIN (recomendado)
SELECT E.EmployeeID, E.LastName, O.OrderID
FROM Employees E
INNER JOIN Orders O
  ON E.EmployeeID = O.EmployeeID;

-- Implicit INNER JOIN (estilo antigo)
SELECT E.EmployeeID, E.LastName, O.OrderID
FROM Employees E, Orders O
WHERE E.EmployeeID = O.EmployeeID;

🔹 Observações

• Chave comum: não precisa ter o mesmo nome, apenas valores compatíveis.

• Sem correspondência → linha é descartada.

• Pode usar múltiplas tabelas → INNER JOIN é associativo.

---

💡 Dicas Bellacosa para Mainframe

1. Prefira joins explícitos (INNER JOIN ON) em DB2 → facilita leitura e manutenção.

2. Sempre qualifique colunas se houver nomes repetidos → evita ambiguidade (E.EmployeeID, O.EmployeeID).

3. Use aliases curtos → economiza digitação e deixa o código limpo.

4. Evite cartesian products sem intenção → FROM A, B sem WHERE é um Product, que explode linhas.

5. Verifique estatísticas de tabela → DB2 otimiza join usando índices.

---

🔍 Curiosidades & Easter Eggs

• No DB2, todas as joins são INNER por padrão se você não usar OUTER.

• Internamente, o otimizador transforma INNER JOIN em operações de álgebra relacional: Product + Selection.

• Usar JOIN explícito ajuda o Explain Plan a gerar caminhos de acesso mais eficientes.

• Combinar índices corretos + INNER JOIN = batch mais rápido, menos I/O.

---

🧪 Exemplo prático

Imagine que temos duas tabelas no z/OS DB2:

EMPLOYEES

EmployeeID	LastName	DeptID
101	Smith	10
102	Jones	20

DEPARTMENTS

DeptID	DeptName
10	Accounting
20	HR
30	IT

Query: INNER JOIN

SELECT E.LastName, D.DeptName
FROM Employees E
INNER JOIN Departments D
  ON E.DeptID = D.DeptID;

Resultado:

LastName	DeptName
Smith	Accounting
Jones	HR

Observe: DeptID = 30 não aparece porque não há funcionário correspondente.

---

📈 Uso e Razão de Uso

• Combinar tabelas relacionadas → RELACIONAL puro

• Resumir informações em relatórios ou dashboards OLAP

• Criar answer sets consistentes para análises

• Fundamental para consultas em ERP, finanças e logística

No mainframe, INNER JOIN é usado em:

• Batch → processa milhões de registros rapidamente

• Online Transaction Processing (OLTP) → respostas rápidas e consistentes

---

⚡ Impacto na Performance e Otimização

1. Indexes importam muito:

   • JOIN em colunas indexadas = leitura rápida, menos I/O

   • Sem índice → DB2 faz table scan → lento em tabelas grandes

2. Estatísticas DB2:

   • RUNSTATS ajuda o otimizador a escolher o caminho ideal

3. Número de tabelas no JOIN:

   • Mais joins = mais complexidade e consumo de CPU

   • Prefira joins em cascata controlados, evite joins desnecessários

4. Filtros antes do JOIN:

   • Use WHERE/qualificação para reduzir linhas antes do INNER JOIN

   • Isso diminui o volume de dados processados e acelera o batch

---

🔑 Comentários finais Bellacosa

• INNER JOIN é a base do SQL relacional, especialmente no DB2 do mainframe.

• Sintaxe explícita + colunas qualificadas + índices corretos = performance top de linha.

• Mesmo em 2026, ele é indispensável em sistemas críticos da IBM.

• Dica bônus: use EXPLAIN PLAN para ver como DB2 executa seus INNER JOINs.

💡 Easter Egg:

Por baixo do capô, o DB2 transforma cada INNER JOIN em Product + Selection + Projection na álgebra relacional — a magia acontece silenciosa enquanto você apenas digita INNER JOIN.