数据库事务处理：事务基本特性、锁和数据库恢复技术

故障种类：事务内部的故障、系统故障、介质故障 

恢复的实现技术 

(1)     数据转储：转储状态、转储方式 

(2)     日志：基本格式和内容、日志的作用、登记日志文件并发控制 

1.    问题：丢失修改、不可重复读、读“脏”数据 

2.    封锁共享锁、排它锁 

事物 

1．什么叫事务？ 

事务是用户定义的一组操作序列。 

①      事务是并发控制的基本单位。 

②      一个事务包含的诸操作要么都执行，要么都不执行。 

2． 事务的属性 

原子性 ：事务是数据库的逻辑工作单位，一个事务的诸操作要么都做，要么都不做。 

一致性 ：指事务执行前后必须保持数据库的逻辑一致性。一致性和原子性是密切相关的。 

隔离性 ：指并发执行的各个事务之间不能互相干扰。 

持续性 ：又称为持久性或永久性， 是指一个事务的操作提交后， 其对数据库的改变是永久的，属于物理的而非逻辑的。

数据的锁定 

一、并发操作与数据不一致性 

1．数据不一致性包括三类 

丢失修改 ：指事务  1 与事务 2 从数据库中读入同一数据并修改，事务 2 的提交结果破坏事务 1 提交的结果，导致事务1 的修改被丢失。 

不可重复读 ：指事务  1 读取数据后， 事务 2 执行更新操作，使事务  1 无法再现前一次读取结果。 

读脏数据：指事务  1 修改某一数据后，事务 2 读取该数据，事务1 由于某种原因被撤销，这时数据又恢复到原值，事务2 读到的数据与数据库中的数据不一致，称为“脏”数据。

产生“幽灵”数据 : 指当事务   T1 按一定条件从数据库中读取了某些数据记录后，事务T2 删除了其中的部分记录，或者在其中添加了部分记录，则当T1 再次按相同条件读取数据时，发现其中莫名其妙地少了（对删除）或多了（对插入）一些记录。这样的数据对T1 来说就是“幽灵”数据或称“幻影”数据。 

2．产生数据不一致性的原因：并发操作破坏了事务的隔离性。

 

二、并发控制的目标、方法

1.目标：确保  DB 中的数据一致性。

2.并发事务正确性的原则：几个事务的并发执行是正确的，当且仅当其结果与任何一个串行执行的结果相同

3.并发控制的方法：DBMS  一般采用“封锁”技术，保证并发操作的可串行化。 

 

三、封锁（ Locking ） 

1． 什么叫封锁？ 

SQL Server 自动强制封锁，并且会将封锁粒度控制在合适的级别，用户不必考虑封锁问题。 

2． 封锁类型 

排它锁（ X 锁）：事务 T对数据 A加X锁，其它事务不能再对A 加锁，即其它事务不能读取和修改 A 。 

共享锁（ S 锁）：事务 T对数据 A加S锁，其它事务只能再对A 加 S 锁，即其它事务只能读 A ，不能修改   A 。

3． 封锁粒度 

封锁对象可以是属性列、元组、关系、整个数据库。封锁对象的大小称为封锁粒度。 

封锁粒度越小，并发度越高，但并发控制的开销越大。

 

4． 封锁协议 （两段锁协议）

①事务 T 在修改数据 A 之前，必须对其加 X 锁，直到事务结束才释放。

②事务 T 在读取数据 A 之前，必须对其加 S 锁，直到事务结束才释放。

遵循封锁协议，可解决三种数据不一致性问题：丢失修改、问题不可重复读、读“脏”数据

 

四、死锁和活锁 

        封锁技术可以解决并发操作的不一致性问题，但也带来新的问题，即死锁和活锁。 

1． 死锁： 

① 定义：两个事务已经各自锁定一个数据，但是又要访问被对方锁定的数据，造成了循环等待，称为死锁。 

②  避免死锁的方法：

一次封锁法：一次性加载所有需要的数据资源。 

顺序封锁法：若规定封锁顺序为A， B，则 T1， T2 只能先封锁  A，再封锁 B。 

2．活锁： 

① 定义：若多个事务请求封锁同一个数据时，其中的某个事务总处于等待状态，则称为活锁。 

②避免活锁的方法：先来先服务  

 

一级封锁协议 

(1)     事务 T 在修改数据 R之前必须先对其加  X 锁，直到事务结束才释放 

(2)     解决的问题：防止丢失修改

 

二级封锁协议 

(1)  一级封锁协议加上事务T 在读取数据R 前必须先对其加S 锁，读完后即可释放S 锁 

(2)     解决的问题：防止丢失修改、防止读“脏”数据三级封锁协议

 三级封锁协议

(1) 一级封锁协议加上事务 T 在读取数据   R 前必须先对其加    S 锁，直到事务结束才释放。 

(2) 解决的问题：防止丢失修改、防止读“脏”数据、防止不可重复读 

 

3.

预防死锁的两种方法： 一次封锁法、顺序封锁法 

死锁的诊断：超时法，等待图法 

死锁的解除：撤消一个处理死锁代价最小的事务，释放此事务持有的所有锁，使其它事务得以继续进行下去。

 

数据库的恢复

数据库运行故障： 

事务故障（可以利用日志文件撤消此事务对数据库已进行的修改） 

系统故障 

介质故障（重装数据库，然后利用备份或镜像设备恢复数据库。）

1、事务内部故障的恢复 ：事务内部故障的恢复由 DBMS  自动完成， 对用户而言是透明的。 

DBMS  执行的恢复步骤如下： 

（ 1）反向扫描文件日志（即从后向前扫描日志文件），查找该事务的更新操作。 

（ 2）对该事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。 

（ 3）继续反向扫描日志文件，进行同样的处理。 

（ 4）如此继续下去，直至独到此事务的开始标记，该事务故障恢复就完成了。

 

2、系统故障的恢复 ：会造成数据库处于不一致的状态，主要是一方面，为完成事务对数据库所做的更新可能已写入数据库；另一方面， 已提交事务对数据库做的更新可能尚留在缓冲区，未能及时写入数据库。因此恢复操作就是撤销（ UNDO ）故障发生时为完成的事务，重做（ REDO ）已完成的事务。恢复步骤如下： 

（ 1）正向扫描日志文件，找出在故障发生之前已经提交的事务队列（ REDO 队列）和为完成的事务队列（   UNDO 队列）。 

（ 2）对于撤销队列中的各个事务进行UNDO  处理。

     进行 UNDO处理的方法是：反向扫描日志文件， 对每个 UNDO 事务的过呢更新操作执行逆操作， 即将日志记录中 “更新前的值”写入数据库中。 

（ 3）对重做队列中的各个事务进行 REDO 处理。

      进行 REDO 处理的方法是：正向扫描日志文件，对每个 REDO 事务重新执行日志文件中所登记的操作，激将日志记录中“更新后的值”写入数据库。

 3、截至故障的恢复 ：恢复方法是重装数据库，然后重做已完成的事务，具体操作如下： 

（ 1） DBA 装入最新的数据库后备副本（离故障发生时刻最近的转储副本） ,使数据库回复到转储时的一致性状态。 

（ 2） DBA 装入转储结束时的日志文件副本。 

（ 3） DBA 启动系统恢复命令，有  DBMS  实现恢复功能，即重做已完成的事务。

简述事务故障的恢复步骤。 

1)  反向扫描日志文件（即从最后向前扫描日志文件） , 查找该事务的更新操作。 

2)    对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。 

3)    继续反向扫描日志文件   , 查找该事务的其他更新操作   , 并做同样处理。 

4)    如此处理下去 , 直至读到此事务的开始标记 , 事务故障恢复就完成了。

简述系统故障的恢复步骤。 

1)    正向扫描日志文件（即从头扫描日志文件），找出重做  (REDO)  队列和撤销  (Undo)队列； 

2)  对撤销 (Undo) 队列事务进行撤销 (UNDO) 处理：即反向扫描日志文件 , 对每个UNDO事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库； 

3)  对重做 (Redo)队列事务进行重做  (REDO) 处理：即正向扫描日志文件  ,对每个  REDO 事务重新执行登记的操作。即将日志记录中“更新后的值”写入数据库。 

检查点记录的内容包括哪些？ 

1)    建立检查点时刻所有正在执行的事物清单； 

2)    这些事物最近一个日志记录的地址。重新开始文件用来记录各个检查点记录在日志文件中的地址。

附：

何谓静态转储？何谓动态转储？它们各有什么优缺点？ 

静态转储指在系统中无事务运行时进行的转储操作。转储期间不允许对数据库的任何存取、修改活动，得到的一定是一个数据一致性的副本。 

动态转储的转储操作与用户事务并发进行，转储期间允许对数据库进行存取或修改。 

静态转储实现简单，但必须等待正运行的事务结束后才能进行，新的事务也必须等转储结束后方可开始，降低了数据库的可用性。 

动态转储不用等待正在运行的用户事务结束即可开始，也不会影响新事务的运行，但不能确保副本中的数据一定正确有效，需要配合日志记录才能完成故障恢复。