Translate

Mostrar mensagens com a etiqueta DB2zOS. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta DB2zOS. Mostrar todas as mensagens

quarta-feira, 11 de março de 2020

🔥☕ DB2 z/OS MAINFRAME — A ANATOMIA DO “CÉREBRO DOS DADOS” ☕🔥

 

Bellacosa Mainframe entenda o funcionamento do DB2

🔥☕ DB2 z/OS MAINFRAME — A ANATOMIA DO “CÉREBRO DOS DADOS” ☕🔥

Salve jovem padawan neste laboratorio pratico veremos alguns dos componentes mais profundos e importantes do DB2 z/OS:
Storage Groups, Bufferpools, Logs, Optimizer, EDM Pool, índices B-Tree, Data Sharing, BSDS e arquitetura interna do banco.

Isso já entra no território de:

  • DBA de produção,
  • suporte avançado,
  • performance tuning,
  • recovery,
  • troubleshooting crítico,
  • arquitetura interna do DB2.

O DB2 no z/OS não é apenas um “banco de dados”.

Ele é:

  • sistema transacional,
  • gerenciador de memória,
  • engine de recovery,
  • scheduler interno,
  • coordenador de locking,
  • otimizador SQL,
  • e controlador de integridade transacional.

🔥 1) STORAGE GROUP — O “MAPEAMENTO DO TERRITÓRIO”

🧠 O que é

Storage Group é o agrupamento lógico de volumes DASD usados pelo DB2.


🔍 Função

O DBA não precisa dizer:

  • “grave exatamente no disco XYZ”

O DB2 usa o Storage Group para decidir:

  • onde alocar datasets,
  • como distribuir dados,
  • onde criar VSAM LDS.

🧨 Exemplo

CREATE STOGROUP STGPRD
VOLUMES(PRD001,PRD002)
VCAT(DB2CAT);

🔥 O que ele controla

  • datasets DB2
  • VSAM LDS
  • tablespaces
  • indexspaces
  • crescimento físico

🚨 Problema clássico

Storage Group sem espaço.

Resultado:

  • inserts falham,
  • extents explodem,
  • utilities quebram.

🔥 LAB 01 — STORAGE GROUP LOTADO

🚨 Problema

Aplicação falhando:

SQLCODE -904
RESOURCE UNAVAILABLE

🔍 Investigação

Verificar volumes:

-DIS DB(*) SPACENAM(*)

💣 Diagnóstico

DASD cheio.


✅ Solução

Adicionar volume:

ALTER STOGROUP STGPRD
ADD VOLUMES(PRD003);

🧠 Explicação

O DB2 não conseguia expandir datasets.


🔥 2) TABELAS — O “CORPO FÍSICO” DOS DADOS

🧠 Estrutura lógica

Tabela:

  • colunas
  • linhas
  • constraints
  • índices

Mas internamente:

  • pages
  • RID
  • slots
  • overflow pages

🧨 Exemplo

CREATE TABLE ALUNOS
(
ID INTEGER,
NOME CHAR(40),
CURSO CHAR(20)
);

🔥 Tipos de tabelas

TipoUso
Segmentedtradicional
Partitionedgrandes volumes
Universalmoderno
Temporarytemporárias
Clonedeploy online

🚨 Problema clássico

Tabela enorme sem particionamento.

Resultado:

  • REORG gigantesco,
  • recovery lento,
  • scans monstruosos.

🔥 LAB 02 — TABELA GIGANTE

🚨 Problema

Tabela com 4 bilhões de linhas.

REORG demora 18 horas.


✅ Solução

Migrar para partitioned tablespace.


🧠 Explicação

Particionamento divide carga física.


🔥 3) ÍNDICES — O GPS DO DB2

🧠 O que fazem

Índices evitam full scan.


🔥 Estrutura B-Tree

Seu material menciona:

B-Tree : Índice – Arvore Binaria


🧠 Como funciona

A árvore possui:

  • root page
  • branch pages
  • leaf pages

🔍 O DB2 percorre:

ROOT → BRANCH → LEAF → ROW

🚨 Sem índice

O DB2 lê:

  • milhões de páginas.

🧨 Exemplo

CREATE INDEX IXALUNO
ON ALUNOS(ID);

🔥 LAB 03 — SQL MATANDO CPU

🚨 Problema

SELECT demorando minutos.


🔍 Investigação

EXPLAIN mostra:

TABLESPACE SCAN

✅ Solução

Criar índice:

CREATE INDEX IXCPF
ON CLIENTE(CPF);

🧠 Explicação

DB2 deixou de varrer tabela inteira.


🔥 4) CATALOGO DB2 — O “DNA” DO BANCO

Seu material aborda:

Catalogo
Metadados


🧠 O que é

O catálogo guarda:

  • definição tabelas
  • índices
  • colunas
  • privileges
  • packages
  • plans

🔍 Tabelas famosas

TabelaFunção
SYSIBM.SYSTABLEStabelas
SYSIBM.SYSCOLUMNScolunas
SYSIBM.SYSINDEXESíndices
SYSIBM.SYSPACKAGEpackages

🧨 Exemplo

SELECT NAME
FROM SYSIBM.SYSTABLES
WHERE CREATOR='ESCOLA';

🔥 LAB 04 — DESCOBRIR ÍNDICES

🚨 Problema

Ninguém sabe quais índices existem.


✅ Solução

SELECT NAME
FROM SYSIBM.SYSINDEXES
WHERE TBNAME='CLIENTE';

🧠 Explicação

Catálogo é o “Google interno” do DB2.


🔥 5) LOG — A “CAIXA PRETA” DO DB2

Seu material aborda:

Active LOG
Archive LOG
BSDS


🧠 O que é o LOG

Tudo que muda no DB2 vai para log.


🔥 Serve para

  • rollback
  • recovery
  • restart
  • integridade
  • auditoria

🔥 ACTIVE LOG

Logs atuais em uso.


🔥 ARCHIVE LOG

Logs antigos arquivados.


🔥 BSDS

Bootstrap Dataset.

Contém:

  • inventário logs
  • checkpoints
  • bootstrap recovery

🚨 Se BSDS corrompe…

O DB2 entra em crise séria.


🔥 LAB 05 — LOG FULL

🚨 Problema

Sistema travado.


🔍 Investigação

-DIS LOG

💣 Resultado

Logs esgotados.


✅ Solução

  • aumentar logs
  • reduzir transações longas
  • acelerar archive

🧠 Explicação

Sem log livre o DB2 para updates.


🔥 6) BUFFERPOOL — O “PULMÃO” DO DB2

Seu material aborda:

Bufferpool
Frame Bufferpool


🧠 O que é

Cache de páginas em memória.


🔍 Fluxo

DASD → BUFFERPOOL → CPU

🚨 Bufferpool ruim = muito I/O


🧨 Exemplo

-DIS BUFFERPOOL(BP0)

🔥 LAB 06 — HIT RATIO HORRÍVEL

🚨 Problema

I/O gigantesco.


🔍 Resultado

HIT RATIO 58%

✅ Solução

Aumentar:

ALTER BUFFERPOOL(BP0) VPSIZE(50000)

🧠 Explicação

Mais páginas em cache.


🔥 7) DB2 DATA SHARING — O “CLUSTER” DO MAINFRAME

Seu material mostra:

DB2 DATA SHARING com Group Bufferpools


🧠 O que é

Vários DB2s compartilhando dados simultaneamente.


🔥 Permite

  • alta disponibilidade
  • escalabilidade
  • failover
  • paralelismo

🔍 Componentes

ComponenteFunção
Coupling Facilitysincronização
GBPcache compartilhado
IRLMlocking

🚨 Problema clássico

Contention no GBP.


🔥 LAB 07 — CONTENTION EM DATA SHARING

🚨 Problema

Locks excessivos.


🔍 Investigação

-DIS GROUP

💣 Resultado

GBP saturation.


✅ Solução

Aumentar Group Bufferpool.


🧠 Explicação

Muitos membros acessando mesmas páginas.


🔥 8) OPTIMIZER — O “CÉREBRO” DO SQL

Seu material aborda:

DB2 Optimizer


🧠 O que faz

Decide:

  • índice
  • join
  • scan
  • sort
  • access path

🔥 Sem optimizer

SQL seria inviável.


🔍 Ele analisa:

  • cardinalidade
  • seletividade
  • RUNSTATS
  • índices
  • distribuição dados

🔥 LAB 08 — OPTIMIZER ESCOLHEU MAL

🚨 Problema

SQL piorou após deploy.


🔍 Investigação

Novo access path.


✅ Solução

Executar:

RUNSTATS TABLESPACE FINANCE.CLIENTE

Rebind package.


🧠 Explicação

Stats antigas enganaram optimizer.


🔥 9) EDM POOL — O “CACHE CEREBRAL”

Seu material aborda:

  • EDM POOL
  • Dynamic Cache
  • PT/CT
  • Skeleton Pool
  • DBD


🧠 O que é

Cache interno de:

  • packages
  • plans
  • SQL dinâmico
  • estruturas DBD

🔥 Problema clássico

EDM pequeno.


🚨 Resultado

  • compilação excessiva
  • CPU alta
  • cache thrashing

🔥 LAB 09 — EDM SATURADO

🚨 Problema

CPU do DB2 explodindo.


🔍 Investigação

-DIS DDF

e monitor EDM.


💣 Resultado

Dynamic statement cache lotado.


✅ Solução

Aumentar EDM pool.


🧠 Explicação

SQL dinâmico recompilando continuamente.


🔥 10) BIND E PACKAGE

Seu material cita:

BindProgram


🧠 O que é BIND

Transforma SQL em package executável.


🔥 PACKAGE

Código SQL otimizado armazenado.


🔥 LAB 10 — PACKAGE INVALIDADO

🚨 Problema

Programa falha após alteração tabela.


💣 Resultado

Package inválido.


✅ Solução

REBIND PACKAGE

🧠 Explicação

DDL alterou estrutura dependente.


🔥 LAB EXTRA — INCIDENTE COMPLETO

🚨 Cenário

Sistema financeiro lento.


🔍 Investigação

Descoberto:

  • RUNSTATS vencido
  • bufferpool saturado
  • índice inválido
  • logs pressionados

✅ Solução

Fluxo:

  1. REBUILD INDEX
  2. REORG
  3. RUNSTATS
  4. Ajuste BUFFERPOOL
  5. Revisão commits

🧠 Resultado

CPU caiu:

  • de 92%
  • para 34%

☕ VISÃO “BELLACOSA MAINFRAME”

O DB2 z/OS parece um banco…

Mas internamente ele é:

  • sistema operacional de dados,
  • motor transacional,
  • mecanismo de recuperação,
  • orquestrador de memória,
  • e inteligência analítica.

Quem aprende:

  • logs,
  • bufferpool,
  • optimizer,
  • EDM,
  • utilities,
  • data sharing,

não aprende apenas SQL…

aprende a anatomia do coração digital das grandes corporações. ☕💣

quarta-feira, 22 de maio de 2019

☕🔥 DB2 z/OS — COMO IDENTIFICAR PROBLEMAS EM ÍNDICES, ANALISAR A SAÚDE E CRIAR ÍNDICES EFICIENTES

 

Bellacosa Mainframe e a saude do Db2

☕🔥 DB2 z/OS — COMO IDENTIFICAR PROBLEMAS EM ÍNDICES, ANALISAR A SAÚDE E CRIAR ÍNDICES EFICIENTES

No Db2 for z/OS, índices são literalmente o “GPS” do otimizador.
Quando um índice está ruim, fragmentado, mal desenhado ou inconsistente, os sintomas aparecem rapidamente:

  • CPU alta

  • GETPAGE excessivo

  • LOCKS maiores

  • Deadlocks

  • Elapsed Time absurdo

  • SORT desnecessário

  • RUNSTATS inconsistentes

  • ACCESS PATH inesperado

  • Tablespace em CHECK/RBDP/RECP

  • RID List Overflow

  • REORG frequente


🔥 COMO IDENTIFICAR PROBLEMAS EM ÍNDICES

1 — Verificando Fragmentação do Índice

Um dos principais indicadores.

Consultas importantes

SELECT
    NAME,
    CLUSTERING,
    CLUSTERRATIOF,
    LEAFDIST,
    NLEVELS,
    FULLKEYCARDF,
    FIRSTKEYCARDF
FROM SYSIBM.SYSINDEXES
WHERE CREATOR = 'SEU_SCHEMA'
AND TBNAME = 'SUA_TABELA';

🔎 O QUE OBSERVAR

CLUSTERRATIOF

Mostra o quanto os dados seguem a sequência do índice clustering.

Valores

ValorSituação
> 95Excelente
80–95Aceitável
< 80Fragmentação séria

Baixo CLUSTERRATIO gera:

  • Mais I/O

  • Mais Sync Read

  • Mais Random Access

  • Mais CPU


LEAFDIST

Distância média entre páginas leaf.

Quanto maior:

  • pior a localidade física

  • mais page split ocorreu


NLEVELS

Quantidade de níveis B-Tree.

NívelInterpretação
2-3Normal
4+Índice muito grande ou mal estruturado

Mais níveis = mais GETPAGE.


🔥 PAGE SPLIT — O GRANDE VILÃO

Quando páginas do índice enchem:

  • Db2 divide páginas

  • reorganiza ponteiros

  • aumenta fragmentação

Sintomas:

  • CPU cresce

  • bufferpool sofre

  • random I/O aumenta


🔎 COMO IDENTIFICAR PAGE SPLIT

SELECT
    NAME,
    SPACEF,
    STATSTIME
FROM SYSIBM.SYSINDEXSPACESTATS
WHERE DBNAME = 'SEU_DB';

🔥 REORGCHECK — O TESTE CLÁSSICO

No Db2 LUW existe REORGCHK.

No z/OS normalmente usamos:

  • RUNSTATS

  • REORG TABLESPACE/INDEX

  • Estatísticas catalogadas

  • RTS (Real Time Statistics)


🔥 REAL TIME STATISTICS (RTS)

Tabela importantíssima:

SYSIBM.SYSINDEXSPACESTATS

Campos críticos:

CampoSignificado
REORGINSERTSInserts desde último REORG
REORGDELETESDeletes
REORGUPDATESUpdates
LEAFDISTFragmentação
FARINDREFReferência distante
NEARINDREFReferência próxima

🔥 FARINDREF — UM DOS MELHORES INDICADORES

Mostra quantos acessos ao índice apontam para linhas longe fisicamente.

Quanto maior:

  • pior clustering

  • pior cache

  • pior bufferpool hit ratio


🔥 COMO SABER SE O ÍNDICE NÃO ESTÁ SENDO USADO

Pacotes e explain.


EXPLAIN

EXPLAIN PLAN SET QUERYNO = 100
FOR
SELECT *
FROM CLIENTES
WHERE CPF = ?;

Depois consulte:

SELECT
    ACCESSNAME,
    ACCESSTYPE,
    MATCHCOLS
FROM PLAN_TABLE
WHERE QUERYNO = 100;

🔎 INTERPRETAÇÃO

CampoSignificado
ACCESSTYPE='I'Uso de índice
MATCHCOLSQuantas colunas casaram
ACCESSNAMEÍndice usado

🔥 INDICADORES DE ÍNDICE RUIM

1 — MATCHCOLS baixo

Índice composto mal desenhado.


2 — ACCESSTYPE = 'R'

Tablespace Scan.

Ruim para tabelas grandes.


3 — RID LIST PROCESSING

Pode indicar:

  • excesso de índices

  • índices ruins

  • baixa seletividade


🔥 COMO DESENHAR UM ÍNDICE FORTE

REGRA #1 — COLUNA MAIS SELETIVA PRIMEIRO

Exemplo ruim:

CREATE INDEX IX1
ON CLIENTES
(SEXO, ESTADO);

Baixa cardinalidade.


Melhor:

CREATE INDEX IX1
ON CLIENTES
(CPF, ESTADO);

🔥 REGRA #2 — RESPEITAR O PREDICATE

Db2 usa LEFTMOST MATCHING.

Exemplo:

INDEX(A,B,C)

Funciona bem para:

WHERE A=?
WHERE A=? AND B=?
WHERE A=? AND B=? AND C=?

Ruim para:

WHERE B=?
WHERE C=?

🔥 REGRA #3 — EVITAR ÍNDICES DEMAIS

Cada índice:

  • aumenta INSERT

  • aumenta UPDATE

  • aumenta DELETE

  • aumenta LOG

  • aumenta LOCKING

  • aumenta CPU


🔥 QUANTOS ÍNDICES UMA TABELA DEVE TER?

Não existe número mágico.

Mas no mundo real:

TipoRecomendação
OLTP3–7
Tabelas críticas10–15 máximo
Acima de 20normalmente problema de modelagem

Já vi tabelas com:

  • 80 índices

  • 120 índices

Resultado:

  • INSERT sofrendo

  • Deadlock

  • log monstruoso

  • CPU absurda


🔥 ÍNDICE CLUSTERING

Muito importante.

CREATE INDEX IXCLI1
ON CLIENTES (CPF)
CLUSTER;

Só pode existir UM clustering index por tabela.

Ele influencia:

  • ordem física

  • prefetch

  • sequential detection

  • range scan


🔥 RUNSTATS — FUNDAMENTAL

Sem RUNSTATS:

  • optimizer fica “cego”

  • access path piora


Exemplo

RUNSTATS TABLESPACE DB1.TSCLI
TABLE(ALL)
INDEX(ALL)
KEYCARD
FREQVAL
HISTOGRAM
UPDATE ALL

🔥 O QUE O RUNSTATS FAZ

Atualiza:

  • cardinalidade

  • clustering

  • distribuição

  • frequência

  • histogramas

  • seletividade


🔥 RUNSTATS COM SHRLEVEL CHANGE

Permite online.

SHRLEVEL CHANGE

Muito usado em produção.


🔥 REORG INDEX

Quando usar:

  • fragmentação

  • page split

  • baixa cluster ratio


Exemplo

REORG INDEX (ALL) TABLESPACE DB1.TSCLI
SHRLEVEL CHANGE

🔥 REBUILD INDEX

Mais pesado.

Usado quando:

  • índice corrompido

  • recover

  • inconsistency

  • rebuild pós LOAD REPLACE


🔥 RUNSTATS x REORG

UtilitárioFunção
RUNSTATSAtualiza estatísticas
REORGReorganiza fisicamente
REBUILD INDEXReconstrói índice

🔥 RUNSTATUS / RESTRICTIVE STATES

Estados importantes no Db2.


🔴 CHECK PENDING (CHKP)

Db2 exige CHECK DATA.

Exemplo:

-904 RESOURCE UNAVAILABLE

Resolver:

CHECK DATA TABLESPACE DB1.TS1

🔴 REORG PENDING (REORP)

Db2 exige REORG.

Muito comum após:

  • ALTER

  • compress

  • partition change

Resolver:

REORG TABLESPACE DB1.TS1

🔴 RECOVER PENDING (RECP)

Objeto precisa RECOVER.


🔴 AUX CHECK PENDING

LOB inconsistente.


🔴 ADVISORY REORG PENDING (AREO*)

Db2 recomenda REORG.

Não bloqueia uso.


🔥 QUIESCE — O “PONTO DE RESTORE”

Cria ponto consistente para recover coordenado.


Exemplo

QUIESCE TABLESPACE DB1.TS1
WRITE YES

🔎 O QUE ELE FAZ

Sincroniza:

  • logs

  • páginas

  • buffers

Muito usado antes de:

  • LOAD

  • grandes mudanças

  • backup crítico


🔥 DISPLAY DATABASE

Comando essencial.

-DISPLAY DATABASE(DB1) SPACENAM(TS1) RESTRICT

Mostra:

  • REORP

  • CHKP

  • AREO*

  • COPY pending

  • advisory states


🔥 DISPLAY INDEX

-DISPLAY DATABASE(DB1) SPACENAM(TS1) USE

🔥 IFCID E MONITORAMENTO

Sysprog geralmente usa:

  • IFCID 199

  • IFCID 376

  • IFCID 389

  • OMEGAMON

  • MainView

  • Query Monitor

Para detectar:

  • index scan ruim

  • getpages altos

  • synchronous I/O

  • random read

  • RID overflow


🔥 SINAIS CLÁSSICOS DE ÍNDICE PROBLEMÁTICO

SintomaPossível causa
CPU altaÍndice ruim
Tablespace Scanfalta índice
GETPAGE altoexcesso de níveis
Sync I/O altofragmentação
Deadlockexcesso índices
INSERT lentomuitos índices
REORG frequentepage split
Bufferpool ruimclustering baixo

☕ MELHOR ESTRATÉGIA ENTERPRISE

Fluxo saudável

RUNSTATS
   ↓
EXPLAIN
   ↓
ANÁLISE RTS
   ↓
REORG
   ↓
MONITORAMENTO IFCID
   ↓
AJUSTE DE ACCESS PATH

🔥 RESUMO ENTERPRISE

Índice saudável:

✅ Alta seletividade
✅ Baixo NLEVELS
✅ CLUSTERRATIO alto
✅ Poucos page splits
✅ MATCHCOLS alto
✅ Bom clustering
✅ Estatísticas atualizadas
✅ Poucos índices redundantes


☕ REGRA DE OURO NO Db2 z/OS

“Índice demais mata INSERT.
Índice de menos mata SELECT.
Índice ruim mata os dois.”