在基于日志的恢复中，为啥我们要重做已提交的事务？

Posted 2023-03-16

【中文标题】在基于日志的恢复中，为啥我们要重做已提交的事务？

【英文标题】：In Log-Based Recovery why do we redo committed transactions?在基于日志的恢复中，为什么我们要重做已提交的事务？

【发布时间】：2017-12-31 01:30:00

【问题描述】：

日志是一系列日志记录，它维护有关数据库更新活动的信息。每当事务开始、读取、写入或提交时，它都会在日志中注册其特定操作。因此，现在从失败中恢复时，如果事务尚未提交，则需要撤消事务，如果已提交，则需要重做。我的疑问是关于这样做背后的逻辑。为什么我们需要重做已提交的事务？

参考：幻灯片 19 - http://codex.cs.yale.edu/avi/db-book/db6/slide-dir/PPT-dir/ch16.ppt

【问题讨论】：

在深入探讨一些非常具体的问题之前，请先了解更多背景信息。

我们撤消未提交的，然后重做已提交的 - 这听起来根本不对。

@stuartd 这是耶鲁大学教授写的书中提到的内容

@stuartd 是的，我提到了参考

你做到了，谢谢。不过这有点过头了。这是指部分完成的交易吗？

【参考方案1】：

已提交事务的数据更改（存储在 SGA 的数据库缓冲区中）不一定由数据库写入器 (DBWn) 后台进程立即写入数据文件。

因为它们在 SGA 中，所以它们对其他用户可见，但如果不立即写入数据文件，这些更改在提交后仍然可能丢失。

参考：https://docs.oracle.com/cd/B19306_01/server.102/b14220/transact.htm

图片参考：https://docs.oracle.com/cd/E17781_01/server.112/e18804/memory.htm#ADMQS174

【讨论】：

如果您认为这个问题是相关的，您是否也可以投票赞成这个问题。谢谢

【参考方案2】：

事务 T1 可能所有日志记录都已输出到稳定存储，但数据的实际更新仍在主内存中。如果此时发生故障，则重做此事务将确保所有因故障而实际上丢失的更新现在都将写入稳定存储。