数据库日志

数据库日志（根据HIT战神讲义截取，仅供个人复习）

一、事务所涉及到的

数据库通常由元素构成，通常一个元素=1个磁盘块也可以更小，等于1条记录或者更大等于1个关系。

每个事务都会读写某些元素

READ(X,t):将元素X读到事务的局部变量t中；

WRITE(X,t):将事务局部变量t写回元素X；

INPUT(X):将元素X从磁盘读入到内存缓冲区中；

OUTPUT(X):将元素X写回到磁盘中。

每个事务都以提交或者撤销结束

COMMIT：事务提交

ABORT：事务撤销

DBMS需要保证事务

1. 持久性

   • 已提交的事务——缓冲区内容保证写回磁盘
   • 未提交的事务——缓冲区内容不能影响磁盘

2. 原子性

   事务的所有操作，要么全都执行，要么全不执行。

注意：缓冲区内容和磁盘内容并不是时刻保持一致的。

二、不同缓冲区策略

Force:内存中的数据最晚在commit的时候写入磁盘。

No steal:不允许在事务commit之前把内存中的数据写入磁盘。

No force:内存中的数据可以一直保留，在commit之后过一段时间再写入磁盘。此时在系统崩溃的时候可能还没写入到磁盘，需要Redo,此方式较为灵活。

Steal:允许事务commit之前把内存中的数据写入磁盘，此时若系统在commit之前崩溃时，已经有数据写入到磁盘了，要恢复到崩溃前的状态，需要Undo,此方式同样较为灵活。

当前最常用：Steal + No force

三、关于日志

三种日志记录内容和记录次序不同，恢复策略也不同。

发生系统故障时，使用日志进行恢复：

• 故障时已提交的事务，重做Redo;
• 故障时未提交的事务，撤销Undo。

四、Undo型日志及其故障恢复

定义

利用Undo日志恢复手段

例

检查点

五、Redo型日志及其故障恢复

定义

Redo日志实例

利用Redo日志恢复手段

例

检查点

执行顺序

六、Undo/Redo结合型日志及其故障恢复

Redo/Undo日志比较

定义

利用Undo/Redo日志恢复手段

例

执行顺序