2009年 11月 10日Designed by Tao Hongcai 1
第五章 数据库安全性
学习目的和要求
◆ 数据库保护概况
◆ 数据库与 OS在安全上的关系
◆ 数据库安全性的目标
◆ 数据库的访问控制类型
◆ DAC访问控制的授 /撤权
◆ SQL SERVER的安全体系结构
◆ 数据库安全其他内容：数据加密、审计、统计数据库安全等
2009年 11月 10日Designed by Tao Hongcai 2
5.1 数据库保护概况
一, 数据库破坏类型
② Concurrency Execution引起数据不一致；
③ 人为破坏；
④ 对数据操作引入的数据错误。
① System Failure；
二, 各种类型的保护措施
② Concurrency Execution引起数据不一致 ── 幵収控制；
③ 人为破坏 ── 数据库安全；
④ 对数据操作引入的数据错误 ── 数据库完整性。
① System Failure ── 故障恢复；
2009年 11月 10日Designed by Tao Hongcai 3
5.2 数据库安全性概况
回答如下问题,
1.数据库与 OS在安全上的关系？
2.数据库安全性的目标？
3,DoD Security Levels？
4.用户标识与鉴别？
2009年 11月 10日Designed by Tao Hongcai 4
一,数据库与 OS在安全上的关系
① 除了 OS的安全屏障外,DBMS为加强其安全性，亦应建立有
自己的安全体系；
② 由于 DBMS建立在 OS乊上，要求 OS提供承诺，即：不允许用
户绕过 DBMS安全体系而直接访问 DB；
③ 正是因为 DBMS和 OS有各自独立的安全体系，因此 OS的用户
要想访问 DBMS，必须由 DBA设置成 DBMS的用户。
2009年 11月 10日Designed by Tao Hongcai 5
二,数据库安全性的目标
① Secrecy；
② Integrity；
③ Availability。
2009年 11月 10日Designed by Tao Hongcai 6
三, DoD Security Levels
1.访问控制类型
强制访问控制 MAC (Mandatory Access Control),基于全系
统范围策略，而不由某个用户改变。 DB对象和用户分别具有
相应的安全级别 (Security Class和 Clearance)，用户只有在满足一
定规则才能访问某个 DB对象。
标准支持情冴,SQL-92不支持 MAC。
自主式访问控制 DAC (Discretionary Access Control),基于访
问权限概念。 SQL-92通过 GRANT和 REVOKE支持该 DAC。
2009年 11月 10日Designed by Tao Hongcai 7
2.Levels
安全级,按 A,B,C和 D四个等级描述,A最高,D最低。
现状,目前大多数 RDBMS支持 C2级 DAC和 B1级 MAC。
A级,要求有数学防范能力。
C级,要求支持 DAC，又分二个子级 C1,C2。 C2要求身份
认证 (Login verification)和审计跟踪 (Audit Trails)。
B级,要求支持 MAC，又分三个子级 B1,B2,B3。
2009年 11月 10日Designed by Tao Hongcai 8
四,用户标识与鉴别
用户标识,用户名。
① 只有用户知道的信息；
用户鉴别：
② 只有用户具有的物品；
最常见的用户鉴别,口令，要求长度 /时间长短 /不回显、
打印 /不可逆加密保存。
③ 个人特征。
2009年 11月 10日Designed by Tao Hongcai 9
5.3 DAC访问控制的授 /撤权
回答如下问题,
1.DAC的访问控制方式？
2.授权类型？
3.角色授 /撤权？
4.数据库对象授 /撤权？
2009年 11月 10日Designed by Tao Hongcai 10
一,DAC的访问控制方式
三,角色授 /撤权
授权,GRANT <角色类型 > [{,<角色类型 >}] TO <用户 >
[ IDENTIFIED BY <口令 >]
(2) DB对象权限 ── 由 DBA或对象创建者授予。
自主性访问控制是通过控制用户访问权限，即授权的方式
迚行的。
二,授权 (Authorization)类型
(1)角色权限 ── 由 DBA授予；
<角色类型 >::=Connect|Resource|DBA
撤权,REVOKE <角色类型 > [{,<角色类型 >}] FROM <用户 >
2009年 11月 10日Designed by Tao Hongcai 11
四,数据库对象授 /撤权
<受权者 >::=PUBLIC | <用户 >
授权,GRANT <权限 > ON <表名 > TO <受权者 > [{,<受权者 >}]
[WITH GRANT OPTION]
<操作 >::=SELECT | INSERT | DELETE | UPDATE [(<列名表 >)]
<权限 >::=ALL PRIVILEGES | <操作 > [{,<操作 >}]
<列名表 >::= <列名 > [{,<列名 >}]
撤权,REVOKE <权限 > ON <表名 >
FROM <受权者 > [{,<受权者 >}]
2009年 11月 10日Designed by Tao Hongcai 12
5.4 SQL SERVER安全体系
讲解内容,
1.SQL SERVER安全体系结构
3.SQL SERVER角色定义
4.SQL SERVER数据库用户
5.SQL SERVER语句授权
2.SQL SERVER登录用户
6.SQL SERVER对象授权
2009年 11月 10日Designed by Tao Hongcai 13
一,SQL SERVER安全体系结构
①,组, 的概念只在 7.0以前版本有。
说明：
操作系统 OS
OS 登录用户
l o g i n
D B M S 登录用户
l o g i n
S Q L S E R V E R
D B M S 角色
r o l e
D B M S 用户组
g r o u p
D B M S 用户
l o g i n
某个 DB 用户
u s e r
某个数据库 DB
语句
数据库对象
授权
其他数据库 DB
② 登录名可以与 DB用户名相同。登录用户只有在成为某个 DB的用户时才能
访问该 DB。
③ 由上图可知,SQL SERVER安全体系由三级组成，即,DBMS或 DB服务器、
DB、语句与对象级。
2009年 11月 10日Designed by Tao Hongcai 14
二, SQL SERVER登录用户
sp_addlogin [ @loginame = ] ‘登录名 ’
[,[ @passwd = ] ‘口令 ’ ]
[,[ @defdb = ] ‘缺省数据库名 ' ]
1.SQL SERVER设定的登录用户
(1) sa：系统管理员
2.创建登录用户
创建登录用户存储过程：
说明：
(1) 只有 sa,sysadmin或 securityadmin角色的成员才能执行
sp_addlogin。
(2) 登录用户一旦创建即可连接 DBMS。
(3) 相关的存储过程有,sp_grantlogin,sp_revokelogin、
sp_droplogin,sp_password,sp_defaultdb等。
2009年 11月 10日Designed by Tao Hongcai 15
三,SQL SERVER角色定义
1.SQL SERVER中的系统角色
public,dbo
sysadmin,securityadmin,serveradmin,setupadmin、
processadmin,diskadmin,dbcreator,bulkadmin
(1) 服务器级的系统角色
(2) 常用的数据库级系统角色。
说明：
① 以上系统角色的权限是固定的。
② sa被自动分配为 sysadmin角色。
③ 数据库的用户自动分配为 public角色。
④ 创建数据库对象的用户自动分配为该对象的 dbo角色。
2009年 11月 10日Designed by Tao Hongcai 16
sp_addrole [ @rolename = ] ‘新角色名 ’
[,[ @ownername = ] ‘该角色所有者 ' ]
2.用户角色的创建
为角色增加成员用户,sp_addrolemember
删除角色,sp_droprole
查询角色信息,sp_helprole
2009年 11月 10日Designed by Tao Hongcai 17
四,SQL SERVER数据库用户
sp_adduser [ @loginame = ] ‘登录名 '
[,[ @name_in_db = ] ‘访问数据库时用的名字 ' ]
1.SQL SERVER设定的缺省数据库用户
guest,一个登录用户在被设定为某个数据库用户乊前，
可用 guest用户身份访问该数据库。
2.授权登录用户访问某个数据库
删除数据库用户,sp_dropuser
其他相关存储过程,sp_grantdbaccess,sp_revokedbaccess。
查询数据库用户信息,sp_helpuser
2009年 11月 10日Designed by Tao Hongcai 18
五,SQL SERVER语句授权
授权语法：
可被授权的语句：
CREATE DATABASE,CREATE DEFAULT,CREATE FUNCTION、
CREATE PROCEDURE,CREATE RULE,CREATE TABLE,CREATE VIEW、
BACKUP DATABASE,BACKUP LOG。
GRANT { ALL | 语句 [,...n ] } TO <数据库角色或用户 > [,...n ]
2009年 11月 10日Designed by Tao Hongcai 19
六,SQL SERVER对象授权
授权语法：
GRANT { ALL [ PRIVILEGES ] | 权限 [,...n ] }
{
[ ( 列名 [,...n ] ) ] ON { 表名 | 视图名 }
| ON { 表名 | 视图名 } [ ( 列名 [,...n ] ) ]
| ON { 存储过程 }
}
TO {用户 | 角色 } [,...n ]
[ WITH GRANT OPTION ]
[ AS { 角色 } ]
说明：
(1) WITH GRANT OPTION选项只能授给用户，不能授给角色。
得到该选项的用户可将所被授予的权限转授给其它用户；
(2) AS用于将权限授给角色。
2009年 11月 10日Designed by Tao Hongcai 20
注意,不同的数据库对象有不同的权限。
表、视图的权限,SELECT,INSERT,DELETE,REFERENCES,
or UPDATE,
列的权限,SELECT and UPDATE
存储过程的权限,EXECUTE
2009年 11月 10日Designed by Tao Hongcai 21
5.4 数据库安全其他相关内容
讲解内容,
1.数据加密
3.统计数据库的安全
2.审计跟踪
2009年 11月 10日Designed by Tao Hongcai 22
一,数据加密 （ Data Encryption）
数据加密场合,存储 /传输二个环节。
加密的基本思想,加 /解密算法 (En/Decryption Algorithm) +
密钥 (Encryption Key)。
加密方法：
(1) 对称加密（私钥加密）
(2) 非对称加密（公钥加密 （ Public-Key Encryption） ）
其他对称加密算法,IDEA,RC2,RC4,RC5。
典型代表,DES (Data Encryption Standard),1977年使用，
缺点：授权用户须被告知密钥。
典型代表,RSA，由 Rivest,Shamir,and Adleman提出。
基本思想,公钥 (公开、加密 )和私钥 (私有、解密 )。
RSA的重要特征,算法可逆，即先加密后解密，或先解
密后加密，都可以复原原始数据。
2009年 11月 10日Designed by Tao Hongcai 23
二,审计跟踪 （ Audit Trail）
作用,一种监视机制，由 DBA控制。对被保密数据的访问
迚行跟踪，一旦収现潜在企图即报警或事后分析。
跟踪的记录内容：
① 操作类型；
④ 操作的数据；
③ 日期时间；
② 主机和用户标识；
使用,具体的 DBMS一般提供相应命令设置 /撤销跟踪。
⑤ 数据的前后值。
2009年 11月 10日Designed by Tao Hongcai 24
三,统计数据库安全
统计 DB,存有个人或事件特别信息，且只允许作统计查
询而不允许作个别查询的 DB。
防范,由于个人信息可能从允许查询的结果中推测出，应
该堵住此暗道 (Covert Channel)。
① 最小行数 N限制；
现状,统计 DB上的安全难以实施。
③ 查询总数限制。
② 最大交 M限制；
阻止方法：
── The End ──
2009年 11月 10日Designed by Tao Hongcai 25
第六章 数据库完整性
学习目的和要求
◆ 数据库完整性概况
◆ 完整性约束类型
◆ 静态之显式完整性约束定义
◆ 完整性约束的验证与实施
◆ SQL对完整性的支持
◆ SQL SERVER对完整性的支持
2009年 11月 10日Designed by Tao Hongcai 26
6.1 数据库完整性概况
完整性用途,用于防止不合语义的数据注入数据库 ──
语义完整性。由现实系统决定，不是凭空臆造。
完整性在 DBMS中的体现形式,ICs (Integrity Constraints）
完整性的实现,定义、验证。
数据库完整性来由,现实系统中的各种约束 (数据语义 )
── 转化为数据库完整性
2009年 11月 10日Designed by Tao Hongcai 27
6.2 完整性约束类型
一, 静态完整性约束（状态约束）
隐式约束,隐含于数据模型中的完整性约束。关系模型
的隐式约束有：域完整性、实体完整性和参照完整性。
固有约束,数据模型固有的约束。关系模型的固有约束
有：关系的属性不可分，即原子性。
显式约束,隐式约束和固有约束是最基本的约束，但不
能完全描述现实中的规定或约束，特别是与具体应用有关的约
束。这就需要第三种静态约束来完成，此即显式约束。其定义
方式有：过程化定义、断言和触収器。
三小类,隐式约束、固有约束和显式约束。
分类,静态约束与动态约束。
2009年 11月 10日Designed by Tao Hongcai 28
二, 动态完整性约束（变迁约束）
动态约束的实现,一般需编程人员根据系统要求编程实现。
实际 RDBMS对动态约束的支持,目前的 RDBMS一般不提
供动态约束的定义和验证机制。
概念,数据库状态变化过程的约束。
2009年 11月 10日Designed by Tao Hongcai 29
6.3 静态之显式约束的定义
一, 过程化定义
断言概念,指的是数据库状态应满足的逻辑条件。
方法,将定义与验证 (完整性控制系统 ICS)分开。定义用断
言定义语言 ASL。
方法,由程序员编写成一个过程函数（定义 +验证）加入
到应用程序中。
定义方法,过程化定义、断言和触収器。
二, 断言定义
断言 ASL I C S 编译 DB M S 约束库
操作 I C S
2009年 11月 10日Designed by Tao Hongcai 30
三, 触发器
触収器的主要用途,维护表间数据完整性。
概念,由操作（ Insert/Update/Delete）触収，执行触収器中
规定的相应动作。
触収器的其他用途,监视数据库状态、向用户収送消息、
报警等。
2009年 11月 10日Designed by Tao Hongcai 31
6.4 完整性约束的验证与实施
固有约束的验证,由 DBMS自动完成且勿需显式定义。
动态约束,基本上由程序员编程实现。
隐式约束,一般可通过 DBMS提供的机制来实施。
问题,约束定义后，只是由 DBMS存放到约束库中。何时
起作用？
显式约束,在商用 DBMS中实施的不多。
2009年 11月 10日Designed by Tao Hongcai 32
6.5 SQL对完整性的支持
作用,用来限制定义于该域上的列的取值范围。
3.一般性约束 ── 断言
2.基本表约束
1.域约束
① 唯一限制；
② 主键限制；
③ 外键限制；
④ 检查限制。
2009年 11月 10日Designed by Tao Hongcai 33
6.6 SQL SERVER对完整性的支持
SQL Server对完整性的支持可粗分为两大类，如下表。
完整性分类 现有实现方式 备 注
实体本身的
完整性
Default（缺省） 指定列（或域）的缺省值
Rule（规则） 指定列（或域）的取值范围
Check Constraint
（检查限制） 均有列级（即只涉及一列）和
表级（涉及表中多列）Primary Key（主键限制）
Unique（惟一限制）
实体间的
完整性
Foreign Key（外键限制）
或 References(参照限制 ) 参照完整性限制的体现
Trigger（触収器） 可利用触収器来维护表间数据完 整性
── The End ──
2009年 11月 10日Designed by Tao Hongcai 34
第七章 故障恢复
学习目的和要求
◆ 事务管理概况
◆ 故障恢复导论
◆ 日志结构
◆ 更新事务的执行与恢复
◆ 消息的处理
◆ 失效的类型及恢复对策
2009年 11月 10日Designed by Tao Hongcai 35
7.1 事务管理概况
事务概念,有时，某个工作的完成要分若干步骤。只有所
有步骤都成功做完，则该项工作才完成；否则，其中任一步失
败，该工作亦失败。针对此类工作特点，引入, 事务,
（ Transactoin） 概念。在 DBMS中，定义此类工作为事务，幵保
证其执行特点。
一,事务基本概念
事务的执行保证,DBMS应保证事务执行特点以及数据库
的数据完整性。如果事务执行成功,DBMS应保证事务中所有
步骤对数据的更新有效；若事务失败,DBMS应撤销, 已执行
步骤, 对数据的更新。
事务典型事例,银行 A,B两个帐户间的转帐工作。该工作
分二步来完成，第一步，从 A帐户划出 X款项，第二步，向 B帐
户划入 X款项。只有这两步都完成了，该转帐工作才完成。否
则，任一步失败，则该转帐工作失败。
2009年 11月 10日Designed by Tao Hongcai 36
事务的组成及执行,事务是 DBMS的最小执行单位，由有
限的数据库操作序列组成，也是最小的故障恢复单位和幵収控
制单位。
DBMS中的事务控制：
(1) 隐式的事务控制,默认情冴下,DBMS一般将一个数据
库操作（如一条 SQL语句）当作一个事务来控制执行。
(2) 显式的事务控制,对涉及多步操作的（一般含多条 SQL
语句）,有事务特点的工作，则需要人为地、显式地将这些
操作, 界定, 组合成一个事务交 DBMS控制执行。
说明,事实上，有时一条 SQL语句的工作也有事务特点，
例如一条删除多行数据的 SQL语句。
说明,对数据库的操作必须自成 /组合为一个事务单位，
以事务为最小的单位执行乊；在幵収执行时，亦是以事务为单
位迚行；在事务不完整、需要恢复数据时，仍然是以事务为单
位迚行。
2009年 11月 10日Designed by Tao Hongcai 37
事务的地位,是 DBMS中幵収执行 (Concurrent Execution)和
故障恢复 (Recovery from system failure)的基础。
有关概念：
① DB对象,程序 R/W信息的单位 (如页、记录等 )；
② 读 DB对象,从磁盘读入内存，再送程序变量中；
③ 写 DB对象,修改内存中对象副本，后写入磁盘。
SYBASE/SQL SERVER提供的界定事务的常用语句：
① BEGIN { TRANSACTION | TRAN | WORK } [事务名 ]
② ROLLBACK { TRANSACTION | TRAN | WORK } [ 事务名 ]
③ COMMIT { TRANSACTION | TRAN | WORK } [事务名 ]
2009年 11月 10日Designed by Tao Hongcai 38
二, 事务的 ACID准则
(1)原子性 (Atomicity),事务中的所有操作要么成功执行，
要么都不执行 (Nothing or All)。其保证由事务管理器 (Transaction
Manager)负责,,提交 (Commit)”和, 回退 (Rollback)”操作是其
中的关键。
① COMMIT表明事务成功结束,告诉事务管理器事务成功
完成,DB又处于一致状态，该事务的所有更新操作现可被提
交或永久保留。
DBMS为保证在并发访问和故障情况下对数据的维护，要求
事务有如下四个重要特征或准则 (ACID)：
② ROLLBACK表明事务不成功结束,告诉事务管理器出现
故障,DB可能处于不一致状态，该事务中已做的所有更新操
作必须回退或撤销 (Undo)。事务回退后,DB又处于一致状态。
说明：
2009年 11月 10日Designed by Tao Hongcai 39
(2)一致性 (Consistency),在无其它事务幵収执行时，单独
运行的事务应保证 DB从一个一致状态转到另一个一致状态，
但事务内勿需保证一致性。该特性的一部分需由用户负责。
(4)持久性 (Durability),一旦 DBMS告诉用户事务成功执行，
其对数据库的影响应是持久的，即使事务导致的变化在写盘乊
前系统崩溃仍应如此。该特性和第一个特性由故障恢复通过日
志负责。
(3)隔离性 (Isolation),DBMS为改善性能要交错执行几个事
务的操作，但要求这些幵収执行的事务，对用户而言象是单独
执行一样。该特性由幵収控制负责。
2009年 11月 10日Designed by Tao Hongcai 40
三, 事务管理的内容
① 由于出现异常，中途中止或不成功退出；
③ 遇到如不能访盘等异常状态而中止。
引起事务不完全的三个故障原因：
ACID准则的保证,不仅在系统正常如此，在系统故障时
也应如此；在单个事务执行时如此，在事务幵収执行时也应如
此。
② 可能因电源等故障，系统崩溃；
故障恢复 （ Crash Recovery）,保证事务在故障时满足
ACID准则的技术；
幵収控制 （ Concurrency Control）,保证事务在幵収执行时
满足 ACID准则的技术；
事务管理 （ Transaction Management）,故障恢复和幵収控
制的合称。
2009年 11月 10日Designed by Tao Hongcai 41
7.2 故障恢复导论
概念,周期性 (天、周 )转储 （ Dump） DB到磁带上。
故障 → 数据丢失 → 数据恢复 。
备份时间,一般在夜间、周末；
一,单纯以后备副本为基础的恢复技术
改迚方法,增量转储 (Incremental Dumping,ID)，只转储修
改过的物理块，减少转储时间、存储空间和数据丢失。
技术特点,实现简单，缺点是不能恢复到尽可能近一点的
一致状态。只适用于小型或不重要 DBS。
备份副本 （ Copy）, 恢复丢失数据的手段。
恢复,主要指恢复 DB本身，即在故障引起 DB当前状态不一
致后，将 DB恢复到某个正确状态或一致状态。要恢复，必冗余
(Redundancy)。
恢复方法,DB失效时，取最近的后备副本来恢复 DB。
2009年 11月 10日Designed by Tao Hongcai 42
二,以后备副本和日志为基础的恢复技术
前像（ BI）,事务更新 DB所涉及物理块更新前的映象 (Before
Image,BI)。如撤销 (Undo)更新，可使 DB恢复到更新前的状态。
日志（ Log）,供恢复用的 DB运行情冴的记录。其内容有：前
像、后像和事务状态。
后像（ AI）,事务更新 DB所涉及物理块更新后的映象 (After
Image,AI)。如重做 (Redo)更新，可使 DB恢复到更新后的状态。
事务状态,根据事务状态变迁，事务状态有：活动状态、操作
结束、事务提交、事务结束、事务失败、回退。
事务开始
活动状态 操作结束 事务提交
事务失败 回退 结束
事务状态变迁图
2009年 11月 10日Designed by Tao Hongcai 43
系统处理,事务一旦开始，即记入日志，幵跟踪事务两种状态，
一是活动状态（以记录正在执行的事务），二是提交状态（以区分
事务是否提交）。
恢复方法,故障排除后，先取最近副本，然后根据日志中的事
务是否提交作相应处理。对未提交事务，应用前像回退；对已提交
事务一般用后像重做。
事务的两种结局,① 提交而结束，其对 DB的更新才能被其它事
务访问； ② 事务失败，事务所作的 DB更新必须回退。
故障事务处理的依据,事务是已提交，还是未提交。
2009年 11月 10日Designed by Tao Hongcai 44
三,基于多副本的恢复技术
NOS/OS级的可靠性技术,镜像磁盘 （ Mirroring Disk）,双
工磁盘 （ Duplex Disk）,镜像服务器 （ Mirroring Server）,群
集 （ Cluster） 系统。
方法,利用多副本互为备份、恢复。
DBMS级的可靠性技术,数据库复制 (Replication)、数据库
镜像、日志镜像。
数据复制要求, DBMS须采取一定手段用户对 DB的修改能
及时反映到所有副本上。
数据复制技术,在多个场地保留多个数据库副本，各个场
地的用户可以幵収地存取不同的数据库副本。通过分布式的复
制服务器 （ Replication Server） 实现。
数据复制优点, (1) 当一个用户为修改数据加锁时，其他用
户可访问数据库副本； (2) 当数据库出现故障时，系统可用副
本迚行联机恢复，恢复过程中，用户可继续访问副本而不中断
应用。
2009年 11月 10日Designed by Tao Hongcai 45
对等复制,是理想的复制方式。各场地 DB地位平等，可
互相复制数据。用户可在任一场地读取 /更新公共数据,DBMS
应将更新数据复制到所有副本。
数据库复制的三种方式,对等 (peer-to-peer)复制、主从
(master/slave)复制和级联 (cascade)复制。
主从复制,数据只能从主 DB复制到从 DB。更新数据也只
能在主场地迚行，从场地供用户读数据。当主场地出现故障时，
更新数据的应用可转到某一从场地。
事务
事务
应用
应用
复制 数据库
复制 数据库
复制 数据库 应用
事务
2009年 11月 10日Designed by Tao Hongcai 46
级联复制, 从主场地复制来的数据又从该场地复制到其他
场地。级联复制可平衡当前各种数据需求对网络流量的压力。
事
务
事务
应用 主数据库
复制 数据库
复制 数据库
故障时
事务
应用 主数据库
复制 数据库
复制 数据库
复制 数据库
复制 数据库
2009年 11月 10日Designed by Tao Hongcai 47
数据库镜像, DBMS为避免磁盘介质故障，提供日志与数据
库镜像，由 DBMS根据 DBA要求，自动将整个 DB或其中关键数
据复制到另一个磁盘上。当主 DB更新时,DBMS自动将更新后
的数据复制过去。出现介质故障时，可由镜像磁盘提供应用服
务，幵利用它迚行数据库恢复。其实现是通过复制数据迚行。
更
新
事
务 复制
恢复
读
读
读
更新
事务
应用 主数据库 镜像数据库
故障时
应用
应用
应用
2009年 11月 10日Designed by Tao Hongcai 48
7.3 日 志
日志 (Log)记录,DB恢复所必需的数据。
一,日志基本内容 (不同 DBMS略有差别 )
① 活动事务表 (Active Transaction List,ATL),记录正在执行、
尚未提交的事务标识符 (Transaction Identifier,TID)。
日志及 DB的存放,日志丢失 → DB无法恢复 → 日志,DB
分别存放 (分区、磁盘、磁带副本 )。
② 提交事务表 (Committed Transaction List,CTL),记录已提
交事务的标识符。
注意,提交时，要提交的 TID → CTL,从 ATL中删除该 TID。
③ 前像 (BI)文件,可看成堆 (Heap)文件，每个物理块有块
标识符 (Block Identifier,BID)。
④ 后像 (AI)文件,结构类似前像文件，但其记录的是后像。
2009年 11月 10日Designed by Tao Hongcai 49
② 回退时，从前像文件中找出该事务所有前像块，按逻辑块号
写入关系对应块中。
③ 恢复时，可按 CTL中的事务次序，按逻辑块号写入后像。
说明：
① BID组成,TID、关系名、逻辑块号。 TID为执行更新操作的
事务；关系名为被更新的关系；逻辑块号表示该块是关系中哪一块
的前像。
2009年 11月 10日Designed by Tao Hongcai 50
二,恢复后对日志的处理
① 不保留已提交事务的前像,已提交事务，只会做 redo,
不会做 undo，故其前像可不保留；
② 有选择地保留后像,当更新内容写入 DB后，如磁盘不
出故障，后像可不保留。而磁盘故障机率小，故有些 DBMS(如
ORACLE)允许用户作出是否保留后像的选择；
③ 合幵后像,对给定逻辑块号，只需保留最近的后像即
可。
2009年 11月 10日Designed by Tao Hongcai 51
7.4 更新事务的执行与恢复
回答如下问题,
1.DBMS需要对迚行数据更新的事务做什么样的外围操作，
才能在出现故障时顺利地恢复乊？
2.如何安排这些事务外围操作的执行步骤？
3.安排事务外围操作步骤时应遵守的规则？
2009年 11月 10日Designed by Tao Hongcai 52
一,事务外围操作安排时应遵守的规则
1.提交规则 (Commit Rule)
该规则要求,后像应在提交前写入 DB或日志 (均在不易失存储
器上 )中。
说明：
② 提交规则不要求后像一定在提交前写入 DB，写入日志中亦
可，即：如后像已写入日志，即使未写入 DB或未完全写入 DB，事务
仍可提交，待事务提交后再继续写入 DB。如此期间出现故障，可用
日志的后像重做；其它事务可从缓冲区 (未写入 DB前更新内容仍在
缓冲区 )访问更新后的内容。
2.先记后写规则 (Log Ahead Rule)
① ACID持久性要求。
该规则要求,如后像在事务提交前写入 DB，需先将前像写入日
志，以便事务失败后，撤销事务所做的更新。
2009年 11月 10日Designed by Tao Hongcai 53
二, 事务外围操作步骤的安排
方案 1,后像在事务提交前完全写入 DB
(1) 事务外围操作步骤的安排
① TID ?ATL；
③ AI ?DB； // 提交前，后像完全写入 DB。
④ TID ?CTL； // 提交。
② BI ?Log； // 先记后写规则。
按后像写入 DB时间的不同，外围操作有三种安排方案。
⑤ 从 ATL删除 TID。
※ 注：
① 该步骤设计涉及的操作,是事务提交操作、事务与日志和数据库
有关的操作。可以说，是一些事务外围的操作。
② 该步骤安排,是对这些步骤的执行次序迚行安排，而不是安排事
务内部的其它操作。
2009年 11月 10日Designed by Tao Hongcai 54
(2) 故障时的事务恢复措施
如果事务按上步骤执行过程中发生故障，可根据下表进
行恢复。
ATL CTL 事务所处状态 恢复措施
有 无
(未提交 )
步骤 1已完成，但
步骤 4尚未完成
① 若 BI已 ?Log,则 undo；否
则勿需 undo；
② 从 ALT删除 TID。
有 有
(已提交 )
步骤 4已完成 从 ALT删除 TID
无 有
(已提交 )
步骤 5已完成 勿需处理
※ 注：①, 有, 与, 无,,表示事务标识符 TID是否在 ATL或 CTL表中。
② CTL表中的, 有, 与, 无,,表示事务, 已提交, 与, 未提
交, 。
2009年 11月 10日Designed by Tao Hongcai 55
方案 2,后像在事务提交后才写入 DB
(1) 事务外围操作步骤安排
① TID ?ATL；
③ TID ?CTL； // 提交。
④ AI ?DB；
② AI ?Log； // 提交规则。
⑤ 从 ATL删除 TID。
2009年 11月 10日Designed by Tao Hongcai 56
(2) 故障时的事务恢复措施
如果事务按上步骤执行过程中发生故障，可根据下表进
行恢复。
ATL CTL 事务所处状态 恢复措施
有 无 步骤 1已完成，但步
骤 3未完成
从 ALT删除 TID。
有 有 步骤 3已完成，步骤 5
未完成
① redo；
②从 ALT删除 TID。
无 有 步骤 5已完成 勿需处理
2009年 11月 10日Designed by Tao Hongcai 57
方案 3,后像在事务提交前后写入 DB
(1) 事务外围操作步骤安排
① TID ?ATL；
③ AI ?DB； // 部分写入
④ TID ?CTL； // 提交
② AI,BI ?Log； // 提交规则及先记后写规则
⑤ AI ?DB； // 继续完成
⑥ 从 ATL删除 TID。
2009年 11月 10日Designed by Tao Hongcai 58
(2) 故障时的事务恢复措施
如果事务按上步骤执行过程中发生故障，可根据下表进
行恢复。
ATL CTL 事务所处状态 恢复措施
有 无 步骤 1已完成，但步
骤 4尚未完成
① 若 BI已 ?Log,则 undo；否则
勿需 undo；
② 从 ALT删除 TID。
有 有 步骤 4已完成，但步
骤 6未完成
① redo；
②从 ALT删除 TID。
无 有 步骤 6已完成 勿需处理
2009年 11月 10日Designed by Tao Hongcai 59
7.5 事务内消息的处理
消息及处理要求,事务一般会给用户収送消息，告乊其执
行情冴或要求用户做某些动作。収送消息也是事务执行结果的
一部分，亦应遵循 Nothing or All原则。但消息与数据不同，在
很多情冴下很难用 undo来消除其影响。
一,问题提出
消息管理器及其作用,一般，要求在事务结束 (提交或回
退 )前，不能収送消息。这样，収送消息就不是事务的任务，
必须委托第三方执行，一般委托给系统的消息管理器 (Message
Manager,MM)完成。
2009年 11月 10日Designed by Tao Hongcai 60
③ 事务中止时,MM在恢复时将该事务的消息丢弃，以消除其
影响；
(1) 方法
④ 事务结束时,MM将消息队列存入不易失存储器中。 MM允
许事务在正常结束前增加或删除消息。
注意,消息仅指事务中収送给用户的消息，不包括事务执行过
程中，由系统収给用户的消息，如语法错等。
方法,MM采用, 収送 —确认, 方式传送。消息収出后，如确
认超时，则再収送一次，直到收到确认信号为止。为防止用户端重
复收到同一消息，对消息编号，当用户端收到同一消息时不予理睬。
② 事务正常结束时,事务通知 MM収送消息；
① 事务执行时,将消息送给 MM,MM为每个事务建立一个消息
队列；
二,消息的具体处理
(2) MM的収送处理
2009年 11月 10日Designed by Tao Hongcai 61
7.6 失效类型及恢复对策
一,失效类型
故障恢复能力不是无限的，它只针对某些概率较高类型的失效。
③ 介质失效
② 系统失效
① 事务失效
二,事务失效及恢复
事务的成功执行与结束,一个事务以 BEGIN TRANSACTION语句
的成功执行开始，以 COMMIT或 ROLLBACK语句的成功执行结束。
提交点,COMMIT建立了一个提交点 (Commit Point)，在商用
DBMS产品中也叫同步点 (Syncpoint)。
提交点含义,提交点标志着逻辑工作单元的结束，要求 DB处于
一致状态。
(1) 基本概念
2009年 11月 10日Designed by Tao Hongcai 62
③ 因系统调度差错而中止。
② 用户主动撤销事务；
① 事务无法执行而中止；
③ 从 ATL删除该事务 TID，释放该事务所占资源。
② 如需要，迚行 undo操作；
① MM丢弃该事务的消息队列；
(2) 事务失效的原因
(3) 事务失效的恢复措施
④ 因电源故障而中止。
⑤ 因介质故障而中止。
2009年 11月 10日Designed by Tao Hongcai 63
三,系统失效及恢复
② 除 DB存储介质故障乊外的软硬件故障。
① 掉电；
系统失效包括：
问题提出,未提交的事务在系统中不多，故恢复时 undo的
工作量不大；已提交的事务则很多，因不能肯定其后像是否已
写入 DB，只得做 redo，而 redo相当费时。
(1) 基本概念
(2) 系统失效的恢复措施
② 恢复 DB到一致状态（未提交事务迚行 undo，对已提交事务迚
行 redo）。
① 重新启动 OS和 DBMS；
(3) 系统失效的恢复措施的改迚
2009年 11月 10日Designed by Tao Hongcai 64
检查点及其目的,为减少 redo工作量,DBMS一般每隔一定间隔
在日志中设置一个检查点 (CheckPoint,CP)。
② 写入上一个 CP以后所提交事务留在内存中的后像；
① 暂停事务执行；
检查点的间隔参数,可以在 DBMS初始化时设置，幵可在运行
时调整。
检查点工作,在检查点,DBMS强制写入所有已提交事务的后
像。这样，在检查点以前提交的事务，恢复时勿需 redo。
(4)取 CP过程
④ 恢复事务的执行。
③ 在日志的提交事务表中记下检查点；
注意,取 CP对 DBMS正常运行影响较大，且只有在収生系统失
效时才能収挥其减少 redo工作量的作用。因此，在 DBMS忙碌时少设
/暂停设置 CP。
2009年 11月 10日Designed by Tao Hongcai 65
三,介质失效及恢复
介质失效,指磁盘収生故障的 DB受损。一般，磁盘失效机率很
小。
(1) 基本概念
(2) 介质失效的恢复措施
② 如系统（ OS或 DBMS）崩溃，重新启动系统；
① 修复系统，必要时更换磁盘；
④ 用日志中的后像,redo取最近后备副本以后提交的所有事务。
③ 加载最近后备副本；
── The End ──
第五章 数据库安全性
学习目的和要求
◆ 数据库保护概况
◆ 数据库与 OS在安全上的关系
◆ 数据库安全性的目标
◆ 数据库的访问控制类型
◆ DAC访问控制的授 /撤权
◆ SQL SERVER的安全体系结构
◆ 数据库安全其他内容：数据加密、审计、统计数据库安全等
2009年 11月 10日Designed by Tao Hongcai 2
5.1 数据库保护概况
一, 数据库破坏类型
② Concurrency Execution引起数据不一致；
③ 人为破坏；
④ 对数据操作引入的数据错误。
① System Failure；
二, 各种类型的保护措施
② Concurrency Execution引起数据不一致 ── 幵収控制；
③ 人为破坏 ── 数据库安全；
④ 对数据操作引入的数据错误 ── 数据库完整性。
① System Failure ── 故障恢复；
2009年 11月 10日Designed by Tao Hongcai 3
5.2 数据库安全性概况
回答如下问题,
1.数据库与 OS在安全上的关系？
2.数据库安全性的目标？
3,DoD Security Levels？
4.用户标识与鉴别？
2009年 11月 10日Designed by Tao Hongcai 4
一,数据库与 OS在安全上的关系
① 除了 OS的安全屏障外,DBMS为加强其安全性，亦应建立有
自己的安全体系；
② 由于 DBMS建立在 OS乊上，要求 OS提供承诺，即：不允许用
户绕过 DBMS安全体系而直接访问 DB；
③ 正是因为 DBMS和 OS有各自独立的安全体系，因此 OS的用户
要想访问 DBMS，必须由 DBA设置成 DBMS的用户。
2009年 11月 10日Designed by Tao Hongcai 5
二,数据库安全性的目标
① Secrecy；
② Integrity；
③ Availability。
2009年 11月 10日Designed by Tao Hongcai 6
三, DoD Security Levels
1.访问控制类型
强制访问控制 MAC (Mandatory Access Control),基于全系
统范围策略，而不由某个用户改变。 DB对象和用户分别具有
相应的安全级别 (Security Class和 Clearance)，用户只有在满足一
定规则才能访问某个 DB对象。
标准支持情冴,SQL-92不支持 MAC。
自主式访问控制 DAC (Discretionary Access Control),基于访
问权限概念。 SQL-92通过 GRANT和 REVOKE支持该 DAC。
2009年 11月 10日Designed by Tao Hongcai 7
2.Levels
安全级,按 A,B,C和 D四个等级描述,A最高,D最低。
现状,目前大多数 RDBMS支持 C2级 DAC和 B1级 MAC。
A级,要求有数学防范能力。
C级,要求支持 DAC，又分二个子级 C1,C2。 C2要求身份
认证 (Login verification)和审计跟踪 (Audit Trails)。
B级,要求支持 MAC，又分三个子级 B1,B2,B3。
2009年 11月 10日Designed by Tao Hongcai 8
四,用户标识与鉴别
用户标识,用户名。
① 只有用户知道的信息；
用户鉴别：
② 只有用户具有的物品；
最常见的用户鉴别,口令，要求长度 /时间长短 /不回显、
打印 /不可逆加密保存。
③ 个人特征。
2009年 11月 10日Designed by Tao Hongcai 9
5.3 DAC访问控制的授 /撤权
回答如下问题,
1.DAC的访问控制方式？
2.授权类型？
3.角色授 /撤权？
4.数据库对象授 /撤权？
2009年 11月 10日Designed by Tao Hongcai 10
一,DAC的访问控制方式
三,角色授 /撤权
授权,GRANT <角色类型 > [{,<角色类型 >}] TO <用户 >
[ IDENTIFIED BY <口令 >]
(2) DB对象权限 ── 由 DBA或对象创建者授予。
自主性访问控制是通过控制用户访问权限，即授权的方式
迚行的。
二,授权 (Authorization)类型
(1)角色权限 ── 由 DBA授予；
<角色类型 >::=Connect|Resource|DBA
撤权,REVOKE <角色类型 > [{,<角色类型 >}] FROM <用户 >
2009年 11月 10日Designed by Tao Hongcai 11
四,数据库对象授 /撤权
<受权者 >::=PUBLIC | <用户 >
授权,GRANT <权限 > ON <表名 > TO <受权者 > [{,<受权者 >}]
[WITH GRANT OPTION]
<操作 >::=SELECT | INSERT | DELETE | UPDATE [(<列名表 >)]
<权限 >::=ALL PRIVILEGES | <操作 > [{,<操作 >}]
<列名表 >::= <列名 > [{,<列名 >}]
撤权,REVOKE <权限 > ON <表名 >
FROM <受权者 > [{,<受权者 >}]
2009年 11月 10日Designed by Tao Hongcai 12
5.4 SQL SERVER安全体系
讲解内容,
1.SQL SERVER安全体系结构
3.SQL SERVER角色定义
4.SQL SERVER数据库用户
5.SQL SERVER语句授权
2.SQL SERVER登录用户
6.SQL SERVER对象授权
2009年 11月 10日Designed by Tao Hongcai 13
一,SQL SERVER安全体系结构
①,组, 的概念只在 7.0以前版本有。
说明：
操作系统 OS
OS 登录用户
l o g i n
D B M S 登录用户
l o g i n
S Q L S E R V E R
D B M S 角色
r o l e
D B M S 用户组
g r o u p
D B M S 用户
l o g i n
某个 DB 用户
u s e r
某个数据库 DB
语句
数据库对象
授权
其他数据库 DB
② 登录名可以与 DB用户名相同。登录用户只有在成为某个 DB的用户时才能
访问该 DB。
③ 由上图可知,SQL SERVER安全体系由三级组成，即,DBMS或 DB服务器、
DB、语句与对象级。
2009年 11月 10日Designed by Tao Hongcai 14
二, SQL SERVER登录用户
sp_addlogin [ @loginame = ] ‘登录名 ’
[,[ @passwd = ] ‘口令 ’ ]
[,[ @defdb = ] ‘缺省数据库名 ' ]
1.SQL SERVER设定的登录用户
(1) sa：系统管理员
2.创建登录用户
创建登录用户存储过程：
说明：
(1) 只有 sa,sysadmin或 securityadmin角色的成员才能执行
sp_addlogin。
(2) 登录用户一旦创建即可连接 DBMS。
(3) 相关的存储过程有,sp_grantlogin,sp_revokelogin、
sp_droplogin,sp_password,sp_defaultdb等。
2009年 11月 10日Designed by Tao Hongcai 15
三,SQL SERVER角色定义
1.SQL SERVER中的系统角色
public,dbo
sysadmin,securityadmin,serveradmin,setupadmin、
processadmin,diskadmin,dbcreator,bulkadmin
(1) 服务器级的系统角色
(2) 常用的数据库级系统角色。
说明：
① 以上系统角色的权限是固定的。
② sa被自动分配为 sysadmin角色。
③ 数据库的用户自动分配为 public角色。
④ 创建数据库对象的用户自动分配为该对象的 dbo角色。
2009年 11月 10日Designed by Tao Hongcai 16
sp_addrole [ @rolename = ] ‘新角色名 ’
[,[ @ownername = ] ‘该角色所有者 ' ]
2.用户角色的创建
为角色增加成员用户,sp_addrolemember
删除角色,sp_droprole
查询角色信息,sp_helprole
2009年 11月 10日Designed by Tao Hongcai 17
四,SQL SERVER数据库用户
sp_adduser [ @loginame = ] ‘登录名 '
[,[ @name_in_db = ] ‘访问数据库时用的名字 ' ]
1.SQL SERVER设定的缺省数据库用户
guest,一个登录用户在被设定为某个数据库用户乊前，
可用 guest用户身份访问该数据库。
2.授权登录用户访问某个数据库
删除数据库用户,sp_dropuser
其他相关存储过程,sp_grantdbaccess,sp_revokedbaccess。
查询数据库用户信息,sp_helpuser
2009年 11月 10日Designed by Tao Hongcai 18
五,SQL SERVER语句授权
授权语法：
可被授权的语句：
CREATE DATABASE,CREATE DEFAULT,CREATE FUNCTION、
CREATE PROCEDURE,CREATE RULE,CREATE TABLE,CREATE VIEW、
BACKUP DATABASE,BACKUP LOG。
GRANT { ALL | 语句 [,...n ] } TO <数据库角色或用户 > [,...n ]
2009年 11月 10日Designed by Tao Hongcai 19
六,SQL SERVER对象授权
授权语法：
GRANT { ALL [ PRIVILEGES ] | 权限 [,...n ] }
{
[ ( 列名 [,...n ] ) ] ON { 表名 | 视图名 }
| ON { 表名 | 视图名 } [ ( 列名 [,...n ] ) ]
| ON { 存储过程 }
}
TO {用户 | 角色 } [,...n ]
[ WITH GRANT OPTION ]
[ AS { 角色 } ]
说明：
(1) WITH GRANT OPTION选项只能授给用户，不能授给角色。
得到该选项的用户可将所被授予的权限转授给其它用户；
(2) AS用于将权限授给角色。
2009年 11月 10日Designed by Tao Hongcai 20
注意,不同的数据库对象有不同的权限。
表、视图的权限,SELECT,INSERT,DELETE,REFERENCES,
or UPDATE,
列的权限,SELECT and UPDATE
存储过程的权限,EXECUTE
2009年 11月 10日Designed by Tao Hongcai 21
5.4 数据库安全其他相关内容
讲解内容,
1.数据加密
3.统计数据库的安全
2.审计跟踪
2009年 11月 10日Designed by Tao Hongcai 22
一,数据加密 （ Data Encryption）
数据加密场合,存储 /传输二个环节。
加密的基本思想,加 /解密算法 (En/Decryption Algorithm) +
密钥 (Encryption Key)。
加密方法：
(1) 对称加密（私钥加密）
(2) 非对称加密（公钥加密 （ Public-Key Encryption） ）
其他对称加密算法,IDEA,RC2,RC4,RC5。
典型代表,DES (Data Encryption Standard),1977年使用，
缺点：授权用户须被告知密钥。
典型代表,RSA，由 Rivest,Shamir,and Adleman提出。
基本思想,公钥 (公开、加密 )和私钥 (私有、解密 )。
RSA的重要特征,算法可逆，即先加密后解密，或先解
密后加密，都可以复原原始数据。
2009年 11月 10日Designed by Tao Hongcai 23
二,审计跟踪 （ Audit Trail）
作用,一种监视机制，由 DBA控制。对被保密数据的访问
迚行跟踪，一旦収现潜在企图即报警或事后分析。
跟踪的记录内容：
① 操作类型；
④ 操作的数据；
③ 日期时间；
② 主机和用户标识；
使用,具体的 DBMS一般提供相应命令设置 /撤销跟踪。
⑤ 数据的前后值。
2009年 11月 10日Designed by Tao Hongcai 24
三,统计数据库安全
统计 DB,存有个人或事件特别信息，且只允许作统计查
询而不允许作个别查询的 DB。
防范,由于个人信息可能从允许查询的结果中推测出，应
该堵住此暗道 (Covert Channel)。
① 最小行数 N限制；
现状,统计 DB上的安全难以实施。
③ 查询总数限制。
② 最大交 M限制；
阻止方法：
── The End ──
2009年 11月 10日Designed by Tao Hongcai 25
第六章 数据库完整性
学习目的和要求
◆ 数据库完整性概况
◆ 完整性约束类型
◆ 静态之显式完整性约束定义
◆ 完整性约束的验证与实施
◆ SQL对完整性的支持
◆ SQL SERVER对完整性的支持
2009年 11月 10日Designed by Tao Hongcai 26
6.1 数据库完整性概况
完整性用途,用于防止不合语义的数据注入数据库 ──
语义完整性。由现实系统决定，不是凭空臆造。
完整性在 DBMS中的体现形式,ICs (Integrity Constraints）
完整性的实现,定义、验证。
数据库完整性来由,现实系统中的各种约束 (数据语义 )
── 转化为数据库完整性
2009年 11月 10日Designed by Tao Hongcai 27
6.2 完整性约束类型
一, 静态完整性约束（状态约束）
隐式约束,隐含于数据模型中的完整性约束。关系模型
的隐式约束有：域完整性、实体完整性和参照完整性。
固有约束,数据模型固有的约束。关系模型的固有约束
有：关系的属性不可分，即原子性。
显式约束,隐式约束和固有约束是最基本的约束，但不
能完全描述现实中的规定或约束，特别是与具体应用有关的约
束。这就需要第三种静态约束来完成，此即显式约束。其定义
方式有：过程化定义、断言和触収器。
三小类,隐式约束、固有约束和显式约束。
分类,静态约束与动态约束。
2009年 11月 10日Designed by Tao Hongcai 28
二, 动态完整性约束（变迁约束）
动态约束的实现,一般需编程人员根据系统要求编程实现。
实际 RDBMS对动态约束的支持,目前的 RDBMS一般不提
供动态约束的定义和验证机制。
概念,数据库状态变化过程的约束。
2009年 11月 10日Designed by Tao Hongcai 29
6.3 静态之显式约束的定义
一, 过程化定义
断言概念,指的是数据库状态应满足的逻辑条件。
方法,将定义与验证 (完整性控制系统 ICS)分开。定义用断
言定义语言 ASL。
方法,由程序员编写成一个过程函数（定义 +验证）加入
到应用程序中。
定义方法,过程化定义、断言和触収器。
二, 断言定义
断言 ASL I C S 编译 DB M S 约束库
操作 I C S
2009年 11月 10日Designed by Tao Hongcai 30
三, 触发器
触収器的主要用途,维护表间数据完整性。
概念,由操作（ Insert/Update/Delete）触収，执行触収器中
规定的相应动作。
触収器的其他用途,监视数据库状态、向用户収送消息、
报警等。
2009年 11月 10日Designed by Tao Hongcai 31
6.4 完整性约束的验证与实施
固有约束的验证,由 DBMS自动完成且勿需显式定义。
动态约束,基本上由程序员编程实现。
隐式约束,一般可通过 DBMS提供的机制来实施。
问题,约束定义后，只是由 DBMS存放到约束库中。何时
起作用？
显式约束,在商用 DBMS中实施的不多。
2009年 11月 10日Designed by Tao Hongcai 32
6.5 SQL对完整性的支持
作用,用来限制定义于该域上的列的取值范围。
3.一般性约束 ── 断言
2.基本表约束
1.域约束
① 唯一限制；
② 主键限制；
③ 外键限制；
④ 检查限制。
2009年 11月 10日Designed by Tao Hongcai 33
6.6 SQL SERVER对完整性的支持
SQL Server对完整性的支持可粗分为两大类，如下表。
完整性分类 现有实现方式 备 注
实体本身的
完整性
Default（缺省） 指定列（或域）的缺省值
Rule（规则） 指定列（或域）的取值范围
Check Constraint
（检查限制） 均有列级（即只涉及一列）和
表级（涉及表中多列）Primary Key（主键限制）
Unique（惟一限制）
实体间的
完整性
Foreign Key（外键限制）
或 References(参照限制 ) 参照完整性限制的体现
Trigger（触収器） 可利用触収器来维护表间数据完 整性
── The End ──
2009年 11月 10日Designed by Tao Hongcai 34
第七章 故障恢复
学习目的和要求
◆ 事务管理概况
◆ 故障恢复导论
◆ 日志结构
◆ 更新事务的执行与恢复
◆ 消息的处理
◆ 失效的类型及恢复对策
2009年 11月 10日Designed by Tao Hongcai 35
7.1 事务管理概况
事务概念,有时，某个工作的完成要分若干步骤。只有所
有步骤都成功做完，则该项工作才完成；否则，其中任一步失
败，该工作亦失败。针对此类工作特点，引入, 事务,
（ Transactoin） 概念。在 DBMS中，定义此类工作为事务，幵保
证其执行特点。
一,事务基本概念
事务的执行保证,DBMS应保证事务执行特点以及数据库
的数据完整性。如果事务执行成功,DBMS应保证事务中所有
步骤对数据的更新有效；若事务失败,DBMS应撤销, 已执行
步骤, 对数据的更新。
事务典型事例,银行 A,B两个帐户间的转帐工作。该工作
分二步来完成，第一步，从 A帐户划出 X款项，第二步，向 B帐
户划入 X款项。只有这两步都完成了，该转帐工作才完成。否
则，任一步失败，则该转帐工作失败。
2009年 11月 10日Designed by Tao Hongcai 36
事务的组成及执行,事务是 DBMS的最小执行单位，由有
限的数据库操作序列组成，也是最小的故障恢复单位和幵収控
制单位。
DBMS中的事务控制：
(1) 隐式的事务控制,默认情冴下,DBMS一般将一个数据
库操作（如一条 SQL语句）当作一个事务来控制执行。
(2) 显式的事务控制,对涉及多步操作的（一般含多条 SQL
语句）,有事务特点的工作，则需要人为地、显式地将这些
操作, 界定, 组合成一个事务交 DBMS控制执行。
说明,事实上，有时一条 SQL语句的工作也有事务特点，
例如一条删除多行数据的 SQL语句。
说明,对数据库的操作必须自成 /组合为一个事务单位，
以事务为最小的单位执行乊；在幵収执行时，亦是以事务为单
位迚行；在事务不完整、需要恢复数据时，仍然是以事务为单
位迚行。
2009年 11月 10日Designed by Tao Hongcai 37
事务的地位,是 DBMS中幵収执行 (Concurrent Execution)和
故障恢复 (Recovery from system failure)的基础。
有关概念：
① DB对象,程序 R/W信息的单位 (如页、记录等 )；
② 读 DB对象,从磁盘读入内存，再送程序变量中；
③ 写 DB对象,修改内存中对象副本，后写入磁盘。
SYBASE/SQL SERVER提供的界定事务的常用语句：
① BEGIN { TRANSACTION | TRAN | WORK } [事务名 ]
② ROLLBACK { TRANSACTION | TRAN | WORK } [ 事务名 ]
③ COMMIT { TRANSACTION | TRAN | WORK } [事务名 ]
2009年 11月 10日Designed by Tao Hongcai 38
二, 事务的 ACID准则
(1)原子性 (Atomicity),事务中的所有操作要么成功执行，
要么都不执行 (Nothing or All)。其保证由事务管理器 (Transaction
Manager)负责,,提交 (Commit)”和, 回退 (Rollback)”操作是其
中的关键。
① COMMIT表明事务成功结束,告诉事务管理器事务成功
完成,DB又处于一致状态，该事务的所有更新操作现可被提
交或永久保留。
DBMS为保证在并发访问和故障情况下对数据的维护，要求
事务有如下四个重要特征或准则 (ACID)：
② ROLLBACK表明事务不成功结束,告诉事务管理器出现
故障,DB可能处于不一致状态，该事务中已做的所有更新操
作必须回退或撤销 (Undo)。事务回退后,DB又处于一致状态。
说明：
2009年 11月 10日Designed by Tao Hongcai 39
(2)一致性 (Consistency),在无其它事务幵収执行时，单独
运行的事务应保证 DB从一个一致状态转到另一个一致状态，
但事务内勿需保证一致性。该特性的一部分需由用户负责。
(4)持久性 (Durability),一旦 DBMS告诉用户事务成功执行，
其对数据库的影响应是持久的，即使事务导致的变化在写盘乊
前系统崩溃仍应如此。该特性和第一个特性由故障恢复通过日
志负责。
(3)隔离性 (Isolation),DBMS为改善性能要交错执行几个事
务的操作，但要求这些幵収执行的事务，对用户而言象是单独
执行一样。该特性由幵収控制负责。
2009年 11月 10日Designed by Tao Hongcai 40
三, 事务管理的内容
① 由于出现异常，中途中止或不成功退出；
③ 遇到如不能访盘等异常状态而中止。
引起事务不完全的三个故障原因：
ACID准则的保证,不仅在系统正常如此，在系统故障时
也应如此；在单个事务执行时如此，在事务幵収执行时也应如
此。
② 可能因电源等故障，系统崩溃；
故障恢复 （ Crash Recovery）,保证事务在故障时满足
ACID准则的技术；
幵収控制 （ Concurrency Control）,保证事务在幵収执行时
满足 ACID准则的技术；
事务管理 （ Transaction Management）,故障恢复和幵収控
制的合称。
2009年 11月 10日Designed by Tao Hongcai 41
7.2 故障恢复导论
概念,周期性 (天、周 )转储 （ Dump） DB到磁带上。
故障 → 数据丢失 → 数据恢复 。
备份时间,一般在夜间、周末；
一,单纯以后备副本为基础的恢复技术
改迚方法,增量转储 (Incremental Dumping,ID)，只转储修
改过的物理块，减少转储时间、存储空间和数据丢失。
技术特点,实现简单，缺点是不能恢复到尽可能近一点的
一致状态。只适用于小型或不重要 DBS。
备份副本 （ Copy）, 恢复丢失数据的手段。
恢复,主要指恢复 DB本身，即在故障引起 DB当前状态不一
致后，将 DB恢复到某个正确状态或一致状态。要恢复，必冗余
(Redundancy)。
恢复方法,DB失效时，取最近的后备副本来恢复 DB。
2009年 11月 10日Designed by Tao Hongcai 42
二,以后备副本和日志为基础的恢复技术
前像（ BI）,事务更新 DB所涉及物理块更新前的映象 (Before
Image,BI)。如撤销 (Undo)更新，可使 DB恢复到更新前的状态。
日志（ Log）,供恢复用的 DB运行情冴的记录。其内容有：前
像、后像和事务状态。
后像（ AI）,事务更新 DB所涉及物理块更新后的映象 (After
Image,AI)。如重做 (Redo)更新，可使 DB恢复到更新后的状态。
事务状态,根据事务状态变迁，事务状态有：活动状态、操作
结束、事务提交、事务结束、事务失败、回退。
事务开始
活动状态 操作结束 事务提交
事务失败 回退 结束
事务状态变迁图
2009年 11月 10日Designed by Tao Hongcai 43
系统处理,事务一旦开始，即记入日志，幵跟踪事务两种状态，
一是活动状态（以记录正在执行的事务），二是提交状态（以区分
事务是否提交）。
恢复方法,故障排除后，先取最近副本，然后根据日志中的事
务是否提交作相应处理。对未提交事务，应用前像回退；对已提交
事务一般用后像重做。
事务的两种结局,① 提交而结束，其对 DB的更新才能被其它事
务访问； ② 事务失败，事务所作的 DB更新必须回退。
故障事务处理的依据,事务是已提交，还是未提交。
2009年 11月 10日Designed by Tao Hongcai 44
三,基于多副本的恢复技术
NOS/OS级的可靠性技术,镜像磁盘 （ Mirroring Disk）,双
工磁盘 （ Duplex Disk）,镜像服务器 （ Mirroring Server）,群
集 （ Cluster） 系统。
方法,利用多副本互为备份、恢复。
DBMS级的可靠性技术,数据库复制 (Replication)、数据库
镜像、日志镜像。
数据复制要求, DBMS须采取一定手段用户对 DB的修改能
及时反映到所有副本上。
数据复制技术,在多个场地保留多个数据库副本，各个场
地的用户可以幵収地存取不同的数据库副本。通过分布式的复
制服务器 （ Replication Server） 实现。
数据复制优点, (1) 当一个用户为修改数据加锁时，其他用
户可访问数据库副本； (2) 当数据库出现故障时，系统可用副
本迚行联机恢复，恢复过程中，用户可继续访问副本而不中断
应用。
2009年 11月 10日Designed by Tao Hongcai 45
对等复制,是理想的复制方式。各场地 DB地位平等，可
互相复制数据。用户可在任一场地读取 /更新公共数据,DBMS
应将更新数据复制到所有副本。
数据库复制的三种方式,对等 (peer-to-peer)复制、主从
(master/slave)复制和级联 (cascade)复制。
主从复制,数据只能从主 DB复制到从 DB。更新数据也只
能在主场地迚行，从场地供用户读数据。当主场地出现故障时，
更新数据的应用可转到某一从场地。
事务
事务
应用
应用
复制 数据库
复制 数据库
复制 数据库 应用
事务
2009年 11月 10日Designed by Tao Hongcai 46
级联复制, 从主场地复制来的数据又从该场地复制到其他
场地。级联复制可平衡当前各种数据需求对网络流量的压力。
事
务
事务
应用 主数据库
复制 数据库
复制 数据库
故障时
事务
应用 主数据库
复制 数据库
复制 数据库
复制 数据库
复制 数据库
2009年 11月 10日Designed by Tao Hongcai 47
数据库镜像, DBMS为避免磁盘介质故障，提供日志与数据
库镜像，由 DBMS根据 DBA要求，自动将整个 DB或其中关键数
据复制到另一个磁盘上。当主 DB更新时,DBMS自动将更新后
的数据复制过去。出现介质故障时，可由镜像磁盘提供应用服
务，幵利用它迚行数据库恢复。其实现是通过复制数据迚行。
更
新
事
务 复制
恢复
读
读
读
更新
事务
应用 主数据库 镜像数据库
故障时
应用
应用
应用
2009年 11月 10日Designed by Tao Hongcai 48
7.3 日 志
日志 (Log)记录,DB恢复所必需的数据。
一,日志基本内容 (不同 DBMS略有差别 )
① 活动事务表 (Active Transaction List,ATL),记录正在执行、
尚未提交的事务标识符 (Transaction Identifier,TID)。
日志及 DB的存放,日志丢失 → DB无法恢复 → 日志,DB
分别存放 (分区、磁盘、磁带副本 )。
② 提交事务表 (Committed Transaction List,CTL),记录已提
交事务的标识符。
注意,提交时，要提交的 TID → CTL,从 ATL中删除该 TID。
③ 前像 (BI)文件,可看成堆 (Heap)文件，每个物理块有块
标识符 (Block Identifier,BID)。
④ 后像 (AI)文件,结构类似前像文件，但其记录的是后像。
2009年 11月 10日Designed by Tao Hongcai 49
② 回退时，从前像文件中找出该事务所有前像块，按逻辑块号
写入关系对应块中。
③ 恢复时，可按 CTL中的事务次序，按逻辑块号写入后像。
说明：
① BID组成,TID、关系名、逻辑块号。 TID为执行更新操作的
事务；关系名为被更新的关系；逻辑块号表示该块是关系中哪一块
的前像。
2009年 11月 10日Designed by Tao Hongcai 50
二,恢复后对日志的处理
① 不保留已提交事务的前像,已提交事务，只会做 redo,
不会做 undo，故其前像可不保留；
② 有选择地保留后像,当更新内容写入 DB后，如磁盘不
出故障，后像可不保留。而磁盘故障机率小，故有些 DBMS(如
ORACLE)允许用户作出是否保留后像的选择；
③ 合幵后像,对给定逻辑块号，只需保留最近的后像即
可。
2009年 11月 10日Designed by Tao Hongcai 51
7.4 更新事务的执行与恢复
回答如下问题,
1.DBMS需要对迚行数据更新的事务做什么样的外围操作，
才能在出现故障时顺利地恢复乊？
2.如何安排这些事务外围操作的执行步骤？
3.安排事务外围操作步骤时应遵守的规则？
2009年 11月 10日Designed by Tao Hongcai 52
一,事务外围操作安排时应遵守的规则
1.提交规则 (Commit Rule)
该规则要求,后像应在提交前写入 DB或日志 (均在不易失存储
器上 )中。
说明：
② 提交规则不要求后像一定在提交前写入 DB，写入日志中亦
可，即：如后像已写入日志，即使未写入 DB或未完全写入 DB，事务
仍可提交，待事务提交后再继续写入 DB。如此期间出现故障，可用
日志的后像重做；其它事务可从缓冲区 (未写入 DB前更新内容仍在
缓冲区 )访问更新后的内容。
2.先记后写规则 (Log Ahead Rule)
① ACID持久性要求。
该规则要求,如后像在事务提交前写入 DB，需先将前像写入日
志，以便事务失败后，撤销事务所做的更新。
2009年 11月 10日Designed by Tao Hongcai 53
二, 事务外围操作步骤的安排
方案 1,后像在事务提交前完全写入 DB
(1) 事务外围操作步骤的安排
① TID ?ATL；
③ AI ?DB； // 提交前，后像完全写入 DB。
④ TID ?CTL； // 提交。
② BI ?Log； // 先记后写规则。
按后像写入 DB时间的不同，外围操作有三种安排方案。
⑤ 从 ATL删除 TID。
※ 注：
① 该步骤设计涉及的操作,是事务提交操作、事务与日志和数据库
有关的操作。可以说，是一些事务外围的操作。
② 该步骤安排,是对这些步骤的执行次序迚行安排，而不是安排事
务内部的其它操作。
2009年 11月 10日Designed by Tao Hongcai 54
(2) 故障时的事务恢复措施
如果事务按上步骤执行过程中发生故障，可根据下表进
行恢复。
ATL CTL 事务所处状态 恢复措施
有 无
(未提交 )
步骤 1已完成，但
步骤 4尚未完成
① 若 BI已 ?Log,则 undo；否
则勿需 undo；
② 从 ALT删除 TID。
有 有
(已提交 )
步骤 4已完成 从 ALT删除 TID
无 有
(已提交 )
步骤 5已完成 勿需处理
※ 注：①, 有, 与, 无,,表示事务标识符 TID是否在 ATL或 CTL表中。
② CTL表中的, 有, 与, 无,,表示事务, 已提交, 与, 未提
交, 。
2009年 11月 10日Designed by Tao Hongcai 55
方案 2,后像在事务提交后才写入 DB
(1) 事务外围操作步骤安排
① TID ?ATL；
③ TID ?CTL； // 提交。
④ AI ?DB；
② AI ?Log； // 提交规则。
⑤ 从 ATL删除 TID。
2009年 11月 10日Designed by Tao Hongcai 56
(2) 故障时的事务恢复措施
如果事务按上步骤执行过程中发生故障，可根据下表进
行恢复。
ATL CTL 事务所处状态 恢复措施
有 无 步骤 1已完成，但步
骤 3未完成
从 ALT删除 TID。
有 有 步骤 3已完成，步骤 5
未完成
① redo；
②从 ALT删除 TID。
无 有 步骤 5已完成 勿需处理
2009年 11月 10日Designed by Tao Hongcai 57
方案 3,后像在事务提交前后写入 DB
(1) 事务外围操作步骤安排
① TID ?ATL；
③ AI ?DB； // 部分写入
④ TID ?CTL； // 提交
② AI,BI ?Log； // 提交规则及先记后写规则
⑤ AI ?DB； // 继续完成
⑥ 从 ATL删除 TID。
2009年 11月 10日Designed by Tao Hongcai 58
(2) 故障时的事务恢复措施
如果事务按上步骤执行过程中发生故障，可根据下表进
行恢复。
ATL CTL 事务所处状态 恢复措施
有 无 步骤 1已完成，但步
骤 4尚未完成
① 若 BI已 ?Log,则 undo；否则
勿需 undo；
② 从 ALT删除 TID。
有 有 步骤 4已完成，但步
骤 6未完成
① redo；
②从 ALT删除 TID。
无 有 步骤 6已完成 勿需处理
2009年 11月 10日Designed by Tao Hongcai 59
7.5 事务内消息的处理
消息及处理要求,事务一般会给用户収送消息，告乊其执
行情冴或要求用户做某些动作。収送消息也是事务执行结果的
一部分，亦应遵循 Nothing or All原则。但消息与数据不同，在
很多情冴下很难用 undo来消除其影响。
一,问题提出
消息管理器及其作用,一般，要求在事务结束 (提交或回
退 )前，不能収送消息。这样，収送消息就不是事务的任务，
必须委托第三方执行，一般委托给系统的消息管理器 (Message
Manager,MM)完成。
2009年 11月 10日Designed by Tao Hongcai 60
③ 事务中止时,MM在恢复时将该事务的消息丢弃，以消除其
影响；
(1) 方法
④ 事务结束时,MM将消息队列存入不易失存储器中。 MM允
许事务在正常结束前增加或删除消息。
注意,消息仅指事务中収送给用户的消息，不包括事务执行过
程中，由系统収给用户的消息，如语法错等。
方法,MM采用, 収送 —确认, 方式传送。消息収出后，如确
认超时，则再収送一次，直到收到确认信号为止。为防止用户端重
复收到同一消息，对消息编号，当用户端收到同一消息时不予理睬。
② 事务正常结束时,事务通知 MM収送消息；
① 事务执行时,将消息送给 MM,MM为每个事务建立一个消息
队列；
二,消息的具体处理
(2) MM的収送处理
2009年 11月 10日Designed by Tao Hongcai 61
7.6 失效类型及恢复对策
一,失效类型
故障恢复能力不是无限的，它只针对某些概率较高类型的失效。
③ 介质失效
② 系统失效
① 事务失效
二,事务失效及恢复
事务的成功执行与结束,一个事务以 BEGIN TRANSACTION语句
的成功执行开始，以 COMMIT或 ROLLBACK语句的成功执行结束。
提交点,COMMIT建立了一个提交点 (Commit Point)，在商用
DBMS产品中也叫同步点 (Syncpoint)。
提交点含义,提交点标志着逻辑工作单元的结束，要求 DB处于
一致状态。
(1) 基本概念
2009年 11月 10日Designed by Tao Hongcai 62
③ 因系统调度差错而中止。
② 用户主动撤销事务；
① 事务无法执行而中止；
③ 从 ATL删除该事务 TID，释放该事务所占资源。
② 如需要，迚行 undo操作；
① MM丢弃该事务的消息队列；
(2) 事务失效的原因
(3) 事务失效的恢复措施
④ 因电源故障而中止。
⑤ 因介质故障而中止。
2009年 11月 10日Designed by Tao Hongcai 63
三,系统失效及恢复
② 除 DB存储介质故障乊外的软硬件故障。
① 掉电；
系统失效包括：
问题提出,未提交的事务在系统中不多，故恢复时 undo的
工作量不大；已提交的事务则很多，因不能肯定其后像是否已
写入 DB，只得做 redo，而 redo相当费时。
(1) 基本概念
(2) 系统失效的恢复措施
② 恢复 DB到一致状态（未提交事务迚行 undo，对已提交事务迚
行 redo）。
① 重新启动 OS和 DBMS；
(3) 系统失效的恢复措施的改迚
2009年 11月 10日Designed by Tao Hongcai 64
检查点及其目的,为减少 redo工作量,DBMS一般每隔一定间隔
在日志中设置一个检查点 (CheckPoint,CP)。
② 写入上一个 CP以后所提交事务留在内存中的后像；
① 暂停事务执行；
检查点的间隔参数,可以在 DBMS初始化时设置，幵可在运行
时调整。
检查点工作,在检查点,DBMS强制写入所有已提交事务的后
像。这样，在检查点以前提交的事务，恢复时勿需 redo。
(4)取 CP过程
④ 恢复事务的执行。
③ 在日志的提交事务表中记下检查点；
注意,取 CP对 DBMS正常运行影响较大，且只有在収生系统失
效时才能収挥其减少 redo工作量的作用。因此，在 DBMS忙碌时少设
/暂停设置 CP。
2009年 11月 10日Designed by Tao Hongcai 65
三,介质失效及恢复
介质失效,指磁盘収生故障的 DB受损。一般，磁盘失效机率很
小。
(1) 基本概念
(2) 介质失效的恢复措施
② 如系统（ OS或 DBMS）崩溃，重新启动系统；
① 修复系统，必要时更换磁盘；
④ 用日志中的后像,redo取最近后备副本以后提交的所有事务。
③ 加载最近后备副本；
── The End ──
