☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta banco de dados. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta banco de dados. Mostrar todas as mensagens

quinta-feira, 25 de junho de 2026

Hybrid Search no Db2: Quando SQL Encontra Inteligência Artificial (e o Banco de Dados Aprende a Entender Pessoas)

 

Bellacosa Mainframe e o hybrid search no db2

☕ Um Café no Bellacosa Mainframe

Hybrid Search no Db2: Quando SQL Encontra Inteligência Artificial (e o Banco de Dados Aprende a Entender Pessoas)

Como o Db2 12.1.5 transformou o banco relacional em uma plataforma de IA para busca semântica, RAG e aplicações inteligentes.

"Durante décadas perguntávamos ao banco de dados 'onde está este registro?'. Agora começamos a perguntar 'o que você sabe sobre este assunto?'. Essa pequena mudança muda absolutamente tudo."


Introdução

Se você programa em COBOL, trabalha com Db2, escreve SQL diariamente ou administra ambientes IBM, talvez tenha ouvido alguém dizer recentemente:

"O Db2 agora suporta Hybrid Search."

E a primeira reação costuma ser:

"Legal... mas o que exatamente isso significa?"

Se você pensou isso, prepare seu café.

Porque essa novidade representa uma das maiores mudanças conceituais do Db2 desde a chegada do suporte nativo a JSON, XML e às tecnologias modernas de integração.

Não estamos falando de mais um índice.

Nem de um novo tipo de tabela.

Estamos falando de ensinar um banco de dados a procurar significados, e não apenas palavras.


Uma pequena viagem no tempo

Durante praticamente cinquenta anos, bancos de dados responderam perguntas muito simples.

Você perguntava:

SELECT *
FROM CLIENTES
WHERE CPF='12345678900';

O banco respondia imediatamente.

Perfeito.

Depois surgiram buscas textuais.

Por exemplo:

SQLCODE -904

ou

CICS RESP 16

O banco localizava exatamente aquelas palavras.

Ainda perfeito.

Mas então chegou a IA.

E os usuários começaram a perguntar coisas como:

"Por que meu batch fica preso durante a madrugada?"

Ou:

"Existe algum programa parecido com este COBOL?"

Ou ainda:

"Onde existe documentação sobre autenticação?"

Nenhuma dessas perguntas possui uma resposta baseada apenas em igualdade de caracteres.

É aí que nasce a busca vetorial.


O problema da busca tradicional

Imagine uma documentação contendo:

Resource unavailable

Deadlock

Timeout

IRLM contention

Agora imagine que alguém pesquisa:

Meu programa trava esperando recursos.

Nenhuma palavra coincide.

Resultado?

0 documentos encontrados

Mas qualquer analista experiente sabe que provavelmente o problema é exatamente um deadlock ou contenção.

O computador não sabia.

A IA sabe.


Keyword Search

Na figura apresentada pelo autor vemos dois blocos.

O primeiro é:

Keyword Search

Essa é a busca clássica.

Ela utiliza motores especializados como:

  • OpenSearch

  • Elasticsearch

Esses motores trabalham com índices invertidos.

Em vez de procurar documento por documento, eles mantêm enormes catálogos de palavras.

Por exemplo:

SQLCODE

↓

Documento 14

Documento 39

Documento 122

ou

COBOL

↓

Documento 2

Documento 98

Documento 430

É extremamente rápido.

E extremamente preciso.


Onde ela é excelente?

Quando você procura:

  • CPF

  • CNPJ

  • Número de pedido

  • Código do produto

  • SQLCODE

  • Nome de programa

  • VSAM KSDS

  • DSNUTILB

  • IKJEFT01

Ela é praticamente imbatível.


Mas existe um limite...

Ela não entende contexto.

Para ela,

erro de conexão

é completamente diferente de

falha de comunicação

Mesmo que um ser humano saiba que são praticamente a mesma coisa.


A revolução dos Embeddings

Agora chegamos ao conceito mais importante.

Quando falamos em IA Generativa existe uma palavra que aparece o tempo inteiro:

Embedding.


Imagine duas frases.

Cliente perdeu acesso.

e

Usuário não consegue entrar.

São palavras diferentes.

Mas possuem praticamente o mesmo significado.

Como um computador entende isso?

Transformando texto em matemática.

Cada documento vira um enorme vetor.

Algo parecido com:

[0.27,
0.81,
-0.19,
...
768 números]

Ou até

1536 dimensões

dependendo do modelo utilizado.

Esses números representam o significado do texto.


Curiosidade

Quando falamos "vetor", muita gente imagina apenas três dimensões.

Como:

X

Y

Z

Na IA isso não existe.

Os vetores normalmente possuem:

  • 384 dimensões

  • 768 dimensões

  • 1024 dimensões

  • 1536 dimensões

  • 3072 dimensões

Cada dimensão captura alguma característica semântica aprendida pelo modelo.

Nenhum ser humano consegue visualizar isso.

Mas algoritmos conseguem calcular a distância entre dois vetores em microssegundos.


Db2 12.1.2: o primeiro passo

A IBM deu um passo importante com o Db2 12.1.2, quando introduziu armazenamento nativo de vetores (Vector Data Type) e busca por similaridade.

Isso permitiu guardar embeddings diretamente nas tabelas do Db2 e realizar consultas de vizinhos mais próximos (Nearest Neighbor Search), sem depender obrigatoriamente de um banco vetorial dedicado.

Na prática, o Db2 passou a ser capaz de responder perguntas como:

"Quais documentos possuem significado semelhante a este?"

Era metade do caminho para aplicações de IA.


Db2 12.1.5: nasce o Hybrid Search

A verdadeira virada acontece com o Db2 12.1.5, disponibilizado pela IBM em 2025, quando foi anunciada a integração entre o mecanismo vetorial do Db2 e motores de busca como OpenSearch e Elasticsearch.

Agora temos duas pesquisas acontecendo simultaneamente:

Keyword Search
Vector Search

E ambas convergem para um único ranking.

Esse conceito recebe o nome de:

Hybrid Search.


Unified Ranking

Talvez este seja o recurso mais inteligente de toda a arquitetura.

Imagine uma pergunta:

Como resolver SQLCODE -904?

A busca por palavras encontra:

SQLCODE -904

Já a busca vetorial localiza documentos que mencionam:

  • Resource unavailable

  • Tablespace offline

  • Dataset indisponível

  • Problemas de I/O

  • Lock de recurso

Mesmo sem citar literalmente o código.

Agora imagine que os resultados sejam combinados.

Em vez de duas listas diferentes, temos apenas uma:

1 Documento A

2 Documento B

3 Documento C

4 Documento D

Todos classificados pela relevância.

É isso que o Unified Ranking faz.


Como essa arquitetura funciona?

                 Pergunta

                     │

                     ▼

      "Como resolver timeout?"

                     │

      ┌──────────────┴──────────────┐

      ▼                             ▼

Keyword Search               Vector Search

(OpenSearch)                 (Db2 Native)

      ▼                             ▼

         Unified Ranking

                 ▼

      Documentos Relevantes

                 ▼

         Large Language Model

                 ▼

          Resposta Final

Perceba algo interessante.

O LLM não pesquisa diretamente.

Quem faz a pesquisa continua sendo o banco.

A IA apenas utiliza os documentos encontrados.

Esse é exatamente o princípio do RAG (Retrieval-Augmented Generation).


E onde entra o SQL?

A primeira coisa que muitos desenvolvedores COBOL perguntam é:

"Vou parar de usar SQL?"

A resposta é:

Não.

Na verdade, você usará ainda mais SQL.

O que muda é que agora existirão novas funções relacionadas a vetores, similaridade e integração com índices textuais.

O SQL continua sendo o coração da solução.


Exemplo prático para quem trabalha com COBOL

Imagine um repositório com:

  • 18.000 programas COBOL

  • 12.000 Copybooks

  • 4.000 Jobs JCL

  • 8.000 documentos técnicos

  • 30 anos de documentação

Um programador novo pergunta:

"Existe alguma rotina semelhante ao cálculo de juros compostos?"

Nenhum programa chama exatamente:

JUROS_COMPOSTOS

Mas diversos possuem comentários como:

Interest calculation

Financial accrual

Capitalization

A busca vetorial encontra todos eles.

A busca lexical encontra aqueles que realmente possuem a palavra "juros".

O Hybrid Search combina tudo.


Outro exemplo

Imagine pesquisar:

Problemas de autenticação RACF

Keyword encontra:

RACF

Vector encontra:

Security

Authorization

Login

Access denied

SAF

ACEE

Muito mais inteligente.


Por que OpenSearch?

Muita gente pergunta:

"Se o Db2 já possui vetor, por que usar OpenSearch?"

Porque são especialidades diferentes.

O OpenSearch continua sendo excelente para:

  • Full Text Search

  • BM25

  • Índices invertidos

  • Autocomplete

  • Facetas

  • Ranking lexical

Enquanto o Db2 faz muito bem:

  • SQL

  • Dados relacionais

  • Vetores

  • Similaridade

Cada um faz aquilo em que é especialista.


Curiosidade

O OpenSearch nasceu quando a Amazon criou um fork aberto do Elasticsearch após mudanças no licenciamento da Elastic.

Hoje ambos continuam extremamente populares.

O Db2 consegue integrar com os dois.


Easter Egg nº 1

Se você já assistiu Star Wars, pense assim.

Keyword Search é como procurar um Jedi pelo nome.

Luke Skywalker

Vector Search é usar a Força.

Você sente que alguém está ali mesmo sem saber exatamente quem é.

Hybrid Search?

É usar os dois ao mesmo tempo.


Easter Egg nº 2

Quem cresceu usando Google provavelmente nunca percebeu.

Quando você pesquisa:

carro vermelho

O Google não procura apenas essas duas palavras.

Ele tenta entender intenção.

Hybrid Search leva essa mesma filosofia para dentro do banco de dados corporativo.


Easter Egg nº 3

O famoso comando do TSO:

FIND

procura caracteres.

O Hybrid Search procura conhecimento.

É uma evolução conceitual parecida com sair de um índice telefônico para um assistente inteligente.


Onde veremos isso nos próximos anos?

Praticamente em todos os sistemas corporativos.

Imagine:

✔ Assistente para COBOL.

✔ Pesquisa inteligente em JCL.

✔ Busca em documentação CICS.

✔ Pesquisa em milhares de Stored Procedures.

✔ Localização automática de código semelhante.

✔ Descoberta de APIs relacionadas.

✔ Pesquisa em incidentes históricos.

✔ Chatbots internos.

✔ Copilotos para desenvolvedores.


O impacto para quem trabalha com Mainframe

Durante muito tempo existiu o mito de que IA e Mainframe eram mundos separados.

Hoje isso não faz mais sentido.

O Mainframe continua sendo responsável pelas informações mais críticas das empresas.

A IA precisa exatamente dessas informações.

E o Db2 está se tornando uma ponte entre esses dois universos.

Em vez de exportar tudo para outra plataforma, é possível realizar boa parte da recuperação inteligente diretamente onde os dados já estão, mantendo segurança, governança e consistência.


Dicas para o programador júnior

  • Continue estudando SQL. Ele continua sendo indispensável.

  • Aprenda conceitos de IA, mas não abandone fundamentos de banco de dados.

  • Entenda o que são embeddings, similaridade e RAG.

  • Familiarize-se com OpenSearch e Elasticsearch.

  • Estude como modelos de linguagem utilizam bases corporativas.

  • Explore as novidades do Db2 12.1.x e acompanhe os anúncios da IBM sobre recursos de IA.


Conclusão

Durante décadas, a missão do Db2 foi responder perguntas objetivas sobre dados estruturados. Com a chegada do suporte a vetores no Db2 12.1.2 e da integração com OpenSearch e Elasticsearch no Db2 12.1.5, o banco passa a participar de uma nova geração de aplicações capazes de compreender contexto e significado.

Essa evolução não substitui SQL nem elimina a importância dos índices tradicionais. Pelo contrário: combina o melhor dos dois mundos. A busca lexical continua sendo excelente para códigos, identificadores e termos exatos, enquanto a busca vetorial amplia a capacidade de encontrar conceitos relacionados, mesmo quando as palavras utilizadas pelo usuário são diferentes daquelas presentes nos documentos.

Para quem desenvolve em COBOL, administra ambientes IBM ou trabalha com arquitetura de sistemas, entender Hybrid Search significa compreender como serão construídos os copilotos, os assistentes técnicos e as soluções RAG que deverão fazer parte do ecossistema corporativo nos próximos anos.

A tecnologia muda. Os princípios permanecem. E talvez a maior lição seja esta: o Db2 continua sendo um banco de dados extraordinário, mas agora ele também começa a compreender o significado das perguntas que fazemos. Isso representa uma mudança de paradigma tão importante quanto a adoção do SQL décadas atrás e coloca o ecossistema IBM em uma posição estratégica para a era da Inteligência Artificial.


sábado, 4 de abril de 2026

🔥Db2 não é banco… é um sistema operacional de dados: o guia definitivo para o COBOL senior

 

Bellacosa Mainframe introduz database manager db2

🔥 Db2 não é banco… é um sistema operacional de dados: o guia definitivo para o COBOL senior

Se você já viveu batch noturno, abend misterioso e reconciliação de saldo às 3 da manhã… então você já sabe:
👉 dados são o coração do sistema
👉 e o IBM Db2 é o que mantém esse coração batendo sem falhar

Este artigo é direto ao ponto, técnico, com história, prática e alguns easter eggs que só quem vive mainframe vai perceber 😏


🧬 1. Origem — o DNA do Db2

O IBM Db2 nasceu nos anos 70, inspirado no modelo relacional de Edgar F. Codd (IBM Research).

👉 Antes disso:

  • IMS dominava (hierárquico)
  • VSAM reinava (arquivos estruturados)

👉 O Db2 trouxe:

  • SQL declarativo
  • Independência lógica
  • Otimização automática

💡 Curiosidade (easter egg)
Db2 foi um dos primeiros sistemas a implementar otimizador baseado em custo (CBO) — algo que até hoje muita stack moderna ainda luta pra fazer direito.


🏗️ 2. Db2 para COBOL — o casamento perfeito

Se você escreve COBOL, você não “usa banco” — você dialoga com o Db2.

📌 Fluxo clássico:

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

👉 O que acontece por baixo:

COBOL → SQL → Db2 Engine → Buffer Pool → Dataset → Disco

💡 Tradução:

Você escreve “o que quer”, o Db2 decide “como buscar”


⚙️ 3. O que o Db2 realmente faz (além do óbvio)

🔐 Controle de concorrência

  • Locks (row/page/table)
  • Isolation levels (CS, RS, RR)

👉 Evita:

  • dirty read
  • lost update

🧾 Logging (o “diário secreto” do banco)

Tudo que acontece é logado:

  • INSERT
  • UPDATE
  • DELETE

👉 Base para:

  • rollback
  • recovery
  • auditoria

🔁 Transações (ACID de verdade)

BEGIN;
UPDATE A;
UPDATE B;
COMMIT;

👉 Se algo falhar:

  • ROLLBACK automático

💡 Isso aqui é o que separa:

sistema confiável vs desastre financeiro


💥 Recovery (o superpoder)

Db2 consegue:

  • restaurar banco
  • aplicar logs
  • voltar no tempo (point-in-time)

👉 Isso mantém:

  • bancos
  • companhias aéreas
  • governos

💾 4. O lado invisível: como o Db2 guarda dados

👉 Você cria tabela:

CREATE TABLE CLIENTES...

👉 O Db2 cria:

  • Tablespaces
  • Index spaces
  • Datasets físicos

💡 Você NÃO acessa direto
👉 Sempre via Db2


🚀 5. Performance — onde mora a magia

🔍 Índices

  • acesso rápido
  • evita full scan

🧠 Buffer Pools

  • cache em memória
  • reduz I/O

📊 RUNSTATS

  • coleta estatísticas
  • alimenta o otimizador

⚡ LOAD / UNLOAD

  • processamento em massa
  • muito mais rápido que SQL linha a linha

💡 Easter egg real de produção

Query lenta 90% das vezes não é CPU… é falta de índice ou estatística desatualizada 😏


🔥 6. Tipos de Backup (e a pegadinha clássica)

TipoComportamento
❄️ ColdBanco parado
🌤️ WarmRead-only
🔥 HotOnline total

👉 Em produção:

quase tudo é hot backup + logs


🧠 7. Stored Procedures — COBOL dentro do banco

Sim, você pode rodar lógica dentro do Db2:

  • SQL PL
  • Stored procedures

👉 Benefícios:

  • menos tráfego
  • mais performance
  • lógica centralizada

🌐 8. Integração com o mundo

Db2 conversa com:

  • CICS
  • Batch (JCL)
  • APIs modernas
  • Java / REST

👉 Ele não é legado…
👉 Ele é o backbone


⚔️ 9. Comparação rápida (pra provocar 😏)

TecnologiaEstilo
VSAMmanual
IMSultra rápido
MySQLsimples
Db2equilíbrio absoluto

🧠 10. Mentalidade que muda o jogo

👉 Desenvolvedor comum:

“vou fazer um SELECT”

👉 Dev COBOL senior com Db2:

“como o otimizador vai executar isso?”


💡 11. Dicas práticas (ouro puro)

✔️ Sempre pense em índice

  • coluna de filtro → índice

✔️ Evite SELECT *

  • pega só o necessário

✔️ Use COMMIT corretamente

  • evita lock longo

✔️ RUNSTATS sempre atualizado

  • sem isso = plano ruim

✔️ Entenda EXPLAIN

  • leia o plano de execução

🧬 12. Insight final (nível Bellacosa)

O Db2 não é só um banco
Ele é o sistema que garante que milhões de transações
aconteçam sem erro, sem perda e sem inconsistência


🚀 Conclusão

Se você domina:

  • SQL embutido em COBOL
  • índices e estatísticas
  • transações e recovery

👉 Você não é só dev
👉 Você é engenheiro de sistemas críticos


☕ Easter egg final

Se você já viu isso:

DSNT408I SQLCODE = -911

👉 Parabéns
Você já entrou no mundo real do Db2 😈

sexta-feira, 3 de abril de 2026

💀 Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações

 

Bellacosa Mainframe introduz o DB2

💀 “Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações”

Se você acha que banco de dados é só “guardar informação”… prepare-se: no mundo corporativo pesado — bancos, seguradoras, governos — quem reina é a dupla COBOL + Db2.
E não, isso não é legado morto. Isso é infraestrutura crítica global.


🧬 Origem: quando dados viraram ciência

Antes do Db2, existia caos.

  • arquivos flat
  • duplicação
  • dificuldade de acesso

Então surge o modelo relacional, criado por Edgar F. Codd na IBM.

👉 Resultado:

  • tabelas
  • chaves
  • SQL

E nos anos 80 nasce o Db2, trazendo isso para o mundo enterprise.


🏛️ Db2 no Mainframe: onde o jogo é sério

O Db2 roda no z/OS, lado a lado com:

  • COBOL
  • CICS
  • IMS

💀 Tradução:

Isso aqui processa dinheiro de verdade


☕ O Dev COBOL Sênior (vida real)

Imagine um sistema bancário:

Cliente faz transferência → COBOL → Db2 → commit

💡 Exemplo COBOL + Db2

EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - 100
WHERE ID = :ORIGEM
END-EXEC.

EXEC SQL
UPDATE CONTA
SET SALDO = SALDO + 100
WHERE ID = :DESTINO
END-EXEC.

EXEC SQL
COMMIT
END-EXEC.

👉 Simples? Sim.
👉 Crítico? ABSURDAMENTE.


🔄 Transações: o coração do sistema

Você viu isso no módulo — aqui é onde ganha vida:

START → UPDATE → COMMIT

Se falhar:

ROLLBACK

💀 Isso evita:

  • dinheiro sumir
  • inconsistência

📜 Logging: a caixa preta do banco

Db2 registra TUDO:

  • INSERT
  • UPDATE
  • DELETE

👉 Isso permite:

  • auditoria
  • recovery
  • rastreamento

💡 Insight

Sem log… você está cego
Com log… você reconstrói o passado


🔄 Recovery: sobrevivência do sistema

Cenário:

  • backup às 6:00
  • falha às 11:00

👉 solução:

Backup + Logs = estado correto

💾 Backup no mundo real

❄️ Cold

  • banco parado

🌡️ Warm

  • leitura apenas

🔥 Hot

  • banco online (produção)

💀 No banco:

parar sistema não é opção → usa hot backup


🔒 Locking: guerra silenciosa

3 programas acessando o mesmo registro:

App1 → lock
App2 → espera
App3 → leitura controlada

👉 Locks evitam corrupção


💡 Regra de ouro

Lock só é liberado no COMMIT


⚡ Performance: onde o DBA brilha

📦 Buffers

  • memória → rápido

📚 Index

  • busca instantânea

⚙️ Optimizer

  • escolhe melhor plano

👉 Exemplo:

Sem índice:

SELECT * FROM CLIENTE WHERE NOME='JOÃO';

Com índice:

CREATE INDEX IDX_NOME ON CLIENTE(NOME);

⚡ diferença absurda


🌐 Integração moderna (sim, Db2 evoluiu)

Hoje Db2 conversa com:

  • APIs
  • Java (JDBC)
  • ODBC
  • microservices

👉 Não é mais só terminal verde 😄


🧠 Stored Procedures: lógica dentro do banco

CREATE PROCEDURE TRANSFERIR(...)

👉 roda dentro do Db2
👉 menos rede
👉 mais performance


🧬 Easter Eggs & Curiosidades

💡 Db2 nasceu dentro da IBM Research
💡 COBOL ainda processa ~70% das transações financeiras mundiais
💡 Muitos sistemas críticos têm décadas sem downtime significativo


💀 Easter Egg raiz:

“If it ain’t broken, don’t migrate it”
(tradução: se está rodando há 30 anos… NÃO mexe 😄)


🔥 Insight nível Bellacosa

Mainframe não é legado…
é infraestrutura estável, segura e absurda em escala


🧠 Visão final (arquitetura)

Usuário → Aplicação (COBOL) → Db2 → Dados

Logs / Backup / Recovery

🚀 Conclusão

Você começou aprendendo:

  • o que é banco
  • modelos
  • DBMS
  • transações
  • logs
  • backup
  • performance

👉 E chegou aqui:

💀 Entendendo como o mundo financeiro roda


💥 Frase final

Enquanto todo mundo fala de cloud…
o dinheiro do mundo continua passando por COBOL + Db2

 

quinta-feira, 22 de janeiro de 2026

💥 DB2 A REGRA QUE MUDA TUDO

 

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


sexta-feira, 16 de janeiro de 2026

💥 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

quarta-feira, 1 de outubro de 2025

☕💾 LAB 1 — Laboratório Prático DB2 para Iniciantes 💾☕

 

Bellacosa Mainframe Laboratorio Pratico Db2

☕ Um Café no Bellacosa Mainframe

☕💾 LAB 1 — Laboratório Prático DB2 para Iniciantes 💾☕

🎯 Objetivo do Laboratório

Neste laboratório o aluno irá aprender:

  • Entrar no ambiente TSO
  • Entender o conceito de Address Space
  • Acessar o SPUFI
  • Configurar o SPUFI
  • Executar os primeiros comandos SQL no DB2

📘 Parte 1 — Entrando no TSO

Objetivo

Acessar o ambiente z/OS.


Passos

1) Entrar no emulador 3270

Exemplo:

  • IBM Personal Communications
  • x3270
  • Rocket BlueZone

2) Informar usuário e senha

LOGON APPLID(TSO)

3) Após login, acessar ISPF

Digite:

ISPF

📘 Parte 2 — Entendendo Address Space

Conceito

No z/OS, cada sistema ou aplicação roda em um espaço de memória chamado:

✅ Address Space

Exemplos:

  • DB2
  • CICS
  • JES2
  • TSO User

Exercício

Pergunta:

O DB2 possui seu próprio Address Space?

✅ Resposta:
Sim.


Curiosidade ☕

O DB2 pode possuir:

  • MSTR
  • DBM1
  • IRLM
  • DIST

Cada um com funções específicas.


📘 Parte 3 — Entrando no SPUFI

Objetivo

Executar SQL interativamente.


Caminho clássico

Dentro do ISPF:

DB2I

ou:

DSN SYSTEM(DB2P)

Menu típico

SPUFI ===> 1

📘 Parte 4 — Configurando o SPUFI

Objetivo

Criar dataset de entrada e saída SQL.


Input Dataset

Exemplo:

USERID.SPufi.INPUT

Output Dataset

Exemplo:

USERID.SPUFI.OUTPUT

Exercício

O dataset INPUT contém:

A) Resultado SQL
B) JCL
C) Comandos SQL
D) Logs JES2

✅ Resposta: C


📘 Parte 5 — Primeiro SELECT

Objetivo

Consultar dados no DB2.


SQL

Digite no dataset INPUT:

SELECT * 
FROM SYSIBM.SYSDUMMY1;

Executar

Pressione:

ENTER

e depois:

PF3

Resultado Esperado

1
-
X

Explicação

SYSIBM.SYSDUMMY1
é uma tabela especial usada para testes simples.


📘 Parte 6 — Primeiro CREATE TABLE

Objetivo

Criar tabela simples.


SQL

CREATE TABLE LAB.CLIENTES
(
ID INTEGER,
NOME VARCHAR(30)
);

Resultado Esperado

SQLCODE = 0

Pergunta

O que significa SQLCODE = 0?

A) Warning
B) Erro grave
C) Execução com sucesso
D) Deadlock

✅ Resposta: C


📘 Parte 7 — Inserindo Dados

SQL

INSERT INTO LAB.CLIENTES
VALUES (1,'BELLACOSA');

Verificando

SELECT * FROM LAB.CLIENTES;

Resultado Esperado

ID   NOME
-- ----------
1 BELLACOSA

📘 Parte 8 — Atualizando Dados

SQL

UPDATE LAB.CLIENTES
SET NOME = 'MAINFRAME'
WHERE ID = 1;

Conferindo

SELECT * FROM LAB.CLIENTES;

Resultado

1   MAINFRAME

📘 Parte 9 — DELETE

SQL

DELETE FROM LAB.CLIENTES
WHERE ID = 1;

Conferindo

SELECT * FROM LAB.CLIENTES;

Resultado

0 ROWS FOUND

☕💀 DESAFIO FINAL — O Erro Clássico 💀☕

O que acontece se executar:

DELETE FROM LAB.CLIENTES;

sem WHERE?

A) Apenas 1 linha removida
B) Nada acontece
C) Todas as linhas são apagadas
D) O SPUFI trava automaticamente

✅ Resposta: C 😱


📘 Parte 10 — Encerrando

Removendo tabela

DROP TABLE LAB.CLIENTES;

📊 Resumo do Laboratório

TemaAprendido
TSOLogin e ISPF
Address SpaceConceito básico
SPUFIExecução SQL
SELECTConsulta
INSERTInclusão
UPDATEAlteração
DELETERemoção
DROPExclusão de objeto

☕🔥 Dica Bellacosa Mainframe 🔥☕

Quem domina:

  • SPUFI,
  • SQL básico,
  • DISPLAY,
  • e entende Address Space…

já começou oficialmente sua jornada no mundo DB2 Mainframe. ☕💾🔥

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...