恢复系统分析.ppt

第9章 恢复系统 本章内容参考: 数据库概念(第四版) by A. Silberschatz Chapter 17 Recovery System 补充内容 本章内容特色: 数据库恢复的“道理”较容易理解 但编程实现较难，算法较多 本章要解决的关键问题： 如何预防和应付各种”故障”,保证ACID性质 * * * * * * * * * * * * * * * * * * * * * * * Undo: in restart-undo, do global ordering of undos abort-undo: since focusing on one transaction, use chained local ordering of undos * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Implementing Commit(T) Commit must be atomic, So it must be implemented by a disk write Suppose T wrote P, T committed, and then the system fails, P must be in stable storage Redo rule: Don’t commit a transaction until the after-images of all pages it wrote are on stable storage(Ensures redo is possible) Often called the Force-At-Commit rule Avoiding Redo To avoid redo, flush all of T’s updates to the stable database before it commits(They must be in stable storage) Usually called a force algorithm, because updates are forced to disk before commit It’s easy, because you don’t need stable bookkeeping of after images But it’s inefficient for hot pages Conversely, a recovery algorithm requires redo if a transaction may commit before all of its updates are in the stable database (no force buffer policy) Avoiding Undo and Redo? To avoid both undo and redo never flush uncommitted updates (to avoid undo), and flush all of T’s updates to the stable database before it commits (to avoid redo) Thus, it requires installing all of a transaction’s updates into the stable database in one write to disk Shadow pages technique It can be done, but it isn’t efficient for short transactions and record-level updates Implementing Restart To recover from a system failure Abort transactions that were active at the failure For every committed transaction, install after-image as current state. Resume normal processing of transactions Restart must be idempotent (many executions of the operation have the same eff