Questão de Banco de Dados — Concorrência em Banco de Dados — FUNDATEC 2025
Banco de Dados›Concorrência em Banco de Dados
Código
qg475065
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Nível
Superior
Cargo
Analista em Computação/Ênfase em Suporte em Banco de Dados
Durante o suporte a um sistema de banco de dados de grande porte, usuários relatam que algumas transações ficam em espera por locks (aparentemente sem avançar). Qual é a causa mais provável dessa situação?
AO otimizador escolheu um plano de execução ineficiente.
BO log de transações foi preenchido e precisa ser limpo.
CA ausência de índices força o uso de varredura completa (table scan).
DUm deadlock entre transações impede a liberação de locks.
EA replicação assíncrona não atualiza todas as réplicas em tempo real.
Revelar gabarito e comentário▾
GabaritoD — Um deadlock entre transações impede a liberação de locks.
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”.
Concorrência em Banco de Dados – Deadlock
Gabarito: letra D. A causa mais provável de transações ficarem em espera por locks sem avançar é a ocorrência de um deadlock (impasse), situação em que duas ou mais transações mantêm bloqueios sobre recursos que as demais necessitam, criando uma espera circular que impede qualquer uma de progredir. O contexto de controle de concorrência indica que o deadlock é um problema clássico que leva a essa paralisação, conforme discutido em técnicas de bloqueio em duas fases.
Causa do Problema
Descrição
Relação com o Sintoma (transações em espera por locks sem avançar)
Deadlock (Gabarito – D)
Duas ou mais transações mantêm locks sobre recursos que as demais necessitam, criando uma espera circular.
Causa direta. Impede que qualquer transação do ciclo progrida, gerando a paralisação descrita.
Plano de execução ineficiente (A)
O otimizador escolhe uma estratégia de acesso lenta (ex.: loops aninhados sem índices).
Incorreta. Torna a transação lenta, mas não a bloqueia permanentemente; ela ainda executa.
Log de transações cheio (B)
O espaço para registro de operações está esgotado, afetando a recuperação.
Incorreta. Não interfere na concessão de locks; afeta a capacidade de gravar, não a espera por bloqueios.
Ausência de índices (C)
Força varreduras completas (table scan), que seguram locks por mais tempo.
Incorreta. Aumenta contenção, mas não gera um impasse; transações eventualmente progridem.
Replicação assíncrona (E)
Atraso na propagação de dados entre réplicas para manter consistência eventual.
Incorreta. Relaciona-se a consistência de dados, não ao gerenciamento de locks no nó primário.
Deadlock: Causa (Espera circular por locks, Transações param sem avançar); Detecção (Timeout, Grafo de espera); Resolução (Rollback de uma transação)
Alternativa A — ❌ Incorreta
Um plano de execução ineficiente pode tornar uma transação lenta, mas não a deixa permanentemente bloqueada por locks sem avançar – a transação ainda pode executar, apenas de forma mais demorada. O sintoma descrito é de espera por locks, não de baixo desempenho.
Alternativa B — ❌ Incorreta
O log de transações cheio está relacionado à recuperação e ao espaço em disco, não ao gerenciamento de locks. Transações em espera por locks não são causadas por log lotado; isso afetaria a capacidade de gravar registros, mas não a concessão de bloqueios.
Alternativa C — ❌ Incorreta
A falta de índices pode levar a table scans, que seguram locks por mais tempo e podem aumentar contenção, mas não geram uma paralisação completa e indefinida. Transações ainda podem avançar quando os locks forem liberados. O enunciado sugere um impasse ("aparentemente sem avançar"), típico de deadlock, não de simples contenção.
Alternativa D — ✅ Correta ⟵ GABARITO
O deadlock ocorre exatamente quando cada transação em um conjunto está aguardando um lock mantido por outra transação do mesmo conjunto, gerando uma espera circular que impede a progressão. Os usuários relatam que as transações ficam paradas – esse é o comportamento clássico de um impasse. O protocolo de bloqueio em duas fases, por exemplo, pode levar a deadlocks, como ilustrado na Seção 21.1.3 do contexto de controle de concorrência. A detecção e resolução de deadlocks (por timeout ou grafo de espera) é uma prática comum em SGBDs.
Alternativa E — ❌ Incorreta
Replicação assíncrona trata de consistência entre réplicas e pode causar atrasos na propagação de dados, mas não interfere diretamente no gerenciamento de locks da transação local. A espera por locks é um problema de concorrência local, não de replicação.