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

野性酷女 2022-06-08 05:48 307阅读 0赞

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

**恢复的实现技术**

**(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) 解决的问题：防止丢失修改、防止读“脏”数据、防止不可重复读

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

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

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

## 数据库的恢复 ##

数据库运行故障：

> 事务故障（可以利用日志文件撤消此事务对数据库已进行的修改） 
> 
> 系统故障 
> 
> 介质故障（重装数据库，然后利用备份或镜像设备恢复数据库。）
> 
>   
>

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) 这些事物最近一个日志记录的地址。重新开始文件用来记录各个检查点记录在日志文件中的地址。
> 
>   
>

**附：**

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

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

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

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

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

>   
>