Bellacosa Mainframe apresenta o ACID

☕ Um Café no Bellacosa Mainframe

🧪 PROFESSOR FARNSWORTH E AS QUATRO LEIS QUE IMPEDIAM O Db2 DE DESTRUIR O UNIVERSO

ACID, COBOL, Db2 for z/OS, COMMIT, ROLLBACK, Unit of Work, locks, IRLM, isolation levels, buffer pools, logging, recovery, CICS, deadlocks, restart — e o dia em que o Professor Farnsworth descobriu que “Good news, everyone!” não era uma estratégia válida de recuperação de banco de dados.

Sob a tutela do Professor Hubert J. Farnsworth, da Planet Express.

🎬 PRÓLOGO — BOAS NOTÍCIAS, PESSOAL!

Eram exatamente 03:17 da manhã quando o telefone tocou.

Nenhum programador COBOL experiente gosta de um telefone tocando às 03:17.

Às 08:00, telefone significa reunião.

Às 14:00, provavelmente alguém esqueceu uma vírgula no JCL.

Às 17:30, significa mudança emergencial que alguém garante ter sido "exaustivamente testada".

Mas às 03:17?

Às 03:17 significa produção.

O jovem programador levantou da cama, abriu o notebook e encontrou uma mensagem assustadora:

URGENTE

TRANSFERÊNCIA FINANCEIRA INCONSISTENTE

CONTA A = DEBITADA
CONTA B = NÃO CREDITADA

— Professor! Temos um problema!

Do fundo do laboratório surgiu uma figura de jaleco, chinelos e óculos grossos.

Professor Hubert J. Farnsworth levantou um dedo.

— Good news, everyone!

— Professor, desapareceram mil reais.

— Então talvez as notícias não sejam tão boas.

Na tela havia algo parecido com isto:

EXEC SQL
   UPDATE CONTA
      SET SALDO = SALDO - 1000
    WHERE CONTA_ID = 100
END-EXEC.

EXEC SQL
   UPDATE CONTA
      SET SALDO = SALDO + 1000
    WHERE CONTA_ID = 200
END-EXEC.

EXEC SQL
   COMMIT
END-EXEC.

O jovem programador olhou para o código.

— Parece simples.

Farnsworth sorriu.

Esse era precisamente o problema.

Porque atrás daquele pequeno COMMIT existia um universo inteiro chamado:

ACID.

🧪 CAPÍTULO 1 — AS QUATRO LEIS DO UNIVERSO TRANSACIONAL

Quem começa a estudar banco de dados encontra rapidamente a famosa sigla:

A — Atomicity
C — Consistency
I — Isolation
D — Durability

Em português:

Atomicidade
Consistência
Isolamento
Durabilidade

O resumo de bolso é:

Atomicidade  → tudo ou nada
Consistência → dados continuam válidos
Isolamento   → controlar concorrência
Durabilidade → confirmou, deve permanecer

Está correto.

Mas para quem trabalha com Db2 for z/OS, isso é apenas a porta do laboratório.

Atrás dela encontramos:

COBOL
   │
   ▼
CICS / Batch
   │
   ▼
Db2
   │
   ├── Unit of Work
   ├── COMMIT / ROLLBACK
   ├── Locks
   ├── IRLM
   ├── Isolation Levels
   ├── Buffer Pools
   ├── Logging
   ├── Checkpoints
   ├── Recovery
   └── Restart

ACID não é simplesmente uma propriedade acadêmica do banco.

É uma resposta para uma pergunta muito mais séria:

Como manter os dados confiáveis quando programas falham, máquinas param, transações concorrem e seres humanos fazem coisas que o Professor Farnsworth jamais colocaria em uma especificação?

Vamos entrar no laboratório.

⚛️ CAPÍTULO 2 — A DE ATOMICITY: NÃO EXISTE MEIA TRANSFERÊNCIA

Imagine duas contas:

CONTA A = R$ 5.000
CONTA B = R$ 3.000

Precisamos transferir:

R$ 1.000

O resultado correto é:

CONTA A = R$ 4.000
CONTA B = R$ 4.000

O programa executa:

1. debita A
2. credita B
3. registra movimento
4. COMMIT

Mas o universo não é obrigado a colaborar.

Pode acontecer:

1. debita A ............ OK
2. credita B ........... OK
3. registra movimento .. ABEND

Sem atomicidade, poderíamos terminar com um estado parcialmente processado.

E isso é exatamente o que não queremos.

Farnsworth desenharia no quadro:

          UNIT OF WORK
┌───────────────────────────────┐
│ UPDATE CONTA A               │
│ UPDATE CONTA B               │
│ INSERT MOVIMENTO             │
│                              │
│ COMMIT                       │
└───────────────────────────────┘

Essa caixa representa uma Unit of Work, ou UOW.

Ela é muito mais importante do que pensar individualmente em cada SQL.

O iniciante olha para:

UPDATE CONTA ...

O engenheiro começa a perguntar:

A qual unidade lógica de negócio esse UPDATE pertence?

Essa mudança mental é enorme.

💥 CAPÍTULO 3 — O ABEND NO MEIO DA EXPERIÊNCIA

Agora Farnsworth puxa uma enorme alavanca vermelha.

O jovem programador grita:

— Professor, o que essa alavanca faz?

CLICK.

As luzes apagam.

— Descobriremos!

Imagine que o Db2 estivesse processando:

BEGIN UOW

UPDATE A
     │
     ▼
A = 4000

UPDATE B
     │
     ▼

💥 FALHA

A transação ainda não chegou ao seu ponto de confirmação.

O banco precisa conseguir impedir que o trabalho incompleto se transforme permanentemente no novo estado lógico.

É aí que entram mecanismos como:

ROLLBACK
BACKOUT
LOGGING
RECOVERY

A ideia de atomicidade pode ser resumida assim:

             TRANSAÇÃO

                  │
          ┌───────┴───────┐
          ▼               ▼
       SUCESSO           FALHA
          │               │
          ▼               ▼
       COMMIT        ROLLBACK/BACKOUT
          │               │
          ▼               ▼
     CONFIRMADA       DESFEITA

O importante é que o banco não termine no meio do caminho lógico.

🛑 CAPÍTULO 4 — COMMIT NÃO SIGNIFICA APENAS "SALVAR"

Essa é uma das primeiras armadilhas para o programador COBOL iniciante.

Muitos aprendem:

COMMIT   = salvar
ROLLBACK = desfazer

Não está totalmente errado.

Mas é uma simplificação perigosa.

Pense no COMMIT como:

a declaração de que uma Unit of Work alcançou seu ponto de confirmação.

Portanto:

EXEC SQL
   COMMIT
END-EXEC.

não deveria ser colocado aleatoriamente no programa.

O lugar do COMMIT define fronteiras transacionais.

Imagine um batch processando dez milhões de registros.

Você poderia fazer:

registro 1
registro 2
registro 3
...
registro 10.000.000

COMMIT

Farnsworth olharia para isso e provavelmente diria:

— Excelente! Agora só precisamos esperar alguma coisa falhar no registro 9.999.999.

Uma UOW gigantesca pode trazer consequências para logging, recursos, locking, rollback, concorrência e restart.

Por isso aplicações batch frequentemente utilizam commits periódicos:

processa 1.000
COMMIT

processa 1.000
COMMIT

processa 1.000
COMMIT

Mas atenção.

Não existe um número mágico:

COMMIT A CADA 1000

que seja correto para todas as aplicações.

O intervalo depende de coisas como volume, duração, concorrência, requisitos do negócio, custo de restart e características do workload.

🔄 CAPÍTULO 5 — DEPOIS DO COMMIT NÃO EXISTE BORRACHA MÁGICA

Suponha:

Registros 1–1000
COMMIT

1001–2000
COMMIT

2001–3000
COMMIT

3001–3782
💥 ABEND

Um ROLLBACK não vai magicamente voltar ao registro 1.

As UOWs anteriores já foram confirmadas.

O programa precisa saber:

último COMMIT válido = registro 3000

E isso nos leva a um conceito importantíssimo em batch:

Restartability.

Uma aplicação bem projetada pode guardar um checkpoint lógico próprio, chave de último registro processado ou outra informação de controle adequada ao desenho.

No restart:

JOB reiniciado
      │
      ▼
consulta controle
      │
      ▼
último ponto = 3000
      │
      ▼
continua de forma segura

E surge uma nova pergunta:

Se eu executar novamente uma operação, ela produzirá o mesmo resultado ou duplicará dinheiro?

Bem-vindo ao mundo da idempotência.

ACID não resolve sozinho todos os problemas de restart da aplicação.

🧱 CAPÍTULO 6 — C DE CONSISTENCY: O Db2 NÃO CONHECE O REGULAMENTO DO PLANETA EXPRESS

Consistência significa que uma transação deve levar o banco de um estado válido para outro estado válido, respeitando as regras relevantes.

O Db2 conhece muitas regras estruturais porque nós as declaramos.

Por exemplo:

CREATE TABLE CONTA
(
    CONTA_ID INTEGER NOT NULL,
    CLIENTE_ID INTEGER NOT NULL,
    SALDO DECIMAL(15,2) NOT NULL,

    PRIMARY KEY (CONTA_ID)
);

Podemos utilizar mecanismos como:

PRIMARY KEY
FOREIGN KEY
UNIQUE
CHECK
NOT NULL

Eles ajudam a preservar integridade.

Por exemplo, uma FOREIGN KEY pode estabelecer uma relação entre conta e cliente.

Mas Farnsworth faz uma pergunta:

— O Db2 sabe que clientes marcianos recebem 15% de desconto às terças-feiras?

Não.

A menos que essa regra esteja adequadamente representada na solução, o banco não a inventará.

Temos então três mundos:

       CONSISTÊNCIA

      /      |       \
     /       |        \
    ▼        ▼         ▼

DATABASE   APLICAÇÃO   NEGÓCIO

Um valor pode ser perfeitamente válido para um DECIMAL(15,2) e completamente absurdo para a empresa.

Por exemplo:

SALDO = -999999999.99

O datatype pode aceitar.

A regra empresarial talvez não.

Portanto:

Consistência ACID não significa que o Db2 entende automaticamente todas as regras da empresa.

Essa é uma diferença pequena na frase e gigantesca na arquitetura.

👥 CAPÍTULO 7 — I DE ISOLATION: FRY E BENDER SACAM O MESMO DINHEIRO

Agora temos:

SALDO = R$ 1.000

Fry tenta sacar:

R$ 800

Bender, exatamente ao mesmo tempo, tenta sacar:

R$ 800

Imagine ingenuamente:

FRY                       BENDER

SELECT SALDO              SELECT SALDO
     │                         │
     ▼                         ▼
   1000                      1000

"Tem dinheiro!"            "Tem dinheiro!"

Agora os dois tentam continuar.

Concorrência é um dos grandes problemas que bancos de dados transacionais precisam controlar.

É aqui que Isolation começa a conversar com:

locks
IRLM
UR
CS
RS
RR
deadlocks
timeouts

🔐 CAPÍTULO 8 — IRLM: O PORTEIRO DO LABORATÓRIO

No ecossistema Db2 for z/OS aparece um personagem importantíssimo:

IRLM — Internal Resource Lock Manager.

Uma representação conceitual:

PROGRAMA A
    │
    ▼
   Db2
    │
    ▼
   IRLM
    ▲
    │
PROGRAMA B

Suponha que A esteja alterando determinado recurso e possua um lock incompatível com aquilo que B deseja fazer.

B pode precisar esperar.

A:

UPDATE CONTA 100
      │
      ▼
    LOCK
      │
      │
      │     B:
      │
      │     UPDATE CONTA 100
      │            │
      │            ▼
      │           WAIT
      │
   COMMIT
      │
      ▼
 liberação conforme
 regras aplicáveis

O usuário pode reclamar:

"O sistema está esperando!"

Mas aquela espera pode ser justamente parte do mecanismo que evita resultados transacionais incorretos.

Performance e consistência frequentemente precisam conversar.

👻 CAPÍTULO 9 — O FANTASMA DO DIRTY READ

Farnsworth altera um saldo:

T1:

1000 → 100

Mas ainda não fez COMMIT.

Outra transação lê aquele valor.

Depois T1 executa:

ROLLBACK

O saldo retorna a 1000.

A segunda transação acabou de enxergar um valor que nunca se tornou um estado confirmado.

Esse fenômeno é associado a:

Dirty Read.

Conceitualmente:

T1                T2

UPDATE 100
   │
   │
   ├──────────► lê 100
   │
ROLLBACK
   │
   ▼
volta 1000

T2 tomou conhecimento de um estado intermediário que foi posteriormente abandonado.

E agora precisamos falar dos níveis de isolamento.

🧬 CAPÍTULO 10 — UR, CS, RS E RR

No Db2 for z/OS, quatro nomes aparecem frequentemente:

UR — Uncommitted Read
CS — Cursor Stability
RS — Read Stability
RR — Repeatable Read

O erro do iniciante é imaginar:

UR = ruim
RR = excelente

Não.

São escolhas com comportamentos e custos diferentes.

Uma maneira didática de pensar é:

            maior proteção
                  ▲
                  │
                 RR
                  │
                 RS
                  │
                 CS
                  │
                 UR
                  │
                  ▼
       maior liberdade de leitura

Mas não transforme isso numa simples régua de qualidade.

A pergunta correta é:

Qual garantia de isolamento esta transação realmente precisa?

Um relatório estatístico pode aceitar comportamento que seria inadmissível em uma autorização financeira.

Mais isolamento também pode significar impactos na concorrência e no locking.

Engenharia é escolher conscientemente.

👻 CAPÍTULO 11 — NON-REPEATABLE READ

Fry executa:

SELECT SALDO
FROM CONTA
WHERE CONTA_ID = 10;

Obtém:

Outra transação altera a mesma linha e confirma:

1000 → 1500

COMMIT

Fry lê novamente e, dependendo das garantias aplicáveis, pode encontrar:

Temos conceitualmente:

primeira leitura = 1000

segunda leitura  = 1500

A mesma linha não repetiu o valor observado anteriormente.

Daí o nome:

non-repeatable read.

👻 CAPÍTULO 12 — PHANTOM READ: AGORA APARECEU OUTRO BENDER

Considere:

SELECT COUNT(*)
FROM PEDIDO
WHERE STATUS = 'PENDENTE';

Resultado:

Outra transação executa:

INSERT INTO PEDIDO ...

criando outro pedido PENDENTE, e confirma.

Uma nova execução da consulta pode encontrar:

A diferença para o exemplo anterior é fascinante.

Não necessariamente alteraram uma das linhas que você já tinha visto.

O conjunto de linhas que satisfaz o predicado mudou.

Temos então três fenômenos fáceis de diferenciar:

DIRTY READ
→ observei dado não confirmado.

NON-REPEATABLE READ
→ uma linha observada mudou.

PHANTOM
→ o conjunto correspondente ao predicado mudou.

Farnsworth chamaria o último de:

— Fantasmas quânticos relacionais!

Não use esse termo numa prova de certificação.

💀 CAPÍTULO 13 — DEADLOCK: FRY ESPERA BENDER, BENDER ESPERA FRY

Imagine:

TRANSAÇÃO A                TRANSAÇÃO B

LOCK RECURSO X             LOCK RECURSO Y
      │                          │
      ▼                          ▼

quer Y                      quer X
      │                          │
      ▼                          ▼

WAIT                         WAIT

Temos um ciclo:

A espera B
▲         │
│         ▼
└──────── B

Isso é deadlock.

O sistema precisa romper a situação e uma das unidades de trabalho envolvidas acaba sendo tratada como vítima.

Para o programador COBOL surge uma lição essencial:

IF SQLCODE NOT = ZERO
    DISPLAY 'ERRO'
END-IF

não representa tratamento transacional adequado.

É necessário compreender o SQLCODE/SQLSTATE e decidir o comportamento correto da aplicação.

⏱️ CAPÍTULO 14 — TIMEOUT NÃO É DEADLOCK

Farnsworth deixa Bender segurando a chave do laboratório.

Fry espera.

E espera.

Não existe necessariamente um ciclo.

Existe um recurso indisponível durante tempo suficiente para que o limite aplicável seja atingido.

Conceitualmente:

DEADLOCK:

A → B
↑   │
└───┘


TIMEOUT:

A possui recurso

B → WAIT → WAIT → WAIT → limite

Para o usuário:

"Travou."

Para quem investiga produção:

Precisamos saber exatamente por quê.

Essa é a diferença entre observar sintoma e diagnosticar sistema.

💾 CAPÍTULO 15 — D DE DURABILITY: O SEGREDO DO COMMIT

Agora Farnsworth aperta novamente o botão vermelho.

— Professor, não!

Tarde demais.

💥

O Db2 caiu logo depois de uma transação ter sido confirmada.

A pergunta é:

Os dados confirmados desapareceram?

A durabilidade existe justamente para estabelecer a expectativa de que uma transação efetivamente comprometida sobreviva a falhas dentro das garantias do sistema.

Mas aqui encontramos uma curiosidade fantástica.

Muitos iniciantes imaginam:

UPDATE
   │
   ▼
grava imediatamente a página no DASD
   │
   ▼
COMMIT

Essa visão é simples demais.

Db2 utiliza buffer pools.

🏊 CAPÍTULO 16 — BUFFER POOL: A PISCINA DO PROFESSOR

Imagine uma página trazida para memória:

       DASD
         │
         ▼
    BUFFER POOL
   ┌────────────┐
   │ DATA PAGE  │
   └────────────┘

Ela é alterada:

    BUFFER POOL
   ┌────────────┐
   │ MODIFIED   │
   │   PAGE     │
   └────────────┘

Essa página modificada precisa, em algum momento apropriado, chegar ao armazenamento persistente.

Mas seria terrivelmente caro exigir ingenuamente uma escrita física completa da página de dados a cada simples UPDATE.

Então surge outro personagem fundamental:

O Db2 Log.

📜 CAPÍTULO 17 — O DIÁRIO SECRETO DO Db2

O Db2 mantém informações de log essenciais para recovery.

Mentalmente:

             SQL UPDATE
                 │
        ┌────────┴────────┐
        ▼                 ▼
   BUFFER POOL          LOG
        │                 │
        ▼                 ▼
   DATA PAGES         RECOVERY

É por isso que uma ideia crucial é:

COMMIT não deve ser entendido como "todas as páginas modificadas foram necessariamente gravadas fisicamente no tablespace naquele mesmo instante".

O sistema possui mecanismos de logging e recuperação justamente para separar adequadamente esses eventos sem abandonar durabilidade.

Esse ponto muda completamente a compreensão do COMMIT.

✍️ CAPÍTULO 18 — WRITE-AHEAD LOGGING

Entra em cena o princípio de Write-Ahead Logging, WAL.

De forma didática, as informações de log necessárias à recuperação precisam obedecer à ordenação apropriada em relação às páginas de dados modificadas.

Farnsworth explicaria:

Antes de mandar Bender alterar o universo, anote no diário o suficiente para descobrir depois o que ele fez.

Suponha o log conceitual:

T001 UPDATE A
T001 UPDATE B
T001 COMMIT

T002 UPDATE C
T002 UPDATE D

💥 CRASH

Temos duas situações.

T001 foi confirmada.

T002 não chegou ao commit.

Durante recovery, o sistema possui informações para preservar/reaplicar o que deve sobreviver e desfazer/backout do que não deveria permanecer, conforme necessário.

Didaticamente:

T001 → REDO se necessário

T002 → UNDO/BACKOUT conforme necessário

E aqui acontece algo maravilhoso.

♻️ CAPÍTULO 19 — ATOMICITY E DURABILITY SE ENCONTRAM NO LOG

Veja:

                    LOG
                  /     \
                 /       \
                ▼         ▼
              UNDO       REDO
                │         │
                ▼         ▼
          ATOMICITY   DURABILITY

Atomicidade diz:

Trabalho incompleto não pode permanecer como se estivesse confirmado.

Durabilidade diz:

Trabalho confirmado não deve desaparecer simplesmente porque houve uma falha.

O log ajuda o Db2 a navegar entre esses dois mundos.

ACID deixa de parecer quatro palavras independentes.

É uma engrenagem.

🗄️ CAPÍTULO 20 — ACTIVE LOG, ARCHIVE LOG E A MÁQUINA DO TEMPO

No Db2 for z/OS encontramos active logs e archive logs dentro da arquitetura de logging.

Uma representação simplificada:

TRANSAÇÕES
     │
     ▼
 ACTIVE LOG
     │
     │ offload
     ▼
ARCHIVE LOG

Ao avançarmos em Db2 recovery aparecem ainda termos importantíssimos:

BSDS
RBA / LRSN
checkpoints
image copies
RECOVER
restart
active logs
archive logs

Perceba como uma simples aula sobre ACID acaba levando diretamente para Backup & Recovery de Db2 for z/OS.

É por isso que conhecimento mainframe funciona como uma catedral.

Você abre uma porta e encontra outras vinte.

🚦 CAPÍTULO 21 — COMMIT, CHECKPOINT E IMAGE COPY NÃO SÃO A MESMA COISA

Guarde isto:

COMMIT ≠ CHECKPOINT ≠ IMAGE COPY

O COMMIT está relacionado à confirmação da Unit of Work.

O checkpoint do Db2 participa de mecanismos internos importantes para restart/recovery e gerenciamento do sistema.

Uma image copy é utilizada dentro da estratégia de backup/recovery dos objetos Db2.

Três ferramentas do universo da confiabilidade.

Três finalidades diferentes.

Misturá-las é como confundir:

SAVE
BACKUP
TRANSACTION

só porque todas parecem envolver a ideia de "não perder alguma coisa".

🚀 CAPÍTULO 22 — PROFESSOR, TEM CICS NESSA EXPERIÊNCIA?

Tem.

E agora Farnsworth realmente fica animado.

Imagine:

ATM / MOBILE / API
        │
        ▼
       CICS
        │
        ▼
      COBOL
        │
   ┌────┼────┐
   ▼    ▼    ▼
  Db2   MQ   VSAM

Uma única operação de negócio pode envolver vários recursos.

Suponha:

1. atualizar Db2
2. atualizar outro recurso transacional
3. produzir uma mensagem

A pergunta já não é apenas:

O Db2 confirmou?

Passa a ser:

A unidade lógica completa foi coordenada corretamente entre os resource managers participantes?

Aqui aparecem conceitos como:

SYNCPOINT
resource managers
transaction coordination
two-phase commit

E percebemos por que o mundo transacional mainframe é muito maior que EXEC SQL.

🤝 CAPÍTULO 23 — TWO-PHASE COMMIT, OU "TODO MUNDO PRONTO?"

Didaticamente, pense num coordenador perguntando:

              COORDENADOR
                   │
          ┌────────┴────────┐
          ▼                 ▼
         Db2                MQ

       pronto?            pronto?
          │                 │
         YES               YES
          │                 │
          └────────┬────────┘
                   ▼
                 COMMIT

Se a operação não puder prosseguir adequadamente, entra o caminho de rollback/recovery previsto pelo protocolo e pelos participantes.

A realidade é mais sofisticada que esse desenho, mas ele mostra uma coisa essencial:

Atomicidade dentro de um banco já é interessante. Atomicidade envolvendo múltiplos resource managers é outro nível de engenharia.

📦 CAPÍTULO 24 — ACID NÃO IMPEDE PAGAMENTO DUPLICADO POR MÁGICA

Farnsworth envia a mensagem:

PAGAMENTO 98472

A rede apresenta problema.

A aplicação tenta novamente:

PAGAMENTO 98472

Temos duas mensagens.

Cada processamento individual pode ser perfeitamente ACID.

Ainda assim, se a aplicação não identificar a duplicidade, poderemos processar o mesmo evento duas vezes.

Talvez o desenho utilize algo equivalente a:

TRANSACTION_ID UNIQUE

ou outra estratégia de idempotência.

Portanto:

ACID
   ≠
IDEMPOTÊNCIA

ACID também não substitui:

tratamento de retries
deduplicação
regras de negócio
recovery da aplicação
restartability

Essa distinção tornou-se ainda mais importante quando o mainframe começou a conversar intensamente com:

APIs
MQ
eventos
cloud
microservices
Kafka

💳 CAPÍTULO 25 — O TESTE FINAL: DUAS COMPRAS, UM LIMITE

Chegamos à experiência final do laboratório.

Limite disponível:

R$ 1.000

Compra de Fry:

R$ 700

Compra de Bender:

R$ 600

As duas chegam praticamente juntas:

                 R$1000
                    │
             ┌──────┴──────┐
             ▼             ▼
          R$700           R$600

Agora ACID inteiro entra em ação.

Atomicity

Se a autorização depende de registrar movimento e atualizar o limite, precisamos da unidade transacional correta.

Não queremos:

limite reduzido
+
autorização inexistente

Consistency

Constraints, relacionamentos e regras implementadas precisam permanecer válidos.

Isolation

As duas compras não podem simplesmente tomar decisões independentes baseadas numa visão concorrente inadequada dos mesmos R$ 1.000.

Aqui entram isolamento, locking e concorrência.

Durability

Depois que a autorização foi efetivamente confirmada, uma falha posterior não deve simplesmente apagá-la da história.

Agora ACID não é mais uma pergunta de entrevista.

É dinheiro.

🧰 CAPÍTULO 26 — CHECKLIST DO PADAWAN COBOL

Sempre que encontrar:

EXEC SQL
   COMMIT
END-EXEC.

não passe correndo.

Pare e investigue:

Qual Unit of Work termina aqui?
Quais alterações pertencem à mesma operação de negócio?
O que acontece se houver ABEND antes deste ponto?
E imediatamente depois?
Como funciona o restart?
Existe risco de reprocessamento?
A operação é idempotente?
Quais outras transações concorrem pelos mesmos dados?
Qual isolamento é necessário?
Há CICS, MQ ou outros resource managers envolvidos?
O programa trata deadlock e timeout adequadamente?
As constraints representam todas as regras importantes ou parte delas vive no COBOL?

Essas doze perguntas valem mais do que decorar ACID para uma prova.

🗺️ CAPÍTULO 27 — O MAPA DO LABORATÓRIO FARNSWORTH

No final da aula, o Professor desenhou tudo no quadro:

                       A C I D
                          │
       ┌──────────────────┼──────────────────┐
       │                  │                  │
       ▼                  ▼                  ▼
  ATOMICITY          CONSISTENCY         ISOLATION
       │                  │                  │
       ▼                  ▼                  ▼
     UOW              Constraints          IRLM
   COMMIT              PK / FK             Locks
  ROLLBACK             UNIQUE            UR/CS/RS/RR
  BACKOUT              CHECK                │
       │               Business        ┌────┴────┐
       │                Rules          ▼         ▼
       │                           Deadlock   Timeout
       │
       └──────────────┐
                      ▼
                    LOG
                 ┌────┴────┐
                 ▼         ▼
               UNDO       REDO
                 │         │
                 ▼         ▼
            Atomicity  Durability
                           │
                ┌──────────┼───────────┐
                ▼          ▼           ▼
           Active Log  Archive Log  Recovery
                                       │
                                       ▼
                                     Restart

E acima disso:

                   USUÁRIO
                      │
                      ▼
                 CICS / BATCH
                      │
                      ▼
                    COBOL
                      │
                      ▼
                     Db2
          ┌───────────┼───────────┐
          ▼           ▼           ▼
     BUFFER POOL     IRLM         LOG
          │           │           │
          ▼           ▼           ▼
        DATA        LOCKING    RECOVERY
          │           │           │
          └───────────┼───────────┘
                      ▼
                     ACID

🧪 EPÍLOGO — GOOD NEWS, EVERYONE!

O jovem programador olhou novamente para o programa.

Naquela manhã, o código parecia simples:

EXEC SQL
   COMMIT
END-EXEC.

Agora ele enxergava outra coisa.

Via uma Unit of Work.

Via alterações ainda não confirmadas.

Via locks sendo administrados.

Via transações concorrentes.

Via IRLM.

Via páginas no buffer pool.

Via logging.

Via trabalho confirmado e não confirmado.

Via possibilidades de REDO e UNDO.

Via restart.

Via CICS coordenando recursos.

Via o batch que precisava saber de onde continuar.

Via o pagamento duplicado que ACID sozinho não impediria.

Via o deadlock escondido entre duas transações perfeitamente corretas quando observadas isoladamente.

Finalmente percebeu uma coisa que todo programador COBOL que trabalha seriamente com Db2 acaba descobrindo:

O SQL que você escreve é apenas a parte visível da transação.

Farnsworth colocou a mão sobre a enorme alavanca vermelha.

— Professor...

— Sim?

— Não toque nisso.

O velho cientista sorriu.

— Good news, everyone! Eu instalei um COMMIT!

— Professor, COMMIT não é backup.

Silêncio.

— Muito bem, jovem.

Farnsworth afastou lentamente a mão da alavanca.

E essa talvez seja a melhor definição do salto entre aprender SQL e começar a compreender Db2 for z/OS.

No começo aprendemos:

SELECT
INSERT
UPDATE
DELETE

Depois aprendemos:

COMMIT
ROLLBACK

Mas o verdadeiro salto acontece quando olhamos para um UPDATE e imediatamente pensamos:

Quem mais está acessando isto?

Qual é minha UOW?

Que lock posso provocar?

Qual isolamento preciso?

O que acontece se eu falhar agora?

O que já está confirmado?

Como faço restart?

Posso executar novamente?

Existe outro resource manager?

Como o Db2 recuperará isso?

Nesse momento você deixa de enxergar Db2 apenas como um lugar onde o COBOL guarda registros.

Você começa a enxergá-lo como uma máquina transacional construída para administrar simultaneamente mudança, concorrência e falha.

E essa é a grande sacada escondida nas quatro letras:

A C I D

ATOMICITY
   │
   └── Não deixe metade da história acontecer.

CONSISTENCY
   │
   └── Não transforme um estado válido em absurdo.

ISOLATION
   │
   └── Não deixe milhares de histórias simultâneas
       destruírem umas às outras.

DURABILITY
   │
   └── Depois de confirmar a história,
       não deixe uma falha apagá-la.

É por isso que bancos, cartões, seguradoras, companhias aéreas, varejistas e tantas outras empresas podem executar volumes enormes de transações sem depender da esperança de que "nada dê errado".

Porque coisas dão errado.

Programas sofrem ABEND.

Jobs são reiniciados.

Transações entram em deadlock.

Recursos ficam indisponíveis.

Sistemas precisam de recovery.

Mensagens podem ser reenviadas.

Aplicações concorrem.

Máquinas podem parar.

E às vezes alguém liga às 03:17 da manhã.

A genialidade não está em construir um universo onde falhas sejam impossíveis.

Está em construir um sistema que saiba o que fazer quando elas inevitavelmente acontecerem.

Farnsworth apagou as luzes do laboratório.

Na tela permaneceu apenas uma mensagem:

DSNE610I NUMBER OF ROWS DISPLAYED IS 1

E, ao lado dela, uma pequena anotação:

*> GOOD NEWS, EVERYONE.
*> SQLCODE = 0.

☕ Bem-vindo ao Db2 no mainframe, Padawan. Aqui até o caos precisa respeitar a Unit of Work.

Translate

terça-feira, 8 de fevereiro de 2022