（教妹学数据库系统）（十二）故障恢复

hello大家好，好久不见！今天我们继续学习《教妹学数据库系统》。教妹学数据库，没见过这么酷炫的标题吧？“语不惊人死不休”，没错，标题就是这么酷炫。 我的妹妹小埋18岁，校园中女神一般的存在，成绩优异体育万能，个性温柔正直善良。然而，只有我知道，众人眼中光芒万丈的小埋，在过去是一个披着仓鼠斗篷，满地打滚，除了吃就是睡和玩的超级宅女。而这一切的转变，是从那一天晚上开始的。 从此之后，小埋经常让我帮她辅导功课。今天她想了解数据库系统中的故障恢复。本篇教程通过我与小埋的对话的方式来谈一谈故障恢复。 故障恢复(failure recovery) 故障发生后，DBMS将数据库恢复到最新的一致性状态 故障 故障恢复是数据库管理系统(DBMS)的关键功能之一，它确保在各种故障情况下，数据库能够恢复到一个一致性的状态，即在故障发生前所有已完成的事务的影响都能被正确反映，而未完成的事务则被撤销。本篇教程以对话的形式介绍了数据库系统中的故障恢复概念。 我们来理解几种常见的故障类型： 1. 事务故障：事务在执行过程中由于内部错误（如违反完整性约束）或内部状态错误（如死锁）而无法完成。在这种情况下，DBMS需要撤销未完成事务对数据库的修改。 2. 系统故障：包括软件故障（如DBMS的bug）和硬件故障（如计算机崩溃）。这类故障可能导致DBMS需要重新启动，但通常不会破坏非易失性存储器中的数据。 3. 存储介质故障：非易失性存储设备出现问题，可能损坏存储的数据。对于这类故障，可能需要依赖备份和恢复操作来恢复数据库。 在故障恢复过程中，DBMS执行两种主要操作： 1. 撤销（Undo）：撤销未完成事务对数据库的修改，以确保这些事务不会影响一致性状态。 2. 重做（Redo）：重做已提交事务对数据库的修改，因为这些事务在故障发生前已经被确认为完成。 DBMS的缓冲池策略影响着撤销和重做的处理方式： - STEAL策略允许未提交事务的修改写入磁盘并覆盖现有数据，而NO-STEAL策略则不允许。STEAL策略在发生故障时需要撤销操作，因为它可能会有未提交的修改；而NO-STEAL策略无需撤销，因为它保证未提交的修改不会持久化。 - FORCE策略要求事务在提交前将所有修改写回磁盘，而NO-FORCE策略不要求。FORCE策略在故障恢复时不需要重做，因为所有提交的事务都已经写回；而NO-FORCE策略可能需要重做，因为并非所有事务都在提交前写回。 预写式日志（Write-Ahead Logging, WAL）是一种广泛采用的保证数据一致性的方法。WAL要求DBMS在写入数据之前先将日志记录写入稳定的存储器，日志记录包含足够的信息以供撤销或重做。WAL协议规定事务在启动、提交和修改对象时都要写入相应的日志记录，并且在返回确认给应用程序之前，必须确保所有日志记录已经刷写到磁盘。 故障恢复过程分为两个阶段： 1. 在正常执行时，记录日志并根据缓冲池策略将修改写回磁盘。 2. 在故障恢复时，根据日志和缓冲池策略对事务进行撤销或重做。根据日志，事务可以分为已提交事务、不完整事务和已中止事务。已中止事务的修改被视为从未执行过，因此不需要撤销。 总结来说，故障恢复是数据库系统为了保持数据完整性的重要机制。通过理解事务的分类、缓冲池策略以及预写式日志的工作原理，我们可以更好地了解DBMS如何在面临不同类型的故障时，有效地恢复数据库到一致状态。