Pular para o conteúdo principal

Questão de Banco de Dados — Concorrência em Banco de Dados — FGV 2025

Banco de DadosConcorrência em Banco de Dados
Código
fg121223
Banca
FGV
Órgão
TCE-PE
Ano
2025
Nível
Superior
Cargo
Analista de Controle Externo - Tecnologia da Informação
Durante a apuração mensal da folha de pagamento de um órgão público, o sistema de recursos humanos executa diversas transações simultâneas para calcular valores de vencimentos e benefícios com base em registros atualizados de frequência, licenças e adicionais.O gestor de TI detectou um problema: em determinados momentos, o sistema calcula valores com base em registros de frequência que são modificados por outra transação ainda em andamento, resultando em inconsistência nos valores pagos.Para evitar esse problema, a equipe propõe ajustar o nível de isolamento da transação utilizada durante o cálculo da folha, de forma que os dados lidos não possam ser modificados ou inseridos por outras transações até que a atual seja concluída.Com base nesse cenário, o nível de isolamento mais apropriado para evitar leituras inconsistentes causadas por alterações concorrentes é:
  1. ARead Uncommitted.
  2. BRead Committed.
  3. CRepeatable Read.
  4. DSerializable.
  5. ESnapshot Read.
Revelar gabarito e comentário

GabaritoD — Serializable.

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

Níveis de Isolamento em Transações

Gabarito: letra D. O nível de isolamento Serializable é o mais restritivo e garante que transações concorrentes não interfiram entre si, eliminando os fenômenos de dirty read, non-repeatable read e phantom read. No cenário descrito, os dados lidos não podem ser modificados ou inseridos por outras transações até a conclusão da atual, exigindo o mais alto nível de isolamento.

A banca testa a compreensão dos níveis de isolamento definidos pelo padrão SQL e suas garantias. O problema de leitura de dados sendo modificados por outra transação em andamento é característico de concorrência. O nível Serializable executa transações como se fossem seriais, evitando qualquer interferência.

Nível de Isolamento

Evita Dirty Read

Evita Non-Repeatable Read

Evita Phantom Read

Atende ao Cenário (dados não podem ser modificados ou inseridos)

A) Read Uncommitted

B) Read Committed

C) Repeatable Read

D) Serializable

E) Snapshot Read

1Read Uncommitted
Dirty read
Non-repeatable read
Phantom read
2Read Committed
Sem dirty read
Non-repeatable read
Phantom read
3Repeatable Read
Sem dirty read
Sem non-repeatable read
Phantom read
4Serializable
Sem dirty read
Sem non-repeatable read
Sem phantom read
Níveis de isolamento (SQL)
LEVELsoulevel.com.br
Níveis de isolamento (SQL): Read Uncommitted (Dirty read, Non-repeatable read, Phantom read); Read Committed (Sem dirty read, Non-repeatable read, Phantom read); Repeatable Read (Sem dirty read, Sem non-repeatable read, Phantom read); Serializable (Sem dirty read, Sem non-repeatable read, Sem phantom read)

Alternativa A — ❌ Incorreta

Read Uncommitted permite dirty reads, ou seja, uma transação pode ler dados ainda não confirmados de outra transação. Isso agravaria o problema, pois os dados lidos podem ser revertidos posteriormente. Não atende ao requisito.

Alternativa B — ❌ Incorreta

Read Committed evita dirty reads, mas permite non-repeatable reads e phantom reads. Uma leitura repetida dentro da mesma transação pode retornar resultados diferentes se outra transação modificar os dados. Ainda assim, não impede que dados lidos sejam alterados por outras transações antes do término da atual.

Alternativa C — ❌ Incorreta

Repeatable Read impede dirty reads e non-repeatable reads, mas permite phantom reads (inserção de novas linhas por outra transação). O enunciado menciona que os dados não podem ser "modificados ou inseridos", logo phantoms também precisam ser evitados — o que Repeatable Read não faz.

Alternativa D — ✅ Correta ⟵ GABARITO

Serializable é o nível mais forte, garantindo que a transação veja uma versão consistente dos dados e que nenhuma outra transação possa interferir. As leituras são isoladas completamente, impedindo modificações, inserções e exclusões de dados que afetariam a consistência. Isso resolve exatamente o problema descrito.

Alternativa E — ❌ Incorreta

Snapshot Read fornece uma visão consistente no momento do início da transação (ou da primeira leitura), evitando dirty reads e non-repeatable reads, mas pode não impedir phantom reads dependendo da implementação. Além disso, não é tão restritivo quanto Serializable e, em alguns SGBDs, pode permitir conflitos de atualização. O padrão SQL não define Snapshot como um nível oficial; os quatro níveis canônicos são: Read Uncommitted, Read Committed, Repeatable Read e Serializable.

NÃO CAIA NESSA!

Confundir Repeatable Read com Serializable. A banca insere o termo "inseridos" no enunciado para que a alternativa C pareça correta, mas Repeatable Read não impede phantom reads (inserções). Lembre-se: apenas Serializable elimina todos os três fenômenos de concorrência. Na dúvida, o nível mais restritivo é sempre a opção mais segura para evitar inconsistências.

Gabarito: letra DSerializable.

Link permanente: /questoes/fg121223