数据库恢复技术，故障的介绍，数据存储，登记日志文件，（事物，系统，介质）故障的恢复，检查点恢复技术，数据库映像
数据库恢复基础知识
数据库发生故障的原因
计算机硬件故障
软件的错误
操作员的失误
恶意的破坏
故障的影响
运行事务非正常中断，影响数据库中数据的正确性
破坏数据库，全部或部分丢失数据
数据库的恢复
数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)的功能，这就是数据库的恢复管理系统对故障的对策。
恢复子系统是数据库管理系统的一个重要组成部分 。
恢复技术是衡量系统优劣的重要指标。
故障的介绍
什么是事务故障
事务在运行过程中未运行至正常终止点就夭折了。
常见原因
输入数据有误
运算溢出
违反了某些完整性限制
某些应用程序出错
并行事务发生死锁
事务故障恢复
(1) 可预见错误：由事务程序来处理
(2) 不可预见错误：由DBMS强行回滚该事务
什么是系统故障
整个系统的正常运行突然被破坏
所有正在运行事务全部非正常终止
内存中缓冲区信息全部丢失，外存中数据未受影响
常见原因
操作系统、DBMS代码错误
硬件错误，如CPU故障
突然断电
系统故障恢复
(1) 回滚非正常终止的事务
(2) 重做缓冲区中已提交的事务
什么是介质故障
存储数据库的设备发生故障，使存储在其上的数据部分或全部受到破坏丢失，又称硬故障。
常见原因
磁盘损坏
磁头碰撞
操作系统的潜在错误
瞬时强磁场干扰
介质故障恢复
(1) 装入发生介质故障前某个时刻的数据库副本
(2) 重做该时刻后的所有成功事务，提交结果记入数据库
恢复的现实的技术（数据转储，登记日志文件）
(1) 建立冗余数据
数据转储(backup)
登记日志文件(log)
(2) 利用冗余数据实施恢复
什么是转储
DBA将整个数据库复制到磁带或另一个磁盘上保存的过程
备用数据称为后备副本或后援副本
转储的分类：静态转储和动态转储
静态转储
在系统中无运行事务时进行
开始时数据库处于一致性状态，期间不允许对数据库的任何存取、修改
优点：实现简单
缺点：降低了数据库的可用性
转储必须等用户事务结束
新的事务必须等转储结束
动态转储
操作与用户事务并发进行
期间允许对数据库进行存取、修改
优点：提高了数据库的可用性
不用等待正在运行的用户事务结束
不影响新事务的运行
缺点：不能保证副本中的数据正确有效
转储的分类：海量存储和增量存储
海量转储：每次转储全部数据库
增量转储：只转储上次转储后更新过的数据
海量转储与增量转储比较：
使用海量转储的后备副本进行恢复较为方便
当数据库很大，事务处理频繁时，增量转储更有效
登记日志文件
日志文件的格式及内容：以记录为单位的日志文件内容：
事务开始标记(BEGIN TRANSACTION)
事务结束标记(COMMIT或ROLLBACK)
事务的所有更新操作
日志记录包含：
事务标识
操作类型(插入、删除或修改)
操作对象(记录ID)
更新前数据的旧值(插入时为空)
更新后数据的新值(删除时为空)
为保证数据库是可恢复的，必须遵循两条原则：
(1) 登记次序严格按并行事务执行的时间次序
(2) 先写日志文件，后写数据库；
写日志文件：把修改的日志记录写到日志文件
写数据库操作：把对数据的修改写到数据库中
为何先写日志文件？
写数据库和写日志文件是两个不同的操作，两个操作之间可能发生故障；
如果先写数据库修改，而在日志文件中没有登记，则无法恢复该修改；
如果先写日志，但没有修改数据库，恢复时只是多执行一次不必要的Undo操作，并不影响数据库的正确性；
（事物，系统，介质）故障的恢复
恢复策略
事务故障的恢复
系统故障的恢复
介质故障的恢复
事务故障的恢复
事务故障：
事务在运行至正常终止点前被中止。
恢复方法：
恢复子系统利用日志文件撤消事务对数据库的修改，由系统自动完成，不需要用户干预。
恢复步骤：
(1) 反向扫描文件日志(从后向前)，查找该事务的更新操作；
(2) 对更新操作执行逆操作，将 “更新前的值” 写入数据库：对插入执行删除，对删除执行插入，对修改执行修改；
(3) 继续反向扫描，查找其他更新操作，执行2；
(4) 扫描到该事务的开始标记，事务故障恢复结束
系统故障的恢复
系统故障恢复需要解决两种情况：
(1) 未完成事务对数据库的更新可能已经写入数据库；
(2) 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。
系统故障恢复恢复步骤：
(1) 正向扫描日志文件(从前向后)
Redo队列：故障发生前已提交的事务T1，T3，T7，…，有BEGIN TRANSACTION和COMMIT记录；
Undo队列：故障发生时未完成的事务T2，T4，T5，…，只有BEGIN TRANSACTION记录，无COMMIT记录；
(2) 对Undo队列事务进行Undo处理
反向扫描日志文件，对每个事务的更新操作执行逆操作；
(3) 对Redo队列事务进行Redo处理
正向扫描日志文件，重新执行对每个事务；
介质故障的恢复
介质恢复方法：
重装数据库，使数据库恢复到一致性状态
重做已完成的事务
介质故障恢复步骤：
(1) 装入最新的后备数据库副本；
装入静态转储的数据库副本，数据库即处于一致性状态
装入动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用与恢复系统故障相同的方法，数据库才能恢复到一致性状态
(2) 装入日志文件副本，重做已完成的事务；
扫描日志文件，找出故障发生时已提交的事务，记入Redo队列；
正向扫描日志文件，重做Redo队列中的事务；
具有检查点的恢复技术
问题：
(1) 扫描日志：搜索整个日志耗费大量时间；
(2) Redo处理：重新执行浪费大量时间；
解决方案：检查点
在日志文件中增加检查点记录；
增加重新开始文件保存检查点地址；
恢复子系统动态维护日志；
维护日志文件步骤：
(1) 将当前日志缓冲区的所有日志记录写入磁盘的日志文件；
(2) 在日志文件中写入一个检查点记录；
(3) 将当前数据缓冲区的所有数据记录写入磁盘的数据库中；
(4) 把检查点记录在日志文件中的地址写入重新开始文件。
建立检查点时间：
定期：按照预定的一个时间间隔；
不定期：按照某种规则，如日志文件写满一半时；
检查点恢复策略：
在检查点之前提交的事务不需要Redo：当事务在一个检查点之前提交，对数据库所做的修改已写入数据库。
检查点恢复的步骤
(1) 在重新开始文件中找到最后一个检查点记录的地址，并在日志文件中找到该检查点记录；
(2) 由该检查点记录得到检查点建立时刻所有正在执行的事务清单，建立Undo队列和Redo队列：正在执行的事务暂时放入Undo队列，Redo队列暂时为空；
(3) 从检查点开始正向扫描日志文件，直到日志文件结束；
新开始的事务：暂时放入Undo队列
提交的事务：从Undo队列移到Redo队列
(4) 对Undo队列中的事务执行Undo操作, 对Redo队列中的事务执行Redo操作。
数据库镜像
介质故障是对系统影响最为严重的一种故障。
介质故障恢复比较费时；
为预防介质故障，DBA必须周期性转储数据库，加重了DBA负担
提高数据库可用性的解决方案：数据库镜像（Mirror）
数据库镜像
DBMS自动利用镜像磁盘整个数据库或关健数据复制到另一个磁盘
主数据库更新时，DBMS自动把更新后的数据复制过去
保证镜像数据与主数据库的一致性
出现介质故障时
镜像磁盘继续提供使用
DBMS自动利用镜像磁盘数据进行数据库恢复
不需要关闭系统和重装数据库副本
没有故障时
可用于并发操作
一个用户对数据加排他锁修改数据时，其他用户可以读取镜像数据库的数据，不必等待用户释放锁
