 |
| Bellacosa Mainframe por dentro do Db2 |
☕ Um Café no Bellacosa Mainframe
Mr. Spock Entra no CPD — O Dia em que o Programador COBOL Disse “É Só um SELECT” e Descobriu uma Civilização Inteira Dentro do Db2
Ou: por que Buffer Pool, IRLM, DDF, Catalog, Directory, Logs, RUNSTATS, Package, RACF, WLM e Parallel Sysplex fazem parte da mesma missão — e por que dizer que Db2 é “apenas um banco de dados” seria, segundo Spock, altamente ilógico
O turno da noite estava tranquilo.
Tranquilo demais.
E todo profissional de mainframe com alguma estrada sabe que essa frase normalmente é seguida por algum desastre.
O monitor do CICS estava verde. O JES2 aparentemente não tinha nada contra a humanidade naquele momento. O RACF não estava distribuindo ICH408I como panfleto em estação de metrô e nenhum operador havia entrado correndo no CPD gritando:
— A PRODUÇÃO PAROU!
Era quase suspeito.
O jovem programador COBOL, ainda naquela fase da carreira em que acreditamos que um programa que compilou também necessariamente funciona, olhou para sua rotina e anunciou:
EXEC SQL
SELECT NOME,
SALDO
INTO :WS-NOME,
:WS-SALDO
FROM CLIENTE
WHERE CONTA = :WS-CONTA
END-EXEC.
Ele sorriu.
— Pronto. É só um SELECT.
Uma sobrancelha levantou-se no outro lado da sala.
Mr. Spock havia entrado no CPD.
Ninguém soube explicar como um oficial científico da Frota Estelar havia conseguido autorização RACF, crachá temporário e acesso à área restrita do datacenter. Mas considerando que o pessoal de infraestrutura já havia liberado consultores externos com justificativas muito piores, ninguém perguntou.
Spock examinou o código.
Depois examinou o programador.
— Sua afirmação contém uma simplificação estatisticamente perigosa.
— Como assim?
— Você acredita ter executado um SELECT. Na realidade, iniciou uma sequência de eventos envolvendo processamento SQL, gerenciamento de memória, otimização, concorrência, storage, catálogo, controle transacional, autorização e possivelmente comunicação distribuída.
O programador ficou olhando para ele.
— Mas voltou um saldo.
— Exatamente. E esta é a parte fascinante.
Assim começa nossa viagem pela arquitetura do Db2 for z/OS.
1. Primeiro diagnóstico de Spock: Db2 não é uma caixa preta
Para muita gente que começa no COBOL, Db2 parece funcionar assim:
COBOL
↓
SQL
↓
Db2
↓
dados
É confortável.
Também está incompleto.
Uma representação mais próxima da realidade seria algo como:
Programa COBOL
↓
CICS / Batch / DDF
↓
Thread Db2
↓
Package
↓
Access Path
↓
DBM1
↓
Buffer Pools
↓
Table Space / Index Space
↓
DFSMS / Storage
Enquanto isso, paralelamente:
IRLM → locking
Logs → recovery
RACF → segurança
WLM → prioridade
Catalog → metadados
DDF → acesso distribuído
Spock provavelmente resumiria:
“A simplicidade percebida pelo programador é consequência da complexidade absorvida pela infraestrutura.”
E isso é um dos maiores triunfos do mainframe.
2. O que é um Db2 Subsystem?
Vamos começar pela porta da nave.
No z/OS, frequentemente trabalhamos com um Db2 subsystem.
Ele representa uma instância operacional do Db2 dentro daquele ambiente.
Uma empresa poderia ter algo como:
DB2D → desenvolvimento
DB2T → testes
DB2H → homologação
DB2P → produção
Os nomes variam conforme a instalação.
Não existe mandamento dizendo que produção precisa se chamar DB2P.
Aliás, se existe algo que mainframe ensina rapidamente é:
cada empresa tem suas tradições.
Algumas parecem normas técnicas.
Outras parecem decisões tomadas em 1989 por alguém chamado Geraldo, que se aposentou em 2003 e nunca documentou nada.
Curiosidade do CPD
É muito comum o iniciante dizer:
— Estou conectado no Db2.
O veterano pergunta:
— Qual?
E aí começa a aula.
Um mesmo ambiente pode possuir múltiplos subsystems.
Por isso entender onde seu programa está executando é tão importante quanto entender o que ele executa.
3. DBM1 — a sala de máquinas
No coração da arquitetura encontramos o DBM1, o Database Services Address Space.
É onde ocorre uma quantidade enorme do trabalho relacionado ao banco.
Dentro dessa paisagem aparecem conceitos como:
Pense no DBM1 como a engenharia da Enterprise.
Você pode estar sentado confortavelmente na ponte dizendo:
— Warp 5.
Mas alguém lá embaixo precisa fazer o motor funcionar.
No COBOL seria:
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTA
WHERE NUM_CONTA = :WS-CONTA
END-EXEC.
Do ponto de vista do desenvolvedor:
SELECT → resultado
Do ponto de vista da infraestrutura:
solicitação
→ contexto de execução
→ access path
→ memória
→ índice
→ páginas
→ locking
→ eventualmente I/O
→ retorno
“É só um SELECT” começa a parecer uma frase corajosa.
4. Buffer Pool — o truque que evita transformar cada consulta em uma excursão ao storage
Se existe um conceito que todo programador Db2 deveria entender cedo, é Buffer Pool.
Imagine que você tenha uma tabela com 100 milhões de registros.
O programa procura:
SELECT NOME
FROM CLIENTE
WHERE ID_CLIENTE = 928173;
Fisicamente, os dados estão persistidos em storage.
Se toda consulta tivesse que buscar diretamente no disco, teríamos:
programa
↓
Db2
↓
storage
↓
I/O
↓
Db2
↓
programa
Constantemente.
A performance seria digna de uma carroça klingon.
O Buffer Pool existe justamente para manter páginas de dados e índices em memória.
MEMÓRIA
┌───────────────────┐
│ BUFFER POOL │
│ │
│ páginas de dados │
│ páginas de índice │
└─────────┬─────────┘
│
página ausente?
│
SIM ↓
STORAGE
Se a página já está em memória, evitamos determinado I/O físico.
Essa diferença pode ser gigantesca.
5. O programador pensa em linha; o Db2 frequentemente pensa em página
Aqui está uma mudança de mentalidade poderosa.
O programador escreve:
WHERE CONTA = 12345
Ele pensa:
“Quero essa linha.”
O Db2 precisa lidar com estruturas de armazenamento organizadas em pages.
Então conceitualmente:
linha solicitada
↓
página onde ela está
↓
Buffer Pool
↓
storage se necessário
Isso explica por que performance de banco não pode ser estudada pensando apenas no SQL textual.
Existem questões envolvendo:
número de páginas;
organização dos dados;
índices;
clustering;
seletividade;
Buffer Pool;
I/O;
estatísticas.
Spock talvez acrescentasse:
— Confundir linha lógica com armazenamento físico seria ilógico.
O DBA responderia:
— Finalmente alguém me entende.
6. Table Space — onde a tabela mora
Uma tabela Db2 precisa viver em uma estrutura apropriada de armazenamento.
Entra o Table Space.
Podemos visualizar:
DATABASE
│
├── TABLE SPACE
│ │
│ └── TABLE
│
└── INDEX SPACE
│
└── INDEX
Aqui vale uma distinção importante.
Table Space e Index Space não são exatamente a mesma coisa.
A tabela reside no Table Space.
O índice possui sua própria estrutura associada.
Essa diferença aparece bastante quando começamos a estudar:
utilities;
administração;
recovery;
reorganização;
performance.
7. Índice — o tricorder do Db2
Imagine um arquivo com 20 milhões de clientes.
Você quer:
SELECT *
FROM CLIENTE
WHERE CPF = '12345678900';
Sem um caminho adequado, o Db2 pode precisar examinar uma grande quantidade de dados.
Com um índice apropriado:
CPF procurado
↓
ÍNDICE
↓
localização das páginas
↓
dados
Parece maravilhoso.
E é.
Mas existe uma regra que iniciantes aprendem um pouco depois:
índice não é almoço grátis.
Cada índice pode representar:
Criar índice para absolutamente tudo seria como equipar cada tripulante da Enterprise com quinze tricorders.
Em algum momento alguém precisa carregar aquilo.
8. O Optimizer — Spock trabalhando dentro do Db2
Talvez nenhum componente mereça mais o título de “Mr. Spock interno” do que o optimizer.
Você escreve:
SELECT C.NOME,
P.VALOR
FROM CLIENTE C
JOIN PAGAMENTO P
ON P.ID_CLIENTE = C.ID_CLIENTE
WHERE C.UF = 'SP';
Você disse o que deseja.
Mas existe mais de uma maneira de conseguir aquilo.
O Db2 pode precisar decidir:
Esse conjunto de decisões produz o chamado access path.
Simplificando:
SQL
↓
Optimizer
↓
estatísticas
↓
custos estimados
↓
Access Path
↓
execução
É por isso que dois SQLs que entregam exatamente o mesmo resultado podem ter performances completamente diferentes.
9. RUNSTATS — não mande Spock calcular com sensores quebrados
O optimizer precisa tomar decisões.
Mas baseado em quê?
Em informações sobre os objetos e os dados.
Entram aí as statistics.
Imagine esta distribuição:
CLIENTE
SP = 5.000.000
RJ = 2.000.000
MG = 1.500.000
AC = 30.000
RR = 20.000
Agora compare:
WHERE UF = 'SP'
com:
WHERE UF = 'RR'
A seletividade pode ser radicalmente diferente.
O optimizer precisa ter noção disso.
Ferramentas como RUNSTATS ajudam a coletar estatísticas utilizadas nas decisões de otimização.
Metáfora Bellacosa
Imagine Spock calculando a rota até Vulcano.
Mas você fornece um mapa feito antes da construção das últimas cinquenta colônias.
Ele continua sendo brilhante.
Só está usando informação ruim.
Em banco de dados:
optimizer bom + estatística ruim = possibilidade de access path ruim.
Por isso performance não é apenas:
— “Reescreve esse SELECT.”
Às vezes o SQL estava perfeitamente aceitável.
O ambiente é que mudou.
10. EDM Pool — aquilo que não queremos reconstruir a toda hora
Outro componente importante é o EDM Pool — Environmental Descriptor Manager Pool.
Ele mantém estruturas importantes usadas pelo Db2, incluindo informações relacionadas a packages e estruturas de execução.
O conceito pedagógico é simples:
aquilo que custa processamento para construir pode ser vantajoso manter disponível em memória.
Não confunda EDM Pool com Buffer Pool.
O Buffer Pool trabalha fortemente com páginas de dados e índices.
O EDM Pool está associado a outras estruturas internas necessárias à execução.
Mas ambos ilustram uma obsessão saudável de sistemas de alta performance:
evitar trabalho desnecessário.
11. IRLM — ninguém toca nesse registro sem conversar com o segurança
Chegamos ao IRLM — Internal Resource Lock Manager.
O problema que ele ajuda a resolver é clássico.
Imagine:
Programa A
UPDATE CONTA
SET SALDO = 500
WHERE CONTA = 100;
Programa B
simultaneamente:
UPDATE CONTA
SET SALDO = 800
WHERE CONTA = 100;
Quem ganha?
Quem espera?
Quem pode ler?
Em qual momento?
Que isolamento estamos usando?
Sem controle de concorrência, banco de dados financeiro viraria bingo.
O IRLM participa do gerenciamento de locks.
Podemos pensar:
Programa A ─────┐
├── IRLM ── recurso
Programa B ─────┘
Locks existem para preservar consistência em ambientes concorrentes.
E ambiente mainframe costuma ser sinônimo de concorrência em escala bastante séria.
12. Deadlock — quando dois oficiais se recusam a sair da porta
Considere:
Programa A tem recurso X
Programa B tem recurso Y
Agora:
A precisa de Y
B precisa de X
Resultado:
A ───── espera por Y
↑ │
│ ↓
X espera por ───── B
Temos um deadlock.
Os dois ficariam esperando eternamente se o sistema não identificasse a situação.
O Db2 precisa detectar o problema e selecionar uma unidade de trabalho para ser interrompida.
Dica para COBOL iniciante
Quando ocorrer erro associado a deadlock ou timeout, não trate imediatamente como:
“Db2 caiu.”
Não.
Na maioria das vezes Db2 está vivíssimo.
Talvez vivo até demais.
Está protegendo a consistência contra seus programas.
13. LOCK não é LATCH
Esse é um pequeno easter egg técnico para quando você estiver conversando com alguém mais experiente.
Lock e latch não são sinônimos.
Locks estão fortemente associados ao controle lógico/transacional de concorrência.
Latches são mecanismos internos de serialização mais leves usados para proteger determinadas estruturas internas.
Portanto quando alguém disser:
— Temos contenção.
Pergunte:
— Que tipo?
Você ganhará pelo menos +3 pontos de experiência mainframe.
Talvez até um café.
14. Logs — a caixa-preta da Enterprise
Agora entramos em uma das áreas mais importantes do Db2.
Imagine:
UPDATE CONTA
SET SALDO = SALDO - 100
WHERE NUM_CONTA = 123;
Uma alteração aconteceu.
O sistema precisa ter capacidade de preservar consistência e recuperar-se de falhas.
Por isso existe toda uma arquitetura de logging.
Em uma visão simplificada:
alteração
↓
Log Buffer
↓
Active Logs
↓
Archive Logs
Os logs guardam informações fundamentais para:
Sem logs, um banco corporativo seria praticamente um caderno escrito a lápis durante um terremoto.
15. COMMIT — quatro letras e uma enorme responsabilidade
No COBOL:
EXEC SQL
UPDATE CONTA
SET SALDO = :WS-NOVO-SALDO
WHERE NUM_CONTA = :WS-CONTA
END-EXEC.
EXEC SQL
COMMIT
END-EXEC.
COMMIT não significa simplesmente:
“terminei.”
Ele marca uma fronteira transacional importante.
Imagine:
UPDATE
INSERT
DELETE
UPDATE
↓
COMMIT
A unidade de trabalho foi confirmada.
O gerenciamento correto de commit é particularmente importante em batch.
Por quê?
Imagine processar cinco milhões de registros e só dar COMMIT no final.
Isso pode aumentar:
Por outro lado, dar COMMIT a cada registro também pode ser inadequado.
A frequência de commit deve ser desenhada conscientemente.
Não existe “número mágico universal”.
16. ACID — as quatro leis de Vulcano das transações
O Db2 trabalha sob princípios transacionais tradicionalmente descritos pela sigla ACID.
Atomicity
Ou a unidade de trabalho ocorre adequadamente ou precisamos impedir resultado parcial inconsistente.
Consistency
O banco deve passar de um estado válido para outro.
Isolation
Transações concorrentes precisam coexistir de forma controlada.
Durability
Depois de confirmado, o resultado deve sobreviver conforme as garantias do sistema.
Considere uma transferência:
Conta Kirk -100
Conta Spock +100
O universo proibido seria:
Conta Kirk -100
💥 falha
Conta Spock +0
O dinheiro sumiu em algum buraco de minhoca.
O banco central provavelmente não aceitaria “anomalia espaço-temporal” como justificativa.
17. Active Log, Archive Log e a arte de voltar no tempo sem DeLorean
Os Active Logs participam diretamente das operações correntes de logging do Db2.
Com o avanço do processamento, parte dessas informações pode ser arquivada em Archive Logs.
Conceitualmente:
atividade recente
↓
Active Logs
↓
arquivamento
↓
Archive Logs
Essa arquitetura é um dos pilares das capacidades de recovery.
E aqui entra outro personagem importante.
18. IMAGE COPY — a fotografia antes da tempestade
Uma Image Copy funciona como uma cópia utilizada em estratégias de recuperação dos objetos Db2.
Imagine:
00:00
IMAGE COPY
│
│ logs
│ logs
│ logs
│
13:42
falha
Dependendo da estratégia e do cenário, combinamos:
IMAGE COPY
+
LOGS
+
procedimento de recovery
para reconstruir o estado necessário.
Isso é muito mais sofisticado do que aquela frase genérica:
“Restauramos o backup.”
Em ambientes grandes, recovery é ciência.
19. Catalog — o cartório galáctico
Imagine que você cria:
CREATE TABLE PLANETA
(
ID_PLANETA INTEGER,
NOME VARCHAR(80),
QUADRANTE CHAR(1)
);
Db2 precisa saber:
que a tabela existe;
quais colunas existem;
seus tipos;
seus índices;
seus relacionamentos;
tablespace;
authorities;
estatísticas;
dependências.
Essas informações vivem no universo do Db2 Catalog.
A metáfora é simples:
Os dados são cidadãos.
O Catalog é o cartório.
Quer saber sobre determinado objeto?
Frequentemente você consulta tabelas do catálogo.
20. Directory — o compartimento em que Spock recomenda não mexer sem motivo
Além do Catalog existe o Db2 Directory.
São estruturas internas essenciais ao próprio funcionamento do Db2.
Uma distinção simplificada:
CATALOG
→ metadados administrativos acessíveis
DIRECTORY
→ estruturas internas do próprio Db2
Não trate os dois termos como sinônimos.
É uma daquelas diferenças que parece acadêmica no começo.
Depois você começa a estudar internals e percebe por que existia.
21. DDF — o momento em que o mainframe abre as portas da nave
Db2 for z/OS não serve apenas a COBOL rodando dentro do próprio mainframe.
Aplicações externas podem acessar Db2 utilizando DDF — Distributed Data Facility.
Por exemplo:
Java
Python
.NET
Linux
Windows
Cloud
│
↓
DRDA
↓
TCP/IP
↓
DDF
↓
Db2 for z/OS
Isso destrói outro mito antigo:
“Mainframe é uma ilha.”
Há décadas não é.
O mainframe moderno pode conversar com praticamente o ecossistema corporativo inteiro.
22. DRDA — o diplomata entre mundos relacionais
DRDA — Distributed Relational Database Architecture fornece mecanismos padronizados para acesso distribuído a bancos relacionais.
Você pode imaginar:
Aplicação externa
↓
Driver
↓
DRDA
↓
TCP/IP
↓
DDF
↓
Db2
Ou seja, aquele programa Java no Kubernetes pode estar consultando informações que no final vivem no Db2 for z/OS.
O desenvolvedor Java talvez nem saiba.
E em muitos casos nem precisa saber.
Mas o arquiteto deveria.
23. COBOL + CICS + Db2 — o triângulo clássico
Agora voltamos à nossa velha sala de produção.
Um caminho clássico:
usuário
↓
CICS
↓
Programa COBOL
↓
SQL
↓
Db2
No programa:
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTA
WHERE NUM_CONTA = :WS-CONTA
END-EXEC.
Parece natural.
Mas como o SQL foi parar dentro daquele programa executável?
Aí vem uma parte fundamental que muitos cursos passam rápido demais.
24. PRECOMPILE — COBOL e SQL precisam conversar
COBOL puro não interpreta nativamente aquele EXEC SQL.
Existe uma etapa de preparação.
De forma tradicional e simplificada:
Fonte COBOL + SQL
↓
PRECOMPILER
┌─┴─────────────┐
↓ ↓
COBOL modificado DBRM
↓ ↓
Compiler BIND
↓ ↓
Object Package
↓
Link
↓
Load Module
O precompiler identifica instruções SQL e prepara os elementos necessários para o processamento posterior.
Esse fluxo explica por que desenvolvimento COBOL + Db2 envolve muito mais que:
compilar
executar
25. DBRM e PACKAGE — o que Spock realmente queria encontrar
O DBRM guarda informações extraídas das instruções SQL durante a preparação.
Posteriormente ocorre o BIND.
O BIND gera estruturas como packages utilizadas pela execução.
Simplificando:
SQL
↓
DBRM
↓
BIND
↓
PACKAGE
↓
Access Path
O package é extremamente importante.
Porque o programa COBOL pode continuar exatamente igual enquanto o comportamento do SQL muda por razões relacionadas a:
rebind;
novas estatísticas;
novos índices;
alteração do ambiente;
manutenção;
mudança de release;
access path diferente.
Essa é uma das primeiras grandes revelações para quem trabalha com performance.
Código-fonte igual não significa necessariamente comportamento operacional idêntico.
26. BIND — o casamento arranjado entre SQL e Db2
O BIND é uma etapa fundamental da vida do SQL estático.
É quando informações do DBRM são utilizadas para produzir um package.
E ali são tomadas decisões importantíssimas.
Se você aprende apenas a programar:
EXEC SQL ...
mas não aprende:
package;
bind;
rebind;
access path;
você aprendeu a dirigir, mas nunca abriu o capô.
Serve.
Até o carro começar a fazer barulho.
27. O verdadeiro caminho de um SELECT
Nosso jovem programador agora olha novamente para:
SELECT SALDO
FROM CONTA
WHERE NUM_CONTA = :WS-CONTA;
Mas depois da aula de Spock ele já enxerga outra coisa:
COBOL
↓
CICS
↓
Thread Db2
↓
Package
↓
Access Path
↓
Index?
↓
Buffer Pool
↓
Página disponível?
├── SIM → usa memória
└── NÃO → solicita I/O
↓
Storage
↓
Buffer Pool
↓
Db2
↓
COBOL
Aquela linha de SQL agora parece uma missão espacial inteira.
E é exatamente essa mudança de percepção que diferencia alguém que apenas escreve SQL de alguém que começa a compreender o Db2.
28. DFSMS — quando descobrimos que storage também faz parte do banco
Db2 não administra storage em um vácuo.
No z/OS existe integração com o universo do DFSMS — Data Facility Storage Management Subsystem.
Entram conceitos como:
datasets;
volumes;
storage classes;
management classes;
data classes;
políticas SMS;
VSAM.
Esse ponto é profundamente “mainframe”.
Em plataformas mais simples, desenvolvedor e banco às vezes parecem universos separados do storage.
No z/OS, você começa a perceber que:
banco
+
storage
+
sistema operacional
+
segurança
+
workload management
formam uma arquitetura integrada.
29. E então aparece VSAM escondido atrás da cortina
Essa curiosidade normalmente surpreende o iniciante.
Db2 for z/OS utiliza infraestrutura de armazenamento associada ao ecossistema VSAM para seus datasets.
Então podemos desenhar:
Db2 object
↓
Table Space
↓
datasets
↓
VSAM / DFSMS
↓
storage
Mas atenção:
Isso NÃO significa que Db2 seja simplesmente “um VSAM com SQL”.
Db2 acrescenta um universo inteiro:
modelo relacional;
SQL;
optimizer;
locking;
logging;
recovery;
catálogo;
integridade;
transações.
VSAM e Db2 possuem propósitos e abstrações diferentes.
30. RACF — nem Spock acessa folha de pagamento sem autorização
Agora imagine:
SELECT *
FROM FOLHA_PAGAMENTO;
Tecnicamente válido.
Mas deveria qualquer programa poder executá-lo?
Claro que não.
Entram mecanismos de segurança do ambiente, incluindo integração com RACF e os mecanismos de autorização do próprio Db2.
A regra fundamental:
SQL válido
≠
SQL autorizado
E ainda bem.
Imagine um estagiário descobrindo:
SELECT *
FROM SALARIOS_DIRETORIA;
e dizendo:
— Funcionou no desenvolvimento.
Produção:
ICH408I
O RACF entra em cena como o segurança vulcano:
— Seu entusiasmo não constitui autorização.
31. WLM — todos são iguais, mas alguns workloads precisam responder em 100 milissegundos
Outro componente importante do ecossistema é o WLM — Workload Manager.
O z/OS pode administrar workloads conforme objetivos definidos.
Imagine simultaneamente:
Transação PIX
Consulta de saldo
Batch de faturamento
Relatório gerencial
Backup
Compilação
Job de teste
Todos querem CPU.
Todos acham que são importantes.
Alguns realmente são.
WLM ajuda o sistema a priorizar recursos conforme políticas de serviço.
Pense nele como o oficial de operações da ponte:
“Essa transação é crítica.”
“Esse relatório pode esperar.”
“Esse batch precisa terminar antes das 06:00.”
É uma das grandes razões pelas quais mainframes conseguem misturar workloads muito distintos de forma eficiente.
32. MQ, CICS, TCP/IP e companhia — Db2 nunca esteve sozinho
Observe uma arquitetura corporativa típica:
Mobile
↓
API
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
Ao lado:
COBOL
↓
MQ
↓
sistema externo
Com:
RACF → segurança
WLM → prioridades
DFSMS → storage
TCP/IP → comunicação
JES → batch
O segredo do mainframe nunca foi um único produto.
É a integração.
Isso vale para Db2 também.
33. Parallel Sysplex — quando uma Enterprise deixa de ser suficiente
Agora entramos em território mais avançado.
Em ambientes de altíssima disponibilidade, Db2 pode operar em configuração de Data Sharing, dentro do universo do Parallel Sysplex.
Imagine:
Aplicações
│
┌─────────┼─────────┐
↓ ↓ ↓
DB2A DB2B DB2C
│ │ │
└─────────┼─────────┘
↓
dados compartilhados
Vários membros Db2 podem trabalhar cooperativamente.
Isso proporciona benefícios associados a:
Mas surge um problema lógico.
Se DB2A e DB2B acessam os mesmos dados:
Como garantir coerência?
Excelente pergunta, jovem cadete.
34. Coupling Facility e Group Buffer Pool
No Data Sharing entram estruturas disponibilizadas através da Coupling Facility.
Entre elas aparecem mecanismos relacionados a Group Buffer Pools e coordenação entre membros.
Simplificando:
DB2A DB2B
│ │
Buffer Pool Buffer Pool
│ │
└──────────┐ ┌──────────┘
↓ ↓
Coupling Facility
│
Group Buffer Pool
Se vários membros acessam os mesmos dados, precisamos impedir que cada um viva numa realidade alternativa.
Afinal, nem Star Trek resolve consistência eventual com universo paralelo em folha de pagamento.
35. O programa funciona, mas está lento. E agora?
Este é um dos momentos mais importantes da carreira.
Iniciante:
“O SQL está lento.”
Profissional experiente:
“Vamos descobrir por quê.”
Possibilidades:
SQL ruim
estatísticas inadequadas
índice ausente
índice inadequado
access path diferente
muito I/O
Buffer Pool pressionado
contenção
locks
volume de dados cresceu
commit inadequado
CPU
storage
DDF
rede
WLM
Percebe a diferença?
Performance não é adivinhação.
É investigação.
Mr. Spock aprovaria.
36. Checklist Bellacosa para o COBOL iniciante
Quando um SQL apresentar problema, pergunte nesta ordem aproximada:
O SQL está logicamente correto?
Quantas linhas deveriam retornar?
Quantas realmente retornam?
Existe índice apropriado?
Qual access path está sendo usado?
As estatísticas estão atualizadas?
Houve REBIND recentemente?
O volume de dados mudou?
Existe contenção?
Existe timeout ou deadlock?
O programa está dando commits adequadamente?
O problema acontece sempre ou apenas em horários específicos?
É batch, CICS ou acesso distribuído?
Existe pressão de CPU ou I/O?
Houve mudança no ambiente?
Já percebeu que:
“Está lento porque Db2 está lento”
é praticamente uma não-explicação.
37. O easter egg do SQLCODE
Todo programador COBOL conhece algum momento assim:
IF SQLCODE NOT = 0
DISPLAY 'ERRO DB2'
END-IF
Spock vê isso.
Fica silencioso durante oito segundos.
Depois diz:
— Fascinante. Você descartou todas as informações diagnósticas e preservou apenas o fato de que algo ocorreu.
Não seja esse programador.
SQLCODE é começo de diagnóstico.
Não fim.
Considere também as informações disponibilizadas por SQLCA e mecanismos apropriados de diagnóstico.
A mensagem:
ERRO DB2
é quase equivalente a chamar a manutenção dizendo:
“A máquina não está normal.”
Boa sorte.
38. Segundo easter egg: SELECT *
Spock observa:
SELECT *
FROM CLIENTE;
— Por que você deseja todas as colunas?
— Porque é mais fácil.
— Essa justificativa não parece relacionada à necessidade funcional.
Silêncio.
SELECT * pode ser conveniente em testes.
Em aplicação profissional, pense nas colunas realmente necessárias.
Isso melhora:
Escreva o que precisa.
Não o que seus dedos acharam mais curto.
39. Terceiro easter egg: COMMIT dentro do loop sem pensar
Outro clássico:
PERFORM UNTIL EOF
...
EXEC SQL
UPDATE ...
END-EXEC
EXEC SQL
COMMIT
END-EXEC
END-PERFORM
Talvez seja correto.
Talvez seja horrível.
Depende.
A pergunta certa não é:
“Posso dar COMMIT aqui?”
É:
“Qual unidade de trabalho faz sentido para esse processo?”
Em batch, estratégia de commit precisa considerar:
restart;
volume;
locking;
recuperação;
consistência;
desempenho.
40. A diferença entre saber SQL e saber Db2
Este talvez seja o ponto mais importante do artigo.
Conhecer:
SELECT
INSERT
UPDATE
DELETE
JOIN
GROUP BY
é conhecer SQL.
Essencial.
Mas conhecer Db2 for z/OS envolve também:
Subsystem
DBM1
MSTR
IRLM
DDF
Buffer Pool
EDM Pool
Table Space
Index Space
Catalog
Directory
Package
DBRM
BIND
Access Path
RUNSTATS
Logs
Recovery
Image Copy
DFSMS
RACF
WLM
Data Sharing
Parallel Sysplex
É outro nível de entendimento.
E você não precisa aprender tudo no primeiro mês.
Apenas precisa saber que essas camadas existem.
41. Um caminho de estudo em sete missões
Se eu estivesse orientando um programador COBOL iniciante, faria assim.
Missão 1 — SQL
Aprenda bem:
SELECT
INSERT
UPDATE
DELETE
JOIN
CURSOR
NULL
SQLCODE
Missão 2 — COBOL + Db2
Entenda:
host variables
SQLCA
cursor
commit
rollback
Missão 3 — preparação
Estude:
Precompile
DBRM
Bind
Package
Plan
Missão 4 — armazenamento
Estude:
Table Space
Index
Page
Buffer Pool
Missão 5 — optimizer
Estude:
Access Path
RUNSTATS
EXPLAIN
seletividade
cardinalidade
Missão 6 — concorrência
Estude:
Lock
Timeout
Deadlock
Isolation
Commit
Missão 7 — arquitetura z/OS
Finalmente:
IRLM
DDF
DFSMS
RACF
WLM
Logs
Recovery
Data Sharing
Quando terminar isso, volte à Missão 1.
Você descobrirá que seu antigo SELECT mudou completamente.
42. A grande revelação
Nosso programador volta finalmente ao código:
EXEC SQL
SELECT NOME,
SALDO
INTO :WS-NOME,
:WS-SALDO
FROM CLIENTE
WHERE CONTA = :WS-CONTA
END-EXEC.
Antes ele via:
“Busca o saldo.”
Agora enxerga:
Aplicação
↓
contexto Db2
↓
Package
↓
Access Path
↓
Optimizer
↓
Statistics
↓
Index
↓
Buffer Pool
↓
Page
↓
possível I/O
↓
Storage
↓
controle transacional
↓
segurança
↓
resultado
Ele olha para Spock.
— Então nunca foi “só um SELECT”.
Spock responde:
— Correto.
— E tudo isso acontece para devolver duas colunas?
— Correto.
— Isso é completamente insano.
Spock levanta novamente a sobrancelha.
— Eu escolheria a palavra “engenharia”.
Epílogo — Vida longa ao Db2
Existe uma tendência natural de ensinar mainframe de fora para dentro.
Primeiro mostramos:
IDENTIFICATION DIVISION.
Depois:
EXEC SQL.
Depois CICS.
Depois JCL.
Está correto.
O problema é quando o aprendizado para ali.
Um profissional começa realmente a amadurecer quando pergunta:
O que existe atrás dessa instrução?
Db2 é um ótimo exemplo.
Por trás do humilde:
SELECT SALDO
existe uma arquitetura desenhada para funcionar em ambientes nos quais:
milhões de transações podem acontecer;
múltiplas aplicações disputam recursos;
dados precisam permanecer consistentes;
falhas precisam ser recuperáveis;
workloads críticos têm prioridade;
segurança precisa ser auditável;
sistemas externos precisam acessar dados;
operações precisam continuar durante enormes cargas.
É por isso que Db2 for z/OS não deve ser estudado apenas como linguagem SQL.
Ele deve ser entendido como parte de uma arquitetura transacional completa.
Buffer Pool ensina que memória é estratégia.
IRLM ensina que concorrência precisa de disciplina.
RUNSTATS ensina que inteligência depende de boas informações.
Logs ensinam que sobreviver ao desastre é tão importante quanto evitar o desastre.
RACF ensina que capacidade técnica não significa autorização.
WLM ensina que nem todo trabalho possui a mesma urgência.
DDF ensina que mainframe não é uma ilha.
Parallel Sysplex ensina que alta disponibilidade é uma arquitetura, não uma frase de marketing.
E o humble COBOL programador aprende finalmente uma verdade que acompanha muita gente durante décadas de carreira:
quanto mais você entende o que existe abaixo do seu programa, melhores ficam as decisões que você toma acima dele.
Spock deixou o CPD pouco antes das três da manhã.
Na saída, encontrou o operador.
— O senhor está indo embora?
— Acredito que meu trabalho aqui terminou.
— E o garoto?
Spock olhou através do vidro para o programador, que naquele momento pesquisava access path, Buffer Pool e RUNSTATS enquanto sua caneca de café esfriava ao lado do terminal.
— Ele cometeu um erro comum.
— Qual?
— Pensou que estava aprendendo apenas COBOL.
Spock fez uma pequena pausa.
— Agora começou a aprender sistemas.
O elevador fechou.
No monitor apareceu:
DSN SYSTEM(...)
Depois:
READY
E em algum lugar profundamente dentro do z/OS, um Buffer Pool continuou recebendo páginas, o IRLM continuou arbitrando recursos, os logs continuaram registrando transações e o velho Db2 fez aquilo que vem fazendo há décadas:
carregar boa parte do mundo corporativo nas costas sem exigir que o usuário saiba quantas maravilhas estavam acontecendo atrás de um simples SELECT.
🖖 Vida longa, prosperidade e um access path decente.
