【数据库CS751:事务处理Transaction Processing(3)】——事务冲突与数据库恢复

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

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

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

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

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

【数据库CS751:事务处理Transaction Processing(3)】——事务冲突与数据库恢复_第1张图片

 我们发现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]
【数据库CS751:事务处理Transaction Processing(3)】——事务冲突与数据库恢复_第2张图片

 

当执行到第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.

你可能感兴趣的:(数据库,数据库,database)