数据库第十讲数据库的安全与保护

造成数据库的数据不正确，甚至被破坏的主要原因有
 自然的或人为的破坏
 如火灾、计算机病毒或未被授权人有意篡改数据等
 对数据库数据的更新操作有误
 如操作时输入的数据有误或存取数据库的应用程序有错等
 数据库的并发操作引起数据的不一致性
 数据库系统的软、硬件故障造成数据被破坏

DBMS层所提供的数据库安全和保护功能：
 安全性(security)保护，即防止非法用户对数据库的非法使用，以
避免数据的泄露、篡改或破坏
 完整性(integrity)保护，即保证数据的正确性和一致性
 并发控制(concurrent control)，即保证多用户能共享数据库，并
维护数据的一致性
 数据库恢复(database recovery)，即在系统失效后的数据库恢复，配合定时备份数据库，使数据库不丢失数据。

10.1 数据库的安全性保护
 用户鉴别
 存取权限控制
 视图机制
 跟踪审查
 数据加密存储

用户鉴别
 登录MySQL服务器
 mysql –h hostname|hostIP –P port –u username –p DatabaseName –e "SQL语句"
 –h hostname|hostIP ，指定连接的MySQL服务器主机名或是主机IP
 –P port ，指定访问的端口号，默认端口是3306
 –u username ，指定登录的用户名
 –p，指明需要输入登录密码
 DatabaseName，指明登录到哪个数据库中，默认直接登录到MySQL数据库
中，然后可使用USE命令来选择数据库
 –e “SQL语句”，登录MySQL服务器以后即可执行指定的SQL语句，然后退
出MySQL服务器

 登录MySQL服务器
 mysql –h hostname|hostIP –P port –u username –p DatabaseName –e "SQL语句"

 用户的种类
 root用户，超级管理员，拥有所有权限
 普通用户，只能拥有被授予的权限
 查看用户信息
 SELECT user, host FROM mysql.user; #只有root才能查看
 SELECT USER(); #查看当前用户
 SELECT CURRENT_USER(); #查看当前用户

 创建用户

 CREATE USER [IF NOT EXISTS] <用户名> [IDENTIFIED BY '密码'][, <用
户名> [IDENTIFIED BY '密码'] ];
 用户名，新建用户的账号，由用户(User)和主机名(Host)构成
 IDENTIFIED BY，指定明文密码值
 [, …]，可同时创建多个用户

 CREATE USER [IF NOT EXISTS] <用户名> [IDENTIFIED BY '密码'][, <用
户名> [IDENTIFIED BY '密码'] ];
 例：CREATE USER zhang3 IDENTIFIED BY '123123'; #默认Host是%

CREATE USER 'kangshifu'@'localhost' IDENTIFIED BY '123456';
%，意味着远程主机可以从任何其他服务器登录到MySQL服务器，localhost，意味着您只能从同一台计算机登录到MySQL服务器。

 修改用户名

 RENAME USER <old_user> TO <new_user> [, <old_user> TO <new_user>] ;
 修改一个或多个已经存在的用户账号名称
 例：RENAME USER zhang3 to li4;
 例：UPDATE mysql.user SET USER='wang5' WHERE USER='li4';

FLUSH PRIVILEGES; #用于重新加载授权表（即 user 表），以使权限
或账户相关的更改立即生效

 删除用户

 DROP USER <user> [, <user>] ;
 注：必须拥有DROP USER的权限
 例：DROP USER 'kangshifu'@'localhost';
 例：DELETE FROM mysql.user WHERE User='wang5' AND Host='%';

FLUSH PRIVILEGES;
 注意：不推荐使用DELETE语句删除用户，系统会有残留信息保留

修改当前用户密码

 ALTER USER USER() IDENTIFIED BY ‘新密码’; 或者
 SET PASSWORD=‘新密码’; #使用root用户登录MySQL

 修改其它用户密码

 ALTER USER <user> IDENTIFIED BY ‘新密码’; 或者
 SET PASSWORD FOR <user>=‘新密码’; #使用root用户登录MySQL
 或者
 UPDATE MySQL.user …（不推荐）

 密码过期策略

在MySQL中，数据库管理员可以手动设置账号密码过期，也可以建立一个
自动密码过期策略
 过期策略可以是全局的，也可以为每个账号设置单独的过期策略 自学。。。

 存取权限控制

 权限级别
 列权限(columns_priv)：其和表中的一个具体列相关
 表权限(tables_priv)：其和一个具体表中的所有数据相关 数据库权限(db)：其和一个具体的数据库中的所有表相关 用户权限(user)：其和MySQL中所有的数据库相关
 授权粒度
 是衡量授权机制是否灵活的一个重要指标
 授权粒度越细，授权子系统就越灵活，能够提供的安全性就越完善，但数据字典会变得大而复杂，系统定义与检查权限的开销也会随之增大。
10.1 数据库的安全性保护
 存取权限控制
 user表，是MySQL中非常重要的一个权限表（用户层权限） 范围列：包括host字段、user字段和authentication_string字段。
 权限列：决定了用户的权限，表示了在全局范围内允许对数据和数据库进行的操作。
 安全列：都是和加密、标识用户、授权插件相关的字段。 资源控制列：用来限制用户使用的资源。
10.1 数据库的安全性保护
 存取权限控制
 user表，是MySQL中非常重要的一个权限表（用户层权限）
 host字段，表示连接类型
 %，表示所有远程通过TCP方式的连接
 IP地址，通过指定IP地址进行的TCP方式的连接
 机器名，通过指定网络中的机器名进行的TCP方式的连接
 ::1，IPv6的本地IP地址，等同于IPv4的127.0.0.1
 localhost，本地方式通过命令行方式的连接
 user字段，表示用户名
 同一用户通过不同方式连接的权限是不一样的
 authentication_string字段，密码
 所有密码串通过password（明文字符串）生成的密文字符串

 db表（数据库层权限）
 用户列：包括host字段、user字段和db字段，表示从某个主机连接某个用户对某个数据库的操作权限。
 权限列：决定了用户是否具有指定的权限。

存取权限控制
 tables_priv表（表层权限）
 用户列：包括host字段、user字段、db字段和Table_name字段。 Grantor列：表示修改该记录的用户。
 Timestamp列：表示修改该记录的时间。
 Table_priv列： 表示对象的操作权限。包括Select、Insert、Update、Delete、Create、Drop、Grant、References、Index和Alter。
 Column_priv列：表示对表中的列的操作权限。包括Select、Insert、Update和References。
10.1 数据库的安全性保护
 存取权限控制
 columns_priv表（字段层权限）
 用户列：包括host字段、user字段、db字段、Table_name字段和Column_name字段。
 Timestamp列：表示修改该记录的时间。
 Column_priv列：表示对表中的列的操作权限。包括Select、Insert、Update和References。
10.1 数据库的安全性保护
 存取权限控制
 procs_priv表，对存储过程和存储函数设置操作权限
 用户列：包括host字段、user字段、db字段
 Routine_name列：存储过程名称
 Routine_type列：存储过程类型，存储过程or存储函数
 Grantor列：表示修改该记录的用户
 Timestamp列：表示修改该记录的时间。
 Proc_priv列：表示对存储过程的操作权限。包括Execute，Alter Routine，
Grant。

存取权限控制
 权限管理

 授予权限
GRANT priv_type[(column_list)] ON database.tableTO user[,user]…
[WITH GRANT OPTION]; ON database.table，ON后面跟的是该权限的适用对象
 全局权限，适用于一个给定服务器中的所有数据库，可用*.*表示。
 数据库权限，适用于一个给定数据库中的所有目标，可用database.*表示
 表权限，适用于一个具体表中的所有列，可用database.table表示
 列权限，适用于表中的具体列，此时在权限后面把具体列表示出来即可

例：将Students表中Sno字段、Sname字段的查询权限授予用户zhang3。
 GRANT SELECT(Sno, Sname) ON jxdb.Students TO zhang3@localhost; mysql -u zhang3@localhost -p jxdb; SELECT Sno, Sname FROM Students WHERE Sno='2014112103'; SELECT Sno, Sname, Mno FROM Students WHERE Sno='2014112103';
10.1 数据库的安全性保护
 存取权限控制
 撤销权限
REVOKE priv_type[(column_list)] ON database.tableFROM user[,user]…
 例：撤销用户zhang3查询Students表中Sname字段的权限，撤销用
户kangshifu的所有权限
REVOKE SELECT(Sname) ON jxdb.Students FROM zhang3@localhost;REVOKE ALL,GRANT OPTION FROM kangshifu@localhost;
10.1 数据库的安全性保护
 存取权限控制
 角色管理
 目的是方便管理拥有相同权限的用户。

存取权限控制
 创建角色
 CREATE ROLE 'role_name'[@'host_name'] [,…n];
 例：
 CREATE ROLE 'manager'@'localhost’; 给角色赋予权限
 GRANT privileges ON table_name TO 'role_name'[@'host_name’];
 SHOW PRIVILEGES;
10.1 数据库的安全性保护
 存取权限控制
 查看角色的权限
 SHOW GRANTS FOR 'role_name'; 回收角色的权限
 REVOKE privileges ON table_name FROM 'role_name'; SHOW PRIVILEGES;
 删除角色
 DROP ROLE 'role_name’;
 注意： 如果你删除了角色，那么用户也就失去了通过这个角色所获得的
所有权限
10.1 数据库的安全性保护
 存取权限控制
 给用户赋予角色
 角色创建并授权后，要赋给用户并处于激活状态才能发挥作用
 ① 授权 GRANT rolename [, …n] TO username; ② 激活 SET DEFAULT ROLE ALL TO username; 撤销用户的角色
 REVOKE rolename FROM username;
10.1 数据库的安全性保护
 视图机制
 通过视图机制可限制用户使用数据的范围，从而自动地对数据提供一定程度的安全保护。
 视图（外模式）
 视图是查询结果的关系，是被存储的查询定义，视图的属性名由子查询
确定
视图数据在物理上是不存在的
10.1 数据库的安全性保护
 视图机制
 视图的特点
 虚拟表：是从一个或几个基本表(或视图)导出的表
 只存放视图的定义(SELECT语句)，不存放视图对应的数据。 基本表中数据发生变化，从视图中查询出的数据也随之改变
 对应用程序来说，视图就相当一个表，数据可以从视图中查得，而且在权限许可的情况下，还可以通过视图来插入、更改和删除基本表中的数据
10.1 数据库的安全性保护
 视图机制
 定义视图的格式为：
CREATE VIEW <视图名> [(<列名>[，…n)]]
AS <SELECT子查询语句>[WITH CHECK OPTION]
通常不允许含有
ORDER BY子句和
DISTINCT短语
对视图进行UPDATE，
INSERT和DELETE操作时要
保证更新、插入或删除的行满
足视图定义中谓词条件（即子
查询中的条件表达式）
10.1 数据库的安全性保护
 视图机制
 组成视图的属性列名要么全部省略要么全部指定。但在下列三种情况下必须明确指定组成视图的所有列名：
 某个目标列不是单纯的属性名，而是集函数或列表达式。
 多表连接导出的视图中有几个同名列作为该视图的属性列名。
 需要在视图中为某个列使用新的更合适的名字
10.1 数据库的安全性保护
 视图机制
 例5：建立学院号为12的学生的视图，并要求进行修改和插入操作时仍需保证该视图只有学院号为12的学生，视图的属性名为Sno, Sname, Sbirth, Dno, MnoCREATE VIEW VIEW_StuInfo1
AS
SELECT Sno, Sname, Sbirth, Dno, MnoFROM Students S
WHERE Dno='12'
WITH CHECK OPTION
10.1 数据库的安全性保护
 视图机制
 例6：建立所有学生的基本信息、选课信息及相关课程信息的视
图
CREATE VIEW VIEW_StuInfo2AS
SELECT S., C., Racademicyear, Rterm, GradeFROM Students S, Reports R, Courses CWHERE S.Sno=R.Sno AND R.Cno=C.Cno
10.1 数据库的安全性保护
 视图机制
 例7：定义一个反应学生出生年份的视图
CREATE VIEW VIEW_StuBirth(Sno, Sname, Syear)AS
SELECT Sno, Sname, YEAR(Sbirth)FROM Students
虚拟列
10.1 数据库的安全性保护
 视图机制
 对于已经定义的视图，用户应用SELECT语句，就像查询基本表
一样查询视图
 例8：基于视图VIEW_StuInfo2建立学生的学号(Sno)、姓名
(Sname)、选修课程名(Cname)及成绩(Grade)的视图CREATE VIEW VIEW_StuRept
AS
SELECT Sno, Sname, Cname, GradeFROM VIEW_StuInfo2
10.1 数据库的安全性保护
 视图机制
 删除视图的语句格式为：DROP VIEW <视图名>
 说明：视图删除后视图的定义将从数据字典中删除。但是由该视图导出的其它视图定义仍在数据字典中，不过该视图已失效。用户使用时就会出错，要用DROP VIEW语句显式将它们一一删除
。
10.1 数据库的安全性保护
 视图机制
 更新视图
 指通过视图来插入(INSERT)、删除(DELETE)和修改(UPDATE)数据。由于视图是不实际存储数据的虚拟表，因此对视图的更新，系统将自动转换为对基本表的更新。
 在对视图的数据进行插入和修改的时候，和向基本表中插入数据一样，用户必须具有向基本表中插入数据的权限。如果视图上没有包括基本表中所有属性为NOT NULL的列，那么插入操作会因为那些列的值为NULL而失败。
10.1 数据库的安全性保护
 视图机制
 更新视图的限制
 在一个基本表上建立的视图，只有包含基本表的主键才可以更新； 一个视图最多只能有250个列；
 不能在视图上建立触发器和索引；
 对视图的一个更新语句只能影响一个基本表，所以由多表连接定义的视图不允许更新。
 定义视图语句不能使用UNION操作符。
 视图定义中用到GROUP BY子句或包含集合函数、计算列的数据不能修改。
注意：不同的系统对视图的更新有不同的限制，使用时要参照具体的DBMS的说明
10.1 数据库的安全性保护
 视图机制
 视图的优点
 提供了一定的数据独立性。即使修改了基本表，通过建立视图，也可以
不改变应用程序
 通过视图简化了应用程序和用户查询
 不同的用户通过视图从不同的观点观察数据
 视图作为授权的单位提高了系统的安全性
10.1 数据库的安全性保护
 跟踪审查
 一种事后监视的安全性保护措施，它跟踪数据库的访问活动，以发现数据库的非法访问，达到安全防范的目的。
 MySQL支持的日志
 错误日志，记录MySQL服务器的启动、关闭、运行错误等信息
 二进制日志，以二进制文件的形式记录数据库中的操作，但不记录查询
语句
 通用查询日志，记录用户登录和记录查询的信息
 慢查询日志，记录执行时间超过指定时间的操作
10.1 数据库的安全性保护
 数据加密存储和传输
 商品化DBMS一般都提供了数据加密例行程序，可根据用户的要求自动对存储和传输的数据进行加密处理。即使未提供这种加密程序，一般也提供了接口，允许用户使用其它厂商推出的加密程序对数据加密。
 由于数据的加密与解密是比较费时的操作，而且数据加密与解密程序会占用大量系统资源，一般只对高度机密的数据加密。

10.2 数据库的完整性保护

**保护数据的
正确性
一致性
相容性 **

 完整性和安全性的关系：它们是数据库保护的两个不同的方面。
 安全性是防止用户非法使用数据库，包括恶意破坏和越权存取数据，即防范的对象是非法用户和非法操作。
 完整性则是防止合法用户使用数据库时向数据库中加入不合语义的数据，即防范的对象是不合语义的数据。

DBMS完整性控制应具有的功能：
 定义功能：为用户提供定义完整性约束条件的命令或工具。
 检查功能：能够自动检查用户发出的操作请求是否违背了完整性约束条件。
 保护功能：当发现用户的操作请求使数据违背了完整性约束条件时，能够自动采取一定的措施确保数据的完整性不遭破坏。

10.2 数据库的完整性保护
 完整性约束的分类(根据执行约束的时机分)
 立即执行的约束：一条语句执行完成后立即检查的完整性约束条件；
 延迟执行的约束：延迟到整个事务执行结束后，正式提交前进行检查的完整性约束条件；
10.2 数据库的完整性保护
 完整性约束的分类(根据控制的方法分)：
 实体完整性约束：违反实体完整性的操作拒绝执行
 参照完整性约束：违反参照完整性的操作，一般不是简单地拒绝执行，有时要根据应用语义执行一些附加的操作，以保证数据库的正确性
 用户定义的完整性约束：违反用户定义的完整性的操作拒绝执行

 实现参照完整性控制需要考虑的几个问题

⑴ 外键的空值问题。
 ⑵ 被参照关系中删除元组的问题。
 ⑶ 在参照关系中插入元组的问题。
 ⑷ 元组中主键值的修改问题

 ⑴ 外键的空值问题。
 允许为空。

例：新生的班级分配，职工的部门分配
 不允许为空。

例：学生的选课信息，客户的购货清单

 ⑵ 被参照关系中删除元组的问题。
当删除被参照关系中的某个元组，而参照关系中存在若干元组，其外键值与被参照关系删除元组的主键值相同时，有3种不同的处理策略：
 级联删除(Cascades)
 受限删除(Restricted)
 置空值删除(Nullifies)
“株连九族”
“上有老，下有小”
“恩断义绝”

⑶ 在参照关系中插入元组的问题。
当在参照关系中插入某个元组，而被参照关系不存在相应的元组时，有以下2种策略：
 受限插入。（仅当被参照关系中存在主键值与参照关系刚插入元组的外
键值相同的元组）
 递归插入

 ⑷ 元组中主键值的修改问题。
当用户欲修改关系中某个元组的主键值时，由于可能存在参照与被参照的问题，系统一般有以下两种处理策略：
 不允许修改主键值
 允许修改主键值，但必须保证主键值的唯一性和非空，否则拒绝修改

当修改的关系是被参照关系，而参照关系存在这样的元组，其外键值等于被参照关系要修改的主键值时，有3种处理策略：
 级联修改
 受限修改
 置空值修改

当修改的关系是参照关系，而其要修改的外键值在被参照关系中不存在这样的主键值时，有2种处理策略：
 受限修改
 递归修改

触发器(Triggers)

 建立(附着)在某个关系(基本表)上的一系列SQL语句的集合(程序)，且经预先编译后存储在数据库中。
 是一种特殊类型的存储过程
 在用户要对某一表内的数据做增、删、改操作时被触发执行
 触发器的功能
 实现数据库的完整性约束和安全保护。

 触发器的类型
 UPDATE
 INSERT
 DELETE
 触发器的优点
 比由完整性约束条件实现的完整性约束要强的多，且更加灵活。

10.3 数据库的并发控制技术

衡量DBMS性能的重要指标之一

事务的定义
 用户定义的一组操作序列的集合，数据恢复和并发控制的基本单位。数据库系统在执行事务时，要么执行事务中全部操作，要么一个操作都不执行。

事务的特性（简称ACID）
 原子性(Atomicity)：一个事务是不可分割的数据库逻辑工作单位，事务中包括的所有操作要么都做，要么都不做。
 一致性(Consistency)：事务执行前后，数据从一个合法性状态变到
另一个合法性状态。（语义上的）

 隔离性(Isolation)：一个事务的执行不能被其它事务干扰。
 持续性(Durability)，也称持久性(Permanence)：指一个事务一旦提交，它对数据库中数据的改变应该是永久性的，其它操作或故障不对其产生任何影响。（通过事务日志来保证）

仅InnoDB支持事务

 事务的应用例子
 基本表用户钱包(UserTab)
 UserID CHAR(2) PRIMARY KEY, UserMoney INT
 基本表商家钱包(SellerTab)
 SellerID CHAR(2),PRIMARY KEY
 SellerMoney INT

事务的定义方法
 语法格式
START TRANSACTION | BEGIN [work] 显式地定义一个事务的开始
执行语句 （主要是DML，不含DDL）…
COMMIT;
…
ROLLBACK;或 显式地提交一个事务，并表示该
事务已正确执行并结束
ROLLBACK TO [SAVEPOINT 显式地回滚(撤销)一个事务，并表示事务因执行失败而结束。

事务的隐式定义
 系统变量autocommit，默认ON，自动提交
 SHOW VARIABLES LIKE 'autocommit’ ; 隐式提交数据的情况
 数据定义语言（DDL）
 隐式使用或修改mysql数据库中的表
 事务控制或关于锁定的语句
 加载数据的语句 … …
 当autocommit设置为OFF时，必须手动执行COMMIT才能提交事务

 数据库的并发控制以事务为单位进行
 串行访问：当多个事务对数据库进行操作时，各个事务按顺序执行，即一个事务执行完全结束后，另一个事务才开始。

数据库的并发控制以事务为单位进行
 并发访问：当多个事务对数据库进行操作时，各事务的执行在时间上有重叠。
 交叉并发：在单CPU系统中，多个事务交叉使用CPU。
 同时并发：在多CPU系统中，多个事务同时占用CPU。

DBMS对事务采用并发机制的主要目的
 改善系统的资源利用率
 改善短事务的响应时间
 但是
 事务的并发控制不当（各事务之间的操作没有做好隔离，互相受
到影响），会引起很多严重问题

并发控制不当引起的问题
 丢失修改(Lost update) ——写-写冲突

 脏读(Dirty read) ——读-写冲突

3、不能重读(Unrepeatable read) ——幻影现象

4、幻读(phantom read)

 事务的隔离性级别
 序列化
 每个用户的事务依次执行，可避免脏读、不可重读和幻读，但性能低下
 可重复读
 用户在同一个事务中执行同条SELECT语句数次，结果总是相同的，可
避免脏读、不可重读，存在幻读问题
 提交读
 其它事务提交的更新操作，在当前事务中可见，可避免脏读，但存在不
可重读和幻读问题
 未提交读
 无任何隔离（未提交的更新操作也可见），存在所有问题
（默认设置）
 命令
 SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL <level>
 level
 序列化，SERIALIZABLE
 可重复读，REPEATABLE READ
 提交读，READ COMMITTED
 未提交读，READ UNCOMMITTED

10.3.4 并发控制方法

 封锁技术
 封锁的定义
 防止其它事务访问指定资源的一种手段，即在一段时间内禁止某些用户对数据对象做某些操作以避免产生数据的不一致性问题的方法。
10.3.4 并发控制方法
 封锁技术
 基本封锁类型（InnoDB）
 ① 排它锁(eXclusive locks)又称X锁：如果某事务T对某数据建立了排它锁，则该事务能对该数据对象进行读、修改、插入和删除等操作，而其它事务则不能。
 ② 共享锁 (Shared locks)又称S锁：如果某事务对某数据建立了共享锁，则该事务能对该数据对象进行读操作，但不能进行修改等更新操作，而其它事务只能对该数据对象加S锁，而不能加X锁，即其它事务只能对该数据对象进行读操作。
 注意：要使用这两种锁，必须关闭自动提交（autocommit），或者明确
开启一个事务

 封锁粒度(Granularity)

 被封锁数据对象的大小 封锁粒度的种类
 行级锁
 页面锁
 表级锁
 封锁粒度与系统并发度和并发控制开销的关系
 封锁粒度越大，系统中能够被封锁的对象就越少，并发度也就越小，当然系统的开销也越少；封锁粒度越小，并发度越高，但系统开销也就越大。

 InnoDB的锁设置
 表级锁
 加锁：LOCK TABLES table_name lock_type,...
 解锁：UNLOCK TABLES
 行级锁
 共享锁：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE; 排他锁：SELECT * FROM table_name WHERE … FOR UPDATE
 封锁协议(Locking protocol)
 为保证正确地调度和控制并发操作，所有事务都应遵循的规则集合，是对事务可能执行的方法和基本操作顺序的一种限制。
 三级封锁协议
 ① 一级封锁协议
 ② 二级封锁协议
 ③ 三级封锁协议

封锁协议
 ① 一级封锁协议
 某事务T若要修改某个数据对象，则必须先对该数据对象加X锁，直到事务结束才释放，它可防止“丢失修改”所产生的数据不一致性问题。

 封锁协议
 ② 二级封锁协议
 一级封锁协议加上某事务T若要读取某个数据对象之前，则必须先对该数据对象加S锁，读完后即可释放S锁，这样可进一步防止“读脏数据”的问题。

封锁协议
 ③ 三级封锁协议
 一级封锁协议加上某事务T若要读取某个数据对象之前，则必须先对该数据对象加S锁，且直到该事务结束后才释放S锁，这样可进一步防止数据“不可重复读”的问题。

死锁和活锁
 活锁

 避免活锁的简单办法:采用先来先服务的策略。

 死锁
 是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

 预防法
 一次封锁法：规定每个事务必须一次性地将所要访问的数据对象全部加锁，并在操作结束后一次性释放加在所有对象上的锁，这样就能预防死锁的发生
 顺序封锁法：预先对数据对象规定一个封锁顺序号，所有事务都按照这个顺序对数据对象实施封锁，这样也能预防死锁的发生。
 诊断解除法
 应用诊断程序发现死锁产生后，通过解锁程序排除死锁。

10.4 数据库的恢复技术

 故障的种类
 事务故障：由于某种原因导致事务尚未运行完成并提交就被中断所产生的故障。
 系统故障：系统在运行过程中，由于某种原因致使所有正在运行的事务都以非正常的方式终止而引起的故障。
 介质故障：系统在运行过程中，由于某种原因致使存储在外存储器中的数据部分丢失或全部丢失的故障。
 病毒破坏：由计算机病毒导致计算机系统和数据库出现的各种故障。

故障对数据库造成的破坏

 数据库结构被破坏。
 数据库结构没有被破坏，但数据的一致性被破坏
 数据库恢复的基本原理
 增加数据冗余
 即数据库中被破坏的不正确或不一致的数据可以利用存储在系统其它存储器上的冗余数据来重建。

数据恢复的两个关键问题
 如何建立冗余数据
 如何利用这些冗余数据实施数据库恢复

 数据转储
 建立冗余数据的基本技术，它是由DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来的(这种数据称为后备副本)过程。当数据库遭到破坏后就可以利用后备副本把数据库恢复到某个一致性状态。

数据转储方法
 按转储时间来分
 静态转储：转储期间不允许对数据库有任何操作(包括存取、修改等)活动，其优点是方法简单，缺点是降低了数据库的可用性。
 动态转储：转储期间允许对数据库进行存取等操作，即数据转储和用户事务可并发执行，其优点是数据库可用性高，缺点是实现技术要求较高

按数据转储量来分
 海量转储：每次都转储数据库的全部数据，其特点是数据一致性好，数据恢复容易，但数据转储量大，转储时间长、不易经常进行。
 增量转储：每次只转储数据库中上次转储以来所产生变化的那些数据，其特点是数据转储量少，时间花费少，易于经常转储，但其数据转储和恢复技术要求较高。

 数据转储策略
 一般根据数据库的使用情况确定适当的转储周期和转储方法。
 例如，每天晚上或每周进行动态增量转储，每月进行一次海量转储等。

10.4.1 建立冗余数据
 日志文件
 由DBMS自动建立和追加记录的、保存每一次对数据库进行更新操作的有关信息的文件，是DBMS的另一种数据冗余措施。
 日志文件的内容
 事务名称、操作的时间、操作类型、修改前数据值以及修改后数据值等，还有事务的开始，提交(COMMIT)及回滚(ROLLBACK)等执行情况内容。

 日志文件的作用
 当数据遭到破坏时，日志文件与数据库的后备副本结合起来才能有效而快速地恢复数据库。
 日志文件的登记原则
 严格按照并行事务执行的时间次序登记；
 必须先写日志文件，后写数据库

 日志文件的分类：
 以记录为单位的日志文件，其主要内容有：① 事务的开始(BEGIN TRANSATION)标记② 事务的结束(COMMIT或ROLLBACK)标记③ 各个事务的所有更新操作
 以数据块为单位的日志文件
当某个数据块中有数据被更新，就将整个块更新前和更新后的内容放入日志文件中。

 事务故障的恢复：
 反向扫描日志文件(从日志文件末尾开始扫描)，查找该事务的更新操作。
 对该事务的更新执行逆向操作。
 继续反向扫描日志文件，查找该事务的其它更新操作，并做同样处理。
 如此处理下去，直至读到此事务的开始标记，事务故障恢复就算完成了。
 说明：事务故障的恢复是系统重新启动后由系统自动完成的，不需要用户干涉。

 系统故障的恢复：
 产生不一致的原因：
 某些未完成事务对数据库的更新已写入数据库；
 有些已经提交的事务对数据库的更新还留在缓存区内没来得及写入数据库。

 系统故障的恢复
 正向扫描日志文件，找出在故障发生前已经提交的事务，并将这些事务标记记入重做队列。同时还要找出故障发生时尚未完成的事务，并将这些事务标记记入撤消队列。
 对撤消队列中的各个事务进行撤消(UNDO)处理，即将日志记录中“更新前的值”写到数据库中去。
 对重做队列中的各个事务进行重做(REDO)处理，即将日志记录中“更新后的值”写到数据库中去。

 介质故障的恢复
 装入最新的数据库后备副本，使数据库恢复到最近一次转储时刻的一致性状态。
 装入有关的日志文件副本，重做已完成的事务
 说明：介质故障的恢复需要DBA介入，但DBA只需要重新装入最近转储的数据库后备副本和有关的日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由DBMS自动完成。

 计算机病毒破坏的恢复
 系统重新启动之前先杀毒，然后根据数据库被破坏的具体情况，选择事务故障、系统故障和介质故障的恢复方法和操作步骤。

 数据恢复的一般过程
 ⑴ 做数据拷贝工作：将数据库后备副本拷贝到数据库系统中。
 ⑵ 做事务恢复第一步：检查日志文件，确​​​​​​​定哪些事务已执行结束，哪些尚未结束。
 ⑶ 做事务恢复第二步：对尚未结束的事务作撤消处理，对已执行结束的事务按日志的记录做。

10.4.2 数据库的恢复策略
 检查点机制
 就是日志文件中一条特殊的日志记录，该记录由数据库恢复子系统定期地自动生成和维护。
 目的：最大限度地改善数据库恢复的效率。