一、事务冲突与数据库恢复

一旦出现一些意外事故，例如：数据机房突然断电，数据机房突然爆炸，数据库突然宕机等等突发事故，我们会出现大量的事务冲突，比如一个订火车票的软件，因为数据库宕机导致大量订单出现冲突风险，可能有的订单已经提交但是没有存储，可能有的订单正在提交过程中，但是并没有完成提交。

那么数据库出现这种问题时，我们如何恢复数据库？

根据ACID四项原则中的持久性和原子性，我们制订了两个规则：

Force policy-确保在提交之前每个更新都在磁盘上。 No Steal policy-不要允许带有未提交更新的缓冲池帧覆盖磁盘上已提交的数据。 当然，这样会给数据恢复提供很好的便利，但是现实生活中，这两种原则并不能实现。 所以我们在这两个原则下寻找更现实的方案：

我们发现Steal，No-force原则更加现实，这样我们能够使用UNDO,REDO操作。

如何操作？

要REDO已经存在稳定存储中的步骤，UNDO没有被稳定记录的步骤。REDO从上到下，UNDO从下到上。

举例：

[nr: 110, ta: 22, obj: x, b: 91, a: 78] [nr: 111, ta: 23, obj: z, b: 23, a: 54] [nr: 112, ta: 22, obj: x, b: 78, a: 53] [nr: 113, ta: 22, obj: y, b: 87, a: 64] [nr: 114, ta: 22, commit] [nr: 116, ta: 23, obj: y, b: 64, a: 85]

当执行到第116个语句时，数据系统宕机，请求恢复。

首先我们REDO，我们发现这里面只由TA22提交了，所以对TA22执行REDO

从上到下，

x存在78,第110完成，

x修改为53，112完成

y修改为64, 113完成

接下来执行UNDO，只有TA23没有提交，只对TA23执行UNDO

从下到上，

y修改为64，继续执行

z修改为23，结束

最终修复完成后x=53，y=64，z=23.