Pular para o conteúdo principal

Questão de Banco de Dados — Banco de Dados Paralelos e Distribuídos — FGV 2026

Banco de DadosBanco de Dados Paralelos e Distribuídos
Código
fg129166
Banca
FGV
Órgão
AMAZUL
Ano
2026
Nível
Superior
Cargo
Engenheiro de Computação
Em um sistema de banco de dados distribuído com replicação, duas transações concorrentes T1 e T2 executam em réplicas diferentes. T1 lê o saldo de uma conta (R$ 1000), subtrai R$ 200 e grava o novo saldo (R$ 800). Simultaneamente, T2 lê o mesmo saldo original (R$ 1000), subtrai R$ 300 e grava o novo saldo (R$ 700). Ambas as transações são confirmadas com sucesso em suas réplicas locais.A anomalia de concorrência que ocorreu e a técnica poderia preveni-la são, respectivamente,
  1. ADirty read; uso de isolamento READ COMMITTED
  2. BWrite skew; uso de predicados em cláusulas WHERE.
  3. CPhantom read; uso de isolamento SERIALIZABLE
  4. DNon-repeatable read; uso de isolamento REPEATABLE READ
  5. ELost update; uso de bloqueio pessimista ou controle de versão otimista com detecção de conflito.
Revelar gabarito e comentário

GabaritoE — Lost update; uso de bloqueio pessimista ou controle de versão otimista com detecção de conflito.

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”.

Anomalias de concorrência: Lost Update

Gabarito: letra E. A situação descrita (T1 e T2 leem o saldo original de R$ 1000, cada uma subtrai um valor e grava, resultando em saldo final de R$ 700 — a atualização de T1 foi perdida) é o clássico exemplo de Lost Update (atualização perdida). A técnica para evitá-la é o uso de bloqueio pessimista (ex.: SELECT ... FOR UPDATE) ou controle de versão otimista (como MVCC) com detecção de conflito.

Anomalia

Descrição

Técnica de Prevenção

Lost update

Duas transações leem o mesmo valor original e escrevem independentemente, sobrescrevendo a atualização uma da outra

Bloqueio pessimista (ex.: SELECT ... FOR UPDATE) ou controle de versão otimista com detecção de conflito

Dirty read

Leitura de dado não confirmado (sujo)

Isolamento READ COMMITTED

Write skew

Duas transações leem um conjunto de dados e escrevem baseadas no que leram, causando inconsistência lógica

Uso de predicados em cláusulas WHERE ou isolamento SERIALIZABLE

Phantom read

Aparição de novas linhas entre leituras de uma transação devido a inserções de outra

Isolamento SERIALIZABLE

Non-repeatable read

Leitura de um dado retorna valores diferentes na mesma transação devido a modificação de outra

Isolamento REPEATABLE READ

Alternativa A — ❌ Incorreta

Dirty read (leitura suja) ocorre quando uma transação lê dados não confirmados (sujos). No cenário, ambas as transações leem o saldo confirmado original, portanto não há dirty read. O erro é confundir a anomalia.

Alternativa B — ❌ Incorreta

Write skew é uma anomalia típica de sistemas com isolamento "snapshot", onde duas transações lêem um conjunto de dados e escrevem baseadas no que leram, causando inconsistência (ex.: ambos acham que há espaço em agendas). Não é o caso de duas escritas no mesmo registro com leitura do mesmo valor — isso é lost update.

Alternativa C — ❌ Incorreta

Phantom read refere-se à aparição de novas linhas entre leituras de uma transação, em função de inserções de outra transação. Não há inserção de novas contas, apenas atualização de um registro existente.

Alternativa D — ❌ Incorreta

Non-repeatable read ocorre quando, em uma mesma transação, a leitura de um dado retorna valores diferentes porque outra transação o modificou e confirmou entre as duas leituras. No caso, cada transação lê apenas uma vez, portanto não se aplica.

Alternativa E — ✅ Correta ⟵ GABARITO

Lost update é exatamente o cenário: duas transações leem o mesmo valor, atualizam independentemente e a última escrita sobrescreve a primeira sem integrar as alterações. As técnicas de prevenção são o bloqueio pessimista (trava o registro durante a leitura) ou o controle otimista com detecção de conflito (ex.: MVCC com validação no commit).

PEGA ESSA DICA!

Para diferenciar as anomalias, foque no tipo de operação e no número de leituras:

  • Lost update: duas escritas concorrentes no mesmo dado sem considerar a outra.

  • Dirty read: leitura de dado não confirmado.

  • Non-repeatable read: mesma leitura retorna valores diferentes (devido a update).

  • Phantom read: leitura de um conjunto que muda (insert/delete).

  • Write skew: leituras de dados relacionados que levam a escritas inconsistentes (ex.: violação de restrição).

Gabarito: letra E.

Link permanente: /questoes/fg129166