Questão de Banco de Dados — Transações (Locks, ACID, etc.) — FUNDATEC 2025

Regras de recuperação de transações: steal, no-steal, force e no-force

Gabarito: letra A. As três assertivas estão corretas: a regra force exige que as páginas atualizadas sejam gravadas em memória secundária antes do commit; a regra no-force permite que uma página atualizada por transação confirmada permaneça em cache; e a regra no-steal impede que páginas de transações não confirmadas sejam gravadas, tornando o UNDO desnecessário. Esses conceitos são fundamentais para entender como o SGBD garante a durabilidade e a atomicidade das transações.

O processo de recuperação de falhas em um SGBD depende de duas decisões de projeto: quando uma página modificada pode ser gravada do cache para o disco e se uma página não confirmada pode ser gravada. Essas decisões são capturadas por quatro regras combináveis: force e no-force (quando gravar) e steal e no-steal (o que pode ser gravado).

A regra force determina que todas as páginas atualizadas por uma transação sejam gravadas em memória secundária antes que a transação confirme (commit). Isso garante que, após o commit, os dados já estejam persistentes, simplificando a recuperação — não é necessário refazer (REDO) as operações de transações confirmadas, pois elas já estão no disco. A regra no-force, por outro lado, permite que as páginas atualizadas permaneçam em cache mesmo após o commit, sendo gravadas posteriormente. Isso melhora o desempenho (menos I/O no momento do commit), mas exige que o log registre as operações para que, em caso de falha, o REDO possa ser aplicado.

A regra steal permite que uma página modificada por uma transação não confirmada seja gravada em disco antes do commit. Isso é comum em sistemas com cache limitado, mas exige que o log registre os valores antigos para permitir o UNDO (desfazer) em caso de rollback. A regra no-steal proíbe essa gravação antecipada: páginas de transações não confirmadas nunca são gravadas em disco. Como consequência, se a transação falhar, não há nada para desfazer — o UNDO nunca é necessário. A combinação no-force + steal é a mais comum em SGBDs modernos (como PostgreSQL e Oracle), pois equilibra desempenho e complexidade de recuperação.

A pegadinha desta questão está em associar corretamente cada regra à sua consequência na recuperação. O candidato pode confundir no-steal com no-force, ou achar que no-steal exige REDO em vez de eliminar o UNDO. A assertiva III é a mais delicada: como o no-steal impede a gravação de páginas não confirmadas, não há efeitos parciais no disco para desfazer — logo, o UNDO é desnecessário. Já a assertiva II explora a consequência do no-force: a página pode continuar em cache e ser atualizada por outra transação, o que é permitido.

Guarde a distinção central: force/no-force decide o momento da gravação em relação ao commit; steal/no-steal decide se páginas não confirmadas podem ser gravadas. É exatamente essa fronteira que as assertivas testam.

Assertiva I — ✅ Correta

A regra force determina que todas as páginas atualizadas por uma transação sejam gravadas em memória secundária antes do commit. Isso garante que, ao confirmar, os dados já estejam persistentes, simplificando a recuperação (não é necessário REDO para transações confirmadas). A assertiva está correta ao afirmar que a gravação ocorre "imediatamente" antes da confirmação.

Assertiva II — ✅ Correta

Na regra no-force, as páginas atualizadas por uma transação confirmada podem permanecer em cache, sendo gravadas em disco posteriormente. Isso significa que outra transação pode atualizar a mesma página enquanto ela ainda está em cache, o que é permitido. A assertiva está correta ao descrever essa possibilidade.

Assertiva III — ✅ Correta

Na regra no-steal, páginas de transações não confirmadas nunca são gravadas em disco. Se a transação falhar, não há efeitos parciais no disco para desfazer — portanto, operações de UNDO nunca são necessárias. A assertiva está correta ao afirmar essa consequência.

Gabarito: letra A — todas as assertivas estão corretas.