数据库原理的十章知识点

10.1事务的基本概念

10.1.1事务

事务（ Transaction）是用户定义的一个数据库操作序列这些操作要么全做，要么全不做，是一个不可分割的工作单位。
事务是恢复和并发控制的基本单位

定义方式

• 显示定义方式：
  BEGIN TRANSACTION
  SQL语句1
  SQL语句2
  …
  COMMIT/ROLLBACK
  • COMMIT：事务正常结束，提交事务的所有操作，事务中所有对数据库的更新写回到磁盘上的物理数据库中
  • ROLLBACK：事务异常终止，事务运行的过程中发生了故障，不能继续执行，系统将事务中对数据库的所有已完成的操作全部撒销事务滚回到开始时的状态
• 隐式定义方式——当用户没有显式地定义事务时，数据库管理系统按缺省规定自动划分事务

10.1.2事务的ACD特性

• 原子性（ Atomicity）——事务中包括的诸操作要么都做，要么都不做
• 一致性（Coinsistency）——事务执行的结果必须是使数据库从一个一致性状态变马一个一性状杰
• 隔离性（ Isolation）——一个事务的执行不能被其他事务干扰
• 持续性（ Durability）——一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

破坏事务ACID特性的因素

• 多个事务并行运行时，不同事务的操作交叉执行
• 事务在运行过程中被强行停止

10.2数据库恢复概述

10.2.1故障

故障是不可避免的，故障会造成运行事务非正常中断，影响数据库中数据的正确性，破坏数据库，全部或部分丢失数据

10.2.2数据库的恢复

数据库管理系统必须具有把数据库从错误状态恢复到某已知的正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复管理系统对故障的对策

10.3故障的种类

1. 事务内部故障
2. 系统故障
3. 介质故障
4. 计算机病毒

10.3.1事务内部故障

事务内部更多的故障是非预期的，是不能由应用程序处理的。如运算溢出，并发事务发生死锁而被选中撤销该事务等

影响：

• 事务没有达到预期的终点 COMMIT或者显式的 ROLLBACK）
• 数据库可能处于不正确状态。

恢复手段：事务撤消（UNDO）

• 强行回滚（ ROLLBACK）该事务
• 撤销该事务已经作出的任何对数据库的修改，使得该事务象根本没有启动一样

10.3.2系统故障

称为软故障，是指造成系统停止运转的任何事件，使得系统要重新启动，如操作系统故障，系统断电等

影响：

• 整个系统的正常运行突然被破坏
• 所有正在运行的事务都非正常终止
• 内存中数据库缓冲区的信息全部丢失
• 不破坏数据库

恢复手段：

• 撤销所有未完成的事务
• 重做所有已提交的事务

10.3.3介质故障

称为硬故障，指外存故障，如磁盘损坏，磁头碰撞等
影响：

• 介质故障破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务
• 介质故障比前两类故障的可能性小得多，但破坏性大得多

10.3.4计算机病毒故障

计算机病毒已成为计算机系统的主要威胁，自然也是数据库系统的主要威胁,数据库一旦被破坏仍要用恢复技术把数据库加以恢复

10.4恢复的实现技术

10.4.1数据转储

数据转储的定义

数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程

转储方法

• 静态转储与动态转储（转储的时机不同）
• 海量转储与增量转储（转储的数量不同）

静态转储

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

动态转储

• 转储操作与用户事务并发进行
• 转储期间允许对数据库进行存取或修改
• 不能保证副本中的数据正确有效
• 故障恢复时需要日志文件才能恢复到某一时刻正确状态

海量转储

每次转储全部数据库增量转储
从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便

增量转储

只转储上次转储后更新过的数据海量转储与增量转储比较
如果数据库很大，事务处理又十分频繁，增量转储方式更实用更有效

10.4.2登记日志文件

日志文件（ log file）是用来记录事务对数据库的更新操作的文件

日志文件的格式和内容

• 以记录为单位的日志文件
  • 各个事务的开始标记（BEGIN TRANSACTION）
  • 各个事务的结束标记（ COMMITI或 ROLLBACK）
  • 各个事务的所有更新操作
• 以数据块为单位的日志文件
  • 事务标识
  • 被更新的数据块

日志文件的作用

• 进行事务故障恢复
• 进行系统故障恢复
• 协助后备副本进行介质故障恢复

登记日志文件

• 登记的次序严格按并发事务执行的时间次序
• 必须先写日志文件，后写数据库

10.5恢复策略

10.5.1事务故障的恢复

事务故障：事务在运行至正常终止点前被终止

恢复方法

由恢复子系统利用日志文件撤消（UNDO）此事务已对数据库进行的修改
事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预

10.5.2系统故障的恢复

恢复方法

1. Undo故障发生时未完成的事务
2. Redo已完成的事务

系统故障的恢复由系统在重新启动时自动完成，不需要用户干预

10.5.3介质故障的恢复

恢复方法

1. 重装数据库
2. 重做已完成的事务

介质故障的恢复需要数据库管理员介入数据库管理员的工作：

1. 重装最近转储的数据库副本和有关的各日志文件副本
2. 执行系统提供的恢复命令

10.6具有检查点的恢复技术

10.6.1问题的提出

• 搜索整个日志将耗费大量的时间
• 重做处理：重新执行，浪费了大量时间

10.6.2检查点技术

• 在日志文件中增加检查点记录（ checkpoint）
• 增加重新开始文件
• 恢复子系统在登录日志文件期间动态地维护日志

检查点记录内容

• 建立检查点时刻所有正在执行的事务清单
• 这些事务最近一个日志记录的地址

动态维护日志文件的方法

周期性地执行如下操作：

• 建立检查点
  • 定期
  • 不定期
• 保存数据库状态。
  

重新开始文件的内容

记录各个检查点记录在日志文件中的地址

10.6.3利用检查点的恢复策略

1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录
2. 由该检查点记录得到检查点建立时刻所有正在执行的事务清单 ACTIVE-LIST，建立两个事务队列：UNDO-LIST和REDO-LIST，把 ACTIVE-LIST暂时放入UND-LIST队列，REDO队列暂为空。
3. 从检査点开始正向扫描日志文件，直到日志文件结束，如有新开始的事务T，把T暂时放入 UNDO-LIST队列，如有提交的事务T，把T从 UNDO-LIST队列移到REDO-LST队列；直到日志文件结束
4. 对 UNDO-LIST中的每个事务执行UNDO操作对 REDO-LIST中的每个事务执行REDO操作

10.7数据库镜像

10.7.1数据库镜像的原因

介质故障是对系统影响最为严重的一种故障，严重影响数据库的可用性
介质故障恢复比较费时，为预防介质故障，数据库管理员必须周期性地转储数据库

10.7.2数据库镜像的操作

• 数据库管理系统自动把整个数据库或其中的关键数据复制到另一个磁盘上
• 数据库管理系统自动保证镜像数据与主数据的一致性，每当主数据库更新时，数据库管理系统自动把更新后的数据复制过去

因为频繁地复制数据自然会降低系统运行效率，在实际应用中用户往往只选择对关键数据和日志文件镜像。而不是对整个数据库进行镜像

10.7.2数据库镜像的作用

出现介质故障

可由镜像磁盘继续提供使用，同时数据库管理系统自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本

没有出现故障时

可用于并发操作个用户对数据加排他锁修改数据，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁