4.10学习总结

数据库原理第七章 数据库保护

数据库保护包括数据的一致性和并发控制、安全性、备份和恢复等

7.1事务

7.1.1 事务

事务是用户定义的数据操作系列，这些操作作为一个完整的工作单元，一个事务内的所有语句被作为一个整体，要么全部执行，要么全部不执行。

7.1.2 事务的特征

原子性（Atomicity） ： 事务是数据库的逻辑工作单位，事务中的操作要么都做，要么都不做。

一致性（Consistency） ： 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

隔离性（Isolation） ： 数据库中一个事务的执行不能被其它事务干扰。

持久性（ Durability ） ：也称为永久性。 事务一旦提交，对数据库数据的改变是永久的。

保证事务的ACID特性是事务处理的重要任务。

事务的ACID特性可能遭到破坏的因素有两种： 多个事务并行运行时，不同事务的操作有交叉情况； 事务在运行过程中被强迫停止。

7.1.3 SQL事务处理模型

隐式事务： 每一条数据操作语句都自动成为一个事务。

显式事务： 有显式的开始和结束标记的事务。

两种处理方式：

ISO事务处理模型

T-SQL事务处理模型

ISO事务处理模型：

明尾暗头：事务的开头是隐含的，事务的结束有明确标记

A．事务结束符 COMMIT：事务成功结束符， ROLLBACK：事务失败结束符，

B．事务提交方式

自动提交：每条SQL语句为一个事务

指定位置提交：在事务结束符或程序正常结束处提交

C．事务起始/终止位置 程序的首条SQL语句或事务结束符后的语句。 在程序正常结束处或COMMIT语句处成功终止； 在程序出错处或ROLLBACK处失败终止。

T-SQL事务处理模型：

每个事务都有显式的开始和结束标记。 事务的开始标记是： BEGIN TRANSACTION | TRAN 事务的结束标记为： COMMIT ［TRANSACTION｜TRAN］ ROLLBACK ［TRANSACTION｜TRAN］

7.2 并发控制

多用户数据库系统的存在: 允许多个用户同时使用的数据库系统. 银行数据库系统 选课系统 特点：同一时刻并发运行的事务数可达数百个。 问题：有可能产生相互干扰。

不同的多事务执行方式：

串行执行 每个时刻只有一个事务运行，其他事务必须等到这个事务结束以后方能运行。 问题：不能充分利用系统资源，发挥数据库共享资源的特点。

交叉并行执行 在单处理机系统中，事务的并行执行是这些并行事务的并行操作轮流交叉运行。 单处理机系统中的并行事务并没有真正地并行运行，但能够减少处理机的空闲时间，提高系统的效率。

同时并发方式 多处理机系统中，每个处理机可以运行一个事务， 多个处理机可以同时运行多个事务，实现多个事务真正的并行运行。 

7.2.1 并发控制概述

事务并发执行带来的问题：

多个事务同时存取同一数据的情况。

可能会存取和存储不正确的数据。

破坏事务一致性和数据库的一致性。

并发控制是衡量DBMS性能的重要标志之一。

并发控制机制的任务：

对并发操作进行正确调度 保证事务的隔离性 保证数据库的一致性

并发操作带来的数据不一致性：

并发操作带来的数据不一致情况： 丢失修改（Lost Update） 读“脏”数据（Dirty Read） 不可重复读（Non-repeatable Read） 记号 R(x)：读数据x W(x)：写数据x

数据不一致性原因： 并发操作破坏了事务的隔离性。 并发控制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其他事务的干扰，从而避免造成数据的不一致性。

7.2.2 并发控制措施

控制目标： 事务运行过程中尽可能隔离事务外操作对本事务数据环境的影响。 并发控制的主要技术： 加锁(Locking)、时间戳、乐观控制法

一个事务对某个数据对象加锁后究竟拥有什么样的控制权由封锁的类型决定。 基本封锁类型 排它锁（Exclusive Locks，简记为X锁） 共享锁（Share Locks，简记为S锁）

排它锁：

排它锁又称为写锁（ X锁）。 若事务T对数据对象加上X锁，则允许事务T读取和修改数据，其它任何事务都不能再对此数据加任何类型的锁，直到事务T释放X锁。 保证其他事务在事务T释放X锁之前不能再读取和修改数据。

共享锁：

共享锁又称为读锁（ S锁） 。 若事务T对数据对象加上S锁，则其它事务只能再对数据加S锁，而不能加X锁，直到事务T释放数据上的S锁。 保证其他事务可以读数据 ，但是在事务T释放S锁前不能对数据做任何修改 。

7.2.3 封锁协议

封锁协议（加锁协议）： 在运用X锁和S锁对数据对象进行加锁时，还需要约定一些规则，如何时申请X锁或S锁、持锁时间、何时释放锁等。 对封锁方式规定不同的规则，就形成了各种不同级别的封锁协议。 不同级别的封锁协议达到的系统一致性级别不同。

一级封锁协议

规定： 对事务T要修改的数据加X锁，直到事务结束（包括正常结束和非正常结束）时才释放。 效果： 可以防止丢失修改 不能防止可重复读和不读“脏”数据。

二级封锁协议

规定： 一级封锁协议加上对事务T对要读取的数据加S锁，读完后即释放S锁。 效果： 可以防止丢失修改、防止读“脏”数据。 不能防止可重复读数据。

三级封锁协议

规定 一级封锁协议加上事务T对要读取的数据加S锁，并直到事务结束才释放。 效果： 可以防止丢失修改、防止读“脏”数据、防止不可重复读。

7.2.4 活锁和死锁

避免活锁： 采用先来先服务的策略。 当多个事务请求封锁同一数据对象时。 按请求封锁的先后次序对这些事务排队。 该数据对象上的锁一旦释放，首先批准申请队列中第一个事务获得锁。

 死锁的预防

产生死锁的原因： 两个或多个事务都已封锁了数据对象，又都请求对已被其他事务封锁的数据对象加锁，从而出现死等待。 预防死锁的发生就是要破坏产生死锁的条件。 预防死锁的方法 一次封锁法、顺序封锁法。

(1)一次封锁法：

要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。 存在的问题： 降低系统并发度； 难于事先精确确定封锁对象。

(2)顺序封锁法：

顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。 存在的问题 维护成本大： 数据库系统中封锁的数据对象多，且在不断地变化。 难以实现： 很难事先确定每一个事务要封锁哪些对象。

2. 死锁的诊断与解除

死锁的诊断方式： 超时法 事务等待图法

(1) 超时法

如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。 优点：实现简单。 缺点： 时限设置过短，有可能误判死锁； 时限设置太长，死锁发生后不能及时发现。

(2)等待图法

用事务等待图动态反映所有事务的等待情况： 事务等待图是一个有向图， 每个结点表示正运行的事务， 每条边表示事务等待的情况， 若T1等待T2，则从T1指向T2划一条有向边。 图中存在回路，则表示系统中出现了死锁。

7.2.5 并发调度的可串行性

可串行化调度： 多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同。

可串行性： 并发事务正确调度的准则。 一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度 。

7.2.6两段锁协议

两段锁协议： 指所有事务必须分两个阶段对数据项加锁和解锁。 第一阶段是获得封锁，也称为扩展阶段： 事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁 。 第二阶段是释放封锁，也称为收缩阶段： 事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁 。

事务遵守两段锁协议是可串行化调度。 可串行化调度不一定都符合两段锁协议 。

两段锁协议与防止死锁的一次封锁法： 一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，因此一次封锁法遵守两段锁协议。 两段锁协议并不要求事务必须一次将所有使用的数据全部加锁，因此遵守两段锁协议的事务可能发生死锁。

7.3 数据库备份与恢复

故障是不可避免的

系统故障：计算机软、硬件故障；

人为故障：操作员的失误、恶意的破坏等。 数

据库的恢复 把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)。

7.3.1 数据库故障的种类

事务内部的故障 系统故障 其他故障

事务内部的故障：

事务内部故障指非预期的，不能由应用程序处理 例如：运算溢出，违反了某些完整性限制等。

事务故障的恢复： 事务故障意味着事务没有达到预期的终点，数据库可能处于不正确状态，因此，要在不影响其它事务运行的情况下，撤销该事务已经做的对数据库的修改，使得该事务好像根本没有运行一样。 事务故障的恢复操作： 撤销事务（UNDO）。

系统故障:

系统故障 称为软故障，是指造成系统停止运转的任何事件，使得 系统要重新启动。 例如：突然断电。 带来的问题： 整个系统的正常运行突然被破坏； 所有正在运行的事务都非正常终止； 数据库缓冲区的信息全部丢失；不破坏数据库。

系统故障的恢复:

发生系统故障时，事务未完成 恢复策略：强行撤消（UNDO）所有未完成事务。 发生系统故障时，事务已提交，但缓冲区中的信息尚未完全写回到磁盘上。 恢复策略：重做（REDO）所有已提交的事务。

其他故障:介质故障 ,计算机病毒

 

介质故障 :

介质故障 称为硬故障，指外存故障。 磁盘损坏； 磁头碰撞； 操作系统的某种潜在错误； 瞬时强磁场干扰。 会破坏数据库或部分数据库，并影响正在存取这部分数据的事务。这类故障发生的可能性小，但破坏性很大。

介质故障的恢复:

1、装入数据库发生介质故障前某个时刻的数据副本； 2、重做自此时始（副本备份时刻）的所有成功事务，将 这些事务已提交的结果重新记入数据库。

计算机病毒:

计算机病毒 一种人为的故障或破坏，一种计算机程序； 可以繁殖和传播。 危害 破坏、盗窃系统中的数据； 破坏系统文件。

应对策略： 查杀病毒，注意安全保护，安装防火墙和实时监控软件； 根据数据备份文件和日志文件恢复数据库。

各类故障，对数据库的影响有两种： 数据库本身被破坏。 数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的。

7.3.2数据库备份

恢复操作的基本原理：冗余 利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据。

数据的恢复涉及两个关键问题： 如何建立冗余数据； 备份 如何利用这些冗余数据实施数据库恢复。

备份的内容:

备份数据（数据转储） 表（结构），包含系统表、用户定义的表。 数据库用户（包括用户和用户操作权）。 用户定义的数据库对象和数据库中的全部数据 备份日志（登记日志文件）

备份频率:

要考虑两个因素： 出现故障时，允许丢失的数据量的大小。 数据库的事务类型（读多还是写多）以及事故发生的频率（经常发生还是不经常发生）。

通常情况下，数据库可以每周备份一次，事务日志可以每日备份一次。 对于一些重要的联机事务处理数据库，可以每日备份，事务日志则每隔数小时备份一次。

备份数据（数据转储）:

数据转储： 转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程，备用的数据称为后备副本或后援副本。

如何使用： 数据库遭到破坏后可以将后备副本重新装入； 重装后备副本只能将数据库恢复到转储时的状态。

备份方法： 静态转储与动态转储 海量转储与增量转储

静态转储与动态转储

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

优点：实现简单。 缺点：降低了数据库的可用性。

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

优点：不会影响事务的运行。 缺点：不能保证副本中的数据正确有效。

海量转储与增量转储:

海量转储: 每次转储全部数据库。

增量转储: 只转储上次转储后更新过的数据。

海量转储与增量转储比较： 从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便； 但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效。

7.3.3数据库恢复

恢复数据库是指将数据库从错误描述状态恢复到正确的描述状态（最近的正确时刻）的过程。

恢复策略,恢复技术

1 事务故障的恢复 2 系统故障的恢复 3 介质故障的恢复

1 事务故障的恢复

事务故障： 事务在运行至正常终止点前被终止。 恢复方法： 利用日志文件撤消此事务已对数据库进行的修改。 事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预。

事务故障的恢复步骤

1. 反向扫描文件日志，查找该事务的更新操作。 2. 对该事务的更新操作执行逆操作。 3. 继续反向扫描日志文件，查找其他更新操作，同样处理。 4. 直至读到此事务的开始标记，事务故障恢复就完成了。

2 系统故障的恢复

系统故障造成数据库不一致状态的原因： 未完成事务对数据库的更新已写入数据库； 已提交事务的更新还留在缓冲区没来得及写入数据库。 恢复方法： 1. 撤销故障发生时未完成的事务； 2. 重做已完成的事务。 系统故障的恢复由系统在重新启动时自动完成。

系统故障的恢复步骤

1. 正向扫描日志文件： 重做队列: 在故障发生前已经提交的事务； 撤销队列: 故障发生时尚未完成的事务； 2. 对撤销队列事务进行撤销处理： 反向扫描日志文件，对每个撤销事务执行逆操作。 3. 对重做队列事务进行重做处理： 正向扫描日志文件，对每个重做事务重新执行。

3 介质故障的恢复

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

介质故障恢复的步骤

1、装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态。 利用静态转储的数据库副本，装入数据库后，系统处于一致性状态 利用动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，才能将数据库恢复到一致性状态。 2. 装入有关的日志文件副本，重做已完成的事务。 首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。 然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。

介质故障的恢复

介质故障的恢复需要DBA介入。 DBA的工作： 重装最近转储的数据库副本和有关的各日志文件副本； 执行系统提供的恢复命令。 具体的恢复操作仍由DBMS完成。

7.3.4 数据库恢复技术

1、利用备份技术 :

定期备份； 利用备份文件将数据库恢复到备份时刻的状态。

2、利用事务日志 :

利用事务日志可以恢复执行不完整的事务； 恢复数据库到事务执行前的状态； 系统自动完成。

3、数据库镜像:

问题： 介质故障是对系统影响严重，影响数据库的可用性。 介质故障恢复比较费时； 为预防介质故障，DBA必须周期性地转储数据库。 解决方案： 数据库镜像（Mirror）： DBMS自动把整个数据库或关键数据复制到另一个磁盘上。 DBMS自动保证镜像数据与主数据库的一致性。 当主数据库更新时，DBMS自动把更新后的数据复制过去。

数据库镜像的用途:

没有出现故障时： 数据库镜像可用于并发操作。 出现介质故障时： 可由镜像磁盘继续提供使用； 同时DBMS自动利用镜像磁盘数据进行数据库的恢复； 不需要关闭系统和重装数据库副本。 频繁地复制数据自然会降低系统运行效率。 只对关键数据和日志文件镜像，而不是对整个数据库进行镜像。