Questão de Banco de Dados — SGBD - Sistema de Gerenciamento de Banco de Dados — FGV 2024
Banco de Dados›SGBD - Sistema de Gerenciamento de Banco de Dados
Código
fg101478
Banca
FGV
Órgão
TRF - 1ª REGIÃO
Ano
2024
Nível
Superior
Cargo
Analista Judiciário - Área Apoio Especializado - Especialidade: Suporte em Tecnologia da Informação
Ana identificou que, em seu banco de dados, ocorria muita demora na execução de algumas transações específicas, que chegavam até a falhar algumas vezes. Ao efetuar uma análise, viu que não havia controle nas transações ocorridas. Como forma de garantir seus schedules estritos, Ana implementou um bloqueio em 2 fases rigoroso.Esse bloqueio implementado por Ana fará com que:
Auma transação bloqueie todos os itens que ela acessa antes que a transação inicie a execução;
Bseja executado um downgrade do bloqueio ao se emitir uma operação read_lock(X), mesmo com a transação ainda em execução;
Cuma transação T não libere nenhum de seus bloqueios exclusivos (gravação) até depois de confirmar ou abortar;
Dseja gerado um rótulo de tempo, que será usado para garantir a serialização das transações;
Euma transação T não libere nenhum de seus bloqueios (exclusivo ou compartilhado) até depois de confirmar ou abortar.
Revelar gabarito e comentário▾
GabaritoE — uma transação T não libere nenhum de seus bloqueios (exclusivo ou compartilhado) até depois de confirmar ou abortar.
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”.
Bloqueio em duas fases rigoroso (strict 2PL)
Gabarito: letra E. No protocolo de bloqueio em duas fases rigoroso (strict two-phase locking), a transação não libera nenhum de seus bloqueios (nem exclusivos, nem compartilhados) até que ela seja confirmada (commit) ou abortada. Essa é a definição clássica que garante schedules estritos (sem leitura de dados não confirmados) e serialabilidade. A alternativa E reproduz exatamente essa regra.
A questão cobra a distinção entre as variantes do 2PL. O 2PL básico permite que bloqueios sejam liberados na segunda fase (encolhimento), podendo gerar cascatas de abortos. O strict 2PL (rigoroso) impede a liberação de qualquer bloqueio antes do fim, evitando leituras sujas e garantindo recuperabilidade.
Análise das alternativas
Característica
Strict 2PL (Bloqueio em 2 fases rigoroso)
2PL básico
Preclaiming
Timestamp Ordering
Liberação de bloqueios
Nenhum bloqueio é liberado antes do commit/abort
Bloqueios podem ser liberados na 2ª fase (encolhimento)
N/A (adquire todos antes)
N/A (não usa bloqueios)
Bloqueios exclusivos retidos até o fim
Sim
Não (podem ser liberados antes)
Sim (todos retidos)
N/A
Bloqueios compartilhados retidos até o fim
Sim
Não (podem ser liberados antes)
Sim (todos retidos)
N/A
Garantia contra leituras sujas
Sim
Não (pode gerar cascatas de aborto)
Sim
Sim
Método de aquisição de bloqueios
Gradual (1ª fase: crescimento)
Gradual (1ª fase: crescimento)
Todos antes da execução
Baseado em carimbo de tempo
Protocolo 2PL: Básico (1ª fase: aquisição, 2ª fase: liberação, Cascatas de aborto); Rigoroso (strict 2PL) (Nenhum bloqueio liberado, Até commit ou abort, Evita leituras sujas); Pré-declaração (preclaiming) (Todos bloqueios antes da execução)
Alternativa A — ❌ Incorreta
Descreve o bloqueio pré-declaração (preclaiming), onde a transação adquire todos os bloqueios antes de começar a executar. Isso não é característico do 2PL, que pode adquiri-los gradualmente durante a primeira fase.
Alternativa B — ❌ Incorreta
Menciona downgrade de bloqueio (exclusivo → compartilhado) por meio da operação read_lock(X). No strict 2PL, não há liberação de bloqueio (nem downgrade) antes do commit; além disso, read_lock é usada para adquirir um bloqueio compartilhado, não para fazer downgrade.
Alternativa C — ❌ Incorreta
Afirma que apenas os bloqueios exclusivos (gravação) não são liberados antes do fim. Essa definição corresponde ao 2PL com retenção de bloqueios exclusivos (às vezes chamado de rigorous 2PL em algumas literaturas), mas não ao strict 2PL exigido pelo enunciado. A banca adotou a definição mais comum, na qual nenhum bloqueio (compartilhado ou exclusivo) é liberado antes do commit/abort.
Alternativa D — ❌ Incorreta
Fala em “rótulo de tempo” para garantir serialização, que é o mecanismo de timestamp ordering – um método diferente de controle de concorrência, baseado em carimbos temporais, e não em bloqueios em duas fases.
Alternativa E — ✅ Correta ⟵ GABARITO
Exatamente a definição de strict 2PL: a transação não libera nenhum de seus bloqueios (exclusivo ou compartilhado) até confirmar ou abortar. Isso garante que nenhuma outra transação veja dados não confirmados, evitando abortos em cascata e produzindo schedules estritos.
NÃO CAIA NESSA!
A alternativa C parece correta, mas a banca considera o “bloqueio em 2 fases rigoroso” como aquele que retém todos os bloqueios, não só os exclusivos. Muitos alunos confundem com a definição mais branda. Lembre-se: no strict 2PL, nem mesmo um bloqueio de leitura é liberado antes do commit.