第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.1 安全性
? 问题的提出
– 数据库的一大特点是数据可以共享
– 但数据共享必然带来数据库的安全性问题
– 数据库系统中的数据共享不能是无条件的共
享
例：军事秘密, 国家机密, 新产品实验数据,
市场需求分析, 市场营销策略, 销售计划,
客户档案, 医疗档案, 银行储蓄数据
安全性（续）
– 数据库中数据的共享是在 DBMS统一的严格
的控制之下的共享, 即只允许有合法使用权
限的用户访问允许他存取的数据
– 数据库系统的安全保护措施是否有效是数据
库系统主要的性能指标之一
安全性（续）
?什么是数据库的安全性
– 数据库的安全性是指保护数据库, 防止因用
户非法使用数据库造成数据泄露, 更改或破
坏 。
?什么是数据的保密
– 数据保密是指用户合法地访问到机密数据后
能否对这些数据保密 。
– 通过制订法律道德准则和政策法规来保证 。
5.1 安全性
5.1.1 安全性控制的一般方法
5.1.2 Oracle数据库的安全性措施
5.1 安全性
5.1.1 安全性控制的一般方法
5.1.2 Oracle数据库的安全性措施
5.1.1 安全性控制的一般方法
?非法使用数据库的情况
– 用户编写一段合法的程序绕过 DBMS及其授
权机制，通过操作系统直接存取、修改或备
份数据库中的数据；
– 直接或编写应用程序执行非授权操作；
数据库安全性控制概述（续）
– 通过多次合法查询数据库从中推导出一些保
密数据
例：某数据库应用系统禁止查询单个人的工资，但
允许查任意一组人的平均工资。用户甲想了解张三
的工资，于是他,
首先查询包括张三在内的一组人的平均工资
然后查用自己替换张三后这组人的平均工资
从而推导出张三的工资
– 破坏安全性的行为可能是无意的，故意的，
恶意的。
数据库安全性控制概述（续）
应用 DBMS OS DB
低 高
安全性控制层次
方法,用户标识 和鉴定
存取控制
审计
视图
操作系统
安全保护 密码存储
?计算机系统中的安全模型
数据库安全性控制概述（续）
?数据库安全性控制的常用方法
– 用户标识和鉴定
– 存取控制
– 视图
– 审计
– 密码存储
1,用户标识与鉴定
?用户标识与鉴别（ Identification &
Authentication）
– 系统提供的最外层安全保护措施
用户标识与鉴定（续）
?基本方法
– 系统提供一定的方式让用户标识自己的名字
或身份；
– 系统内部记录着所有合法用户的标识；
– 每次用户要求进入系统时，由系统核对用户
提供的身份标识；
– 通过鉴定后才提供机器使用权。
– 用户标识和鉴定可以重复多次
用户标识与鉴定（续）
?让用户标识自己的名字或身份的方法
– 用户名 /口令
? 简单易行，容易被人窃取
– 每个用户预先约定好一个 计算过程 或者 函数
? 系统提供一个随机数
? 用户根据自己预先约定的计算过程或者
函数进行计算
? 系统根据用户计算结果是否正确鉴定用
户身份
2,存取控制
?存取控制机制的功能
– 存取控制机制的组成
? 定义存取权限
? 检查存取权限
用户权限定义和合法权检查机制一起组成
了 DBMS的安全子系统
存取控制（续）
– 定义存取权限
? 在数据库系统中，为了保证用户只能访问
他有权存取的数据，必须预先对每个用户
定义存取权限。
– 检查存取权限
? 对于通过鉴定获得上机权的用户（即合法
用户），系统根据他的存取权限定义对他
的各种操作请求进行控制，确保他只执行
合法操作。
存取控制（续）
?定义存取权限
– 存取权限
? 存取权限由两个要素组成
–数据对象
–操作类型
存取控制（续）
– 定义存取权限
? 定义一个用户可以在哪些数据对象上进行
哪些类型的操作
? 在数据库系统中，定义存取权限称为授权
（ Authorization）
? 授权定义经过编译后存放在数据字典中
存取控制（续）
– 关系系统中的存取权限
? 类型
数据对象 操作类型
模 式 模 式 建立、修改、删除
外模式 建立、删除
内模式 建立、删除
数 据 表 查找、插入、修改、删除
属性列 查找、插入、修改、删除
存取控制（续）
– 关系系统中的存取权限 (续 )
? 定义方法
– GRANT/REVOKE
自主存取控制方法（续）
– 关系系统中的存取权限 (续 )
? 例, 一张授权表
用户名 数据对象名 允许的操作类型
王平 关系 Student SELECT
李青 关系 Student UPDATE
李青 关系 Course ALL
李青 关系 SC UPDATE
李青 关系 SC SELECT
李青 关系 SC SELECT
存取控制（续）
?检查存取权限
– 对于获得上机权后又进一步发出存取数据库
操作的用户
? DBMS查找数据字典，根据其存取权限对
操作的合法性进行检查
? 若用户的操作请求超出了定义的权限，系
统将拒绝执行此操作
存取控制（续）
? 授权粒度
– 授权粒度是指可以定义的数据对象的范围
? 它是衡量授权机制是否灵活的一个重要指
标。
? 授权定义中数据对象的粒度越细，即可以
定义的数据对象的范围越小，授权子系统
就越灵活。
存取控制（续）
– 关系数据库中授权的数据对象粒度
? 数据库
? 表
? 属性列
? 行
– 能否提供与数据值有关的授权反映了授权子
系统精巧程度
存取控制（续）
?实现与数据值有关的授权
– 利用存取谓词
? 存取谓词可以很复杂
–可以引用系统变量，如终端设备号，
系统时钟等，实现与时间地点有关的
存取权限，这样用户只能在某段时间
内，某台终端上存取有关数据
例：规定“教师只能在每年 1月份和 7月份星期
一至星期五上午 8点到下午 5点处理学生成绩数
据”。
存取控制（续）
例：扩充后的授权表
用户名 数据对象名 允许的操作类型 存取谓词
王平 关系 Student SELECT Sdept=?CS?
张明霞 关系 Student UPDATE Sname=?张明霞 ?
张明霞 关系 Course ALL 空
3,定义视图
? 视图机制把要保密的数据对无权存取这些数据
的用户隐藏起来，从而自动地对数据提供一定
程度的安全保护。
? 视图机制更主要的功能在于提供数据独立性，
其安全保护功能太不精细，往往远不能达到应
用系统的要求。
定义视图（续）
? 在实际应用中通常是视图机制与授权机制配合
使用，首先用视图机制屏蔽掉一部分保密数据，
然后在视图上面再进一步定义存取权限。
– 这时视图机制实际上间接实现了支持存取谓
词的用户权限定义
定义视图（续）
例：王平只能检索计算机系学生的信息
先建立计算机系学生的视图 CS_Student
CREATE VIEW CS_Student
AS
SELECT
FROM Student
WHERE Sdept='CS'；
定义视图（续）
在视图上进一步定义存取权限
GRANT SELECT
ON CS_Student
TO 王平 ；
4,审计
?什么是审计
– 审计功能启用一个专用的审计日志（ Audit
Log），系统自动将用户对数据库的所有操
作记录在上面
– DBA可以利用审计日志中的追踪信息，重现
导致数据库现有状况的一系列事件，以找出
非法存取数据的人
– C2以上安全级别的 DBMS必须具有审计功能
审计（续）
?审计功能的可选性
– 审计很费时间和空间，所以 DBMS往往都将
其作为可选特征
? DBA可以根据应用对安全性的要求，灵
活地打开或关闭审计功能。
审计（续）
– 用户识别和鉴定、存取控制、视图等安全性
措施均为强制性机制，将用户操作限制在规
定的安全范围内。审计技术是预防手段，监
测可能的不合法行为。
审计（续）
– 由于任何系统的安全性措施都不可能是完美
无缺的，蓄意盗窃、破坏数据的人总是想方
设法打破控制。所以，当数据相当敏感，或
者对数据的处理极为重要时，就必须使用审
计技术。
5,数据加密
?数据加密
– 防止数据库中数据在存储和传输中失密的有
效手段
?加密的基本思想
– 根据一定的算法将原始数据（术语为明文，
Plain text）变换为不可直接识别的格式（术
语为密文,Cipher text）
– 不知道解密算法的人无法获知数据的内容
数据加密（续）
?加密方法
– 替换方法
? 使用密钥（ Encryption Key）将明文中的每一个
字符转换为密文中的一个字符
– 置换方法
? 将明文的字符按不同的顺序重新排列
– 这两种方法结合能提供相当高的安全程度
例：美国 1977年制定的官方加密标准：数据加密标
准（ Data Encryption Standard，简称 DES）
数据加密（续）
?DBMS中的数据加密
– 有些数据库产品提供了数据加密例行程序
– 有些数据库产品本身未提供加密程序，但提
供了接口
数据加密（续）
?数据加密功能通常也作为可选特征，允
许用户自由选择
– 数据加密与解密是比较费时的操作
– 数据加密与解密程序会占用大量系统资源
– 应该只对高度机密的数据加密
5.1 安全性
5.1.1 安全性控制的一般方法
5.1.2 Oracle数据库的安全性措施
5.1.2 Oracle数据库的安全性措施
?ORACLE的安全措施,
– 用户标识和鉴定
– 授权和检查机制
– 审计技术
– 用户通过触发器灵活定义自己的安全性措施
一,ORACLE的用户标识和鉴定
?ORACLE允许用户重复标识三次
?如果三次仍未通过，系统自动退出
二,ORACLE的授权与检查机制
?ORACLE授权和检查机制的特色
– ORACLE的权限包括 系统权限 和 数据库对象的权限
– 采用非集中式的授权机制
– 每个用户授予与回收自己创建的数据库对象的权限
– DBA负责授予与回收系统权限，也可以授予与回收
所有数据库对象的权限
– 允许重复授权，即可将某一权限多次授予同一用户，
系统不会出错
– 允许无效回收，即用户不具有某权限，但回收此权
限的操作仍是成功的。
ORACLE的授权与检查机制（续）
?ORACLE的权限
– 系统权限
– 数据库对象的权限
1.系统权限
?80多种系统权限
– 创建会话
– 创建表
– 创建视图
– 创建用户
系统权限（续）
? DBA在创建一个用户时需要将其中的一些权限
授予该用户
? 角色
– ORACLE支持角色的概念。
– 角色就是一组系统权限的集合，目的在于减
化权限管理。
– ORACLE允许 DBA定义角色
– ORACLE提供的预定义角色
? CONNECT
? RESOURCE
? DBA
系统权限（续）
?CONNECT角色
– 允许用户登录数据库并执行数据查询和操纵
? ALTER TABLE
? CREATE VIEW / INDEX
? DROP TABLE / VIEW / INDEX
? GRANT,REVOKE
? INSERT,UPDATE,DELETE
? SELETE
? AUDIT / NOAUDIT
系统权限（续）
?RESOURCE角色
– 允许用户建表，即执行 CREATE TABLE操
作
– 由于创建表的用户将拥有该表，因此他具有
对该表的任何权限
系统权限（续）
?DBA角色
– 允许用户执行授权命令，建表，对任何表的
数据进行操纵。
– DBA角色涵盖了前两种角色，此外还可以执
行一些管理操作。
– DBA角色拥有最高级别的权限。
系统权限（续）
例,DBA建立一用户 U12后，欲将 ALTER
TABLE,CREATE VIEW,CREATE INDEX、
DROP TABLE,DROP VIEW,DROP
INDEX,GRANT,REVOKE,INSERT,
SELETE,UPDATE,DELETE,AUDIT、
NOAUDIT等系统权限授予 U12，则可以只简
单地将 CONNECT角色授予 U12即可,
GRANT CONNECT TO U12;
这样就可以省略十几条 GRANT语句。
2.数据库对象的权限
?ORACLE可以授权的数据库对象
– 基本表
– 视图
– 序列
– 同义词
– 存储过程
– 函数
数据库对象的权限（续）
?基本表的安全性级别
– 表级
– 行级
– 列级
数据库对象的权限（续）
?表级安全性
– 表的创建者或 DBA可以把对表的权限授予其
他用户
数据库对象的权限（续）
– 表级权限
? ALTER,修改表定义
? DELETE：删除表记录
? INDEX,在表上建索引
? INSERT,向表中插入数据记录
? SELECT：查找表中记录
? UPDATE：修改表中的数据
? ALL,上述所有权限
数据库对象的权限（续）
– 表级授权使用 GRANT／ REVOKE语句
例,GRANT SELECT ON SC TO U12;
数据库对象的权限（续）
?行级安全性
– ORACLE行级安全性由视图间接实现
数据库对象的权限（续）
例：用户 U1只允许用户 U12查看自己创建的
Student表中有关信息系学生的信息，则首先
创建视图信息系学生视图 S_IS,
CREATE VIEW S_IS
AS
SELECT Sno,Sname,Ssex,Sage,Sdept
FROM Student
WHERE Sdept='IS';
然后将关于该视图的 SELECT权限授予 U12用户,
GRANT SELECT ON S_IS TO U12;
数据库对象的权限（续）
?列级安全性
– 实现方法
? 由视图间接实现
? 直接在基本表上定义
数据库对象的权限（续）
?列级安全性 (续 )
– 借助视图实现列级安全性
CREATE VIEW S_V
AS
SELECT Sno,Sname
FROM Student；
GRANT SELECT ON S_V TO U12;
数据库对象的权限（续）
?列级安全性 (续 )
– 直接在基本表上定义列级安全性
例,GRANT UPDATE(Sno,Cno) ON SC TO U12;
数据库对象的权限（续）
?三级对象的层次结构
– 表、行、列三级对象自上而下构成一个层次
结构
– 上一级对象的权限制约下一级对象的权限
例：当一个用户拥有了对某个表的 UPDATE权
限，即相当于在表的所有列了都拥有了
UPDATE 权限。
数据库对象的权限（续）
? ORACLE对数据库对象的权限采用分散控制方
式
– 允许具有 WITH GRANT OPTION的用户把
相应权限或其子集传递授予其他用户
? ORACLE不允许循环授权，即授权者不能把权
限再授予其授权者或祖先
U1 ───→ U2 ───→ U3 ───→ U4
↑ │
└───────× ─────────┘
ORACLE的授权与检查机制（续）
?ORACLE的权限检查机制
– ORACLE把所有权限信息记录在数据字典中
– 当用户进行数据库操作时,ORACLE首先根
据数据字典中的权限信息，检查操作的合法
性。
– 在 ORACLE中，安全性检查是任何数据库操
作的第一步。
三,ORACLE的审计技术
?审计分类
– 审计分类
? 用户级审计
? 系统级审计
三,ORACLE的审计技术
?审计分类 (续 )
– 用户级审计
? 设置者
– 任何 ORACLE用户
? 审计对象
– 用户针对自己创建的数据库表或视图进行审计
? 审计内容
– 所有用户对这些表或视图的一切成功和／或不
成功的访问要求
– 所有用户对这些表或视图的各类 SQL操作
ORACLE的审计技术 (续 )
?审计分类 (续 )
– 系统级审计
? 设置者
– DBA
? 审计对象和内容
– 成功或失败的登录要求
– GRANT和 REVOKE操作
– 其他数据库级权限下的操作
ORACLE的审计技术（续）
? 审计设置
– 可以自由设置
? 是否使用审计
? 对哪些表进行审计
? 对哪些操作进行审计
ORACLE的审计技术（续）
? 审计设置 (续 )
– 设置方法
? AUDIT：设置审计功能
例,AUDIT ALTER,UPDATE ON SC;
? NOAUDIT：取消审计功能
例,NOAUDIT ALL ON SC;
ORACLE的审计技术（续）
?与审计功能有关的数据字典表
– SYS.TABLES：审计设置
– SYS.AUDIT_TRAIL：审计内容
四、用户定义的安全性措施
?用数据库级触发器定义用户级安全性
例：规定只能在工作时间内更新 Student表
可以定义如下触发器,
用户定义的安全性措施（续）
CREATE OR REPLACE TRIGGER secure_student
BEFORE INSERT OR UPDATE OR DELETE ON Student
BEGIN
IF (TO_CHAR(sysdate,'DY') IN ('SAT','SUN'))
OR (TO_NUMBER(sysdate,'HH24') NOT
BETWEEN 8 AND 17)
THEN
RAISE_APPLICATION_ERROR(-20506,'You may
only change data during normal business hours.')
END IF;
END;
用户定义的安全性措施（续）
– 触发器一经定义后，将存放在数据字典中
– 用户每次对 Student表执行 INSERT、
UPDATE或 DELETE操作时都会自动触发该
触发器，由系统检查当时的系统时间，如果
是周六或周日，或者不是 8点至 17点，系统
会拒绝执行用户的更新操作，并提示出错信
息。
用户定义的安全性措施（续）
?利用触发器进一步细化审计规则，使审
计操作的粒度更细
第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.2 完整性
?什么是数据库的完整性
– 数据库的完整性是指数据的正确性和相容性,
防止不合语义的数据进入数据库 。
例, 学生的年龄必须是整数, 取值范围为 14--29；
学生的性别只能是男或女；
学生的学号一定是唯一的；
学生所在的系必须是学校开设的系；
– 数据库是否具备完整性关系到数据库系统能
否真实地反映现实世界, 因此维护数据库的
完整性是非常重要的 。
完整性（续）
?完整性控制机制
1.完整性约束条件定义机制
2.完整性检查机制
3.违约反应
完整性（续）
?完整性控制机制 (续 )
1.完整性约束条件定义机制
– 完整性约束条件是数据模型的一个重要组成
部分,它约束了数据库中数据的语义。
– DBMS应提供手段让用户根据现实世界的语
义定义数据库的完整性约束条件，并把它们
作为模式的一部分存入数据库中。
完整性（续）
?完整性控制机制 (续 )
2.完整性检查机制
– 检查用户发出的操作请求是否违背了完整性
约束条件。
完整性（续）
?完整性控制机制 (续 )
3.违约反应
– 如果发现用户的操作请求使数据违背了完整
性约束条件，则采取一定的动作来保证数据
的完整性。
5.2 完整性
5.2.1 完整性约束条件
5.2.2 完整性控制
5.2.3 Oracle的完整性
5.2 完整性
5.2.1 完整性约束条件
5.2.2 完整性控制
5.2.3 Oracle的完整性
5.2.1 完整性约束条件
? 整个完整性控制都是围绕完整性约束条件进行
的，从这个角度说，完整性约束条件是完整性
控制机制的核心。
完整性约束条件（续）
?完整性约束条件作用的对象
– 对象
? 列
–对属性的取值类型、范围、精度等的
约束条件
? 元组
–对元组中各个属性列间的联系的约束
? 关系
–对若干元组间、关系集合上以及关系
之间的联系的约束
完整性约束条件（续）
?完整性约束条件作用的对象 (续 )
– 对象的状态
? 静态
–对静态对象的约束是反映数据库状态
合理性的约束
–这是最重要的一类完整性约束
? 动态
–对动态对象的约束是反映数据库状态
变迁的约束
完整性约束条件（续）
?完整性约束条件分类
六类完整性约束条件
– 静态列级约束
– 静态元组约束
– 静态关系约束
– 动态列级约束
– 动态元组约束
– 动态关系约束
完整性约束条件（续）
对象状态
动态列级约束 动态元组约束 动态关系约束
动态 ④ ⑤ ⑥
静态列级约束 静态元组约束 静态关系约束
静态 ① ② ③
列 元组 关系 对象粒度
完整性约束条件（续）
?1,静态列级约束
– 静态列级约束是对一个列的取值域的说明，
这是最常见最简单同时也最容易实现的一类
完整性约束
完整性约束条件（续）
– 五类静态列级约束
1) 对数据类型的约束，包括数据的类型、长
度、单位、精度等
例：规定学生姓名的数据类型应为字符型，
长度为 8。
2) 对数据格式的约束
例：规定学号的格式为前两位表示入学年份，
后四位为顺序编号。出生日期的格式为
YY.MM.DD。
完整性约束条件（续）
3) 对取值范围或取值集合的约束
例：规定成绩的取值范围为 0-100，年龄的
取值范围为 14-29，性别的取值集合为 [男,
女 ]。
4) 对空值的约束
空值表示未定义或未知的值，它与零值和空
格不同。有的列允许空值，有的则不允许。
例如规定成绩可以为空值。
5) 其他约束
例：关于列的排序说明，组合列等。
完整性约束条件（续）
?2,静态元组约束
– 静态元组约束就是规定组成一个元组的各个
列之间的约束关系。
例：订货关系中包含发货量、订货量等列,
发货量不得超过订货量
教师关系中包含职称、工资等列,
教授的工资不得低于 700元
– 静态元组约束只局限在单个元组上
完整性约束条件（续）
?3,静态关系约束
– 在一个关系的各个元组之间或者若干关系之
间常常存在各种联系或约束
– 常见静态关系约束
1) 实体完整性约束
2) 参照完整性约束
3) 函数依赖约束
4) 统计约束
完整性约束条件（续）
– 函数依赖约束
? 大部分函数依赖约束都是隐含在关系模式
结构中的，特别是规范化程度较高的关系
模式（例如 3NF或 BCNF），都由模式来
保持函数依赖。
? 但是在实际应用中，为了不使信息过于分
离，常常不过分地追求规范化。
完整性约束条件（续）
– 函数依赖约束 (续 )
? 这样在关系的字段间就可以存在一些函数
依赖需要显式地表示出来。
例：在学生－课程－教师关系 SJT(S,J,T)中
存在如下的函数依赖 ((S,J） →T,T→J)，
将 (S,J)作为主码，还需要显式地表示
T→J这个函数依赖。
完整性约束条件（续）
– 统计约束
? 定义某个字段值与一个关系多个元组的统
计值之间的约束关系
例：规定部门经理的工资不得高于本部门职工平
均工资的 5倍，不得低于本部门职工平均工资的 2
倍。本部门职工的平均工资值是一个统计计算值。
完整性约束条件（续）
?4,动态列级约束
– 动态列级约束是修改列定义或列值时应满足
的约束条件
完整性约束条件（续）
– 常见动态列级约束
1) 修改列定义时的约束
例：规定将原来允许空值的列改为不允许空值时，
如果该列目前已存在空值，则拒绝这种修改。
2) 修改列值时的约束
? 修改列值有时需要参照其旧值，并且新旧
值之间需要满足某种约束条件。
例：职工工资调整不得低于其原来工资，学生年
龄只能增长
完整性约束条件（续）
?5,动态元组约束
– 动态元组约束是指修改某个元组的值时需要
参照其旧值，并且新旧值之间需要满足某种
约束条件。
例, 职工工资调整不得低于其原来工资 +工龄 *1.5
完整性约束条件（续）
?6,动态关系约束
– 动态关系约束是加在关系变化前后状态上的
限制条件
例：事务一致性、原子性等约束条件
完整性约束条件（续）
?完整性约束条件小结
粒 度
状态
列 级 元 组 级 关 系 级
静 态 列定义
·类型
·格式
·值域
·空值
元组值应满足
的条件
实体完整性约束
参照完整性约束
函数依赖约束
统计约束
动 态 改变列定义或列值 元组新旧值之间应满足的约束条
件
关系新旧状态间
应满足的约束条
件
5.2 完整性
5.2.1 完整性约束条件
5.2.2 完整性控制
5.2.3 Oracle的完整性
5.2.2 完整性控制
一,DBMS的完整性控制机制
二、关系系统三类完整性的实现
三、参照完整性的实现
一,DBMS的完整性控制机制
?DBMS的完整性控制机制的主要功能
1,定义功能
2,检查功能
3,违约反应
DBMS的完整性控制机制（续）
?1,定义功能
– 一个完善的完整性控制机制应该允许用户定
义各类完整性约束条件。
DBMS的完整性控制机制（续）
?2,检查功能
– 立即执行的约束 (Immediate constraints)
? 检查是否违背完整性约束的时机通常是在
一条语句执行完后立即检查，我们称这类
约束为立即执行的约束
– 延迟执行的约束 (Deferred constrainsts)
? 在某些情况下，完整性检查需要延迟到整
个事务执行结束后再进行，我们称这类约
束为延迟执行的约束
DBMS的完整性控制机制（续）
例：银行数据库中“借贷总金额应平衡”的约束
就应该是延迟执行的约束
– 从账号 A转一笔钱到账号 B为一个事务，从
账号 A转出去钱后账就不平了，必须等转入
账号 B后账才能重新平衡，这时才能进行完
整性检查。
DBMS的完整性控制机制（续）
?3,违约反应
– 拒绝该操作
– 其他处理方法
DBMS的完整性控制机制（续）
?完整性规则的形式化表述
一条完整性规则可以用一个五元组表示,
(D,O,A,C,P)
– D（ Data） 约束作用的 数据对象 ；
– O（ Operation） 触发完整性检查的 数据库操作,
即当用户发出什么操作请求时需要检查该完整性规
则，是立即检查还是延迟检查；
– A（ Assertion） 数据对象必须满足的 断言 或 语义约
束,这是规则的主体；
– C（ Condition） 选择 A作用的数据对象值的 谓词 ；
– P（ Procedure） 违反完整性规则时触发的 过程 。
DBMS的完整性控制机制（续）
例 1：在,学号不能为空,的约束中
D 约束作用的对象为 Sno属性
O 插入或修改 Student 元组时
A Sno不能为空
C 无（ A可作用于所有记录的 Sno属性）
P 拒绝执行该操作
DBMS的完整性控制机制（续）
例 2：在,教授工资不得低于 1000元,的约束中
D 约束作用的对象为工资 Sal属性
O 插入或修改职工元组时
A Sal不能小于 1000
C 职称 =′教授 ′(A仅作用于职称 =‘教授’的记
录 )
P 拒绝执行该操作
二、关系系统三类完整性的实现
? 目前许多关系数据库系统都提供了定义和检查
实体完整性、参照完整性和用户定义的完整性
的功能。
? 对于违反实体完整性规则和用户定义的完整性
规则的操作一般都是采用拒绝执行的方式进行
处理。
? 而对于违反参照完整性的操作，并不都是简单
地拒绝执行，有时还需要采取另一种方法，即
接受这个操作，同时执行一些附加的操作，以
保证数据库的状态仍然是正确的。
三、参照完整性的实现
例,职工－部门数据库包含职工表 EMP和部门表 DEPT
– DEPT关系的主码为部门号 Deptno
– EMP关系的主码为职工号 Empno,外码为部门号 Deptno
– 该 Deptno与 DEPT关系中 Deptno相对应
– 称 DEPT为被参照关系或目标关系,EMP为参照关系
RDBMS实现参照完整性时需要考虑以下 4方面,
参照完整性的实现（续）
?1,外码是否可以接受空值的问题
– 外码是否能够取空值是依赖于应用环境的语
义的。
– 在实现参照完整性时，系统除了应该提供定
义外码的机制，还应提供定义外码列是否允
许空值的机制。
参照完整性的实现（续）
例 1：在职工－部门数据库中,EMP关系包含有
外码 Deptno，某一元组的这一列若为空值，表
示这个职工尚未分配到任何具体的部门工作。
这和应用环境的语义是相符的，因此 EMP的
Deptno列应允许空值。
参照完整性的实现（续）
例 2：在学生－选课数据库中,
Student关系为被参照关系，其主码为 Sno。
SC为参照关系，外码为 Sno。
若 SC的 Sno为空值，则表明尚不存在的某个学生，
或者某个不知学号的学生，选修了某门课程，
其成绩记录在 Grade列中。这与学校的应用环
境是不相符的，因此 SC的 Sno列不能取空值。
参照完整性的实现（续）
?2,删除被参照关系的元组时的问题
– 出现违约操作的情形
? 需要删除被参照关系的某个元组，而参照
关系有若干元组的外码值与被删除的被参
照关系的主码值相对应
参照完整性的实现（续）
? 2,在被参照关系中删除元组时的问题 (续 )
– 违约反应：可有三种策略
? 级联删除（ CASCADES）
? 受限删除（ RESTRICTED）
? 置空值删除（ NULLIFIES）
这三种处理方法，哪一种是正确的，要依应
用环境的语义来定。
参照完整性的实现（续）
– 级联删除
? 将参照关系中所有外码值与被参照关系中
要删除元组主码值相对应的元组一起删除。
– 受限删除
? 只有当参照关系中没有任何元组的外码值
与要删除的被参照关系的元组的主码值相
对应时，系统才执行删除操作，否则拒绝
此删除操作。
参照完整性的实现（续）
– 置空值删除
? 删除被参照关系的元组，并将参照关系中
所有与被参照关系中被删除元组主码值相
等的外码值置为空值。
参照完整性的实现（续）
例：要删除 Student关系中 Sno=950001的元组,
而 SC关系中有 4个元组的 Sno都等于 950001。
– 级联删除：将 SC关系中所有 4个 Sno=950001
的元组一起删除。如果参照关系同时又是另
一个关系的被参照关系，则这种删除操作会
继续级联下去。
– 受限删除：系统将拒绝执行此删除操作。
参照完整性的实现（续）
– 置空值删除：将 SC关系中所有 Sno=950001
的元组的 Sno值置为空值。
– 在学生选课数据库中，显然第一种方法和第
二种方法都是对的。第三种方法不符合应用
环境语义。
参照完整性的实现（续）
?3,修改被参照关系中主码的问题
– 两种策略
? (1)不允许修改主码
? (2)允许修改主码
参照完整性的实现（续）
– 允许修改主码策略
? 违约操作
?要 修改被参照关系 中某些元组的主码
值，而参照关系中有些元组的外码值
正好等于被参照关系要修改的主码值
?要 修改参照关系 中某些元组的主码值，
而被参照关系中没有任何元组的外码
值等于被参照关系修改后的主码值
参照完整性的实现（续）
– 允许修改主码策略 (续 )
? 违约反应 (1)
–修改的关系是被参照关系：与删除类
似
?级联修改
?受限修改
?置空值修改
参照完整性的实现（续）
– 级联修改
? 修改被参照关系中主码值同时，用相同的
方法修改参照关系中相应的外码值。
– 受限修改
? 拒绝此修改操作。只当参照关系中没有任
何元组的外码值等于被参照关系中某个元
组的主码值时，这个元组的主码值才能被
修改。
– 置空值修改
? 修改被参照关系中主码值，同时将参照关
系中相应的外码值置为空值。
参照完整性的实现（续）
例：学生 950001休学一年后复学，这时需要
将 Student关系中 Sno=950001的元组中 Sno值
改为 960123。而 SC关系中有 4个元组的
Sno=950001
– 级联修改：将 SC关系中 4个 Sno=950001元组
中的 Sno值也改为 960123。如果参照关系同
时又是另一个关系的被参照关系，则这种修
改操作会继续级联下去。
参照完整性的实现（续）
– 受限修改：只有 SC中没有任何元组的
Sno=950001时，才能修改 Student表中
Sno=950001的元组的 Sno值改为 960123。
– 置空值修改：将 Student表中 Sno=950001的
元组的 Sno值改为 960123。而将 S表中所有
Sno=950001的元组的 Sno值置为空值。
– 在学生选课数据库中只有第一种方法是正确
的。
参照完整性的实现（续）
– 允许修改主码策略 (续 )
? 违约反应 (2)
–修改的关系是参照关系：与插入类似
?受限修改
?递归修改
参照完整性的实现（续）
?结论
– RDBMS在实现参照完整性时，除了需要向
用户提供定义主码、外码的机制外，还需要
向用户提供按照自己的应用要求选择处理依
赖关系中对应的元组的方法。
5.2 完整性
5.2.1 完整性约束条件
5.2.2 完整性控制
5.2.3 Oracle的完整性
5.2.3 Oracle的完整性
一,Oracle中的实体完整性
二,Oracle中的参照完整性
三,Oracle中用户定义的完整性
一,ORACLE中的实体完整性
? ORACLE在 CREATE TABLE语句中提供了
PRIMARY KEY子句，供用户在建表时指定
关系的主码列。
– 在列级使用 PRIMARY KEY子句
– 在表级使用 PRIMARY KEY子句
ORACLE中的实体完整性（续）
例 1：在学生选课数据库中，要定义 Student表的 Sno属性
为主码
CREATE TABLE Student
(Sno NUMBER(8),
Sname VARCHAR(20),
Sage NUMBER(20),
CONSTRAINT PK_SNO PRIMARY KEY (Sno));
或,
CREATE TABLE Student
(Sno NUMBER(8) PRIMARY KEY,
Sname VARCHAR(20),
Sage NUMBER(20));
ORACLE中的实体完整性（续）
例 2：要在 SC表中定义 (Sno,Cno)为主码
CREATE TABLE SC
(Sno NUMBER(8),
Cno NUMBER(2),
Grade NUMBER(2),
CONSTRAINT PK_SC PRIMARY KEY (Sno,Cno));
ORACLE中的实体完整性（续）
? 在用 PRIMARY KEY语句定义了关系的主码后，
每当用户程序对主码列进行更新操作时，系统
自动进行完整性检查
– 违约操作
? 使主属性值为空值的操作
? 使主码值在表中不唯一的操作
– 违约反应
? 系统拒绝此操作，从而保证了实体完整性
二,ORACLE中的参照完整性
? ORACLE的 CREATE TABLE语句允许用户定
义参照完整性
– 用 FOREIGN KEY子句定义哪些列为外码列
– 用 REFERENCES子句指明这些外码相应于
哪个表的主码
– 用 ON DELETE CASCADE短语指明在删除
被参照关系的元组时，同时删除参照关系中
外码值等于被删除的被参照关系的元组中主
码值的元组
ORACLE中的参照完整性（续）
例 1：建立表 EMP表
CREATE TABLE EMP
(Empno NUMBER(4),
Ename VARCHAR(10),
Job VERCHAR2(9),
Mgr NUMBER(4),
Sal NUMBER(7,2),
Deptno NUMBER(2),
CONSTRAINT FK_DEPTNO
FOREIGN KEY (Deptno)
REFERENCES DEPT(Deptno)
ON DELETE CASCADE);
ORACLE中的参照完整性（续）
或,
CREATE TABLE EMP
(Empno NUMBER(4),
Ename VARCHAR(10),
Job VERCHAR2(9),
Mgr NUMBER(4),
Sal NUMBER(7,2),
Deptno NUMBER(2) CONSTRAINT FK_DEPTNO
FOREIGN KEY REFERENCES DEPT(Deptno)
ON DELETE CASCADE);
ORACLE中的参照完整性（续）
– 这时 EMP表中外码为 Deptno，它相应于
DEPT表中的主码 Deptno。
– 当要修改 DEPT表中的 DEPTNO值时，先要
检查 EMP表中有无元组的 Deptno值与之对
应
? 若没有，系统接受这个修改操作
? 否则，系统拒绝此操作
ORACLE中的参照完整性（续）
– 当要删除 DEPT表中某个元组时，系统要检
查 EMP表，若找到相应元组即将其随之删
除。
– 当要插入 EMP表中某个元组时，系统要检
查 DEPT表，先要检查 DEPT表中有无元组
的 Deptno值与之对应
? 若没有，系统拒绝此插入操作
? 否则，系统接受此操作
三,ORACLE中的用户定义的完整性
? ORACLE中定义用户完整性的两类方法
– 用 CREATE TABLE语句在建表时定义用户
完整性约束
– 通过触发器来定义用户的完整性规则
ORACLE中的用户定义的完整性（续）
? 1,用 CREATE TABLE语句在建表时定义用户
完整性约束
– 可定义三类完整性约束
? 列值非空（ NOT NULL短语）
? 列值唯一（ UNIQUE短语）
? 检查列值是否满足一个布尔表达式
（ CHECK短语）
ORACLE中的用户定义的完整性（续）
例 1：建立部门表 DEPT，要求部门名称 Dname列
取值唯一，部门编号 Deptno列为主码
CREATE TABLE DEPT
(Deptno NUMBER,
Dname VARCHAR(9) CONSTRAINT U1 UNIQUE,
Loc VARCHAR(10),
CONSTRAINT PK_DEPT PRIMARY KEY (Deptno));
其中 CONSTRAINT U1 UNIQUE 表示约束名为 U1,
该约束要求 Dname列值唯一。
ORACLE中的用户定义的完整性（续）
例 2,建立学生登记表 Student，要求学号在
900000至 999999之间，年龄 <29，性别
只能是‘男’或‘女’，姓名非空
CREATE TABLE Student
(Sno NUMBER(5)
CONSTRAINT C1 CHECK
(Sno BETWEEN 10000 AND 99999),
Sname VARCHAR(20) CONSTRAINT C2 NOT NULL,
Sage NUMBER(3) CONSTRAINT C3 CHECK (Sage < 29),
Ssex VARCHAR(2)
CONSTRAINT C4 CHECK (Ssex IN ('男 ','女 '));
ORACLE中的用户定义的完整性（续）
例 3,建立职工表 EMP，要求每个职工的应发工资不得超
过 3000元。 应发工资实际上就是实发工资列 Sal与扣
除项 Deduct之和。
CREATE TABLE EMP
(Eno NUMBER(4)
Ename VARCHAR(10),
Job VARCHAR(8),
Sal NUMBER(7,2),
Deduct NUMBER(7,2)
Deptno NUMBER(2),
CONSTRAINTS C1 CHECK (Sal + Deduct <=3000));
ORACLE中的用户定义的完整性（续）
? 2,通过触发器来定义用户的完整性规则
– 定义其它的完整性约束时，需要用数据库触发器
（ Trigger）来实现。
– 数据库触发器是一类靠事件驱动的特殊过程，一旦
由某个用户定义，任何用户对该数据的增、删、改
操作均由服务器自动激活相应的触发子，在核心层
进行集中的完整性控制。
– 定义数据库触发器的语句
CREATE [OR REPLACE] TRIGGER
ORACLE中的用户定义的完整性（续）
例 4,为教师表 Teacher定义完整性规则“教授的
工资不得低于 800元，如果低于 800元，自动改
为 800元”
ORACLE中的用户定义的完整性（续）
CREATE TRIGGER UPDATE_SAL
BEFORE INSERT OR UPDATE OF Sal,Pos ON Teacher
FOR EACH ROW
WHEN (:new.Pos='教授 ')
BEGIN
IF,new.sal<800 THEN
,new.Sal:=800;
END IF;
END;
第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.3 并发控制
?多事务执行方式 (1)
– 事务串行执行
? 每个时刻只有一个事务运行, 其他事务必
须等到这个事务结束以后方能运行
? 不能充分利用系统资源, 发挥数据库共享
资源的特点
并发控制（续）
?多事务执行方式 (2)
– 交叉并发方式 （ interleaved concurrency）
? 事务的并行执行是这些并行事务的并行操
作轮流交叉运行
? 是单处理机系统中的并发方式, 能够减少
处理机的空闲时间, 提高系统的效率
并发控制（续）
?多事务执行方式 (3)
– 同时并发方式 （ simultaneous concurrency）
? 多处理机系统中, 每个处理机可以运行一
个事务, 多个处理机可以同时运行多个事
务, 实现多个事务真正的并行运行
? 最理想的并发方式, 但受制于硬件环境
并发控制（续）
?事务并发执行带来的问题
– 对多用户并发存取同一数据的操作不加控制
可能会存取和存储不正确的数据, 破坏事务
的隔离性和数据库的一致性
– DBMS必须提供并发控制机制
– 并发控制机制是衡量一个 DBMS性能的重要
标志之一
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3.1 并发控制概述
?1,并发控制的单位 ——事务
?2,并发操作与数据的不一致性
一、事务
? 事务 (Transaction)是用户定义的一个数据库操
作序列，这些操作要么全做，要么全不做，是
一个不可分割的工作单位。
? 事务和程序是两个概念
– 在关系数据库中，一个事务可以是一条 SQL语句，
一组 SQL语句或整个程序
– 一个应用程序通常包含多个事务
? 事务是恢复和并发控制的基本单位
事务（续）
?定义事务的两种方式
– 显式方式
? 事务的开始由用户显式控制或 DBMS自动
隐含
? 事务结束由用户显式控制
– 隐式方式
? 当用户没有显式地定义事务时，由 DBMS
按缺省规定自动划分事务
事务（续）
?显式定义事务
– 1,事务开始
BEGIN TRANSACTION
事务（续）
?显式定义事务（续）
– 2,事务结束（ 1）
? COMMIT
–事务正常结束
–提交事务的所有操作
?使事务中所有对数据库的更新永久
生效（保存在物理数据库中）。
事务（续）
?显式定义事务（续）
– 2,事务结束（ 2）
? ROLLBACK
–事务异常终止
–回滚事务的所有操作
?在事务运行的过程中发生了某种故
障，事务不能继续执行
?系统将事务中对数据库的所有已完
成的更新操作全部撤消，滚回到事
务开始时的状态
事务（续）
事务的 ACID特性,
? 原子性（ Atomicity）
? 一致性（ Consistency）
? 隔离性（ Isolation）
? 持续性（ Durability ）
1,原子性
?事务是数据库的逻辑工作单位
– 事务中包括的诸操作要么都做，要么都不做
2,一致性
?事务执行的结果必须是使数据库从一个
一致性状态变到另一个一致性状态。
– 一致性状态,数据库中只包含成功事务提交
的结果
– 不一致状态,数据库中包含失败事务的结果
? 数据库系统运行中发生故障，有些事务尚
未完成就被迫中断，这些未完成事务对数
据库所做的修改有一部分已写入物理数据
库中
一致性（续）
?一致性与原子性是密切相关的。
例：银行转帐：从帐号 A中取出一万元，存入帐
号 B。
– 定义一个事务，该事务包括两个操作
? 第一个操作是从帐号 A中减去一万元
? 第二个操作是向 帐 号 B中加入一万元
– 这两个操作要么全做，要么全不做
? 全做或者全不做，数据库都处于一致性状态。
? 如果只做一个操作则用户逻辑上就会发生错误，
少了一万元，这时数据库就处于不一致性状态 。
3,隔离性
?一个事务的执行不能被其他事务干扰
– 一个事务内部的操作及使用的数据对其他并
发事务是隔离的，并发执行的各个事务之间
不能互相干扰。
4,持续性
?持续性也称永久性（ Permanence）
– 一个事务一旦提交，它对数据库中数据的改
变就应该是永久性的。
– 接下来的其他操作或故障不应该对其执行结
果有任何影响。
事务的特性 (续 )
? 保证事务 ACID特性是事务处理的重要任务。
? 破坏事务 ACID特性的因素
– 多个事务并行运行时，不同事务的操作交叉执行
? DBMS必须保证多个事务的交叉运行不影响这些
事务 ACID特性，特别是原子性和隔离性
– 事务在运行过程中被强行停止
? DBMS必须保证被强行终止的事务对数据库和其
他事务没有任何影响
这些就是 DBMS中恢复机制和并发控制机制的
责任。
二,并发操作与数据的不一致性
?什么是数据的不一致性
例：飞机订票系统中的一个活动序列,
1） 甲售票员读出某航班的机票余额 A,设 A=16
2） 乙售票员读出同一航班的机票余额 A,也为 16
3） 甲售票点卖出一张机票, 修改机票余额 A←A-1,
所以 A=15,把 A写回数据库
4） 乙售票点也卖出一张机票, 修改机票余额 A←A-1,
所以 A=15,把 A写回数据库
结果：卖出两张机票, 但数据库中机票余额只减少 1。
这种情况称为数据库的不一致性 。
并发控制概述（续）
– 产生原因
? 由甲乙两个售票员并发操作引起
? 在并发操作情况下, 对甲, 乙两个事务的
操作序列的调度是随机的
? 若按上面的调度序列执行, 甲事务的修改
就被丢失 。 因为第 4步中乙事务修改 A并
写回后覆盖了甲事务的修改
并发控制概述（续）
?并发操作带来的数据不一致性
– 丢失修改 （ lost update）
– 不可重复读 （ non-repeatable read）
– 读, 脏, 数据 （ dirty read）
1,丢失修改
? 事务 1与事务 2从数据库中读入同一数据并修改
? 事务 2的提交结果破坏了事务 1提交的结果
? 导致事务 1的修改被丢失 。
图 三种数据不一致性
T1 T2
① 读 A=16
②
③ A←A-1
写回 A=15
④
读 A=16
A←A-1
写回 A=15
(a) 丢失修改
2,不可重复读
?事务 1读取数据
?之后, 事务 2执行更新操作
?从而使事务 1无法再现前一次读取结果 。
图 三种数据不一致性 (续 )
读 B=100
B←B*2
写回 B=200
① 读 A=50
读 B=100
求和 =150
②
③ 读 A=50
读 B=200
求和 =250
(验算不对 )
T2 T1
(b) 不可重复读
不可重复读（续）
?三类不可重复读
– 1,读 -更新
? 事务 1读取某一数据
? 事务 2对其做了修改
? 当事务 1再次读该数据时, 得到与前一次
不同的值 。
不可重复读（续）
?三类不可重复读
– 2,读 -删除
? 事务 1按一定条件从数据库中读取某些数
据记录
? 事务 2删除了其中部分记录
? 当事务 1再次按相同条件读取数据时, 发
现某些记录神密地消失了 。
不可重复读（续）
? 三类不可重复读 (续 )
– 3,读 -插入
? 事务 1按一定条件从数据库中读取某些数
据记录
? 事务 2插入了一些记录
? 当事务 1再次按相同条件读取数据时, 发
现多了一些记录 。
后两种不可重复读有时也称为幻行现象
3,读“脏”数据
? 事务 1修改某一数据, 并将其写回磁盘
? 事务 2读取同一数据
? 之后, 事务 1由于某种原因被撤消, 这时事务 1
已修改过的数据恢复原值
? 事务 2读到的数据就与数据库中的数据不一致,
是不正确的数据, 又称为, 脏, 数据 。
图 三种数据不一致性 (续 )
读 C=200
① 读 C=100
C←C*2
写回 C
②
③ ROLLBACK
C恢复为 100
T2 T1
(c) 读“脏”数据
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3.2 并发操作的调度
? 计算机系统对并行事务中并行操作的调度是的
随机的，而不同的调度可能会产生不同的结果。
? 将所有事务串行起来的调度策略一定是正确的
调度策略。
– 如果一个事务运行过程中没有其他事务在同
时运行，也就是说它没有受到其他事务的干
扰，那么就可以认为该事务的运行结果是正
常的或者预想的
并发操作的调度（续）
? 以不同的顺序串行执行事务也有可能会产生不
同的结果，但由于不会将数据库置于不一致状
态，所以都可以认为是正确的。
? 几个事务的并行执行是正确的,当且仅当其结
果与按某一次序串行地执行它们时的结果相同。
这种并行调度策略称为可串行化（ Serializable）
的调度。
并发操作的调度（续）
?可串行性是并行事务正确性的唯一准则
例：现在有两个事务，分别包含下列操作,
事务 1：读 B； A=B+1；写回 A；
事务 2：读 A； B=A+1；写回 B；
假设 A的初值为 2,B的初值为 2。
并发操作的调度（续）
– 对这两个事务的不同调度策略
? 串行执行
–串行调度策略 1
–串行调度策略 2
? 交错执行
– 不可串行化的调度
– 可串行化的调度
(a) 串行调度策略，正确的调度
读 B＝ 2
A B＋ 1
写回 A＝ 3
读 A＝ 3
B A＋ 1
写回 B＝ 4
T1 T2
(b) 串行调度策略，正确的调度
读 B＝ 11
A B＋ 1
写回 A＝ 12
读 A＝ 10
B A＋ 1
写回 B＝ 11
T1 T2
(c) 不可串行化的调度
读 B＝ 2
A B＋ 1
写回 A＝ 3
读 A＝ 10
B A＋ 1
写回 B＝ 11
T1 T2
(c) 不可串行化的调度 (续 )
– 由于其执行结果与 (a),(b)的结果都不同，
所以是错误的调度。
(d) 可串行化的调度
读 B＝ 2
A B＋ 1
写回 A＝ 3
等待
等待
等待
读 A＝ 3
B A＋ 1
写回 B＝ 4
T1 T2
(d) 可串行化的调度（续）
? 由于其执行结果与串行调度（ a）的执行
结果相同，所以是正确的调度。
并发操作的调度（续）
? 为了保证并行操作的正确性,DBMS的并行控
制机制必须提供一定的手段来保证调度是可串
行化的。
? 从理论上讲，在某一事务执行时禁止其他事务
执行的调度策略一定是可串行化的调度，这也
是最简单的调度策略，但这种方法实际上是不
可行的，因为它使用户不能充分共享数据库资
源。
并发操作的调度（续）
?保证并发操作调度正确性的方法
– 封锁方法,两段锁 （ Two-Phase Locking，
简称 2PL） 协议
– 时标方法
– 乐观方法
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3.3 封锁
? 封锁就是事务 T在对某个数据对象（例如表、
记录等）操作之前，先向系统发出请求，对其
加锁。加锁后事务 T就对该数据对象有了一定
的控制，在事务 T释放它的锁之前，其它的事
务不能更新此数据对象。
? 封锁是实现并发控制的一个非常重要的技术
5.5.3 封锁
?5.3.3.1 封锁类型
?5.3.3.2 封锁粒度
?5.3.3.3 封锁协议
5.5.3 封锁
?5.3.3.1 封锁类型
?5.3.3.2 封锁粒度
?5.3.3.3 封锁协议
5.3.3.1 封锁类型
? DBMS通常提供了多种类型的封锁。一个事务
对某个数据对象加锁后究竟拥有什么样的控制
是由封锁的类型决定的。
? 基本封锁类型
– 排它锁（ eXclusive lock，简记为 X锁）
– 共享锁（ Share lock，简记为 S锁）
封锁类型（续）
? 排它锁
– 排它锁又称为写锁。
– 若事务 T对数据对象 A加上 X锁，则只允许 T
读取和修改 A，其它任何事务都不能再对 A
加任何类型的锁，直到 T释放 A上的锁。
封锁类型（续）
? 共享锁
– 共享锁又称为读锁。
– 若事务 T对数据对象 A加上 S锁，则其它事务
只能再对 A加 S锁，而不能加 X锁，直到 T释
放 A上的 S锁。
封锁类型（续）
Y=Yes，相容的请求
N=No，不相容的请求
T1
T2
X S -
X N N Y
S N Y Y
- Y Y Y
5.5.3 封锁
?5.3.3.1 封锁类型
?5.3.3.2 封锁粒度
?5.3.3.3 封锁协议
5.3.3.2 封锁粒度
? X锁和 S锁都是加在某一个数据对象上的。
? 封锁的对象可以是逻辑单元，也可以是物理单
元。
例：在关系数据库中，封锁对象可以是,
– 逻辑单元, 属性值、属性值集合、元组、关
系、索引项、整个索引、整个数据库等
– 物理单元：页（数据页或索引页）、块等
封锁粒度（续）
? 封锁对象可以很大也可以很小
例,对整个数据库加锁
对某个属性值加锁
? 封锁对象的大小称为封锁的粒度 (Granularity)
封锁粒度（续）
? 封锁粒度与系统的并发度和并发控制的开销密
切相关。
– 封锁的粒度越大，系统中能够被封锁的对象
就越少，并发度也就越小，但同时系统开销
也越小；
– 封锁的粒度越小，并发度越高，但系统开销
也就越大。
? 选择封锁粒度时必须同时考虑封锁机构和并发
度两个因素，对系统开销与并发度进行权衡，
以求得最优的效果。
封锁粒度（续）
?一般原则
– 需要处理大量元组的用户事务：以关系为封
锁单元；
– 需要处理多个关系的大量元组的用户事务：
以数据库为封锁单位；
– 只处理少量元组的用户事务：以元组为封锁
单位
5.5.3 封锁
?5.3.3.1 封锁类型
?5.3.3.2 封锁粒度
?5.3.3.3 封锁协议
5.3.3.3 封锁协议
?什么是封锁协议
– 在运用 X锁和 S锁对数据对象加锁时，需要约定一些
规则，这些规则为封锁协议（ Locking Protocol）。
? 何时申请 X锁或 S锁
? 持锁时间
? 何时释放
– 对封锁方式规定不同的规则，就形成了各种不同的
封锁协议，它们分别在不同的程度上为并发操作的
正确调度提供一定的保证。
封锁协议 （续）
?一、保证数据一致性的封锁协议
?二、保证并行调度可串行性的封锁协
议 ——两段锁协议
一、保证数据一致性的封锁协
议 ——三级封锁协议
三级封锁协议
– 1级封锁协议
– 2级封锁协议
– 3级封锁协议
1级封锁协议
? 1级封锁协议
– 事务 T在修改数据 R之前必须先对其加 X锁，
直到事务结束才释放。
? 正常结束 （ COMMIT）
? 非正常结束 （ ROLLBACK）
? 1级封锁协议可防止丢失修改，并保证事务 T是
可恢复的。
? 在 1级封锁协议中，如果仅仅是读数据不对其
进行修改，是不需要加锁的，所以它不能保证
可重复读和不读“脏”数据。
图 用封锁机制解决三种数据不一致性示例
T1 T2
① Xlock A
获得
② 读 A=16
③ A←A-1
写回 A=15
Commit
Unlock A
④
⑤
Xlock A
等待
等待
等待
等待
获得 Xlock A
读 A=15
A←A-1
写回 A=14
Commit
Unlock A
(a) 没有丢失修改
图 用封锁机制解决三种数据不一致性示例
读 A=15
① Xlock A
获得
② 读 A=16
A←A-1
写回 A=15
③
④ Rollback
Unlock A
T2 T1
(a.1) 读“脏”数据
图 用封锁机制解决三种数据不一致性示例
Xlock B
获得
读 B=100
B←B*2
写回 B=200
Commit
Unlock B
① 读 A=50
读 B=100
求和 =150
②
③ 读 A=50
读 B=200
求和 =250
(验算不对 )
T2 T1
(a.2) 不可重复读
2级封锁协议
? 2级封锁协议
– 1级封锁协议加上事务 T在读取数据 R之前必
须先对其加 S锁，读完后即可释放 S锁。
? 2级封锁协议可以防止丢失修改和读“脏”数
据。
? 在 2级封锁协议中，由于读完数据后即可释放 S
锁，所以它不能保证可重复读。
图 用封锁机制解决三种数据不一致性示例
T1 T2
① Xlock C
读 C= 100
C←C*2
写回 C=200
②
③ ROLLBACK
(C恢复为 100)
Unlock C
④
⑤
Slock C
等待
等待
等待
等待
获得 Slock C
读 C=100
Commit C
Unlock C
(c) 不读“脏”数据
图 用封锁机制解决三种数据不一致性示例
(c.1) 不可重复读
① Sclock A
获得
读 A=50
Unlock A
② Sclock B
获得
读 B=100
Unlock B
③ 求和 =150
Xlock B
等待
等待
获得 Xlock B
读 B=100
B←B*2
写回 B=200
Commit
Unlock B
T2 T1
④ Sclock A
获得
读 A=50
Unlock A
Sclock B
获得
读 B=200
Unlock B
求和 =250
(验算不对 )
T2 T1 (续 )
3级封锁协议
? 3级封锁协议
– 1级封锁协议加上事务 T在读取数据 R之前必
须先对其加 S锁，直到事务结束才释放。
? 3级封锁协议可防止丢失修改、读脏数据和不
可重复读。
图 用封锁机制解决三种数据不一致性示例
T1 T2
① Slock A
读 A=50
Slock B
读 B=100
求和 =150
②
③ 读 A=50
读 B=100
求和 =150
Commit
Unlock A
Unlock B
④
⑤
Xlock B
等待
等待
等待
等待
等待
等待
等待
等待
获得 Xlock B
读 B=100
B←B*2
写回 B=200
Commit
Unlock B
(b) 可重复读
三级封锁协议
?三级协议的主要区别
– 什么操作需要申请封锁以及何时释放锁（即
持锁时间）
三级封锁协议 (续 )
二、两段锁协议
? 可串行性是并行调度正确性的唯一准则，两段
锁（ 2PL）协议就是为保证并行调度可串行性
而提供的封锁协议。
? 两段锁协议的内容
1,在对任何数据进行读、写操作之前，事务
首先要获得对该数据的封锁
2,在释放一个封锁之后，事务不再获得任何
其他封锁。
两段锁协议（续）
?“两段”锁的含义
– 事务分为两个阶段
? 第一阶段是获得封锁，也称为扩展阶段；
? 第二阶段是释放封锁，也称为收缩阶段。
两段锁协议（续）
例,
事务 1的封锁序列,
Slock A,.,Slock B,.,Xlock C,.,Unlock B,.,Unlock A,.,
Unlock C；
事务 2的封锁序列,
Slock A,.,Unlock A,.,Slock B,.,Xlock C,.,Unlock C,.,
Unlock B；
事务 1遵守两段锁协议，而事务 2不遵守两段协议。
两段锁协议（续）
? 并行执行的所有事务均遵守两段锁协议，则对
这些事务的所有并行调度策略都是可串行化的。
所有遵守两段锁协议的事务，其并行执行的结
果一定是正确的。
? 事务遵守两段锁协议是可串行化调度的 充分条
件,而不是必要条件。即可串行化的调度中，
不一定所有事务都必须符合两段锁协议。
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3.4 死锁和活锁
?封锁技术可以有效地解决并行操作的一
致性问题，但也带来一些新的问题
– 死锁
– 活锁
一,活锁
什么是活锁
活锁 (续 )
如何避免活锁
?采用先来先服务的策略
– 当多个事务请求封锁同一数据对象时, 封
锁子系统按请求封锁的先后次序对这些事务
排队
– 该数据对象上的锁一旦释放, 首先批准申
请队列中第一个事务获得锁 。
二,死锁
什么是死锁
T1 T2
Xlock R1
,
,
,
Xlock R2
等待
等待
等待
,
,
,
Xlock R2
,
,
Xlock R1
等待
等待
,
死锁 （续）
如何解决死锁
?解决死锁的两类方法
1,死锁的预防
2,死锁的诊断与解除
1,死锁的预防
?预防死锁为何能解决死锁
– 产生死锁的原因是两个或多个事务都已封锁
了一些数据对象，然后又都请求对已为其他
事务封锁的数据对象加锁，从而出现死等待。
– 预防死锁的发生就是要破坏产生死锁的条件。
死锁的预防 （续）
?预防死锁的方法
– 一次封锁法
– 顺序封锁法
（ 1）一次封锁法
? 一次封锁法要求每个事务必须一次将所有要使
用的数据全部加锁，否则就不能继续执行。
? 一次封锁法存在的问题：降低并发度
– 扩大封锁范围
? 一次就将以后要用到的全部数据加锁，势
必扩大了封锁的范围，从而降低了系统的
并发度。
一次封锁法（续）
– 难于事先精确确定封锁对象
? 数据库中数据是不断变化的，原来不要求
封锁的数据，在执行过程中可能会变成封
锁对象，所以很难事先精确地确定每个事
务所要封锁的数据对象
? 解决方法：将事务在执行过程中可能要封
锁的数据对象全部加锁，这就进一步降低
了并发度 。
（ 2）顺序封锁法
? 顺序封锁法是预先对数据对象规定一个封锁顺
序，所有事务都按这个顺序实行封锁。
? 顺序封锁法存在的问题
– 维护成本高
? 数据库系统中可封锁的数据对象极其众多，
并且随数据的插入、删除等操作而不断地
变化，要维护这样极多而且变化的资源的
封锁顺序非常困难，成本很高。
顺序封锁法（续）
– 难于实现
? 事务的封锁请求可以随着事务的执行而动
态地决定，很难事先确定每一个事务要封
锁哪些对象，因此也就很难按规定的顺序
去施加封锁。
例：规定数据对象的封锁顺序为 A,B,C,D,E。
事务 T3起初要求封锁数据对象 B,C,E，但当
它封锁了 B,C后，才发现还需要封锁 A，这
样就破坏了封锁顺序,
死锁的预防（续）
?结论
– 在操作系统中广为采用的预防死锁的策略并
不很适合数据库的特点
– DBMS在解决死锁的问题上更普遍采用的是
诊断并解除死锁的方法
2,死锁的诊断与解除
?方法
– 由 DBMS的并发控制子系统定期检测系统中
是否存在死锁，一旦检测到死锁，就要设法
解除。
死锁的诊断与解除（续）
? 检测死锁
– 超时法
? 如果一个事务的等待时间超过了规定的时
限，就认为发生了死锁。
? 优点
–实现简单
? 缺点
–有可能误判死锁
–时限若设置得太长，死锁发生后不能
及时发现
死锁的诊断与解除（续）
– 等待图法
? 用事务等待图动态反映所有事务的等待情况
– 事务等待图是一个有向图 G=(T,U)
– T为结点的集合，每个结点表示正运行的事务
– U为边的集合，每条边表示事务等待的情况
– 若 T1等待 T2，则 T1,T2之间划一条有向边，从 T1
指向 T2
? 并发控制子系统周期性地（比如每隔 1 min）
检测事务等待图，如果发现图中存在回路，
则表示系统中出现了死锁。
死锁的诊断与解除（续）
?解除死锁
– 选择一个处理死锁代价最小的事务，
将其撤消，释放此事务持有的所有的
锁，使其它事务能继续运行下去。
第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.4 恢复
? 故障是不可避免的
– 计算机硬件故障
– 系统软件和应用软件的错误
– 操作员的失误
– 恶意的破坏
? 故障的影响
– 轻则造成运行事务非正常中断，影响数据库中数据
的正确性
– 重则破坏数据库，使数据库中数据部分或全部丢失。
例，银行转帐。
恢复（续）
? 数据库管理系统对故障的对策
– DBMS提供了恢复子系统，用来保证各种故
障发生后，能把数据库中的数据从错误状态
恢复到某种逻辑一致的状态。即保证各个事
务中的操作要么全部完成，要么全部不做。
? 数据库系统所采用的恢复技术是否行之有效是
衡量系统性能优劣的重要指标。
5.4 恢复
5.4.1 恢复的原理
5.4.2 恢复的实现技术
5.4.3 ORACLE的恢复技术
5.4 恢复
5.4.1 恢复的原理
5.4.2 恢复的实现技术
5.4.3 ORACLE的恢复技术
5.4.1 恢复的原理
?事务故障
?系统故障
?介质故障
一、事务故障
?什么是事务故障
– 某个事务在运行过程中由于种种原因未运行
至正常终止点就夭折了
?事务故障的常见原因
– 输入数据有误
– 运算溢出
– 违反了某些完整性限制
– 某些应用程序出错
– 并行事务发生死锁
事务故障（续）
?事务故障的恢复
– 发生事务故障时，夭折的事务可能已把对数
据库的部分修改写回磁盘。
– 事务故障的恢复,事务撤消（ UNDO）
? 恢复程序要在不影响其它事务运行的情况
下，强行回滚（ ROLLBACK）该事务，
即清除该事务对数据库的所有修改，使得
这个事务象根本没有启动过一样
二、系统故障
?什么是系统故障
– 由于某种原因造成整个系统的正常运行突然
停止，致使所有正在运行的事务都以非正常
方式终止。
– 发生系统故障时，内存中数据库缓冲区的信
息全部丢失，但存储在外部存储设备上的数
据未受影响
系统故障（续）
?系统故障的常见原因
– 操作系统或 DBMS代码错误
– 操作员操作失误
– 特定类型的硬件错误（如 CPU故障）
– 突然停电
系统故障（续）
?系统故障的恢复
– 1,清除尚未完成的事务对数据库的所有修改
? 如果 DBMS无法确定哪些事务已更新过数据库，
则系统重新启动后，恢复程序要强行撤消
（ UNDO）所有未完成事务，使这些事务象没有
运行过一样。
– 2,将缓冲区中已完成事务提交的结果写入数据库
? 如果 DBMS无法确定哪些事务的提交结果尚未写
入物理数据库，则系统重新启动后，恢复程序需
要重做（ REDO）所有已提交的事务。
三、介质故障
?什么是介质故障
– 硬件故障使存储在外存中的数据部分丢失或
全部丢失
– 介质故障比前两类故障的可能性小得多，但
破坏性最大。
介质故障 (续 )
?介质故障的常见原因
– 硬件故障
? 磁盘损坏
? 磁头碰撞
– 操作系统的某种潜在错误
– 瞬时强磁场干扰
介质故障（续）
?介质故障的恢复
– 装入 数据库发生介质故障前某个时刻的数据
副本
– 重做自此时始的所有 成功事务,将这些事务
已提交的结果重新记入数据库
故障的种类小结
?数据库系统中各类故障对数据库的影响
– 数据库本身被破坏 （介质故障）
– 数据库处于不一致状态
? 数据库中包含了未完成事务对数据库的修
改（事务故障、系统故障）
? 数据库中丢失了已提交事务对数据库的修
改（系统故障）
?不同类型的故障应采用不同的恢复操作
故障的种类小结（续）
?恢复操作的基本原理：简单
– 任何恢复操作的原理都是一样的
– 原理,利用 存储在系统其它地方的 冗余数据
来 重建 数据库中已经被破坏或已经不正确的
那部分数据
?恢复的实现技术：复杂
– 一般一个大型数据库产品，恢复子系统的代
码要占全部代码的 10%以上
5.4 恢复
5.4.1 恢复的原理
5.4.2 恢复的实现技术
5.4.3 ORACLE的恢复技术
5.4.2 恢复的实现技术
? 恢复技术的原理
– 利用存储在系统其它地方的冗余数据来修复或重建
数据库中被破坏的或不正确的数据。
? 恢复机制涉及的关键问题
1,如何建立冗余数据
? 数据转储
? 登记日志文件
2,如何利用这些冗余数据实施数据库恢复
5.4.2 恢复的实现技术
5.4.2.1 数据转储
5.4.2.2 登记日志文件
5.4.2.3 恢复策略
5.4.2 恢复的实现技术
5.4.2.1 数据转储
5.4.2.2 登记日志文件
5.4.2.3 恢复策略
5.4.2.1 数据转储
一、什么是转储
二、转储的用途
三、转储方法
一、什么是转储
? 转储是指 DBA将整个数据库复制到磁带或另一
个磁盘上保存起来的过程。
? 这些备用的数据文本称为 后备副本 或 后援副本 。
二、转储的用途
? 用途：供介质故障恢复时使用
– 一旦系统发生介质故障，数据库遭到破坏，
可以将后备副本重新装入，把数据库恢复起
来。
? 恢复的程度
– 重装后备副本只能将 DB恢复到转储时的状
态
– 要想恢复到故障发生时的状态，必须重新运
行自转储以后的所有更新事务
转储的用途（续）
例,
故障发生点
转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本 重新运行事务
恢复 ────────┴ －－－－－－－－－－－ － →
三、转储方法
1．静态转储与动态转储
2．海量转储与增量转储
3．转储方法小结
1．静态转储与动态转储
?静态转储
– 静态转储是在系统中无运行事务时进行的转
储操作
? 转储操作开始的时刻，数据库处于一致性
状态
? 转储期间不允许（或不存在）对数据库的
任何存取、修改活动
– 静态转储得到的一定是一个数据一致性的副
本
静态转储与动态转储（续）
– 静态转储的优点
? 实现简单
– 静态转储的缺点
? 降低了数据库的可用性
–转储必须等待用户事务结束才能进行
–新的事务必须等待转储结束才能执行
静态转储与动态转储（续）
– 利用静态转储得到的副本进行故障恢复
? 只需要把静态转储得到的后备副本装入，
就能把数据库恢复到转储时刻的正确状态
利用静态转储副本进行恢复
故障发生点
静态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本
恢复 ━━━━━━┥
静态转储与动态转储（续）
? 动态转储
– 动态转储是指转储操作与用户事务并发进行，
转储期间允许对数据库进行存取或修改。
– 动态转储的优点
? 不用等待正在运行的用户事务结束
? 不会影响新事务的运行
– 动态转储的缺点
? 不能保证副本中的数据正确有效
静态转储与动态转储（续）
– 利用动态转储得到的副本进行故障恢复
? 需要把动态转储期间各事务对数据库的修
改活动登记下来，建立日志文件
? 后备副本加上日志文件才能把数据库恢复
到某一时刻的正确状态
利用动态转储副本进行恢复
Ta Tb Tf
动态 转储 运行事务 故障发生点
正常运行 ─┼───────┼─────────────
登记日志文件 登记新日志文件
─────────┼─────────────
?
转储日志文件
重装后备副本, 然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态
2．海量转储与增量转储
? 海量转储
– 每次转储全部数据库
? 增量转储
– 只转储上次转储后更新过的数据
? 海量转储与增量转储比较
– 从恢复角度看，使用海量转储得到的后备副
本进行恢复往往更方便
– 但如果数据库很大，事务处理又十分频繁，
则增量转储方式更实用更有效
3．转储方法小结
?转储方法分类
转储状态
动态转储 静态转储
转储
方式
海量转储
动态海量转储 静态海量转储
增量转储 动态增量转储 静态增量转储
转储方法小结（续）
?转储策略
– 从恢复方便角度看，应经常进行数据转储，制作后
备副本。
– 但转储又是十分耗费时间和资源的，不能频繁进行。
– DBA应该根据数据库使用情况确定适当的转储周期
和转储方法。
例,
? 每天晚上进行动态增量转储
? 每周进行一次动态海量转储
? 每月进行一次静态海量转储
5.4.2 恢复的实现技术
5.4.2.1 数据转储
5.4.2.2 登记日志文件
5.4.2.3 恢复策略
5.4.2.2 登记日志文件
一、日志文件的内容
二、日志文件的用途
三、登记日志文件的原则
一、日志文件的内容
?1,什么是日志文件
– 日志文件 (log)是用来记录事务对数据库的更
新操作的文件。
?2,日志文件的格式
– 以记录为单位的日志文件
– 以数据块为单位的日志文件
日志文件的内容（续）
?3,日志文件内容
– 各个事务的开始标记 (BEGIN TRANSACTION)
– 各个事务的结束标记 (COMMIT或 ROLLBACK)
– 各个事务的所有更新操作
– 每个事务开始的标记、每个事务的结束标记和每个
更新操作均作为日志文件中的一个日志记录 (log
record)
日志文件的内容（续）
?4,基于记录的日志文件
– 每条日志记录的内容
? 事务标识（标明是那个事务）
? 操作类型（插入、删除或修改）
? 操作对象
? 更新前数据的旧值（对插入操作而言，此
项为空值）
? 更新后数据的新值（对删除操作而言,此
项为空值）
日志文件的内容（续）
?5,基于数据块的日志文件
– 每条日志记录的内容
? 事务标识（标明是那个事务）
? 更新前数据所在的整个数据块的值（对插
入操作而言，此项为空值）
? 更新后整个数据块的值（对删除操作而言,
此项为空值）
二、日志文件的用途
? 1．用途
– 进行事务故障恢复
– 进行系统故障恢复
– 协助后备副本进行介质故障恢复
日志文件的用途（续）
? 2．与静态转储后备副本配合进行介质故障恢
复
– 静态转储的数据已是一致性的数据
– 如果静态转储完成后，仍能定期转储日志文
件，则在出现介质故障重装数据副本后，可
以利用这些日志文件副本对已完成的事务进
行重做处理
– 这样不必重新运行那些已完成的事务程序就
可把数据库恢复到故障前某一时刻的正确状
态
日志文件的用途（续）
故障发生点
静态转储 运行事务 ↓
正常运行 ─┼──────┼─────────────
Ta Tb Tf
登记日志文件
└─────────────
重装后备副本 利用日志文件恢复事务 继续运行
介质故障恢复 ───────┴ －－－－－－－－－－ ┴───────→
登记日志文件
└─────── →
日志文件的用途（续）
? 3．与动态转储后备副本配合使用进行介质故
障恢复
– 动态转储机制在转储数据库时，必须同时转
储同一时间点的日志文件，后备副本与该日
志文件结合起来才能将数据库恢复到一致性
状态。
– 与静态转储一样，如果动态转储完成后，仍
能定期转储日志文件，则在做介质故障恢复
时，可以利用这些日志文件副本进一步恢复
数据库，避免重新运行事务程序。
三、登记日志文件的原则
? 为保证数据库是可恢复的，登记日志文件时必
须遵循两条原则
– 登记的次序严格按并行事务执行的时间次序
– 必须先写日志文件，后写数据库
? 写数据库操作：把对数据的修改写到数据库中
? 写日志文件操作：把表示这个修改的日志记录写
到日志文件
登记日志文件的原则（续）
? 为什么要先写日志文件
– 写数据库和写日志文件是两个不同的操作
– 有可能在这两个操作之间发生故障，即这两个写操
作只完成了一个
– 如果先写了数据库修改，而在日志文件中没有登记
下这个修改，则以后就无法恢复这个修改了
– 如果先写日志，但没有修改数据库，按日志文件恢
复时只不过是多执行一次不必要的 UNDO操作，并
不会影响数据库的正确性
5.4.2 恢复的实现技术
5.4.2.1 数据转储
5.4.2.2 登记日志文件
5.4.2.3 恢复策略
5.4.2.3 恢复策略
?1,事务故障的恢复
?2,系统故障的恢复
?3,介质故障的恢复
1,事务故障的恢复
? 事务故障是指事务在运行至正常终止点前被中
止
? 恢复方法
– 由恢复子系统应利用日志文件撤消（ UNDO）
此事务已对数据库进行的修改
? 事务故障的恢复由系统自动完成，不需要用户
干预
事务故障的恢复（续）
?恢复步骤
1,反向扫描文件日志（即从最后向前扫描日
志文件），查找该事务的更新操作。
2,对该事务的更新操作执行逆操作。即将日
志记录中“更新前的值”写入数据库。
– 如果记录中是插入操作，则相当于做删除操作（因
为此时“更新前的值”为空）
– 若记录中是删除操作，则相当于做插入操作（因为
此时“更新后的值”为空）
– 若是修改操作，则相当于用修改前值代替修改后值
事务故障的恢复（续）
– 3,继续反向扫描日志文件，查找该事务的其
他更新操作，并做同样处理。
– 4,如此处理下去，直至读到此事务的开始标
记，事务故障恢复就完成了。
2,系统故障的恢复
? 系统故障造成数据库不一致状态的原因
– 一些未完成事务对数据库的更新已写入数据库
– 一些已提交事务对数据库的更新还留在缓冲区
没来得及写入数据库
? 恢复方法
– 1,撤消故障发生时未完成的事务
– 2,重做已完成的事务
? 系统故障的恢复由系统在重新启动时自动完成，
不需要用户干预
系统故障的恢复（续）
?恢复步骤
1,正向扫描日志文件（即从头扫描日志文件）
– 找出在故障发生前已经提交的事务,将事务
标识记入重做队列
– 同时找出故障发生时尚未完成的事务,将事
务标识记入撤消队列
系统故障的恢复（续）
2,对撤消队列中的各个事务进行撤消 (UNDO)
处理
– 反向扫描日志文件，对每个 UNDO事务的更
新操作执行逆操作，即将日志记录中“更新
前的值”写入数据库
3,对重做队列中的各个事务进行重做 (REDO)
处理
– 正向扫描日志文件，对每个 REDO事务重新
执行登记的操作。即将日志记录中“更新后
的值”写入数据库
3,介质故障的恢复
? 发生介质故障后，磁盘上的物理数据和日志文
件被破坏，这是最严重的一种故障
? 恢复方法
– 1,重装数据库，使数据库恢复到一致性状态
– 2,重做已完成的事务
介质故障的恢复（续）
?恢复步骤
1,装入最新的后备数据库副本，使数据库恢复到
最近一次转储时的一致性状态。
– 对于静态转储的数据库副本，装入后数据库
即处于一致性状态
– 对于动态转储的数据库副本，还须同时装入
转储时刻的日志文件副本，利用与恢复系统
故障相同的方法（即 REDO+UNDO），才
能将数据库恢复到一致性状态。
利用静态转储副本将数据库恢复到一致性状态
故障发生点
静态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
登记日志文件
└─────────────
重装后备副本
恢复 ━━━━━━┥
利用动态转储副本将数据库恢复到一致性状态
Ta Tb Tf
动态 转储 运行事务 故障发生点
正常运行 ─┼───────┼─────────────
登记日志文件 登记新日志文件
─────────┼─────────────
?
转储日志文件
重装后备副本, 然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态
介质故障的恢复（续）
2,装入有关的日志文件副本，重做已完成的事务。
– 首先扫描日志文件，找出故障发生时已提交
的事务的标识，将其记入重做队列。
– 然后正向扫描日志文件，对重做队列中的所
有事务进行重做处理。即将日志记录中“更
新后的值”写入数据库。
介质故障的恢复（续）
?介质故障的恢复需要 DBA介入
– DBA的工作
? 重装最近转储的数据库副本和有关的各日
志文件副本
? 执行系统提供的恢复命令
– 具体的恢复操作仍由 DBMS完成
5.4 恢复
5.4.1 恢复的原理
5.4.2 恢复的实现技术
5.4.3 ORACLE的恢复技术
5.4.3 Oracle的恢复技术
?ORACLE恢复机制
– 1,转储
– 2,登记日志文件
Oracle的恢复技术（续）
?1,转储
– 转储后备副本的方法
? 文件拷贝
? EXPORT实用程序
? 用 SQL命令 SPOOL
? 自己编程实现
Oracle的恢复技术（续）
– 重装后备副本的方法
? 文件拷贝
? IMPORT实用程序
? SQL*LOADER实用程序
? 自己编程实现
Oracle的恢复技术（续）
?2,登记日志文件
– ORACLE V.5：以数据块为单位
– ORACLE V.7,REDO日志 + 回滚段
Oracle的恢复技术（续）
?ORACLE V.5的恢复技术
– 日志文件以数据块为单位，恢复操作不是基
于操作，而是基于数据块
– 将更新前的旧值与更新后的新值分别放在两
个不同的日志文件中
? 记录数据库更新前旧值的日志文件称为数
据库前像文件（ Before Image，简称 BI文
件）
? 记录数据库更新后新值的日志文件称为数
据库的后像文件（ After Image，简称 AI
文件）
Oracle的恢复技术（续）
?ORACLE V.5的恢复技术 (续 )
– BI文件是必须的,AI文件是任选的
– 没有 AI文件：只能执行 UNDO处理，不能执
行 REDO处理
Oracle的恢复技术（续）
?ORACLE V.7的恢复技术
– REDO日志文件：记录被更新数据的前像和
后像
– 回滚段 (Rollback Segment）：记录尚未完成
的更新事务的更新数据的前像
– 事务故障恢复
? 根据回滚段中的数据，撤消该事务的操作
Oracle的恢复技术（续）
?ORACLE V.7的恢复技术 (续 )
– 系统故障恢复
? 首先扫描 REDO日志文件，重做所有操作，
并对更新操作建立回滚段数据。当遇到提
交记录，取消相应回滚段中数据。
? 再根据回滚段中的数据，撤消未正常提交
的事务的操作（图 7.6）
优点：只需要扫描日志文件一遍
Oracle的恢复技术（续）
图 Oracle的恢复过程
(a) 发生故障，事务非正常终止
Ta Tf
T1 T3
T2 T44
时间
Oracle的恢复技术（续）
(b) 利用 REDO文件，重做所有操作
时间
T1 T3
T2 T44
Oracle的恢复技术（续）
(c) 利用回滚段撤消未提交的事务数据库恢复到一致性状态
时间
T1
T2
Oracle的恢复技术（续）
?ORACLE V.7的恢复技术 (续 )
– 介质故障恢复
? 重装数据库后备副本文件，恢复到转储时
的数据库一致性状态
? 利用在此之后转储的 REDO日志文件副本
将数据库恢复到最近点 (类似于系统故障
恢复 )
小结
? 如果数据库只包含成功事务提交的结果，就说
数据库处于一致性状态。保证数据一致性是对
数据库的最基本的要求。
? 事务是数据库的逻辑工作单位
– DBMS保证系统中一切事务的原子性、一致
性、隔离性和持续性
小结（续）
? DBMS必须对事务故障、系统故障和介质故障
进行恢复
? 恢复中最经常使用的技术：数据库转储和登记
日志文件
? 恢复的基本原理：利用存储在后备副本、日志
文件和数据库镜像中的冗余数据来重建数据库
小结（续）
?常用恢复技术
– 事务故障的恢复
? UNDO
– 系统故障的恢复
? UNDO + REDO
– 介质故障的恢复
? 重装备份并恢复到一致性状态 + REDO
第 5章 数据库保护
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.5 数据库复制和数据库镜像
?5.5.1 数据库复制
?5.5.2 数据库镜像
5.5 数据库复制和数据库镜像
?5.5.1 数据库复制
?5.5.2 数据库镜像
5.5.1 数据库复制
?复制是数据库更具容错性的方法，主要用
于分布式结构的数据库中
?在多个场地保留多个数据库备份，可是是
整个数据库的副本，也可以是部分数据库
的副本
?各个场地的用户可以并发存取不同的数据
库副本，进一步提高系统并发度。但 DBMS
必须采取一定手段，保证用户对数据库的
修改能够及时反映到其所有副本上
数据库复制（续）
?当数据库出现故障，系统可以用副本对
其进行联机恢复，而在恢复过程中，用
户可以继续访问该数据库的副本，而不
必中断其应用，如下页图所示
图：数据复制
结点 1 结点 2
主数据库 备份数据库
结点 2
主数据库 备份数据库
数据库复制（续）
?数据库复制三种方式,
– 对等复制
– 主 /从复制
– 级联复制
?不同的复制方式提供了不同程度的数据
一致性
1、对等复制
?对等复制是最理想的复制方式
– 哥哥场地的数据库地位是平等的，可以互相
复制数据
– 用户可以在任何场地读取和更新公共数据集，
在某一场地更新公共数据集时,DBMS会立
即将数据传送到所有其它副本
对等复制（续）
应用 复制数据库
复制数据库 复制数据库
复制数据库
应用
事务
事务
2、主 /从复制
?数据只能从主数据库中复制到从数据库
中
?更新数据只能在主场地上进行，从场地
供用户读数据
?当主场地出现故障时，更新数据的应用
可以转到其中一个复制场地上去
?实现起来比较简单，易于维护数据一致
性
主 /从数据库（续）
复制数据库
复制数据库 复制数据库
复制数据库
应用 事务
3、级联复制
?指从主场的复制过来的数据，又从该场
地再次复制到其它场地，即 A场地把数据
复制到 B场地,B场地又把这些数据或其
中部分数据再复制到其它场地
?可以平衡当前各种数据需求对网络交通
的压力
?通常与前两种配置联合使用
级联复制（续）
复制数据库
复制数据库 复制数据库
复制数据库
应用 事务
复制数据库 复制数据库
数据库复制（续）
? DBMS在使用复制技术时必须做到以下几点,
– 1、数据库复制必须对用户透明
– 2、主数据库和各个从复制数据库在任何时候都必
须保持事务的完整性
– 3、对于对异步的可在任何地方更新的复制方式，
当两个应用在两个场地同时更新同一个记录，一个
场地的更新事务尚未复制到另一个场地时，第二个
场地已开始更新，这时可能引起冲突。 DBMS必须
提供控制冲突的方法，包括各种形式的自动解决方
法和人工干预方法
5.5 数据库复制和数据库镜像
?5.5.1 数据库复制
?5.5.2 数据库镜像
5.5.2 数据库镜像
? 介质故障是对系统影响最为严重的一种故障，
严重影响数据库的可用性
– 介质故障恢复比较费时
– 为预防介质故障,DBA必须周期性地转储数
据库
? 提高数据库可用性的解决方案
– 数据库镜像（ Mirror）
数据库镜像（续）
?数据库镜像
– DBMS自动把整个数据库或其中的关键数据
复制到另一个磁盘上
– DBMS自动保证镜像数据与主数据的一致性
(图 7.5a)
数据库镜像（续）
?数据库镜像的用途
– 出现介质故障时
? DBMS自动利用镜像磁盘数据进行数据库
的恢复，不需要关闭系统和重装数据库副
本 (图 7.5b)
– 没有出现故障时
? 可用于并发操作 (图 7.5a)
–一个用户对数据加排他锁修改数据
–其他用户可以读镜像数据库上的数据
数据库镜像（续）
图数据库镜像
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.1 安全性
? 问题的提出
– 数据库的一大特点是数据可以共享
– 但数据共享必然带来数据库的安全性问题
– 数据库系统中的数据共享不能是无条件的共
享
例：军事秘密, 国家机密, 新产品实验数据,
市场需求分析, 市场营销策略, 销售计划,
客户档案, 医疗档案, 银行储蓄数据
安全性（续）
– 数据库中数据的共享是在 DBMS统一的严格
的控制之下的共享, 即只允许有合法使用权
限的用户访问允许他存取的数据
– 数据库系统的安全保护措施是否有效是数据
库系统主要的性能指标之一
安全性（续）
?什么是数据库的安全性
– 数据库的安全性是指保护数据库, 防止因用
户非法使用数据库造成数据泄露, 更改或破
坏 。
?什么是数据的保密
– 数据保密是指用户合法地访问到机密数据后
能否对这些数据保密 。
– 通过制订法律道德准则和政策法规来保证 。
5.1 安全性
5.1.1 安全性控制的一般方法
5.1.2 Oracle数据库的安全性措施
5.1 安全性
5.1.1 安全性控制的一般方法
5.1.2 Oracle数据库的安全性措施
5.1.1 安全性控制的一般方法
?非法使用数据库的情况
– 用户编写一段合法的程序绕过 DBMS及其授
权机制，通过操作系统直接存取、修改或备
份数据库中的数据；
– 直接或编写应用程序执行非授权操作；
数据库安全性控制概述（续）
– 通过多次合法查询数据库从中推导出一些保
密数据
例：某数据库应用系统禁止查询单个人的工资，但
允许查任意一组人的平均工资。用户甲想了解张三
的工资，于是他,
首先查询包括张三在内的一组人的平均工资
然后查用自己替换张三后这组人的平均工资
从而推导出张三的工资
– 破坏安全性的行为可能是无意的，故意的，
恶意的。
数据库安全性控制概述（续）
应用 DBMS OS DB
低 高
安全性控制层次
方法,用户标识 和鉴定
存取控制
审计
视图
操作系统
安全保护 密码存储
?计算机系统中的安全模型
数据库安全性控制概述（续）
?数据库安全性控制的常用方法
– 用户标识和鉴定
– 存取控制
– 视图
– 审计
– 密码存储
1,用户标识与鉴定
?用户标识与鉴别（ Identification &
Authentication）
– 系统提供的最外层安全保护措施
用户标识与鉴定（续）
?基本方法
– 系统提供一定的方式让用户标识自己的名字
或身份；
– 系统内部记录着所有合法用户的标识；
– 每次用户要求进入系统时，由系统核对用户
提供的身份标识；
– 通过鉴定后才提供机器使用权。
– 用户标识和鉴定可以重复多次
用户标识与鉴定（续）
?让用户标识自己的名字或身份的方法
– 用户名 /口令
? 简单易行，容易被人窃取
– 每个用户预先约定好一个 计算过程 或者 函数
? 系统提供一个随机数
? 用户根据自己预先约定的计算过程或者
函数进行计算
? 系统根据用户计算结果是否正确鉴定用
户身份
2,存取控制
?存取控制机制的功能
– 存取控制机制的组成
? 定义存取权限
? 检查存取权限
用户权限定义和合法权检查机制一起组成
了 DBMS的安全子系统
存取控制（续）
– 定义存取权限
? 在数据库系统中，为了保证用户只能访问
他有权存取的数据，必须预先对每个用户
定义存取权限。
– 检查存取权限
? 对于通过鉴定获得上机权的用户（即合法
用户），系统根据他的存取权限定义对他
的各种操作请求进行控制，确保他只执行
合法操作。
存取控制（续）
?定义存取权限
– 存取权限
? 存取权限由两个要素组成
–数据对象
–操作类型
存取控制（续）
– 定义存取权限
? 定义一个用户可以在哪些数据对象上进行
哪些类型的操作
? 在数据库系统中，定义存取权限称为授权
（ Authorization）
? 授权定义经过编译后存放在数据字典中
存取控制（续）
– 关系系统中的存取权限
? 类型
数据对象 操作类型
模 式 模 式 建立、修改、删除
外模式 建立、删除
内模式 建立、删除
数 据 表 查找、插入、修改、删除
属性列 查找、插入、修改、删除
存取控制（续）
– 关系系统中的存取权限 (续 )
? 定义方法
– GRANT/REVOKE
自主存取控制方法（续）
– 关系系统中的存取权限 (续 )
? 例, 一张授权表
用户名 数据对象名 允许的操作类型
王平 关系 Student SELECT
李青 关系 Student UPDATE
李青 关系 Course ALL
李青 关系 SC UPDATE
李青 关系 SC SELECT
李青 关系 SC SELECT
存取控制（续）
?检查存取权限
– 对于获得上机权后又进一步发出存取数据库
操作的用户
? DBMS查找数据字典，根据其存取权限对
操作的合法性进行检查
? 若用户的操作请求超出了定义的权限，系
统将拒绝执行此操作
存取控制（续）
? 授权粒度
– 授权粒度是指可以定义的数据对象的范围
? 它是衡量授权机制是否灵活的一个重要指
标。
? 授权定义中数据对象的粒度越细，即可以
定义的数据对象的范围越小，授权子系统
就越灵活。
存取控制（续）
– 关系数据库中授权的数据对象粒度
? 数据库
? 表
? 属性列
? 行
– 能否提供与数据值有关的授权反映了授权子
系统精巧程度
存取控制（续）
?实现与数据值有关的授权
– 利用存取谓词
? 存取谓词可以很复杂
–可以引用系统变量，如终端设备号，
系统时钟等，实现与时间地点有关的
存取权限，这样用户只能在某段时间
内，某台终端上存取有关数据
例：规定“教师只能在每年 1月份和 7月份星期
一至星期五上午 8点到下午 5点处理学生成绩数
据”。
存取控制（续）
例：扩充后的授权表
用户名 数据对象名 允许的操作类型 存取谓词
王平 关系 Student SELECT Sdept=?CS?
张明霞 关系 Student UPDATE Sname=?张明霞 ?
张明霞 关系 Course ALL 空
3,定义视图
? 视图机制把要保密的数据对无权存取这些数据
的用户隐藏起来，从而自动地对数据提供一定
程度的安全保护。
? 视图机制更主要的功能在于提供数据独立性，
其安全保护功能太不精细，往往远不能达到应
用系统的要求。
定义视图（续）
? 在实际应用中通常是视图机制与授权机制配合
使用，首先用视图机制屏蔽掉一部分保密数据，
然后在视图上面再进一步定义存取权限。
– 这时视图机制实际上间接实现了支持存取谓
词的用户权限定义
定义视图（续）
例：王平只能检索计算机系学生的信息
先建立计算机系学生的视图 CS_Student
CREATE VIEW CS_Student
AS
SELECT
FROM Student
WHERE Sdept='CS'；
定义视图（续）
在视图上进一步定义存取权限
GRANT SELECT
ON CS_Student
TO 王平 ；
4,审计
?什么是审计
– 审计功能启用一个专用的审计日志（ Audit
Log），系统自动将用户对数据库的所有操
作记录在上面
– DBA可以利用审计日志中的追踪信息，重现
导致数据库现有状况的一系列事件，以找出
非法存取数据的人
– C2以上安全级别的 DBMS必须具有审计功能
审计（续）
?审计功能的可选性
– 审计很费时间和空间，所以 DBMS往往都将
其作为可选特征
? DBA可以根据应用对安全性的要求，灵
活地打开或关闭审计功能。
审计（续）
– 用户识别和鉴定、存取控制、视图等安全性
措施均为强制性机制，将用户操作限制在规
定的安全范围内。审计技术是预防手段，监
测可能的不合法行为。
审计（续）
– 由于任何系统的安全性措施都不可能是完美
无缺的，蓄意盗窃、破坏数据的人总是想方
设法打破控制。所以，当数据相当敏感，或
者对数据的处理极为重要时，就必须使用审
计技术。
5,数据加密
?数据加密
– 防止数据库中数据在存储和传输中失密的有
效手段
?加密的基本思想
– 根据一定的算法将原始数据（术语为明文，
Plain text）变换为不可直接识别的格式（术
语为密文,Cipher text）
– 不知道解密算法的人无法获知数据的内容
数据加密（续）
?加密方法
– 替换方法
? 使用密钥（ Encryption Key）将明文中的每一个
字符转换为密文中的一个字符
– 置换方法
? 将明文的字符按不同的顺序重新排列
– 这两种方法结合能提供相当高的安全程度
例：美国 1977年制定的官方加密标准：数据加密标
准（ Data Encryption Standard，简称 DES）
数据加密（续）
?DBMS中的数据加密
– 有些数据库产品提供了数据加密例行程序
– 有些数据库产品本身未提供加密程序，但提
供了接口
数据加密（续）
?数据加密功能通常也作为可选特征，允
许用户自由选择
– 数据加密与解密是比较费时的操作
– 数据加密与解密程序会占用大量系统资源
– 应该只对高度机密的数据加密
5.1 安全性
5.1.1 安全性控制的一般方法
5.1.2 Oracle数据库的安全性措施
5.1.2 Oracle数据库的安全性措施
?ORACLE的安全措施,
– 用户标识和鉴定
– 授权和检查机制
– 审计技术
– 用户通过触发器灵活定义自己的安全性措施
一,ORACLE的用户标识和鉴定
?ORACLE允许用户重复标识三次
?如果三次仍未通过，系统自动退出
二,ORACLE的授权与检查机制
?ORACLE授权和检查机制的特色
– ORACLE的权限包括 系统权限 和 数据库对象的权限
– 采用非集中式的授权机制
– 每个用户授予与回收自己创建的数据库对象的权限
– DBA负责授予与回收系统权限，也可以授予与回收
所有数据库对象的权限
– 允许重复授权，即可将某一权限多次授予同一用户，
系统不会出错
– 允许无效回收，即用户不具有某权限，但回收此权
限的操作仍是成功的。
ORACLE的授权与检查机制（续）
?ORACLE的权限
– 系统权限
– 数据库对象的权限
1.系统权限
?80多种系统权限
– 创建会话
– 创建表
– 创建视图
– 创建用户
系统权限（续）
? DBA在创建一个用户时需要将其中的一些权限
授予该用户
? 角色
– ORACLE支持角色的概念。
– 角色就是一组系统权限的集合，目的在于减
化权限管理。
– ORACLE允许 DBA定义角色
– ORACLE提供的预定义角色
? CONNECT
? RESOURCE
? DBA
系统权限（续）
?CONNECT角色
– 允许用户登录数据库并执行数据查询和操纵
? ALTER TABLE
? CREATE VIEW / INDEX
? DROP TABLE / VIEW / INDEX
? GRANT,REVOKE
? INSERT,UPDATE,DELETE
? SELETE
? AUDIT / NOAUDIT
系统权限（续）
?RESOURCE角色
– 允许用户建表，即执行 CREATE TABLE操
作
– 由于创建表的用户将拥有该表，因此他具有
对该表的任何权限
系统权限（续）
?DBA角色
– 允许用户执行授权命令，建表，对任何表的
数据进行操纵。
– DBA角色涵盖了前两种角色，此外还可以执
行一些管理操作。
– DBA角色拥有最高级别的权限。
系统权限（续）
例,DBA建立一用户 U12后，欲将 ALTER
TABLE,CREATE VIEW,CREATE INDEX、
DROP TABLE,DROP VIEW,DROP
INDEX,GRANT,REVOKE,INSERT,
SELETE,UPDATE,DELETE,AUDIT、
NOAUDIT等系统权限授予 U12，则可以只简
单地将 CONNECT角色授予 U12即可,
GRANT CONNECT TO U12;
这样就可以省略十几条 GRANT语句。
2.数据库对象的权限
?ORACLE可以授权的数据库对象
– 基本表
– 视图
– 序列
– 同义词
– 存储过程
– 函数
数据库对象的权限（续）
?基本表的安全性级别
– 表级
– 行级
– 列级
数据库对象的权限（续）
?表级安全性
– 表的创建者或 DBA可以把对表的权限授予其
他用户
数据库对象的权限（续）
– 表级权限
? ALTER,修改表定义
? DELETE：删除表记录
? INDEX,在表上建索引
? INSERT,向表中插入数据记录
? SELECT：查找表中记录
? UPDATE：修改表中的数据
? ALL,上述所有权限
数据库对象的权限（续）
– 表级授权使用 GRANT／ REVOKE语句
例,GRANT SELECT ON SC TO U12;
数据库对象的权限（续）
?行级安全性
– ORACLE行级安全性由视图间接实现
数据库对象的权限（续）
例：用户 U1只允许用户 U12查看自己创建的
Student表中有关信息系学生的信息，则首先
创建视图信息系学生视图 S_IS,
CREATE VIEW S_IS
AS
SELECT Sno,Sname,Ssex,Sage,Sdept
FROM Student
WHERE Sdept='IS';
然后将关于该视图的 SELECT权限授予 U12用户,
GRANT SELECT ON S_IS TO U12;
数据库对象的权限（续）
?列级安全性
– 实现方法
? 由视图间接实现
? 直接在基本表上定义
数据库对象的权限（续）
?列级安全性 (续 )
– 借助视图实现列级安全性
CREATE VIEW S_V
AS
SELECT Sno,Sname
FROM Student；
GRANT SELECT ON S_V TO U12;
数据库对象的权限（续）
?列级安全性 (续 )
– 直接在基本表上定义列级安全性
例,GRANT UPDATE(Sno,Cno) ON SC TO U12;
数据库对象的权限（续）
?三级对象的层次结构
– 表、行、列三级对象自上而下构成一个层次
结构
– 上一级对象的权限制约下一级对象的权限
例：当一个用户拥有了对某个表的 UPDATE权
限，即相当于在表的所有列了都拥有了
UPDATE 权限。
数据库对象的权限（续）
? ORACLE对数据库对象的权限采用分散控制方
式
– 允许具有 WITH GRANT OPTION的用户把
相应权限或其子集传递授予其他用户
? ORACLE不允许循环授权，即授权者不能把权
限再授予其授权者或祖先
U1 ───→ U2 ───→ U3 ───→ U4
↑ │
└───────× ─────────┘
ORACLE的授权与检查机制（续）
?ORACLE的权限检查机制
– ORACLE把所有权限信息记录在数据字典中
– 当用户进行数据库操作时,ORACLE首先根
据数据字典中的权限信息，检查操作的合法
性。
– 在 ORACLE中，安全性检查是任何数据库操
作的第一步。
三,ORACLE的审计技术
?审计分类
– 审计分类
? 用户级审计
? 系统级审计
三,ORACLE的审计技术
?审计分类 (续 )
– 用户级审计
? 设置者
– 任何 ORACLE用户
? 审计对象
– 用户针对自己创建的数据库表或视图进行审计
? 审计内容
– 所有用户对这些表或视图的一切成功和／或不
成功的访问要求
– 所有用户对这些表或视图的各类 SQL操作
ORACLE的审计技术 (续 )
?审计分类 (续 )
– 系统级审计
? 设置者
– DBA
? 审计对象和内容
– 成功或失败的登录要求
– GRANT和 REVOKE操作
– 其他数据库级权限下的操作
ORACLE的审计技术（续）
? 审计设置
– 可以自由设置
? 是否使用审计
? 对哪些表进行审计
? 对哪些操作进行审计
ORACLE的审计技术（续）
? 审计设置 (续 )
– 设置方法
? AUDIT：设置审计功能
例,AUDIT ALTER,UPDATE ON SC;
? NOAUDIT：取消审计功能
例,NOAUDIT ALL ON SC;
ORACLE的审计技术（续）
?与审计功能有关的数据字典表
– SYS.TABLES：审计设置
– SYS.AUDIT_TRAIL：审计内容
四、用户定义的安全性措施
?用数据库级触发器定义用户级安全性
例：规定只能在工作时间内更新 Student表
可以定义如下触发器,
用户定义的安全性措施（续）
CREATE OR REPLACE TRIGGER secure_student
BEFORE INSERT OR UPDATE OR DELETE ON Student
BEGIN
IF (TO_CHAR(sysdate,'DY') IN ('SAT','SUN'))
OR (TO_NUMBER(sysdate,'HH24') NOT
BETWEEN 8 AND 17)
THEN
RAISE_APPLICATION_ERROR(-20506,'You may
only change data during normal business hours.')
END IF;
END;
用户定义的安全性措施（续）
– 触发器一经定义后，将存放在数据字典中
– 用户每次对 Student表执行 INSERT、
UPDATE或 DELETE操作时都会自动触发该
触发器，由系统检查当时的系统时间，如果
是周六或周日，或者不是 8点至 17点，系统
会拒绝执行用户的更新操作，并提示出错信
息。
用户定义的安全性措施（续）
?利用触发器进一步细化审计规则，使审
计操作的粒度更细
第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.2 完整性
?什么是数据库的完整性
– 数据库的完整性是指数据的正确性和相容性,
防止不合语义的数据进入数据库 。
例, 学生的年龄必须是整数, 取值范围为 14--29；
学生的性别只能是男或女；
学生的学号一定是唯一的；
学生所在的系必须是学校开设的系；
– 数据库是否具备完整性关系到数据库系统能
否真实地反映现实世界, 因此维护数据库的
完整性是非常重要的 。
完整性（续）
?完整性控制机制
1.完整性约束条件定义机制
2.完整性检查机制
3.违约反应
完整性（续）
?完整性控制机制 (续 )
1.完整性约束条件定义机制
– 完整性约束条件是数据模型的一个重要组成
部分,它约束了数据库中数据的语义。
– DBMS应提供手段让用户根据现实世界的语
义定义数据库的完整性约束条件，并把它们
作为模式的一部分存入数据库中。
完整性（续）
?完整性控制机制 (续 )
2.完整性检查机制
– 检查用户发出的操作请求是否违背了完整性
约束条件。
完整性（续）
?完整性控制机制 (续 )
3.违约反应
– 如果发现用户的操作请求使数据违背了完整
性约束条件，则采取一定的动作来保证数据
的完整性。
5.2 完整性
5.2.1 完整性约束条件
5.2.2 完整性控制
5.2.3 Oracle的完整性
5.2 完整性
5.2.1 完整性约束条件
5.2.2 完整性控制
5.2.3 Oracle的完整性
5.2.1 完整性约束条件
? 整个完整性控制都是围绕完整性约束条件进行
的，从这个角度说，完整性约束条件是完整性
控制机制的核心。
完整性约束条件（续）
?完整性约束条件作用的对象
– 对象
? 列
–对属性的取值类型、范围、精度等的
约束条件
? 元组
–对元组中各个属性列间的联系的约束
? 关系
–对若干元组间、关系集合上以及关系
之间的联系的约束
完整性约束条件（续）
?完整性约束条件作用的对象 (续 )
– 对象的状态
? 静态
–对静态对象的约束是反映数据库状态
合理性的约束
–这是最重要的一类完整性约束
? 动态
–对动态对象的约束是反映数据库状态
变迁的约束
完整性约束条件（续）
?完整性约束条件分类
六类完整性约束条件
– 静态列级约束
– 静态元组约束
– 静态关系约束
– 动态列级约束
– 动态元组约束
– 动态关系约束
完整性约束条件（续）
对象状态
动态列级约束 动态元组约束 动态关系约束
动态 ④ ⑤ ⑥
静态列级约束 静态元组约束 静态关系约束
静态 ① ② ③
列 元组 关系 对象粒度
完整性约束条件（续）
?1,静态列级约束
– 静态列级约束是对一个列的取值域的说明，
这是最常见最简单同时也最容易实现的一类
完整性约束
完整性约束条件（续）
– 五类静态列级约束
1) 对数据类型的约束，包括数据的类型、长
度、单位、精度等
例：规定学生姓名的数据类型应为字符型，
长度为 8。
2) 对数据格式的约束
例：规定学号的格式为前两位表示入学年份，
后四位为顺序编号。出生日期的格式为
YY.MM.DD。
完整性约束条件（续）
3) 对取值范围或取值集合的约束
例：规定成绩的取值范围为 0-100，年龄的
取值范围为 14-29，性别的取值集合为 [男,
女 ]。
4) 对空值的约束
空值表示未定义或未知的值，它与零值和空
格不同。有的列允许空值，有的则不允许。
例如规定成绩可以为空值。
5) 其他约束
例：关于列的排序说明，组合列等。
完整性约束条件（续）
?2,静态元组约束
– 静态元组约束就是规定组成一个元组的各个
列之间的约束关系。
例：订货关系中包含发货量、订货量等列,
发货量不得超过订货量
教师关系中包含职称、工资等列,
教授的工资不得低于 700元
– 静态元组约束只局限在单个元组上
完整性约束条件（续）
?3,静态关系约束
– 在一个关系的各个元组之间或者若干关系之
间常常存在各种联系或约束
– 常见静态关系约束
1) 实体完整性约束
2) 参照完整性约束
3) 函数依赖约束
4) 统计约束
完整性约束条件（续）
– 函数依赖约束
? 大部分函数依赖约束都是隐含在关系模式
结构中的，特别是规范化程度较高的关系
模式（例如 3NF或 BCNF），都由模式来
保持函数依赖。
? 但是在实际应用中，为了不使信息过于分
离，常常不过分地追求规范化。
完整性约束条件（续）
– 函数依赖约束 (续 )
? 这样在关系的字段间就可以存在一些函数
依赖需要显式地表示出来。
例：在学生－课程－教师关系 SJT(S,J,T)中
存在如下的函数依赖 ((S,J） →T,T→J)，
将 (S,J)作为主码，还需要显式地表示
T→J这个函数依赖。
完整性约束条件（续）
– 统计约束
? 定义某个字段值与一个关系多个元组的统
计值之间的约束关系
例：规定部门经理的工资不得高于本部门职工平
均工资的 5倍，不得低于本部门职工平均工资的 2
倍。本部门职工的平均工资值是一个统计计算值。
完整性约束条件（续）
?4,动态列级约束
– 动态列级约束是修改列定义或列值时应满足
的约束条件
完整性约束条件（续）
– 常见动态列级约束
1) 修改列定义时的约束
例：规定将原来允许空值的列改为不允许空值时，
如果该列目前已存在空值，则拒绝这种修改。
2) 修改列值时的约束
? 修改列值有时需要参照其旧值，并且新旧
值之间需要满足某种约束条件。
例：职工工资调整不得低于其原来工资，学生年
龄只能增长
完整性约束条件（续）
?5,动态元组约束
– 动态元组约束是指修改某个元组的值时需要
参照其旧值，并且新旧值之间需要满足某种
约束条件。
例, 职工工资调整不得低于其原来工资 +工龄 *1.5
完整性约束条件（续）
?6,动态关系约束
– 动态关系约束是加在关系变化前后状态上的
限制条件
例：事务一致性、原子性等约束条件
完整性约束条件（续）
?完整性约束条件小结
粒 度
状态
列 级 元 组 级 关 系 级
静 态 列定义
·类型
·格式
·值域
·空值
元组值应满足
的条件
实体完整性约束
参照完整性约束
函数依赖约束
统计约束
动 态 改变列定义或列值 元组新旧值之间应满足的约束条
件
关系新旧状态间
应满足的约束条
件
5.2 完整性
5.2.1 完整性约束条件
5.2.2 完整性控制
5.2.3 Oracle的完整性
5.2.2 完整性控制
一,DBMS的完整性控制机制
二、关系系统三类完整性的实现
三、参照完整性的实现
一,DBMS的完整性控制机制
?DBMS的完整性控制机制的主要功能
1,定义功能
2,检查功能
3,违约反应
DBMS的完整性控制机制（续）
?1,定义功能
– 一个完善的完整性控制机制应该允许用户定
义各类完整性约束条件。
DBMS的完整性控制机制（续）
?2,检查功能
– 立即执行的约束 (Immediate constraints)
? 检查是否违背完整性约束的时机通常是在
一条语句执行完后立即检查，我们称这类
约束为立即执行的约束
– 延迟执行的约束 (Deferred constrainsts)
? 在某些情况下，完整性检查需要延迟到整
个事务执行结束后再进行，我们称这类约
束为延迟执行的约束
DBMS的完整性控制机制（续）
例：银行数据库中“借贷总金额应平衡”的约束
就应该是延迟执行的约束
– 从账号 A转一笔钱到账号 B为一个事务，从
账号 A转出去钱后账就不平了，必须等转入
账号 B后账才能重新平衡，这时才能进行完
整性检查。
DBMS的完整性控制机制（续）
?3,违约反应
– 拒绝该操作
– 其他处理方法
DBMS的完整性控制机制（续）
?完整性规则的形式化表述
一条完整性规则可以用一个五元组表示,
(D,O,A,C,P)
– D（ Data） 约束作用的 数据对象 ；
– O（ Operation） 触发完整性检查的 数据库操作,
即当用户发出什么操作请求时需要检查该完整性规
则，是立即检查还是延迟检查；
– A（ Assertion） 数据对象必须满足的 断言 或 语义约
束,这是规则的主体；
– C（ Condition） 选择 A作用的数据对象值的 谓词 ；
– P（ Procedure） 违反完整性规则时触发的 过程 。
DBMS的完整性控制机制（续）
例 1：在,学号不能为空,的约束中
D 约束作用的对象为 Sno属性
O 插入或修改 Student 元组时
A Sno不能为空
C 无（ A可作用于所有记录的 Sno属性）
P 拒绝执行该操作
DBMS的完整性控制机制（续）
例 2：在,教授工资不得低于 1000元,的约束中
D 约束作用的对象为工资 Sal属性
O 插入或修改职工元组时
A Sal不能小于 1000
C 职称 =′教授 ′(A仅作用于职称 =‘教授’的记
录 )
P 拒绝执行该操作
二、关系系统三类完整性的实现
? 目前许多关系数据库系统都提供了定义和检查
实体完整性、参照完整性和用户定义的完整性
的功能。
? 对于违反实体完整性规则和用户定义的完整性
规则的操作一般都是采用拒绝执行的方式进行
处理。
? 而对于违反参照完整性的操作，并不都是简单
地拒绝执行，有时还需要采取另一种方法，即
接受这个操作，同时执行一些附加的操作，以
保证数据库的状态仍然是正确的。
三、参照完整性的实现
例,职工－部门数据库包含职工表 EMP和部门表 DEPT
– DEPT关系的主码为部门号 Deptno
– EMP关系的主码为职工号 Empno,外码为部门号 Deptno
– 该 Deptno与 DEPT关系中 Deptno相对应
– 称 DEPT为被参照关系或目标关系,EMP为参照关系
RDBMS实现参照完整性时需要考虑以下 4方面,
参照完整性的实现（续）
?1,外码是否可以接受空值的问题
– 外码是否能够取空值是依赖于应用环境的语
义的。
– 在实现参照完整性时，系统除了应该提供定
义外码的机制，还应提供定义外码列是否允
许空值的机制。
参照完整性的实现（续）
例 1：在职工－部门数据库中,EMP关系包含有
外码 Deptno，某一元组的这一列若为空值，表
示这个职工尚未分配到任何具体的部门工作。
这和应用环境的语义是相符的，因此 EMP的
Deptno列应允许空值。
参照完整性的实现（续）
例 2：在学生－选课数据库中,
Student关系为被参照关系，其主码为 Sno。
SC为参照关系，外码为 Sno。
若 SC的 Sno为空值，则表明尚不存在的某个学生，
或者某个不知学号的学生，选修了某门课程，
其成绩记录在 Grade列中。这与学校的应用环
境是不相符的，因此 SC的 Sno列不能取空值。
参照完整性的实现（续）
?2,删除被参照关系的元组时的问题
– 出现违约操作的情形
? 需要删除被参照关系的某个元组，而参照
关系有若干元组的外码值与被删除的被参
照关系的主码值相对应
参照完整性的实现（续）
? 2,在被参照关系中删除元组时的问题 (续 )
– 违约反应：可有三种策略
? 级联删除（ CASCADES）
? 受限删除（ RESTRICTED）
? 置空值删除（ NULLIFIES）
这三种处理方法，哪一种是正确的，要依应
用环境的语义来定。
参照完整性的实现（续）
– 级联删除
? 将参照关系中所有外码值与被参照关系中
要删除元组主码值相对应的元组一起删除。
– 受限删除
? 只有当参照关系中没有任何元组的外码值
与要删除的被参照关系的元组的主码值相
对应时，系统才执行删除操作，否则拒绝
此删除操作。
参照完整性的实现（续）
– 置空值删除
? 删除被参照关系的元组，并将参照关系中
所有与被参照关系中被删除元组主码值相
等的外码值置为空值。
参照完整性的实现（续）
例：要删除 Student关系中 Sno=950001的元组,
而 SC关系中有 4个元组的 Sno都等于 950001。
– 级联删除：将 SC关系中所有 4个 Sno=950001
的元组一起删除。如果参照关系同时又是另
一个关系的被参照关系，则这种删除操作会
继续级联下去。
– 受限删除：系统将拒绝执行此删除操作。
参照完整性的实现（续）
– 置空值删除：将 SC关系中所有 Sno=950001
的元组的 Sno值置为空值。
– 在学生选课数据库中，显然第一种方法和第
二种方法都是对的。第三种方法不符合应用
环境语义。
参照完整性的实现（续）
?3,修改被参照关系中主码的问题
– 两种策略
? (1)不允许修改主码
? (2)允许修改主码
参照完整性的实现（续）
– 允许修改主码策略
? 违约操作
?要 修改被参照关系 中某些元组的主码
值，而参照关系中有些元组的外码值
正好等于被参照关系要修改的主码值
?要 修改参照关系 中某些元组的主码值，
而被参照关系中没有任何元组的外码
值等于被参照关系修改后的主码值
参照完整性的实现（续）
– 允许修改主码策略 (续 )
? 违约反应 (1)
–修改的关系是被参照关系：与删除类
似
?级联修改
?受限修改
?置空值修改
参照完整性的实现（续）
– 级联修改
? 修改被参照关系中主码值同时，用相同的
方法修改参照关系中相应的外码值。
– 受限修改
? 拒绝此修改操作。只当参照关系中没有任
何元组的外码值等于被参照关系中某个元
组的主码值时，这个元组的主码值才能被
修改。
– 置空值修改
? 修改被参照关系中主码值，同时将参照关
系中相应的外码值置为空值。
参照完整性的实现（续）
例：学生 950001休学一年后复学，这时需要
将 Student关系中 Sno=950001的元组中 Sno值
改为 960123。而 SC关系中有 4个元组的
Sno=950001
– 级联修改：将 SC关系中 4个 Sno=950001元组
中的 Sno值也改为 960123。如果参照关系同
时又是另一个关系的被参照关系，则这种修
改操作会继续级联下去。
参照完整性的实现（续）
– 受限修改：只有 SC中没有任何元组的
Sno=950001时，才能修改 Student表中
Sno=950001的元组的 Sno值改为 960123。
– 置空值修改：将 Student表中 Sno=950001的
元组的 Sno值改为 960123。而将 S表中所有
Sno=950001的元组的 Sno值置为空值。
– 在学生选课数据库中只有第一种方法是正确
的。
参照完整性的实现（续）
– 允许修改主码策略 (续 )
? 违约反应 (2)
–修改的关系是参照关系：与插入类似
?受限修改
?递归修改
参照完整性的实现（续）
?结论
– RDBMS在实现参照完整性时，除了需要向
用户提供定义主码、外码的机制外，还需要
向用户提供按照自己的应用要求选择处理依
赖关系中对应的元组的方法。
5.2 完整性
5.2.1 完整性约束条件
5.2.2 完整性控制
5.2.3 Oracle的完整性
5.2.3 Oracle的完整性
一,Oracle中的实体完整性
二,Oracle中的参照完整性
三,Oracle中用户定义的完整性
一,ORACLE中的实体完整性
? ORACLE在 CREATE TABLE语句中提供了
PRIMARY KEY子句，供用户在建表时指定
关系的主码列。
– 在列级使用 PRIMARY KEY子句
– 在表级使用 PRIMARY KEY子句
ORACLE中的实体完整性（续）
例 1：在学生选课数据库中，要定义 Student表的 Sno属性
为主码
CREATE TABLE Student
(Sno NUMBER(8),
Sname VARCHAR(20),
Sage NUMBER(20),
CONSTRAINT PK_SNO PRIMARY KEY (Sno));
或,
CREATE TABLE Student
(Sno NUMBER(8) PRIMARY KEY,
Sname VARCHAR(20),
Sage NUMBER(20));
ORACLE中的实体完整性（续）
例 2：要在 SC表中定义 (Sno,Cno)为主码
CREATE TABLE SC
(Sno NUMBER(8),
Cno NUMBER(2),
Grade NUMBER(2),
CONSTRAINT PK_SC PRIMARY KEY (Sno,Cno));
ORACLE中的实体完整性（续）
? 在用 PRIMARY KEY语句定义了关系的主码后，
每当用户程序对主码列进行更新操作时，系统
自动进行完整性检查
– 违约操作
? 使主属性值为空值的操作
? 使主码值在表中不唯一的操作
– 违约反应
? 系统拒绝此操作，从而保证了实体完整性
二,ORACLE中的参照完整性
? ORACLE的 CREATE TABLE语句允许用户定
义参照完整性
– 用 FOREIGN KEY子句定义哪些列为外码列
– 用 REFERENCES子句指明这些外码相应于
哪个表的主码
– 用 ON DELETE CASCADE短语指明在删除
被参照关系的元组时，同时删除参照关系中
外码值等于被删除的被参照关系的元组中主
码值的元组
ORACLE中的参照完整性（续）
例 1：建立表 EMP表
CREATE TABLE EMP
(Empno NUMBER(4),
Ename VARCHAR(10),
Job VERCHAR2(9),
Mgr NUMBER(4),
Sal NUMBER(7,2),
Deptno NUMBER(2),
CONSTRAINT FK_DEPTNO
FOREIGN KEY (Deptno)
REFERENCES DEPT(Deptno)
ON DELETE CASCADE);
ORACLE中的参照完整性（续）
或,
CREATE TABLE EMP
(Empno NUMBER(4),
Ename VARCHAR(10),
Job VERCHAR2(9),
Mgr NUMBER(4),
Sal NUMBER(7,2),
Deptno NUMBER(2) CONSTRAINT FK_DEPTNO
FOREIGN KEY REFERENCES DEPT(Deptno)
ON DELETE CASCADE);
ORACLE中的参照完整性（续）
– 这时 EMP表中外码为 Deptno，它相应于
DEPT表中的主码 Deptno。
– 当要修改 DEPT表中的 DEPTNO值时，先要
检查 EMP表中有无元组的 Deptno值与之对
应
? 若没有，系统接受这个修改操作
? 否则，系统拒绝此操作
ORACLE中的参照完整性（续）
– 当要删除 DEPT表中某个元组时，系统要检
查 EMP表，若找到相应元组即将其随之删
除。
– 当要插入 EMP表中某个元组时，系统要检
查 DEPT表，先要检查 DEPT表中有无元组
的 Deptno值与之对应
? 若没有，系统拒绝此插入操作
? 否则，系统接受此操作
三,ORACLE中的用户定义的完整性
? ORACLE中定义用户完整性的两类方法
– 用 CREATE TABLE语句在建表时定义用户
完整性约束
– 通过触发器来定义用户的完整性规则
ORACLE中的用户定义的完整性（续）
? 1,用 CREATE TABLE语句在建表时定义用户
完整性约束
– 可定义三类完整性约束
? 列值非空（ NOT NULL短语）
? 列值唯一（ UNIQUE短语）
? 检查列值是否满足一个布尔表达式
（ CHECK短语）
ORACLE中的用户定义的完整性（续）
例 1：建立部门表 DEPT，要求部门名称 Dname列
取值唯一，部门编号 Deptno列为主码
CREATE TABLE DEPT
(Deptno NUMBER,
Dname VARCHAR(9) CONSTRAINT U1 UNIQUE,
Loc VARCHAR(10),
CONSTRAINT PK_DEPT PRIMARY KEY (Deptno));
其中 CONSTRAINT U1 UNIQUE 表示约束名为 U1,
该约束要求 Dname列值唯一。
ORACLE中的用户定义的完整性（续）
例 2,建立学生登记表 Student，要求学号在
900000至 999999之间，年龄 <29，性别
只能是‘男’或‘女’，姓名非空
CREATE TABLE Student
(Sno NUMBER(5)
CONSTRAINT C1 CHECK
(Sno BETWEEN 10000 AND 99999),
Sname VARCHAR(20) CONSTRAINT C2 NOT NULL,
Sage NUMBER(3) CONSTRAINT C3 CHECK (Sage < 29),
Ssex VARCHAR(2)
CONSTRAINT C4 CHECK (Ssex IN ('男 ','女 '));
ORACLE中的用户定义的完整性（续）
例 3,建立职工表 EMP，要求每个职工的应发工资不得超
过 3000元。 应发工资实际上就是实发工资列 Sal与扣
除项 Deduct之和。
CREATE TABLE EMP
(Eno NUMBER(4)
Ename VARCHAR(10),
Job VARCHAR(8),
Sal NUMBER(7,2),
Deduct NUMBER(7,2)
Deptno NUMBER(2),
CONSTRAINTS C1 CHECK (Sal + Deduct <=3000));
ORACLE中的用户定义的完整性（续）
? 2,通过触发器来定义用户的完整性规则
– 定义其它的完整性约束时，需要用数据库触发器
（ Trigger）来实现。
– 数据库触发器是一类靠事件驱动的特殊过程，一旦
由某个用户定义，任何用户对该数据的增、删、改
操作均由服务器自动激活相应的触发子，在核心层
进行集中的完整性控制。
– 定义数据库触发器的语句
CREATE [OR REPLACE] TRIGGER
ORACLE中的用户定义的完整性（续）
例 4,为教师表 Teacher定义完整性规则“教授的
工资不得低于 800元，如果低于 800元，自动改
为 800元”
ORACLE中的用户定义的完整性（续）
CREATE TRIGGER UPDATE_SAL
BEFORE INSERT OR UPDATE OF Sal,Pos ON Teacher
FOR EACH ROW
WHEN (:new.Pos='教授 ')
BEGIN
IF,new.sal<800 THEN
,new.Sal:=800;
END IF;
END;
第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.3 并发控制
?多事务执行方式 (1)
– 事务串行执行
? 每个时刻只有一个事务运行, 其他事务必
须等到这个事务结束以后方能运行
? 不能充分利用系统资源, 发挥数据库共享
资源的特点
并发控制（续）
?多事务执行方式 (2)
– 交叉并发方式 （ interleaved concurrency）
? 事务的并行执行是这些并行事务的并行操
作轮流交叉运行
? 是单处理机系统中的并发方式, 能够减少
处理机的空闲时间, 提高系统的效率
并发控制（续）
?多事务执行方式 (3)
– 同时并发方式 （ simultaneous concurrency）
? 多处理机系统中, 每个处理机可以运行一
个事务, 多个处理机可以同时运行多个事
务, 实现多个事务真正的并行运行
? 最理想的并发方式, 但受制于硬件环境
并发控制（续）
?事务并发执行带来的问题
– 对多用户并发存取同一数据的操作不加控制
可能会存取和存储不正确的数据, 破坏事务
的隔离性和数据库的一致性
– DBMS必须提供并发控制机制
– 并发控制机制是衡量一个 DBMS性能的重要
标志之一
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3.1 并发控制概述
?1,并发控制的单位 ——事务
?2,并发操作与数据的不一致性
一、事务
? 事务 (Transaction)是用户定义的一个数据库操
作序列，这些操作要么全做，要么全不做，是
一个不可分割的工作单位。
? 事务和程序是两个概念
– 在关系数据库中，一个事务可以是一条 SQL语句，
一组 SQL语句或整个程序
– 一个应用程序通常包含多个事务
? 事务是恢复和并发控制的基本单位
事务（续）
?定义事务的两种方式
– 显式方式
? 事务的开始由用户显式控制或 DBMS自动
隐含
? 事务结束由用户显式控制
– 隐式方式
? 当用户没有显式地定义事务时，由 DBMS
按缺省规定自动划分事务
事务（续）
?显式定义事务
– 1,事务开始
BEGIN TRANSACTION
事务（续）
?显式定义事务（续）
– 2,事务结束（ 1）
? COMMIT
–事务正常结束
–提交事务的所有操作
?使事务中所有对数据库的更新永久
生效（保存在物理数据库中）。
事务（续）
?显式定义事务（续）
– 2,事务结束（ 2）
? ROLLBACK
–事务异常终止
–回滚事务的所有操作
?在事务运行的过程中发生了某种故
障，事务不能继续执行
?系统将事务中对数据库的所有已完
成的更新操作全部撤消，滚回到事
务开始时的状态
事务（续）
事务的 ACID特性,
? 原子性（ Atomicity）
? 一致性（ Consistency）
? 隔离性（ Isolation）
? 持续性（ Durability ）
1,原子性
?事务是数据库的逻辑工作单位
– 事务中包括的诸操作要么都做，要么都不做
2,一致性
?事务执行的结果必须是使数据库从一个
一致性状态变到另一个一致性状态。
– 一致性状态,数据库中只包含成功事务提交
的结果
– 不一致状态,数据库中包含失败事务的结果
? 数据库系统运行中发生故障，有些事务尚
未完成就被迫中断，这些未完成事务对数
据库所做的修改有一部分已写入物理数据
库中
一致性（续）
?一致性与原子性是密切相关的。
例：银行转帐：从帐号 A中取出一万元，存入帐
号 B。
– 定义一个事务，该事务包括两个操作
? 第一个操作是从帐号 A中减去一万元
? 第二个操作是向 帐 号 B中加入一万元
– 这两个操作要么全做，要么全不做
? 全做或者全不做，数据库都处于一致性状态。
? 如果只做一个操作则用户逻辑上就会发生错误，
少了一万元，这时数据库就处于不一致性状态 。
3,隔离性
?一个事务的执行不能被其他事务干扰
– 一个事务内部的操作及使用的数据对其他并
发事务是隔离的，并发执行的各个事务之间
不能互相干扰。
4,持续性
?持续性也称永久性（ Permanence）
– 一个事务一旦提交，它对数据库中数据的改
变就应该是永久性的。
– 接下来的其他操作或故障不应该对其执行结
果有任何影响。
事务的特性 (续 )
? 保证事务 ACID特性是事务处理的重要任务。
? 破坏事务 ACID特性的因素
– 多个事务并行运行时，不同事务的操作交叉执行
? DBMS必须保证多个事务的交叉运行不影响这些
事务 ACID特性，特别是原子性和隔离性
– 事务在运行过程中被强行停止
? DBMS必须保证被强行终止的事务对数据库和其
他事务没有任何影响
这些就是 DBMS中恢复机制和并发控制机制的
责任。
二,并发操作与数据的不一致性
?什么是数据的不一致性
例：飞机订票系统中的一个活动序列,
1） 甲售票员读出某航班的机票余额 A,设 A=16
2） 乙售票员读出同一航班的机票余额 A,也为 16
3） 甲售票点卖出一张机票, 修改机票余额 A←A-1,
所以 A=15,把 A写回数据库
4） 乙售票点也卖出一张机票, 修改机票余额 A←A-1,
所以 A=15,把 A写回数据库
结果：卖出两张机票, 但数据库中机票余额只减少 1。
这种情况称为数据库的不一致性 。
并发控制概述（续）
– 产生原因
? 由甲乙两个售票员并发操作引起
? 在并发操作情况下, 对甲, 乙两个事务的
操作序列的调度是随机的
? 若按上面的调度序列执行, 甲事务的修改
就被丢失 。 因为第 4步中乙事务修改 A并
写回后覆盖了甲事务的修改
并发控制概述（续）
?并发操作带来的数据不一致性
– 丢失修改 （ lost update）
– 不可重复读 （ non-repeatable read）
– 读, 脏, 数据 （ dirty read）
1,丢失修改
? 事务 1与事务 2从数据库中读入同一数据并修改
? 事务 2的提交结果破坏了事务 1提交的结果
? 导致事务 1的修改被丢失 。
图 三种数据不一致性
T1 T2
① 读 A=16
②
③ A←A-1
写回 A=15
④
读 A=16
A←A-1
写回 A=15
(a) 丢失修改
2,不可重复读
?事务 1读取数据
?之后, 事务 2执行更新操作
?从而使事务 1无法再现前一次读取结果 。
图 三种数据不一致性 (续 )
读 B=100
B←B*2
写回 B=200
① 读 A=50
读 B=100
求和 =150
②
③ 读 A=50
读 B=200
求和 =250
(验算不对 )
T2 T1
(b) 不可重复读
不可重复读（续）
?三类不可重复读
– 1,读 -更新
? 事务 1读取某一数据
? 事务 2对其做了修改
? 当事务 1再次读该数据时, 得到与前一次
不同的值 。
不可重复读（续）
?三类不可重复读
– 2,读 -删除
? 事务 1按一定条件从数据库中读取某些数
据记录
? 事务 2删除了其中部分记录
? 当事务 1再次按相同条件读取数据时, 发
现某些记录神密地消失了 。
不可重复读（续）
? 三类不可重复读 (续 )
– 3,读 -插入
? 事务 1按一定条件从数据库中读取某些数
据记录
? 事务 2插入了一些记录
? 当事务 1再次按相同条件读取数据时, 发
现多了一些记录 。
后两种不可重复读有时也称为幻行现象
3,读“脏”数据
? 事务 1修改某一数据, 并将其写回磁盘
? 事务 2读取同一数据
? 之后, 事务 1由于某种原因被撤消, 这时事务 1
已修改过的数据恢复原值
? 事务 2读到的数据就与数据库中的数据不一致,
是不正确的数据, 又称为, 脏, 数据 。
图 三种数据不一致性 (续 )
读 C=200
① 读 C=100
C←C*2
写回 C
②
③ ROLLBACK
C恢复为 100
T2 T1
(c) 读“脏”数据
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3.2 并发操作的调度
? 计算机系统对并行事务中并行操作的调度是的
随机的，而不同的调度可能会产生不同的结果。
? 将所有事务串行起来的调度策略一定是正确的
调度策略。
– 如果一个事务运行过程中没有其他事务在同
时运行，也就是说它没有受到其他事务的干
扰，那么就可以认为该事务的运行结果是正
常的或者预想的
并发操作的调度（续）
? 以不同的顺序串行执行事务也有可能会产生不
同的结果，但由于不会将数据库置于不一致状
态，所以都可以认为是正确的。
? 几个事务的并行执行是正确的,当且仅当其结
果与按某一次序串行地执行它们时的结果相同。
这种并行调度策略称为可串行化（ Serializable）
的调度。
并发操作的调度（续）
?可串行性是并行事务正确性的唯一准则
例：现在有两个事务，分别包含下列操作,
事务 1：读 B； A=B+1；写回 A；
事务 2：读 A； B=A+1；写回 B；
假设 A的初值为 2,B的初值为 2。
并发操作的调度（续）
– 对这两个事务的不同调度策略
? 串行执行
–串行调度策略 1
–串行调度策略 2
? 交错执行
– 不可串行化的调度
– 可串行化的调度
(a) 串行调度策略，正确的调度
读 B＝ 2
A B＋ 1
写回 A＝ 3
读 A＝ 3
B A＋ 1
写回 B＝ 4
T1 T2
(b) 串行调度策略，正确的调度
读 B＝ 11
A B＋ 1
写回 A＝ 12
读 A＝ 10
B A＋ 1
写回 B＝ 11
T1 T2
(c) 不可串行化的调度
读 B＝ 2
A B＋ 1
写回 A＝ 3
读 A＝ 10
B A＋ 1
写回 B＝ 11
T1 T2
(c) 不可串行化的调度 (续 )
– 由于其执行结果与 (a),(b)的结果都不同，
所以是错误的调度。
(d) 可串行化的调度
读 B＝ 2
A B＋ 1
写回 A＝ 3
等待
等待
等待
读 A＝ 3
B A＋ 1
写回 B＝ 4
T1 T2
(d) 可串行化的调度（续）
? 由于其执行结果与串行调度（ a）的执行
结果相同，所以是正确的调度。
并发操作的调度（续）
? 为了保证并行操作的正确性,DBMS的并行控
制机制必须提供一定的手段来保证调度是可串
行化的。
? 从理论上讲，在某一事务执行时禁止其他事务
执行的调度策略一定是可串行化的调度，这也
是最简单的调度策略，但这种方法实际上是不
可行的，因为它使用户不能充分共享数据库资
源。
并发操作的调度（续）
?保证并发操作调度正确性的方法
– 封锁方法,两段锁 （ Two-Phase Locking，
简称 2PL） 协议
– 时标方法
– 乐观方法
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3.3 封锁
? 封锁就是事务 T在对某个数据对象（例如表、
记录等）操作之前，先向系统发出请求，对其
加锁。加锁后事务 T就对该数据对象有了一定
的控制，在事务 T释放它的锁之前，其它的事
务不能更新此数据对象。
? 封锁是实现并发控制的一个非常重要的技术
5.5.3 封锁
?5.3.3.1 封锁类型
?5.3.3.2 封锁粒度
?5.3.3.3 封锁协议
5.5.3 封锁
?5.3.3.1 封锁类型
?5.3.3.2 封锁粒度
?5.3.3.3 封锁协议
5.3.3.1 封锁类型
? DBMS通常提供了多种类型的封锁。一个事务
对某个数据对象加锁后究竟拥有什么样的控制
是由封锁的类型决定的。
? 基本封锁类型
– 排它锁（ eXclusive lock，简记为 X锁）
– 共享锁（ Share lock，简记为 S锁）
封锁类型（续）
? 排它锁
– 排它锁又称为写锁。
– 若事务 T对数据对象 A加上 X锁，则只允许 T
读取和修改 A，其它任何事务都不能再对 A
加任何类型的锁，直到 T释放 A上的锁。
封锁类型（续）
? 共享锁
– 共享锁又称为读锁。
– 若事务 T对数据对象 A加上 S锁，则其它事务
只能再对 A加 S锁，而不能加 X锁，直到 T释
放 A上的 S锁。
封锁类型（续）
Y=Yes，相容的请求
N=No，不相容的请求
T1
T2
X S -
X N N Y
S N Y Y
- Y Y Y
5.5.3 封锁
?5.3.3.1 封锁类型
?5.3.3.2 封锁粒度
?5.3.3.3 封锁协议
5.3.3.2 封锁粒度
? X锁和 S锁都是加在某一个数据对象上的。
? 封锁的对象可以是逻辑单元，也可以是物理单
元。
例：在关系数据库中，封锁对象可以是,
– 逻辑单元, 属性值、属性值集合、元组、关
系、索引项、整个索引、整个数据库等
– 物理单元：页（数据页或索引页）、块等
封锁粒度（续）
? 封锁对象可以很大也可以很小
例,对整个数据库加锁
对某个属性值加锁
? 封锁对象的大小称为封锁的粒度 (Granularity)
封锁粒度（续）
? 封锁粒度与系统的并发度和并发控制的开销密
切相关。
– 封锁的粒度越大，系统中能够被封锁的对象
就越少，并发度也就越小，但同时系统开销
也越小；
– 封锁的粒度越小，并发度越高，但系统开销
也就越大。
? 选择封锁粒度时必须同时考虑封锁机构和并发
度两个因素，对系统开销与并发度进行权衡，
以求得最优的效果。
封锁粒度（续）
?一般原则
– 需要处理大量元组的用户事务：以关系为封
锁单元；
– 需要处理多个关系的大量元组的用户事务：
以数据库为封锁单位；
– 只处理少量元组的用户事务：以元组为封锁
单位
5.5.3 封锁
?5.3.3.1 封锁类型
?5.3.3.2 封锁粒度
?5.3.3.3 封锁协议
5.3.3.3 封锁协议
?什么是封锁协议
– 在运用 X锁和 S锁对数据对象加锁时，需要约定一些
规则，这些规则为封锁协议（ Locking Protocol）。
? 何时申请 X锁或 S锁
? 持锁时间
? 何时释放
– 对封锁方式规定不同的规则，就形成了各种不同的
封锁协议，它们分别在不同的程度上为并发操作的
正确调度提供一定的保证。
封锁协议 （续）
?一、保证数据一致性的封锁协议
?二、保证并行调度可串行性的封锁协
议 ——两段锁协议
一、保证数据一致性的封锁协
议 ——三级封锁协议
三级封锁协议
– 1级封锁协议
– 2级封锁协议
– 3级封锁协议
1级封锁协议
? 1级封锁协议
– 事务 T在修改数据 R之前必须先对其加 X锁，
直到事务结束才释放。
? 正常结束 （ COMMIT）
? 非正常结束 （ ROLLBACK）
? 1级封锁协议可防止丢失修改，并保证事务 T是
可恢复的。
? 在 1级封锁协议中，如果仅仅是读数据不对其
进行修改，是不需要加锁的，所以它不能保证
可重复读和不读“脏”数据。
图 用封锁机制解决三种数据不一致性示例
T1 T2
① Xlock A
获得
② 读 A=16
③ A←A-1
写回 A=15
Commit
Unlock A
④
⑤
Xlock A
等待
等待
等待
等待
获得 Xlock A
读 A=15
A←A-1
写回 A=14
Commit
Unlock A
(a) 没有丢失修改
图 用封锁机制解决三种数据不一致性示例
读 A=15
① Xlock A
获得
② 读 A=16
A←A-1
写回 A=15
③
④ Rollback
Unlock A
T2 T1
(a.1) 读“脏”数据
图 用封锁机制解决三种数据不一致性示例
Xlock B
获得
读 B=100
B←B*2
写回 B=200
Commit
Unlock B
① 读 A=50
读 B=100
求和 =150
②
③ 读 A=50
读 B=200
求和 =250
(验算不对 )
T2 T1
(a.2) 不可重复读
2级封锁协议
? 2级封锁协议
– 1级封锁协议加上事务 T在读取数据 R之前必
须先对其加 S锁，读完后即可释放 S锁。
? 2级封锁协议可以防止丢失修改和读“脏”数
据。
? 在 2级封锁协议中，由于读完数据后即可释放 S
锁，所以它不能保证可重复读。
图 用封锁机制解决三种数据不一致性示例
T1 T2
① Xlock C
读 C= 100
C←C*2
写回 C=200
②
③ ROLLBACK
(C恢复为 100)
Unlock C
④
⑤
Slock C
等待
等待
等待
等待
获得 Slock C
读 C=100
Commit C
Unlock C
(c) 不读“脏”数据
图 用封锁机制解决三种数据不一致性示例
(c.1) 不可重复读
① Sclock A
获得
读 A=50
Unlock A
② Sclock B
获得
读 B=100
Unlock B
③ 求和 =150
Xlock B
等待
等待
获得 Xlock B
读 B=100
B←B*2
写回 B=200
Commit
Unlock B
T2 T1
④ Sclock A
获得
读 A=50
Unlock A
Sclock B
获得
读 B=200
Unlock B
求和 =250
(验算不对 )
T2 T1 (续 )
3级封锁协议
? 3级封锁协议
– 1级封锁协议加上事务 T在读取数据 R之前必
须先对其加 S锁，直到事务结束才释放。
? 3级封锁协议可防止丢失修改、读脏数据和不
可重复读。
图 用封锁机制解决三种数据不一致性示例
T1 T2
① Slock A
读 A=50
Slock B
读 B=100
求和 =150
②
③ 读 A=50
读 B=100
求和 =150
Commit
Unlock A
Unlock B
④
⑤
Xlock B
等待
等待
等待
等待
等待
等待
等待
等待
获得 Xlock B
读 B=100
B←B*2
写回 B=200
Commit
Unlock B
(b) 可重复读
三级封锁协议
?三级协议的主要区别
– 什么操作需要申请封锁以及何时释放锁（即
持锁时间）
三级封锁协议 (续 )
二、两段锁协议
? 可串行性是并行调度正确性的唯一准则，两段
锁（ 2PL）协议就是为保证并行调度可串行性
而提供的封锁协议。
? 两段锁协议的内容
1,在对任何数据进行读、写操作之前，事务
首先要获得对该数据的封锁
2,在释放一个封锁之后，事务不再获得任何
其他封锁。
两段锁协议（续）
?“两段”锁的含义
– 事务分为两个阶段
? 第一阶段是获得封锁，也称为扩展阶段；
? 第二阶段是释放封锁，也称为收缩阶段。
两段锁协议（续）
例,
事务 1的封锁序列,
Slock A,.,Slock B,.,Xlock C,.,Unlock B,.,Unlock A,.,
Unlock C；
事务 2的封锁序列,
Slock A,.,Unlock A,.,Slock B,.,Xlock C,.,Unlock C,.,
Unlock B；
事务 1遵守两段锁协议，而事务 2不遵守两段协议。
两段锁协议（续）
? 并行执行的所有事务均遵守两段锁协议，则对
这些事务的所有并行调度策略都是可串行化的。
所有遵守两段锁协议的事务，其并行执行的结
果一定是正确的。
? 事务遵守两段锁协议是可串行化调度的 充分条
件,而不是必要条件。即可串行化的调度中，
不一定所有事务都必须符合两段锁协议。
5.3 并发控制
5.3.1 并发控制概述
5.3.2 并发操作的调度
5.3.3 封锁
5.3.4 死锁和活锁
5.3.5 Oracle的并发控制
5.3.4 死锁和活锁
?封锁技术可以有效地解决并行操作的一
致性问题，但也带来一些新的问题
– 死锁
– 活锁
一,活锁
什么是活锁
活锁 (续 )
如何避免活锁
?采用先来先服务的策略
– 当多个事务请求封锁同一数据对象时, 封
锁子系统按请求封锁的先后次序对这些事务
排队
– 该数据对象上的锁一旦释放, 首先批准申
请队列中第一个事务获得锁 。
二,死锁
什么是死锁
T1 T2
Xlock R1
,
,
,
Xlock R2
等待
等待
等待
,
,
,
Xlock R2
,
,
Xlock R1
等待
等待
,
死锁 （续）
如何解决死锁
?解决死锁的两类方法
1,死锁的预防
2,死锁的诊断与解除
1,死锁的预防
?预防死锁为何能解决死锁
– 产生死锁的原因是两个或多个事务都已封锁
了一些数据对象，然后又都请求对已为其他
事务封锁的数据对象加锁，从而出现死等待。
– 预防死锁的发生就是要破坏产生死锁的条件。
死锁的预防 （续）
?预防死锁的方法
– 一次封锁法
– 顺序封锁法
（ 1）一次封锁法
? 一次封锁法要求每个事务必须一次将所有要使
用的数据全部加锁，否则就不能继续执行。
? 一次封锁法存在的问题：降低并发度
– 扩大封锁范围
? 一次就将以后要用到的全部数据加锁，势
必扩大了封锁的范围，从而降低了系统的
并发度。
一次封锁法（续）
– 难于事先精确确定封锁对象
? 数据库中数据是不断变化的，原来不要求
封锁的数据，在执行过程中可能会变成封
锁对象，所以很难事先精确地确定每个事
务所要封锁的数据对象
? 解决方法：将事务在执行过程中可能要封
锁的数据对象全部加锁，这就进一步降低
了并发度 。
（ 2）顺序封锁法
? 顺序封锁法是预先对数据对象规定一个封锁顺
序，所有事务都按这个顺序实行封锁。
? 顺序封锁法存在的问题
– 维护成本高
? 数据库系统中可封锁的数据对象极其众多，
并且随数据的插入、删除等操作而不断地
变化，要维护这样极多而且变化的资源的
封锁顺序非常困难，成本很高。
顺序封锁法（续）
– 难于实现
? 事务的封锁请求可以随着事务的执行而动
态地决定，很难事先确定每一个事务要封
锁哪些对象，因此也就很难按规定的顺序
去施加封锁。
例：规定数据对象的封锁顺序为 A,B,C,D,E。
事务 T3起初要求封锁数据对象 B,C,E，但当
它封锁了 B,C后，才发现还需要封锁 A，这
样就破坏了封锁顺序,
死锁的预防（续）
?结论
– 在操作系统中广为采用的预防死锁的策略并
不很适合数据库的特点
– DBMS在解决死锁的问题上更普遍采用的是
诊断并解除死锁的方法
2,死锁的诊断与解除
?方法
– 由 DBMS的并发控制子系统定期检测系统中
是否存在死锁，一旦检测到死锁，就要设法
解除。
死锁的诊断与解除（续）
? 检测死锁
– 超时法
? 如果一个事务的等待时间超过了规定的时
限，就认为发生了死锁。
? 优点
–实现简单
? 缺点
–有可能误判死锁
–时限若设置得太长，死锁发生后不能
及时发现
死锁的诊断与解除（续）
– 等待图法
? 用事务等待图动态反映所有事务的等待情况
– 事务等待图是一个有向图 G=(T,U)
– T为结点的集合，每个结点表示正运行的事务
– U为边的集合，每条边表示事务等待的情况
– 若 T1等待 T2，则 T1,T2之间划一条有向边，从 T1
指向 T2
? 并发控制子系统周期性地（比如每隔 1 min）
检测事务等待图，如果发现图中存在回路，
则表示系统中出现了死锁。
死锁的诊断与解除（续）
?解除死锁
– 选择一个处理死锁代价最小的事务，
将其撤消，释放此事务持有的所有的
锁，使其它事务能继续运行下去。
第 5章 数据库安全
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.4 恢复
? 故障是不可避免的
– 计算机硬件故障
– 系统软件和应用软件的错误
– 操作员的失误
– 恶意的破坏
? 故障的影响
– 轻则造成运行事务非正常中断，影响数据库中数据
的正确性
– 重则破坏数据库，使数据库中数据部分或全部丢失。
例，银行转帐。
恢复（续）
? 数据库管理系统对故障的对策
– DBMS提供了恢复子系统，用来保证各种故
障发生后，能把数据库中的数据从错误状态
恢复到某种逻辑一致的状态。即保证各个事
务中的操作要么全部完成，要么全部不做。
? 数据库系统所采用的恢复技术是否行之有效是
衡量系统性能优劣的重要指标。
5.4 恢复
5.4.1 恢复的原理
5.4.2 恢复的实现技术
5.4.3 ORACLE的恢复技术
5.4 恢复
5.4.1 恢复的原理
5.4.2 恢复的实现技术
5.4.3 ORACLE的恢复技术
5.4.1 恢复的原理
?事务故障
?系统故障
?介质故障
一、事务故障
?什么是事务故障
– 某个事务在运行过程中由于种种原因未运行
至正常终止点就夭折了
?事务故障的常见原因
– 输入数据有误
– 运算溢出
– 违反了某些完整性限制
– 某些应用程序出错
– 并行事务发生死锁
事务故障（续）
?事务故障的恢复
– 发生事务故障时，夭折的事务可能已把对数
据库的部分修改写回磁盘。
– 事务故障的恢复,事务撤消（ UNDO）
? 恢复程序要在不影响其它事务运行的情况
下，强行回滚（ ROLLBACK）该事务，
即清除该事务对数据库的所有修改，使得
这个事务象根本没有启动过一样
二、系统故障
?什么是系统故障
– 由于某种原因造成整个系统的正常运行突然
停止，致使所有正在运行的事务都以非正常
方式终止。
– 发生系统故障时，内存中数据库缓冲区的信
息全部丢失，但存储在外部存储设备上的数
据未受影响
系统故障（续）
?系统故障的常见原因
– 操作系统或 DBMS代码错误
– 操作员操作失误
– 特定类型的硬件错误（如 CPU故障）
– 突然停电
系统故障（续）
?系统故障的恢复
– 1,清除尚未完成的事务对数据库的所有修改
? 如果 DBMS无法确定哪些事务已更新过数据库，
则系统重新启动后，恢复程序要强行撤消
（ UNDO）所有未完成事务，使这些事务象没有
运行过一样。
– 2,将缓冲区中已完成事务提交的结果写入数据库
? 如果 DBMS无法确定哪些事务的提交结果尚未写
入物理数据库，则系统重新启动后，恢复程序需
要重做（ REDO）所有已提交的事务。
三、介质故障
?什么是介质故障
– 硬件故障使存储在外存中的数据部分丢失或
全部丢失
– 介质故障比前两类故障的可能性小得多，但
破坏性最大。
介质故障 (续 )
?介质故障的常见原因
– 硬件故障
? 磁盘损坏
? 磁头碰撞
– 操作系统的某种潜在错误
– 瞬时强磁场干扰
介质故障（续）
?介质故障的恢复
– 装入 数据库发生介质故障前某个时刻的数据
副本
– 重做自此时始的所有 成功事务,将这些事务
已提交的结果重新记入数据库
故障的种类小结
?数据库系统中各类故障对数据库的影响
– 数据库本身被破坏 （介质故障）
– 数据库处于不一致状态
? 数据库中包含了未完成事务对数据库的修
改（事务故障、系统故障）
? 数据库中丢失了已提交事务对数据库的修
改（系统故障）
?不同类型的故障应采用不同的恢复操作
故障的种类小结（续）
?恢复操作的基本原理：简单
– 任何恢复操作的原理都是一样的
– 原理,利用 存储在系统其它地方的 冗余数据
来 重建 数据库中已经被破坏或已经不正确的
那部分数据
?恢复的实现技术：复杂
– 一般一个大型数据库产品，恢复子系统的代
码要占全部代码的 10%以上
5.4 恢复
5.4.1 恢复的原理
5.4.2 恢复的实现技术
5.4.3 ORACLE的恢复技术
5.4.2 恢复的实现技术
? 恢复技术的原理
– 利用存储在系统其它地方的冗余数据来修复或重建
数据库中被破坏的或不正确的数据。
? 恢复机制涉及的关键问题
1,如何建立冗余数据
? 数据转储
? 登记日志文件
2,如何利用这些冗余数据实施数据库恢复
5.4.2 恢复的实现技术
5.4.2.1 数据转储
5.4.2.2 登记日志文件
5.4.2.3 恢复策略
5.4.2 恢复的实现技术
5.4.2.1 数据转储
5.4.2.2 登记日志文件
5.4.2.3 恢复策略
5.4.2.1 数据转储
一、什么是转储
二、转储的用途
三、转储方法
一、什么是转储
? 转储是指 DBA将整个数据库复制到磁带或另一
个磁盘上保存起来的过程。
? 这些备用的数据文本称为 后备副本 或 后援副本 。
二、转储的用途
? 用途：供介质故障恢复时使用
– 一旦系统发生介质故障，数据库遭到破坏，
可以将后备副本重新装入，把数据库恢复起
来。
? 恢复的程度
– 重装后备副本只能将 DB恢复到转储时的状
态
– 要想恢复到故障发生时的状态，必须重新运
行自转储以后的所有更新事务
转储的用途（续）
例,
故障发生点
转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本 重新运行事务
恢复 ────────┴ －－－－－－－－－－－ － →
三、转储方法
1．静态转储与动态转储
2．海量转储与增量转储
3．转储方法小结
1．静态转储与动态转储
?静态转储
– 静态转储是在系统中无运行事务时进行的转
储操作
? 转储操作开始的时刻，数据库处于一致性
状态
? 转储期间不允许（或不存在）对数据库的
任何存取、修改活动
– 静态转储得到的一定是一个数据一致性的副
本
静态转储与动态转储（续）
– 静态转储的优点
? 实现简单
– 静态转储的缺点
? 降低了数据库的可用性
–转储必须等待用户事务结束才能进行
–新的事务必须等待转储结束才能执行
静态转储与动态转储（续）
– 利用静态转储得到的副本进行故障恢复
? 只需要把静态转储得到的后备副本装入，
就能把数据库恢复到转储时刻的正确状态
利用静态转储副本进行恢复
故障发生点
静态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本
恢复 ━━━━━━┥
静态转储与动态转储（续）
? 动态转储
– 动态转储是指转储操作与用户事务并发进行，
转储期间允许对数据库进行存取或修改。
– 动态转储的优点
? 不用等待正在运行的用户事务结束
? 不会影响新事务的运行
– 动态转储的缺点
? 不能保证副本中的数据正确有效
静态转储与动态转储（续）
– 利用动态转储得到的副本进行故障恢复
? 需要把动态转储期间各事务对数据库的修
改活动登记下来，建立日志文件
? 后备副本加上日志文件才能把数据库恢复
到某一时刻的正确状态
利用动态转储副本进行恢复
Ta Tb Tf
动态 转储 运行事务 故障发生点
正常运行 ─┼───────┼─────────────
登记日志文件 登记新日志文件
─────────┼─────────────
?
转储日志文件
重装后备副本, 然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态
2．海量转储与增量转储
? 海量转储
– 每次转储全部数据库
? 增量转储
– 只转储上次转储后更新过的数据
? 海量转储与增量转储比较
– 从恢复角度看，使用海量转储得到的后备副
本进行恢复往往更方便
– 但如果数据库很大，事务处理又十分频繁，
则增量转储方式更实用更有效
3．转储方法小结
?转储方法分类
转储状态
动态转储 静态转储
转储
方式
海量转储
动态海量转储 静态海量转储
增量转储 动态增量转储 静态增量转储
转储方法小结（续）
?转储策略
– 从恢复方便角度看，应经常进行数据转储，制作后
备副本。
– 但转储又是十分耗费时间和资源的，不能频繁进行。
– DBA应该根据数据库使用情况确定适当的转储周期
和转储方法。
例,
? 每天晚上进行动态增量转储
? 每周进行一次动态海量转储
? 每月进行一次静态海量转储
5.4.2 恢复的实现技术
5.4.2.1 数据转储
5.4.2.2 登记日志文件
5.4.2.3 恢复策略
5.4.2.2 登记日志文件
一、日志文件的内容
二、日志文件的用途
三、登记日志文件的原则
一、日志文件的内容
?1,什么是日志文件
– 日志文件 (log)是用来记录事务对数据库的更
新操作的文件。
?2,日志文件的格式
– 以记录为单位的日志文件
– 以数据块为单位的日志文件
日志文件的内容（续）
?3,日志文件内容
– 各个事务的开始标记 (BEGIN TRANSACTION)
– 各个事务的结束标记 (COMMIT或 ROLLBACK)
– 各个事务的所有更新操作
– 每个事务开始的标记、每个事务的结束标记和每个
更新操作均作为日志文件中的一个日志记录 (log
record)
日志文件的内容（续）
?4,基于记录的日志文件
– 每条日志记录的内容
? 事务标识（标明是那个事务）
? 操作类型（插入、删除或修改）
? 操作对象
? 更新前数据的旧值（对插入操作而言，此
项为空值）
? 更新后数据的新值（对删除操作而言,此
项为空值）
日志文件的内容（续）
?5,基于数据块的日志文件
– 每条日志记录的内容
? 事务标识（标明是那个事务）
? 更新前数据所在的整个数据块的值（对插
入操作而言，此项为空值）
? 更新后整个数据块的值（对删除操作而言,
此项为空值）
二、日志文件的用途
? 1．用途
– 进行事务故障恢复
– 进行系统故障恢复
– 协助后备副本进行介质故障恢复
日志文件的用途（续）
? 2．与静态转储后备副本配合进行介质故障恢
复
– 静态转储的数据已是一致性的数据
– 如果静态转储完成后，仍能定期转储日志文
件，则在出现介质故障重装数据副本后，可
以利用这些日志文件副本对已完成的事务进
行重做处理
– 这样不必重新运行那些已完成的事务程序就
可把数据库恢复到故障前某一时刻的正确状
态
日志文件的用途（续）
故障发生点
静态转储 运行事务 ↓
正常运行 ─┼──────┼─────────────
Ta Tb Tf
登记日志文件
└─────────────
重装后备副本 利用日志文件恢复事务 继续运行
介质故障恢复 ───────┴ －－－－－－－－－－ ┴───────→
登记日志文件
└─────── →
日志文件的用途（续）
? 3．与动态转储后备副本配合使用进行介质故
障恢复
– 动态转储机制在转储数据库时，必须同时转
储同一时间点的日志文件，后备副本与该日
志文件结合起来才能将数据库恢复到一致性
状态。
– 与静态转储一样，如果动态转储完成后，仍
能定期转储日志文件，则在做介质故障恢复
时，可以利用这些日志文件副本进一步恢复
数据库，避免重新运行事务程序。
三、登记日志文件的原则
? 为保证数据库是可恢复的，登记日志文件时必
须遵循两条原则
– 登记的次序严格按并行事务执行的时间次序
– 必须先写日志文件，后写数据库
? 写数据库操作：把对数据的修改写到数据库中
? 写日志文件操作：把表示这个修改的日志记录写
到日志文件
登记日志文件的原则（续）
? 为什么要先写日志文件
– 写数据库和写日志文件是两个不同的操作
– 有可能在这两个操作之间发生故障，即这两个写操
作只完成了一个
– 如果先写了数据库修改，而在日志文件中没有登记
下这个修改，则以后就无法恢复这个修改了
– 如果先写日志，但没有修改数据库，按日志文件恢
复时只不过是多执行一次不必要的 UNDO操作，并
不会影响数据库的正确性
5.4.2 恢复的实现技术
5.4.2.1 数据转储
5.4.2.2 登记日志文件
5.4.2.3 恢复策略
5.4.2.3 恢复策略
?1,事务故障的恢复
?2,系统故障的恢复
?3,介质故障的恢复
1,事务故障的恢复
? 事务故障是指事务在运行至正常终止点前被中
止
? 恢复方法
– 由恢复子系统应利用日志文件撤消（ UNDO）
此事务已对数据库进行的修改
? 事务故障的恢复由系统自动完成，不需要用户
干预
事务故障的恢复（续）
?恢复步骤
1,反向扫描文件日志（即从最后向前扫描日
志文件），查找该事务的更新操作。
2,对该事务的更新操作执行逆操作。即将日
志记录中“更新前的值”写入数据库。
– 如果记录中是插入操作，则相当于做删除操作（因
为此时“更新前的值”为空）
– 若记录中是删除操作，则相当于做插入操作（因为
此时“更新后的值”为空）
– 若是修改操作，则相当于用修改前值代替修改后值
事务故障的恢复（续）
– 3,继续反向扫描日志文件，查找该事务的其
他更新操作，并做同样处理。
– 4,如此处理下去，直至读到此事务的开始标
记，事务故障恢复就完成了。
2,系统故障的恢复
? 系统故障造成数据库不一致状态的原因
– 一些未完成事务对数据库的更新已写入数据库
– 一些已提交事务对数据库的更新还留在缓冲区
没来得及写入数据库
? 恢复方法
– 1,撤消故障发生时未完成的事务
– 2,重做已完成的事务
? 系统故障的恢复由系统在重新启动时自动完成，
不需要用户干预
系统故障的恢复（续）
?恢复步骤
1,正向扫描日志文件（即从头扫描日志文件）
– 找出在故障发生前已经提交的事务,将事务
标识记入重做队列
– 同时找出故障发生时尚未完成的事务,将事
务标识记入撤消队列
系统故障的恢复（续）
2,对撤消队列中的各个事务进行撤消 (UNDO)
处理
– 反向扫描日志文件，对每个 UNDO事务的更
新操作执行逆操作，即将日志记录中“更新
前的值”写入数据库
3,对重做队列中的各个事务进行重做 (REDO)
处理
– 正向扫描日志文件，对每个 REDO事务重新
执行登记的操作。即将日志记录中“更新后
的值”写入数据库
3,介质故障的恢复
? 发生介质故障后，磁盘上的物理数据和日志文
件被破坏，这是最严重的一种故障
? 恢复方法
– 1,重装数据库，使数据库恢复到一致性状态
– 2,重做已完成的事务
介质故障的恢复（续）
?恢复步骤
1,装入最新的后备数据库副本，使数据库恢复到
最近一次转储时的一致性状态。
– 对于静态转储的数据库副本，装入后数据库
即处于一致性状态
– 对于动态转储的数据库副本，还须同时装入
转储时刻的日志文件副本，利用与恢复系统
故障相同的方法（即 REDO+UNDO），才
能将数据库恢复到一致性状态。
利用静态转储副本将数据库恢复到一致性状态
故障发生点
静态 转储 运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
登记日志文件
└─────────────
重装后备副本
恢复 ━━━━━━┥
利用动态转储副本将数据库恢复到一致性状态
Ta Tb Tf
动态 转储 运行事务 故障发生点
正常运行 ─┼───────┼─────────────
登记日志文件 登记新日志文件
─────────┼─────────────
?
转储日志文件
重装后备副本, 然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态
介质故障的恢复（续）
2,装入有关的日志文件副本，重做已完成的事务。
– 首先扫描日志文件，找出故障发生时已提交
的事务的标识，将其记入重做队列。
– 然后正向扫描日志文件，对重做队列中的所
有事务进行重做处理。即将日志记录中“更
新后的值”写入数据库。
介质故障的恢复（续）
?介质故障的恢复需要 DBA介入
– DBA的工作
? 重装最近转储的数据库副本和有关的各日
志文件副本
? 执行系统提供的恢复命令
– 具体的恢复操作仍由 DBMS完成
5.4 恢复
5.4.1 恢复的原理
5.4.2 恢复的实现技术
5.4.3 ORACLE的恢复技术
5.4.3 Oracle的恢复技术
?ORACLE恢复机制
– 1,转储
– 2,登记日志文件
Oracle的恢复技术（续）
?1,转储
– 转储后备副本的方法
? 文件拷贝
? EXPORT实用程序
? 用 SQL命令 SPOOL
? 自己编程实现
Oracle的恢复技术（续）
– 重装后备副本的方法
? 文件拷贝
? IMPORT实用程序
? SQL*LOADER实用程序
? 自己编程实现
Oracle的恢复技术（续）
?2,登记日志文件
– ORACLE V.5：以数据块为单位
– ORACLE V.7,REDO日志 + 回滚段
Oracle的恢复技术（续）
?ORACLE V.5的恢复技术
– 日志文件以数据块为单位，恢复操作不是基
于操作，而是基于数据块
– 将更新前的旧值与更新后的新值分别放在两
个不同的日志文件中
? 记录数据库更新前旧值的日志文件称为数
据库前像文件（ Before Image，简称 BI文
件）
? 记录数据库更新后新值的日志文件称为数
据库的后像文件（ After Image，简称 AI
文件）
Oracle的恢复技术（续）
?ORACLE V.5的恢复技术 (续 )
– BI文件是必须的,AI文件是任选的
– 没有 AI文件：只能执行 UNDO处理，不能执
行 REDO处理
Oracle的恢复技术（续）
?ORACLE V.7的恢复技术
– REDO日志文件：记录被更新数据的前像和
后像
– 回滚段 (Rollback Segment）：记录尚未完成
的更新事务的更新数据的前像
– 事务故障恢复
? 根据回滚段中的数据，撤消该事务的操作
Oracle的恢复技术（续）
?ORACLE V.7的恢复技术 (续 )
– 系统故障恢复
? 首先扫描 REDO日志文件，重做所有操作，
并对更新操作建立回滚段数据。当遇到提
交记录，取消相应回滚段中数据。
? 再根据回滚段中的数据，撤消未正常提交
的事务的操作（图 7.6）
优点：只需要扫描日志文件一遍
Oracle的恢复技术（续）
图 Oracle的恢复过程
(a) 发生故障，事务非正常终止
Ta Tf
T1 T3
T2 T44
时间
Oracle的恢复技术（续）
(b) 利用 REDO文件，重做所有操作
时间
T1 T3
T2 T44
Oracle的恢复技术（续）
(c) 利用回滚段撤消未提交的事务数据库恢复到一致性状态
时间
T1
T2
Oracle的恢复技术（续）
?ORACLE V.7的恢复技术 (续 )
– 介质故障恢复
? 重装数据库后备副本文件，恢复到转储时
的数据库一致性状态
? 利用在此之后转储的 REDO日志文件副本
将数据库恢复到最近点 (类似于系统故障
恢复 )
小结
? 如果数据库只包含成功事务提交的结果，就说
数据库处于一致性状态。保证数据一致性是对
数据库的最基本的要求。
? 事务是数据库的逻辑工作单位
– DBMS保证系统中一切事务的原子性、一致
性、隔离性和持续性
小结（续）
? DBMS必须对事务故障、系统故障和介质故障
进行恢复
? 恢复中最经常使用的技术：数据库转储和登记
日志文件
? 恢复的基本原理：利用存储在后备副本、日志
文件和数据库镜像中的冗余数据来重建数据库
小结（续）
?常用恢复技术
– 事务故障的恢复
? UNDO
– 系统故障的恢复
? UNDO + REDO
– 介质故障的恢复
? 重装备份并恢复到一致性状态 + REDO
第 5章 数据库保护
?5.1 安全性
?5.2 完整性
?5.3 并发控制
?5.4 恢复
?5.5 数据库复制与数据库镜像
5.5 数据库复制和数据库镜像
?5.5.1 数据库复制
?5.5.2 数据库镜像
5.5 数据库复制和数据库镜像
?5.5.1 数据库复制
?5.5.2 数据库镜像
5.5.1 数据库复制
?复制是数据库更具容错性的方法，主要用
于分布式结构的数据库中
?在多个场地保留多个数据库备份，可是是
整个数据库的副本，也可以是部分数据库
的副本
?各个场地的用户可以并发存取不同的数据
库副本，进一步提高系统并发度。但 DBMS
必须采取一定手段，保证用户对数据库的
修改能够及时反映到其所有副本上
数据库复制（续）
?当数据库出现故障，系统可以用副本对
其进行联机恢复，而在恢复过程中，用
户可以继续访问该数据库的副本，而不
必中断其应用，如下页图所示
图：数据复制
结点 1 结点 2
主数据库 备份数据库
结点 2
主数据库 备份数据库
数据库复制（续）
?数据库复制三种方式,
– 对等复制
– 主 /从复制
– 级联复制
?不同的复制方式提供了不同程度的数据
一致性
1、对等复制
?对等复制是最理想的复制方式
– 哥哥场地的数据库地位是平等的，可以互相
复制数据
– 用户可以在任何场地读取和更新公共数据集，
在某一场地更新公共数据集时,DBMS会立
即将数据传送到所有其它副本
对等复制（续）
应用 复制数据库
复制数据库 复制数据库
复制数据库
应用
事务
事务
2、主 /从复制
?数据只能从主数据库中复制到从数据库
中
?更新数据只能在主场地上进行，从场地
供用户读数据
?当主场地出现故障时，更新数据的应用
可以转到其中一个复制场地上去
?实现起来比较简单，易于维护数据一致
性
主 /从数据库（续）
复制数据库
复制数据库 复制数据库
复制数据库
应用 事务
3、级联复制
?指从主场的复制过来的数据，又从该场
地再次复制到其它场地，即 A场地把数据
复制到 B场地,B场地又把这些数据或其
中部分数据再复制到其它场地
?可以平衡当前各种数据需求对网络交通
的压力
?通常与前两种配置联合使用
级联复制（续）
复制数据库
复制数据库 复制数据库
复制数据库
应用 事务
复制数据库 复制数据库
数据库复制（续）
? DBMS在使用复制技术时必须做到以下几点,
– 1、数据库复制必须对用户透明
– 2、主数据库和各个从复制数据库在任何时候都必
须保持事务的完整性
– 3、对于对异步的可在任何地方更新的复制方式，
当两个应用在两个场地同时更新同一个记录，一个
场地的更新事务尚未复制到另一个场地时，第二个
场地已开始更新，这时可能引起冲突。 DBMS必须
提供控制冲突的方法，包括各种形式的自动解决方
法和人工干预方法
5.5 数据库复制和数据库镜像
?5.5.1 数据库复制
?5.5.2 数据库镜像
5.5.2 数据库镜像
? 介质故障是对系统影响最为严重的一种故障，
严重影响数据库的可用性
– 介质故障恢复比较费时
– 为预防介质故障,DBA必须周期性地转储数
据库
? 提高数据库可用性的解决方案
– 数据库镜像（ Mirror）
数据库镜像（续）
?数据库镜像
– DBMS自动把整个数据库或其中的关键数据
复制到另一个磁盘上
– DBMS自动保证镜像数据与主数据的一致性
(图 7.5a)
数据库镜像（续）
?数据库镜像的用途
– 出现介质故障时
? DBMS自动利用镜像磁盘数据进行数据库
的恢复，不需要关闭系统和重装数据库副
本 (图 7.5b)
– 没有出现故障时
? 可用于并发操作 (图 7.5a)
–一个用户对数据加排他锁修改数据
–其他用户可以读镜像数据库上的数据
数据库镜像（续）
图数据库镜像
