Questão de Banco de Dados — Recuperação de Dados em SGBDs — CESPE / CEBRASPE 2025

Recuperação de Falhas em SGBD – Rollback e Log de Transações

Gabarito: Errado. A afirmação está incorreta porque, na recuperação por rollback, o SGBD não retorna todas as transações (confirmadas e não confirmadas) ao estado anterior à falha; ele desfaz apenas as transações não confirmadas (que não chegaram ao commit), enquanto as transações confirmadas são refeitas (redo) ou mantidas, conforme o protocolo de recuperação baseado em log. Essa distinção é essencial para garantir a propriedade de durabilidade (ACID), que exige que os efeitos de transações confirmadas persistam mesmo após falhas.

A recuperação de falhas em SGBDs é um dos mecanismos que garantem as propriedades ACID das transações. Quando ocorre uma falha (queda de energia, erro de software, etc.), o sistema precisa restaurar o banco de dados a um estado consistente. Para isso, utiliza-se o log de transações (ou write-ahead log), que registra todas as operações de escrita realizadas pelas transações, antes que elas sejam efetivadas no banco.

O processo de recuperação envolve duas operações principais: undo (desfazer) e redo (refazer). O rollback é a operação de undo, que desfaz os efeitos de transações que não foram confirmadas (não chegaram ao commit). Já as transações confirmadas (que chegaram ao commit) têm seus efeitos refeitos (redo) ou já estão persistidos, pois a durabilidade garante que, uma vez confirmadas, as alterações não podem ser perdidas.

A afirmação do enunciado erra ao dizer que o rollback retorna todas as transações, tanto as confirmadas quanto as não confirmadas. Na verdade, o rollback só desfaz as não confirmadas; as confirmadas são preservadas (ou refeitas) para garantir a durabilidade. Se o SGBD desfizesse também as confirmadas, violaria a propriedade de durabilidade, pois uma transação que já foi confirmada (e, portanto, prometida ao usuário) seria perdida.

Um exemplo clássico: imagine uma transferência bancária T1 que debita R$ 100 da conta A e credita R$ 100 na conta B. Se T1 for confirmada (commit) e, logo depois, ocorrer uma falha, o rollback não deve desfazer essa transferência, pois ela já foi confirmada. O sistema deve garantir que os R$ 100 continuem na conta B (durabilidade). Se T1 estivesse em andamento (sem commit) quando a falha ocorreu, aí sim o rollback desfaria as operações, retornando as contas ao estado anterior.

A pegadinha da banca está em generalizar o rollback para todas as transações, ignorando a distinção entre confirmadas e não confirmadas. O candidato que confunde rollback com uma "volta no tempo" geral acaba marcando "certo", mas o correto é entender que o rollback atua seletivamente, preservando o que já foi confirmado.

Guarde a fronteira: rollback desfaz apenas transações não confirmadas; transações confirmadas são preservadas (durabilidade). É exatamente nessa distinção que a questão se apoia.

Item — ❌ Errado

A afirmação está errada porque o rollback não retorna todas as transações ao estado anterior à falha. O rollback (undo) desfaz somente as transações não confirmadas (que não chegaram ao commit). As transações confirmadas (que chegaram ao commit) são preservadas ou refeitas (redo) para garantir a durabilidade (propriedade ACID). Se o SGBD desfizesse também as confirmadas, violaria a durabilidade, pois os efeitos de transações já confirmadas não podem ser perdidos.

Gabarito: Errado