造成数据库的数据不精确，甚至被破坏的主要缘故原由有
自然的或人为的破坏
如火警、盘算机病毒或未被授权人故意篡改数据等
对数据库数据的更新操作有误
如操作时输入的数据有误或存取数据库的应用程序有错等
数据库的并发操作引起数据的不同等性
数据库体系的软、硬件故障造成数据被破坏
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 数据库的恢复策略
检查点机制
就是日记文件中一条特殊的日记记载，该记载由数据库恢复子体系定期地自动生成和维护。
目的：最大限度地改善数据库恢复的效率。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ 更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
