Questão de Banco de Dados — Transações (Locks, ACID, etc.) — CESPE / CEBRASPE 2025
Banco de Dados›Transações (Locks, ACID, etc.)
Código
ce417233
Banca
CESPE / CEBRASPE
Órgão
PC DF
Ano
2025
Cargo
GAAPC ( )
A respeito de arquitetura, segurança, integridade, concorrência, recuperação após falhas e gerenciamento de transições em sistemas de gerenciamento de banco de dados (SGDB), julgue o item a seguir.
Um SGBD que implementa um sistema de log de transações segundo o princípio WAL (write-ahead logging) é capaz de garantir que, mesmo após uma falha inesperada, todas as transações confirmadas possam ser recuperadas ao estado consistente anterior à falha.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
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”.
WAL (Write-Ahead Logging) e Recuperação de Transações
Gabarito: Certo. O princípio WAL (write-ahead logging) garante que, antes de qualquer alteração de página de dados ser gravada em disco, o registro correspondente dessa alteração já tenha sido persistido no log. Dessa forma, após uma falha inesperada, o SGBD pode usar o log para refazer (redo) as operações de transações confirmadas, recuperando-as ao estado consistente anterior à falha. Essa é a base da propriedade de durabilidade do ACID.
O WAL é uma técnica fundamental de recuperação em SGBDs. Para entender por que ele funciona, é preciso compreender o papel do log de transações. O log é um arquivo sequencial que registra, em ordem cronológica, todas as operações de escrita realizadas pelas transações, incluindo informações suficientes para refazer (redo) ou desfazer (undo) cada operação. O princípio WAL estabelece uma ordem obrigatória: primeiro o log, depois o dado. Ou seja, antes de o SGBD gravar uma página de dados modificada no disco, ele deve garantir que o registro de log correspondente a essa modificação já esteja gravado de forma durável (em disco).
A razão dessa ordem é simples: se o sistema falhar após gravar a página de dados, mas antes de gravar o log, não haveria como saber se a operação foi efetivada ou não, comprometendo a atomicidade e a durabilidade. Com o WAL, ao reiniciar, o SGBD examina o log e identifica as transações que foram confirmadas (commit) mas cujas alterações podem não ter sido gravadas no disco. Para essas, ele aplica o redo (refaz as operações a partir do log). Para transações que não foram confirmadas, ele aplica o undo (desfaz as operações). Esse processo é chamado de recuperação após falha.
A propriedade ACID diretamente relacionada a essa capacidade é a durabilidade: uma vez que uma transação é confirmada (commit), suas alterações devem persistir mesmo diante de falhas. O WAL é o mecanismo que viabiliza essa persistência. É importante distinguir a durabilidade da atomicidade: enquanto a atomicidade lida com falhas durante a execução da transação (garantindo o rollback total), a durabilidade lida com falhas após a confirmação (garantindo o redo). O WAL, ao registrar as operações antes de aplicá-las, serve a ambos os propósitos, mas a questão foca especificamente na recuperação de transações confirmadas, que é a durabilidade.
Na prática, imagine uma transferência bancária: a transação debita a conta A e credita a conta B. Se o sistema falhar logo após o commit, mas antes de gravar o crédito em B no disco, o WAL garante que, ao reiniciar, o SGBD refaça a operação de crédito a partir do log, assegurando que a transferência não se perca. Sem o WAL, o banco de dados poderia ficar em um estado inconsistente, com o débito aplicado e o crédito perdido.
A pegadinha que a banca explora aqui é a confusão entre o que o WAL garante e o que ele não garante. O WAL garante a recuperação de transações confirmadas (durabilidade) e o rollback de transações não confirmadas (atomicidade). Ele não garante, por si só, que o banco de dados estará em um estado consistente se houver falhas de hardware que corrompam o próprio log ou o disco de dados. Nesses casos, outras técnicas (como backups e espelhamento) são necessárias. A questão, no entanto, afirma corretamente que o WAL é capaz de garantir a recuperação de transações confirmadas após uma falha inesperada, o que é verdadeiro.
Guarde a fronteira entre durabilidade (falhas após o commit, resolvida com redo via WAL) e atomicidade (falhas antes do commit, resolvida com undo via log): é exatamente nessa distinção que a banca costuma armar as pegadinhas.
1Transação confirma (commit)
2Registro gravado no log
3Página de dados gravada
4Falha inesperada
5Redo das confirmadas
6Undo das não confirmadas
LEVEL · soulevel.com.br
Item — ✅ CERTO
A afirmação está correta. O WAL (write-ahead logging) é exatamente o mecanismo que garante a durabilidade das transações confirmadas. Ao gravar o registro de log antes da página de dados, o SGBD assegura que, após uma falha, possa refazer (redo) as operações das transações que receberam commit, recuperando o banco de dados ao estado consistente anterior à falha. Isso está alinhado com a propriedade de durabilidade do ACID, que afirma que as mudanças aplicadas por uma transação confirmada devem persistir mesmo na ocorrência de falhas no sistema.
NÃO CAIA NESSA!
Para questões sobre WAL e recuperação, lembre-se da ordem: log primeiro, dado depois. Se a alternativa falar em recuperar transações confirmadas, pense em redo e durabilidade. Se falar em desfazer transações não confirmadas, pense em undo e atomicidade. Essa distinção resolve a maioria das pegadinhas.