Questão de Banco de Dados — SQL Server — Quadrix 2025
Banco de Dados›SQL Server
Código
qg599048
Banca
Quadrix
Órgão
CRMV-GO
Ano
2025
Nível
Superior
Cargo
Analista Administrativo
Acerca dos bancos de dados relacionais e NoSQL, do gerenciamento de usuários e das permissões e dos conceitos de virtualização, julgue o item a seguir.No SQL Server, o Transaction Log é responsável por garantir a atomicidade e a durabilidade das transações, permitindo a recuperação ponto a ponto (detalhada) de dados em caso de falhas, inclusive no modo Simple Recovery Model.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
Transaction Log e Simple Recovery Model no SQL Server
Gabarito: ERRADO. O Transaction Log garante atomicidade e durabilidade, mas a recuperação ponto a ponto (point-in-time) não é possível no Simple Recovery Model — nesse modelo, o log é truncado periodicamente, permitindo apenas a recuperação até o último backup completo/diferencial. A afirmação está incorreta ao afirmar que a recuperação detalhada é possível nesse modo.
O Transaction Log (log de transações) é um componente fundamental de qualquer banco de dados do SQL Server. Ele registra, em sequência, todas as modificações feitas no banco, antes mesmo de os dados serem gravados nas páginas de dados (técnica conhecida como write-ahead logging — WAL). Essa gravação antecipada é o que permite ao SGBD garantir duas das propriedades ACID:
Atomicidade: se uma transação falhar no meio, o log contém as informações necessárias para desfazer (rollback) as alterações já feitas, restaurando o estado anterior.
Durabilidade: se o sistema falhar após o commit, o log garante que as alterações confirmadas possam ser refeitas (redo) quando o banco for reiniciado.
O log também é a base para os backups de log e para a recuperação point-in-time (PITR), que permite restaurar o banco para um momento específico no tempo, como um minuto antes de um erro lógico. No entanto, essa capacidade depende diretamente do modelo de recuperação configurado para o banco. O SQL Server oferece três modelos:
Modelo de Recuperação
Backup de Log
Recuperação Point-in-Time
Comportamento do Log
Simple
Não permitido
Não suportada
O log é truncado automaticamente após cada checkpoint, mantendo apenas o necessário para rollback de transações ativas.
Full
Permitido
Suportada
O log cresce continuamente até o próximo backup de log, preservando todo o histórico de transações.
Bulk-Logged
Permitido (com ressalvas)
Suportada (com limitações)
Semelhante ao Full, mas operações em massa são minimamente logadas.
A pegadinha da questão está exatamente em afirmar que a recuperação ponto a ponto é possível inclusive no Simple Recovery Model. Nesse modelo, como o log é truncado, não há histórico suficiente para restaurar o banco para um ponto específico no tempo — a recuperação se limita ao último backup completo ou diferencial. Para usar PITR, é obrigatório o modelo Full (ou Bulk-Logged, com restrições).
NÃO CAIA NESSA!
A banca mistura a função geral do Transaction Log (garantir atomicidade e durabilidade) com uma capacidade que depende do modelo de recuperação. O candidato que sabe que o log garante ACID tende a marcar "certo", mas esquece que a recuperação point-in-time exige o modelo Full. No Simple, o log é truncado e não há como recuperar ponto a ponto.
Na prática, se um banco está no Simple Recovery Model e ocorre uma falha, a restauração só pode ser feita até o último backup completo ou diferencial — qualquer transação confirmada após esse backup será perdida. Para minimizar perdas, é preciso mudar para o modelo Full e fazer backups de log regulares.
Guarde a distinção: Transaction Log = garante atomicidade e durabilidade (sempre), mas recuperação point-in-time = só com modelo Full (ou Bulk-Logged). É exatamente essa fronteira que decide a questão.
Item — ❌ ERRADO
A afirmação está incorreta porque, embora o Transaction Log realmente garanta atomicidade e durabilidade, a recuperação ponto a ponto (detalhada)não é possível no Simple Recovery Model. Nesse modelo, o log é truncado automaticamente após cada checkpoint, descartando o histórico de transações confirmadas. Sem esse histórico, não há como restaurar o banco para um momento específico — a recuperação fica limitada ao último backup completo ou diferencial. A recuperação point-in-time exige o modelo Full (ou Bulk-Logged, com restrições), que mantém o log íntegro até o próximo backup de log.