APRENDER. PRATICAR. EVOLUIR.Descrever o recurso antes de alterar a transação
O laboratório representa uma capacidade fictícia de processamento de batch, limitada ao intervalo de zero a cem unidades. FREE_UNITS é NUMBER RESERVABLE, ID identifica a linha e NOTE é uma coluna normal. Duas sessões usam o mesmo schema descartável. A reserva um consumo de 35 e B um consumo de 45, antes de qualquer commit. Ambas avançam até às observações seguintes: a coluna base ainda mostra 100, enquanto cada journal consultado pela respetiva sessão mostra a sua reserva. Esta distinção interessa ao L3 que vê «100 livres» numa consulta e recebe uma rejeição ao tentar consumir 25. Não existe contradição: o pedido adicional deve respeitar os compromissos já admitidos. A leitura isolada não é uma promessa de capacidade futura.
Seguir a alteração no journal e no valor confirmado
Após as duas reservas, restam 20 para novo consumo. O pedido adicional de B para 25 é rejeitado com ORA-02290. A cria um savepoint e reserva mais 10; a sua quantidade passa de 35 para 45. ROLLBACK TO devolve-a a 35, conservando a reserva anterior ao savepoint. Quando B faz commit, a coluna base passa a 55. A lê 55 apesar de ainda manter a sua reserva de 35. Depois do commit de A, o valor é 20. Guarda uma tabela temporal com sessão, instrução, journal visível e valor base. Sem esta ordem, um relatório pode confundir a reserva com uma atualização já aplicada ou atribuir a B a confirmação do trabalho de A.
Não financiar consumo com um incremento pendente
Com 20 confirmados, B reserva um incremento de 40. Antes do commit de B, A tenta consumir 30 e recebe outra violação de CHECK. O incremento alheio ainda pode ser revertido; a admissão não depende dele. Depois do commit de B, o valor passa a 60 e a reserva de 30 por A é aceite. O rollback de A liberta essa reserva e mantém 60. Num passo seguinte, A reserva 15 e B reserva 20: A reverte e B confirma, deixando 40. Estes casos ajudam a desenhar cancelamentos independentes de pedidos. Não generalizes a conclusão a Sagas ou a mensagens enviadas a sistemas externos. O laboratório executou apenas transações locais, sem integração de compensação distribuída.
Distinguir restrição da instrução e espera por recurso
O ensaio de atribuição direta SET free_units=25 devolveu ORA-55746. A intenção de consumo deve usar a forma de delta suportada e identificar a linha corretamente. Misturar na mesma instrução a coluna reservable e NOTE normal devolveu ORA-55735. É necessário separar instruções e rever atomicidade e bloqueios do fluxo completo. Noutro passo, B altera NOTE e mantém o row lock; A consegue obter uma reserva de cinco unidades. Só depois de B reverter é executado o commit de A, ficando 35. A observação demonstra aquisição da reserva naquela condição, sem provar commit sem espera enquanto B retinha o lock. Na análise de incidentes, associa o erro à instrução e fase, em vez de tratar todas as falhas como timeouts.
Preparar manutenção sem manipular o journal
Com uma reserva pendente, DELETE devolveu ORA-55754 e a linha permaneceu. O fluxo resolveu as transações antes da manutenção seguinte. A conversão para NOT RESERVABLE removeu o journal da última coluna reservable, mas preservou a CHECK ativa. Uma atribuição de -1 continuou a falhar; uma atribuição válida a 31 foi confirmada. Logo, retirar a funcionalidade não remove os limites de negócio definidos na tabela. O journal é gerido pelo Oracle e não deve ser corrigido com DML manual. Antes de uma mudança real, inventaria transações, dependências e requisitos de retorno. Os dois ensaios removeram o schema criado; o contentor e a rede exclusivos também foram removidos, mantendo a imagem para outros exercícios.
Reproduzir e entregar uma conclusão limitada à evidência
O SQL abaixo organiza a parte central do exercício por sessões A e B. Usa apenas um schema descartável autorizado com quota limitada. Prevê primeiro os valores 100, 55 e 20 e explica por que 25 adicionais são rejeitados. Identifica o journal criado através da metadata, sem escrever diretamente nele, e compara a visibilidade das duas sessões. Acrescenta savepoint, rollback e incremento pendente seguindo a sequência descrita. O executor conservado em content/labs/oracle-reservation-journal reproduziu duas passagens de 42 verificações em Oracle Free 26ai. Não mediu throughput, duração de locks no commit, crash recovery ou compensação de Sagas. O entregável é um diagrama temporal e uma decisão sobre a elegibilidade de um recurso fictício; uma recomendação para produção exige testar as dependências reais.
-- Authorized disposable Oracle Free 26ai schema only.
-- Session A: setup, then reserve. Session B uses the same schema in a separate connection.
CREATE TABLE batch_capacity (
id NUMBER PRIMARY KEY,
free_units NUMBER RESERVABLE CONSTRAINT dr_capacity_bounds CHECK(free_units BETWEEN 0 AND 100),
note VARCHAR2(30));
INSERT INTO batch_capacity VALUES(7,100,'synthetic capacity');
COMMIT;
-- A
UPDATE batch_capacity SET free_units=free_units-35 WHERE id=7;
SELECT free_units FROM batch_capacity WHERE id=7;
-- B, without committing A
UPDATE batch_capacity SET free_units=free_units-45 WHERE id=7;
-- B: expected CHECK violation, capacity already reserved by A and B
UPDATE batch_capacity SET free_units=free_units-25 WHERE id=7;
-- Each session can locate and query its own reservation journal; do not modify it.
SELECT table_name FROM user_tables WHERE table_name LIKE 'SYS_RESERVJRNL_%';
-- A
SAVEPOINT before_extra;
UPDATE batch_capacity SET free_units=free_units-10 WHERE id=7;
ROLLBACK TO before_extra;
-- B
COMMIT;
SELECT free_units FROM batch_capacity WHERE id=7; -- 55
-- A
SELECT free_units FROM batch_capacity WHERE id=7; -- 55
COMMIT;
SELECT free_units FROM batch_capacity WHERE id=7; -- 20
-- Resolve both sessions before removing the disposable exercise objects.100 confirmados, reservas de 35 e 45: SELECT ainda mostra 100, mas um consumo adicional de 25 é rejeitado.
Armadilhas comuns
Confundir valor base com capacidade disponível; gastar incrementos pendentes; alterar o journal manualmente; tratar lock-free como garantia de ausência de espera no commit.
Tópicos relacionados: Pesquisa vetorial e migração de modelos · Visibilidade e fronteiras de transação · True Cache, reservas e evidência de auditoria
A reserva admite um delta dentro dos limites; commit aplica-o e rollback liberta-o. Regista cada fase e respeita o âmbito da evidência.
Referência: Using Lock-Free Reservation · 1Z0-183 public objectives inspected 2026-09-30; revision date not published