Pular para o conteúdo principal

Questão de Banco de Dados — Concorrência em Banco de Dados — FCC 2026

Banco de DadosConcorrência em Banco de Dados
Código
gp018328
Banca
FCC
Órgão
MPE-AL
Ano
2026
Cargo
Analista do Ministério Público - Especialidade: Desenvolvimento de Sistemas
Um sistema de distribuição de um Ministério Público Estadual sofre bloqueios entre consultas de painel e atualizações de andamento. Com o objetivo de reduzir bloqueio leitor-escritor mantendo consistência por instrução, a configuração de concorrência que se alinha ao uso de row versioning no SQL Server 2019+ é
  1. Aaplicar UPDLOCK nas consultas do painel para reduzir contenção com writers e estabilizar ordenação de acesso.
  2. Bhabilitar READ_COMMITTED_SNAPSHOT para que READ COMMITTED use versionamento em vez de locks de leitura.
  3. Cdesabilitar índices não clusterizados para reduzir locks de índice e manter lock no heap/clustered.
  4. Dforçar WITH (NOLOCK) nas consultas do painel para evitar bloqueios evitando alterar a configuração do banco.
  5. Econfigurar LOCK_TIMEOUT baixo no painel para evitar bloqueios e garantir leituras completas.
Revelar gabarito e comentário

GabaritoB — habilitar READ_COMMITTED_SNAPSHOT para que READ COMMITTED use versionamento em vez de locks de leitura.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Row versioning no SQL Server: READ_COMMITTED_SNAPSHOT

Gabarito: letra B. A configuração READ_COMMITTED_SNAPSHOT (RCSI) no SQL Server faz com que o nível de isolamento READ COMMITTED utilize versionamento de linhas (row versioning) em vez de shared locks em leituras, eliminando bloqueios entre leitores e escritores e mantendo consistência por instrução. Essa é a solução correta para reduzir contenção leitor-escritor sem usar NOLOCK ou alterar o comportamento padrão de locks.

A banca testa o conhecimento sobre a funcionalidade de row versioning no SQL Server 2019+, em especial a diferença entre as opções de isolamento. O cenário descreve bloqueios entre consultas de painel (leituras) e atualizações (escritas). A alternativa B é a única que implementa o versionamento de forma nativa e recomendada pela Microsoft.

  1. 1Problema: bloqueio leitor-escritor
  2. 2Solução: RCSI habilitado
  3. 3READ COMMITTED usa versionamento
  4. 4Leitores sem shared locks
  5. 5Escritores não bloqueiam leitores
  6. 6Consistência por instrução mantida
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Aplicar UPDLOCK nas consultas do painel força locks exclusivos (update locks) durante a leitura, o que aumenta a contenção com escritores, em vez de reduzi-la. UPDLOCK não resolve o bloqueio leitor-escritor; pelo contrário, eleva o isolamento e pode causar deadlocks.

Alternativa B — ✅ Correta ⟵ GABARITO

Habilitar READ_COMMITTED_SNAPSHOT no banco de dados faz com que o nível READ_COMMITTED (padrão) use row versioning: as leituras enxergam uma versão consistente dos dados no momento em que a instrução começa, sem adquirir shared locks. Escritores não bloqueiam leitores e vice-versa, mantendo consistência por instrução (não por transação). Essa é a configuração alinhada ao objetivo da questão.

Alternativa C — ❌ Incorreta

Desabilitar índices não clusterizados é uma medida drástica que prejudica o desempenho de consultas e não é uma configuração de concorrência. O bloqueio ocorre nos dados (linhas/páginas), não nos índices em si. A manutenção de locks no heap/clustered não resolve o problema.

Alternativa D — ❌ Incorreta

Usar WITH (NOLOCK) equivale a ler com READ UNCOMMITTED, permitindo leitura de dados não confirmados (dirty reads) e inconsistências. Embora elimine bloqueios, compromete a consistência, o que contraria o requisito de “mantendo consistência por instrução”. Além disso, não é uma configuração de banco, mas uma dica de tabela pontual.

Alternativa E — ❌ Incorreta

LOCK_TIMEOUT baixo faz com que consultas sejam abortadas se não conseguirem lock no tempo limite, gerando leituras incompletas (erros de timeout), não leituras consistentes. Não reduz bloqueios, apenas faz a transação desistir.

NÃO CAIA NESSA!

A banca tenta confundir o candidato com alternativas que “parecem” reduzir bloqueios (UPDLOCK, NOLOCK, LOCK_TIMEOUT), mas a única que realmente implementa row versioning sem perder consistência é a READ_COMMITTED_SNAPSHOT. Lembre-se: NOLOCK resolve contenção, mas quebra a consistência; UPDLOCK agrava a contenção.

Gabarito: letra B.

Link permanente: /questoes/gp018328