Questão de Banco de Dados — Transações (Locks, ACID, etc.) — FCC 2026

Transações e controle de concorrência no SQL Server

Gabarito: letra B. Para garantir a integridade das transações em cenários de alta concorrência, o trecho que melhor atende é BEGIN TRANSACTION; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;, pois o nível SERIALIZABLE é o mais restritivo, garantindo o isolamento total entre transações concorrentes (propriedade I do ACID) e prevenindo todos os fenômenos de concorrência (leitura suja, leitura não repetível e fantasma). As demais alternativas ou desabilitam mecanismos de isolamento, ou usam níveis mais permissivos, ou contêm comandos inválidos.

O controle de concorrência é o mecanismo que o SGBD utiliza para garantir que transações simultâneas não interfiram umas nas outras, preservando a consistência do banco. A propriedade que trata diretamente disso é o isolamento, uma das quatro propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). O isolamento define o grau em que as operações de uma transação ficam visíveis para outras transações concorrentes. Quanto maior o nível de isolamento, maior a proteção contra fenômenos como leitura suja (ler dados não commitados), leitura não repetível (ler o mesmo dado duas vezes e obter valores diferentes) e fantasma (linhas que aparecem ou desaparecem durante uma transação).

O SQL Server oferece níveis de isolamento configuráveis via SET TRANSACTION ISOLATION LEVEL. O nível SERIALIZABLE é o mais alto: ele coloca locks de intervalo (range locks) que impedem que outras transações insiram, atualizem ou excluam linhas que afetariam o resultado da transação atual, garantindo o isolamento completo. É o nível que mais se aproxima da execução serial das transações, daí o nome. Em contrapartida, é o que mais reduz a concorrência, pois aumenta o bloqueio de recursos.

Na prática, um analista que precisa garantir integridade em alta demanda deve escolher o nível de isolamento que equilibre consistência e desempenho. Para cenários onde a integridade é crítica, o SERIALIZABLE é a escolha conservadora. O comando BEGIN TRANSACTION inicia a transação, e o SET TRANSACTION ISOLATION LEVEL define o comportamento de isolamento para aquela transação. A ordem correta é iniciar a transação e depois definir o nível de isolamento, como na alternativa B.

A pegadinha da questão está em confundir os níveis de isolamento e os comandos de configuração do banco. As alternativas A e C desabilitam opções de snapshot, que são mecanismos de versionamento de linhas que melhoram a concorrência — desabilitá-los não garante integridade, pelo contrário. A alternativa D usa READ UNCOMMITTED, o nível mais permissivo, que permite leitura suja, violando o isolamento. A alternativa E usa SET BLOCK_TIMEOUT 0, que não é um comando válido no SQL Server (é do MySQL) e não tem relação com isolamento.

Guarde a hierarquia dos níveis de isolamento do SQL Server: READ UNCOMMITTED < READ COMMITTED < REPEATABLE READ < SERIALIZABLE. É exatamente nessa escala que as alternativas se dividem: a correta usa o nível mais forte, enquanto as incorretas usam níveis mais fracos ou comandos que reduzem a proteção.

Alternativa A — ❌ Incorreta

O comando ALTER DATABASE SET ALLOW_SNAPSHOT_ISOLATION OFF desabilita o isolamento de snapshot no banco. O snapshot isolation é um recurso que permite que transações leiam uma versão consistente dos dados sem bloquear outras transações, melhorando a concorrência. Desabilitá-lo reduz a capacidade de controle de concorrência, não a garante. Além disso, é um comando de configuração do banco, não de uma transação específica.

Alternativa B — ✅ Correta ⟵ GABARITO

Este trecho inicia uma transação com BEGIN TRANSACTION e define o nível de isolamento como SERIALIZABLE. O nível SERIALIZABLE é o mais alto do SQL Server, garantindo que a transação seja totalmente isolada das demais, prevenindo leitura suja, leitura não repetível e fantasma. É a escolha que melhor atende ao requisito de garantir integridade em cenários de alta concorrência, pois sacrifica desempenho em prol da consistência.

Alternativa C — ❌ Incorreta

O comando ALTER DATABASE SET READ_COMMITTED_SNAPSHOT OFF desabilita o snapshot no nível READ COMMITTED. Quando habilitado, o READ COMMITTED usa versionamento de linhas para fornecer consistência de leitura sem bloqueios. Desabilitá-lo faz com que o READ COMMITTED use locks de compartilhamento, o que pode aumentar bloqueios e reduzir a concorrência, mas não garante o isolamento máximo. É uma configuração de banco, não uma definição de nível de isolamento para uma transação.

Alternativa D — ❌ Incorreta

O nível READ UNCOMMITTED é o mais permissivo do SQL Server. Ele permite que uma transação leia dados que ainda não foram commitados por outras transações (leitura suja), violando a propriedade de isolamento. Em cenários de alta demanda onde a integridade é crítica, esse nível é inadequado, pois pode levar a inconsistências graves. A alternativa até inicia a transação corretamente, mas o nível de isolamento escolhido é o oposto do que se deseja.

Alternativa E — ❌ Incorreta

O comando SET BLOCK_TIMEOUT 0 não é um comando válido no SQL Server. Ele existe no MySQL (para definir o tempo de espera por locks). Além disso, COMMIT sozinho não define nenhum nível de isolamento e não há BEGIN TRANSACTION para iniciar a transação. O trecho é sintaticamente inválido no contexto do SQL Server e não atende ao requisito de controle de concorrência.

Gabarito: letra B