 |
| Bellacosa Mainframe apresenta DBMS |
☕ Um Café no Bellacosa Mainframe
🐒 Detetive Chimp e o Mistério do Banco de Dados que Jurava Ser Consistente
DBMS, modelagem ER, SQL, normalização, índices, ACID, locks, concorrência, COMMIT, ROLLBACK e recovery investigados por um detetive que sabe que os dados sempre deixam pistas
Há uma coisa que aprendi observando sistemas durante muito tempo: quando um programa diz que “não fez nada”, comece procurando o log.
Quando um usuário afirma que “clicou apenas uma vez”, procure duas transações.
Quando uma aplicação garante que “ninguém alterou aquele registro”, procure um UPDATE.
E quando um banco de dados afirma que está tudo consistente...
...chame o Detetive Chimp.
Nosso investigador chega ao data center usando seu tradicional chapéu, examina o terminal 3270 e encontra a primeira pista:
03:17:00.001 TRANSACTION T1
03:17:00.003 TRANSACTION T2Dois milissegundos.
Uma diferença ridiculamente pequena para um humano.
Uma eternidade para um computador.
Sobre a mesa há ainda cinco folhas intituladas DBMS Quick Revision Sheet. Elas falam de DBMS, ER Model, SQL, normalização, ACID, transações, concorrência e índices.
Chimp olha para aquilo.
— Interessante.
Acende seu cachimbo imaginário.
— Temos vários suspeitos.
E assim começa nosso caso.
🕵️ CAPÍTULO 1 — O cadáver era um banco de dados
Antes de investigar o crime precisamos entender a vítima.
DBMS significa:
Database Management System — Sistema Gerenciador de Banco de Dados.
Para o iniciante, é tentador pensar:
banco de dados = lugar onde guardamos informações.
Não está errado.
Mas é tão incompleto quanto dizer que um aeroporto é um lugar onde estacionamos aviões.
Um DBMS precisa armazenar, organizar, localizar, proteger, compartilhar, alterar e recuperar dados, além de arbitrar o que acontece quando diversos usuários tentam mexer neles simultaneamente.
Imagine:
USUÁRIOS
│
▼
┌─────────────┐
│ APLICAÇÕES │
└──────┬──────┘
│
▼
┌─────────────┐
│ DBMS │
└──────┬──────┘
│
▼
┌─────────────┐
│ DADOS │
└─────────────┘O DBMS fica entre as aplicações e os dados.
Mas Detetive Chimp imediatamente acrescentaria vários departamentos escondidos naquele retângulo:
DBMS
│
┌────────────┼─────────────┐
│ │ │
SQL Segurança Transações
│ │ │
Optimizer Controle Logging
│ │
Access Path Recovery
│
StorageÉ uma pequena cidade funcionando atrás de uma palavra de quatro letras.
🐒 CAPÍTULO 2 — O primeiro suspeito: SQL
Chimp encontra uma consulta:
SELECT NOME, LIMITE
FROM CLIENTE
WHERE CPF = :WS-CPF;— Parece inocente.
O programador COBOL iniciante concorda.
Chimp continua:
— É exatamente por isso que devemos investigá-la.
SQL é uma linguagem declarativa.
Quando escrevemos:
SELECT NOME
FROM CLIENTE
WHERE CPF = '123';estamos essencialmente dizendo:
“Db2, quero o nome do cliente cujo CPF é 123.”
Não estamos necessariamente dizendo:
“vá até determinado cilindro, encontre determinada página, leia o registro número 427...”
O DBMS precisa descobrir uma estratégia eficiente.
Simplificando:
SQL
│
▼
PARSER
│
▼
OPTIMIZER
│
▼
ACCESS PATH
│
├── INDEX?
│
├── SCAN?
│
└── JOIN?
│
▼
DADOSAqui aparece um personagem que aquelas folhas introdutórias mal conseguem explorar: o optimizer.
Ele analisa possibilidades para executar a consulta.
Portanto, duas consultas SQL que produzem resultados semelhantes podem apresentar comportamentos de performance radicalmente diferentes.
Saber escrever SQL é uma habilidade.
Entender como o banco chega aos dados é outra.
🧩 CAPÍTULO 3 — Antes do banco havia o mundo real
Chimp desenha três objetos no quadro:
CLIENTE
CONTA
TRANSAÇÃOAntes de existir tabela, índice ou SELECT, alguém precisou transformar uma realidade de negócio em um modelo de dados.
É aí que entra o ER Model — Entity Relationship Model.
Temos três conceitos fundamentais:
ENTITY
ATTRIBUTE
RELATIONSHIPUma entidade pode ser:
CLIENTESeus atributos:
ID_CLIENTE
CPF
NOME
DATA_NASCIMENTOOutra entidade:
CONTACom:
ID_CONTA
AGENCIA
SALDOExiste então uma relação:
CLIENTE ───── POSSUI ───── CONTAUm cliente pode possuir várias contas.
Podemos representar:
CLIENTE 1 ───────── N CONTAChimp bate o cachimbo no quadro.
— Eis uma pista importante: muitos crimes de dados começam antes de existir código.
Um modelo ruim acaba contaminando tabelas, programas, APIs, relatórios e integrações.
🔑 CAPÍTULO 4 — O caso das chaves desaparecidas
A apostila apresenta:
Super Key, Candidate Key, Primary Key, Alternate Key e Foreign Key.
Parece matéria de prova.
Não é.
Imagine:
CLIENTE
-----------------------
ID_CLIENTE
CPF
NOMEEscolhemos:
ID_CLIENTE → PRIMARY KEYOutra tabela:
CONTA
-----------------------
ID_CONTA
ID_CLIENTE
SALDOAqui:
ID_CONTA → PRIMARY KEY
ID_CLIENTE → FOREIGN KEYAgora existe uma relação:
CLIENTE
ID_CLIENTE
│
│
▼
CONTA
ID_CLIENTEA chave estrangeira representa uma relação entre os dados.
Sem integridade adequada poderíamos encontrar:
CONTA 999999
CLIENTE 777777mas descobrir que:
CLIENTE 777777não existe.
Chimp imediatamente pergunta:
— Então de quem é essa conta?
Silêncio no data center.
Temos um órfão de dados.
🧹 CAPÍTULO 5 — Normalização: arrumando a cena do crime
Agora encontramos uma tabela criada por alguém numa sexta-feira às 17:58:
PEDIDO
---------------------------------
CLIENTE
ENDERECO
PRODUTO1
PRECO1
PRODUTO2
PRECO2
PRODUTO3
PRECO3Chimp olha horrorizado.
— Quem fez isso?
Ninguém responde.
Naturalmente.
A normalização procura organizar estruturas de dados reduzindo redundâncias e dependências problemáticas.
A apostila percorre:
1NF
↓
2NF
↓
3NF
↓
BCNFUma modelagem mais organizada poderia resultar em:
CLIENTE
│
│
▼
PEDIDO
│
│
▼
ITEM_PEDIDO
│
│
▼
PRODUTOIsso reduz problemas clássicos de:
INSERT
UPDATE
DELETEImagine armazenarmos o endereço do cliente repetidamente em 30 mil pedidos.
Ele muda de endereço.
Quantas ocorrências precisam ser alteradas?
Esse tipo de redundância é terreno fértil para inconsistência.
Mas Chimp deixa uma observação importante no relatório:
Normalização é ferramenta de engenharia, não religião.
Projetos reais também consideram performance, padrões de acesso, volume, frequência de atualização e características específicas do workload.
🏦 CAPÍTULO 6 — Finalmente encontramos o dinheiro
Agora o caso fica sério.
Temos:
CONTA A = R$ 1.000
CONTA B = R$ 500Queremos transferir:
R$ 100Conceitualmente:
A = A - 100
B = B + 100Depois:
A = 900
B = 600Perfeito.
Um programa COBOL poderia executar uma sequência equivalente a:
LER A
SUBTRAIR 100
UPDATE A
LER B
SOMAR 100
UPDATE BMas Chimp coloca uma banana exatamente entre os dois updates.
UPDATE A
│
▼
A = 900
💥 ABEND S0C7
UPDATE B
│
XAgora temos:
A = 900
B = 500Os R$100 desapareceram.
Não foram transferidos.
Foram sacrificados aos deuses do processamento de dados.
É aqui que surge um dos conceitos mais importantes de toda a apostila:
TRANSACTION
🔄 CAPÍTULO 7 — A transação é o verdadeiro suspeito
Uma transação representa uma unidade lógica de trabalho.
Queremos que:
DEBITAR A
CREDITAR Bsejam tratados como parte de uma operação coerente.
Conceitualmente:
┌──── UNIT OF WORK ─────┐
│ │
│ UPDATE A │
│ UPDATE B │
│ │
│ COMMIT │
│ │
└───────────────────────┘Se tudo funcionar:
COMMITSe alguma coisa der errado antes da confirmação apropriada:
ROLLBACKChimp sorri.
— Agora encontramos o mecanismo que impede o dinheiro de desaparecer.
Mas ainda não resolvemos o crime.
Porque existem outros usuários.
🧪 CAPÍTULO 8 — ACID entra para interrogatório
Na parede aparecem quatro letras:
A C I DNão é uma banda psicodélica de mainframe.
São propriedades fundamentais das transações.
A — Atomicity
Tudo ou nada.
A - 100
B + 100Não queremos:
A - 100 ✓
B + 100 ✗A operação lógica deve ser tratada atomicamente.
C — Consistency
Antes:
A = 1000
B = 500
TOTAL = 1500Depois:
A = 900
B = 600
TOTAL = 1500O sistema deve preservar as regras de consistência definidas para os dados.
Mas cuidado: consistência não significa que o DBMS magicamente conhece todas as regras do negócio.
Se uma regra diz:
clientes menores de determinada idade não podem contratar determinado produto,
alguém precisa expressar e implementar essa regra adequadamente.
O banco não consulta uma bola de cristal.
I — Isolation
Chimp finalmente encontra a pista decisiva.
Temos limite disponível:
R$ 1.000Duas compras chegam:
T1 → R$700
T2 → R$600Quase simultaneamente.
T1 pergunta:
LIMITE?Resposta:
1000T2 pergunta:
LIMITE?Resposta:
1000T1 pensa:
700 < 1000
APROVADOT2 pensa:
600 < 1000
APROVADOResultado:
700 + 600 = 1300Oops.
É por isso que concorrência não é detalhe acadêmico.
D — Durability
Depois que uma transação é confirmada, esperamos que sua alteração sobreviva a falhas previstas pelo mecanismo transacional.
Não queremos:
COMMITe cinco minutos depois:
“Desculpe, perdemos sua transferência.”
Logging e recovery existem justamente porque computadores, discos, processos e aplicações podem falhar.
🔐 CAPÍTULO 9 — As impressões digitais chamadas LOCKS
A apostila apresenta dois conceitos:
S LOCK
X LOCKSimplificando didaticamente:
Shared Lock permite compartilhamento compatível para determinados acessos de leitura.
Exclusive Lock protege recursos que estão sendo modificados contra acessos incompatíveis.
Chimp desenha:
TRANSACTION A
│
▼
RESOURCE
▲
│
TRANSACTION BAgora temos concorrência.
Um sistema empresarial não pode simplesmente dizer:
“Só uma pessoa pode usar o banco por vez.”
Imagine um banco com milhões de clientes operando assim.
CLIENTE 1 → terminou?
CLIENTE 2 → pode entrar.
CLIENTE 3 → espere.
CLIENTE 4 → senha 493827.😂
Precisamos permitir enorme paralelismo enquanto preservamos integridade.
Esse é um dos grandes desafios do DBMS.
💀 CAPÍTULO 10 — Deadlock: encontramos dois cadáveres
Chimp encontra:
T1 possui LOCK A
T2 possui LOCK BDepois:
T1 precisa de B
T2 precisa de AVisualmente:
espera
┌──────────────►
│
T1 T2
▲ │
◄───────────────┘
esperaParabéns.
Criamos um deadlock.
T1 espera T2.
T2 espera T1.
Nenhum resolve voluntariamente a situação.
O DBMS precisa detectar e solucionar esse tipo de conflito, normalmente escolhendo uma transação como vítima para quebrar o ciclo.
E aí o programador descobre uma lição maravilhosa:
ROLLBACK não significa necessariamente que o DBMS está quebrado.
Às vezes o rollback é justamente o mecanismo impedindo que o sistema permaneça preso.
🚦 CAPÍTULO 11 — Isolation Level: quanta privacidade você quer?
Aqui começamos a sair definitivamente da apostila de revisão e entrar na engenharia.
No Db2 encontramos níveis como:
UR
CS
RS
RRConceitualmente podemos imaginar um controle:
MAIS ISOLAMENTO
▲
│
│ proteção
│
│
│ concorrência
▼
MENOS ISOLAMENTOIsso não significa simplesmente:
“mais isolamento é melhor.”
Um sistema transacional gigantesco precisa equilibrar:
integridade
concorrência
latência
throughput
CPU
locks
tempo de respostaO programador que escolhe mecanismos de isolamento sem entender o workload está fazendo engenharia com os olhos vendados.
💾 CAPÍTULO 12 — SAVEPOINT, a máquina do tempo
Chimp encontra:
SAVEPOINT SP1— Finalmente uma testemunha inteligente.
Imagine:
PASSO A
PASSO B
PASSO C
SAVEPOINT SP1
PASSO D
PASSO E
PASSO FO passo F falha.
Dependendo da situação e do desenho da aplicação, podemos voltar a um savepoint apropriado:
A ✓
B ✓
C ✓
--- SP1 ---
D ↶
E ↶
F ↶É quase um:
SAVE GAMEdo processamento transacional.
Só não diga isso durante entrevista para DBA.
Ou diga.
Talvez ele goste.
🔎 CAPÍTULO 13 — O índice não matou ninguém... provavelmente
Chimp encontra uma tabela gigantesca:
CLIENTE
100.000.000 ROWSConsulta:
SELECT NOME
FROM CLIENTE
WHERE CPF = :CPF;Como encontramos aquele CPF?
Sem uma estrutura de acesso adequada, poderíamos ter um trabalho enorme de procura.
Com um índice apropriado:
CPF
│
▼
INDEX
│
▼
LOCALIZAÇÃO
│
▼
DADOMuito melhor.
Então surge a ideia perigosa:
“Vamos criar índice para tudo!”
Chimp imediatamente fecha o notebook.
— Não.
Índices também possuem custo.
Precisam ser armazenados e mantidos quando dados são inseridos, removidos ou alterados.
Temos novamente um compromisso:
MAIS ÍNDICES
│
├── potencial de melhores acessos
│
└── maior custo de manutenção/espaçoBanco de dados é uma sucessão de decisões de engenharia.
🧠 CAPÍTULO 14 — O verdadeiro cérebro estava escondido: Optimizer
Finalmente encontramos o personagem que faltava nas folhas.
O programador escreve:
SELECT ...
FROM CLIENTE C
JOIN CONTA A
ON C.ID_CLIENTE = A.ID_CLIENTE
WHERE C.CPF = :CPF;O DBMS precisa descobrir como executar aquilo.
Conceitualmente:
SQL
│
▼
OPTIMIZER
│
├── estatísticas
├── cardinalidade
├── índices
├── predicates
├── joins
└── estimativas
│
▼
ACCESS PATHÉ por isso que:
SQL corretonão implica necessariamente:
SQL eficienteEle pode retornar exatamente os dados solicitados e ainda assim fazer um trabalho absurdamente maior do que o necessário.
Chimp escreve no relatório:
O suspeito tinha álibi funcional, mas não tinha álibi de performance.
🏭 CAPÍTULO 15 — Agora tragam CICS, COBOL e Db2
Chegamos ao Bellacosa Mainframe.
Coloque tudo junto:
CLIENTE
│
▼
┌────────────┐
│ CICS │
└─────┬──────┘
│
▼
┌────────────┐
│ COBOL │
└─────┬──────┘
│
SQL
│
▼
┌────────────┐
│Db2 for z/OS│
└─────┬──────┘
│
┌─────────┴─────────┐
▼ ▼
INDEX DATAAgora multiplique por milhares de transações.
T000001
T000002
T000003
...
T999999Todas querem:
READ
INSERT
UPDATE
DELETE
COMMITO problema deixa de ser:
“Como salvo um cliente?”
Passa a ser:
Como milhares de operações podem alterar um universo compartilhado simultaneamente sem destruir sua coerência?
Essa pergunta explica boa parte da existência dos mecanismos transacionais.
💳 CAPÍTULO 16 — Chimp investiga uma compra de cartão
Compra:
R$100A mensagem chega ao sistema.
COMPRA
│
▼
CICS
│
▼
COBOL
│
┌────────┼─────────┐
▼ ▼ ▼
CLIENTE CARTÃO PRODUTO
│ │ │
└────────┼─────────┘
▼
LIMITE
│
▼
FRAUDE?
│
▼
AUTORIZAÇÃO
│
┌──────┴──────┐
▼ ▼
APPROVE DECLINEParece simples.
Agora chegam duas compras:
03:17:00.001 → R$700
03:17:00.003 → R$600Limite:
R$1000Eis o easter egg.
03:17.
Chimp olha para o relógio.
— Sempre é 03:17 quando algo interessante acontece no mainframe.
Dois milissegundos separam um fluxo trivial de um excelente caso de concorrência.
Agora fazem sentido:
ACID
LOCK
ISOLATION
COMMIT
ROLLBACK
LOG
RECOVERYCada palavra da apostila ganhou consequências financeiras.
🧯 CAPÍTULO 17 — “Mas funcionou no teste!”
Chimp fecha os olhos.
Essa é uma das frases favoritas do culpado.
No teste:
1 usuário
1 transação
100 registrosProdução:
10.000 usuários
milhares de transações
milhões/bilhões de registros
concorrência
timeout
deadlock
falhas
rede
batch
online
APIsO programa:
SELECT
UPDATE
COMMITfunciona maravilhosamente sozinho.
Coloque centenas de instâncias disputando os mesmos recursos e você descobrirá características que nunca apareceram no teste simplificado.
É por isso que engenharia transacional exige pensar não apenas:
MEU PROGRAMAmas:
SISTEMA
│
┌───────────┼───────────┐
▼ ▼ ▼
ONLINE BATCH APIs
│ │ │
└───────────┼───────────┘
▼
DB2Seu programa nunca está realmente sozinho.
🐒 CAPÍTULO 18 — Detetive Chimp apresenta os suspeitos
Depois de horas investigando, Chimp monta o quadro:
O CASO DBMS
│
┌───────────┼────────────┐
▼ ▼ ▼
MODELAGEM SQL TRANSAÇÃO
│ │ │
▼ ▼ ▼
ER OPTIMIZER ACID
│ │ │
▼ ▼ ▼
KEYS INDEXES LOCKING
│ │
▼ ▼
NORMALIZATION ISOLATION
│
┌────────┴────────┐
▼ ▼
COMMIT ROLLBACK
│ │
└────────┬────────┘
▼
LOG
│
▼
RECOVERYNenhum deles isoladamente matou o banco.
O problema estava na interação entre todos eles.
🎓 CAPÍTULO 19 — A trilha para o programador COBOL iniciante
Se eu transformasse aquelas cinco folhas em uma trilha de estudo, seguiria esta ordem:
Entenda DBMS e a diferença entre dado, banco e gerenciador. Depois modele entidades, atributos, relacionamentos, cardinalidades e chaves. Aprenda SQL básico —
SELECT,INSERT,UPDATE,DELETEeJOIN— e só então entre em normalização e integridade referencial.Em seguida estude transações profundamente: Unit of Work,
COMMIT,ROLLBACK,SAVEPOINTe ACID. Depois avance para concorrência, locks, isolamento, timeout e deadlock. Finalmente estude índices, optimizer, access paths, logging, backup/recovery e performance.Só então faça o exercício realmente divertido: implemente mentalmente tudo isso em COBOL + CICS + Db2, primeiro com um usuário e depois imaginando 10.000 usuários concorrentes.
Nesse ponto o estudante deixa de decorar definições e começa a pensar como engenheiro.
☕ EPÍLOGO — O banco nunca mentiu
O sol começa a nascer sobre o data center.
Chimp termina seu café.
O jovem programador pergunta:
— Então quem era o assassino?
Chimp coloca o chapéu.
— Ninguém.
— Como assim?
— O banco fez exatamente aquilo que mandaram fazer.
Silêncio.
Essa talvez seja uma das maiores lições de sistemas.
Computadores são extraordinariamente obedientes.
Se você modelar mal, eles executarão rapidamente um modelo ruim.
Se escrever uma transação incorreta, executarão corretamente a transação incorreta.
Se criar SQL ineficiente, poderão produzir exatamente o resultado esperado — lentamente.
Se esquecer concorrência, o sistema poderá funcionar perfeitamente durante meses...
...até duas transações chegarem juntas.
03:17:00.001
03:17:00.003E então você descobrirá que dois milissegundos podem revelar um erro arquitetural escondido durante anos.
Chimp deixa sobre a mesa as cinco folhas de revisão.
No começo da investigação elas diziam:
DBMS
ER MODEL
NORMALIZATION
SQL
ACID
TRANSACTION
INDEXAgora significam:
REALIDADE
↓
MODELAGEM
↓
DADOS
↓
TRANSAÇÕES
↓
CONCORRÊNCIA
↓
INTEGRIDADE
↓
RECUPERAÇÃO
↓
PERFORMANCE
↓
NEGÓCIOÉ essa a diferença entre decorar banco de dados para uma prova e compreender por que bancos, seguradoras, companhias aéreas, governos e sistemas de cartões investem tanto em engenharia transacional.
Aquelas quatro letras — ACID — parecem matéria de apostila.
Um COMMIT parece apenas um comando.
Um LOCK parece detalhe técnico.
Um índice parece somente uma maneira de procurar dados mais rapidamente.
Até o dia em que você percebe que do outro lado daqueles registros existem dinheiro, passagens, pedidos, pagamentos, estoques, contratos e pessoas.
Detetive Chimp abre a porta.
Antes de sair, olha novamente para o terminal.
READYCaso encerrado?
Claro que não.
Em mainframe sempre existe outro JOB esperando na fila.
E provavelmente existe algum programador jurando:
“Mas eu não alterei nada...”
Chimp sorri.
Procure o log. 🐒🔎☕
