Oracle恢复内部原理(各式各样的恢复特性)

并行恢复的目标是用计算和I/O的并行机制减少崩溃恢复、单实例恢复和介质恢复的时间。当多个磁盘上多个数据文件同时进行恢复时能有

10.1  并行恢复(v7.1)

并行恢复的目标是用计算和I/O的并行机制减少崩溃恢复、单实例恢复和介质恢复的时间。当多个磁盘上多个数据文件同时进行恢复时能有效的降低恢复时间。

10.1.1  并行恢复架构

并行恢复分区做两件事：

1.      读重做日志。

2.      应用改变向量。

步骤1不适合并行，重做日志必须按顺序读取，然后在介质恢复中合并。因此这个任务由一个进程完成：读重做日志的进程

步骤2很适合并行，因此应用改变向量的任务就委托给一组重做程序的从属进程。重做日志读取进程将改变向量发送给重做程序从属进程，用的是跟并行查询中同样的 IPC机制（进程间通讯机制）。改变向量使用HASH函数利用数据块地址做参数来分布。因此每个重做程序 进程只处理分配到它的“桶”里的改变向量。重做程序从属进程负责将数据块读入到缓存中，检查是否要应用改变向量，如果需要就应用。

这个架构达到了数据块读取I/O和改变向量应用过程中的并行。它允许日志读取I/O和数据块读取I/O可以并行进行。此外，它还允许不同HASH桶中的数据块的读取I/O可以并行进行。只要并行带来的好处比进程管理和通信带来的成本大就有效的缩减了恢复用的时间。

10.1.2  并行恢复系统初始化参数

PARALLEL_RECOVERY_MAX_THREADS

PARALLEL_RECOVERY_MIN_THREADS

这两个参数控制崩溃恢复或者介质恢复中重做程序从属进程的数量。

PARALLEL_INSTANCE_RECOVERY_THREADS

这个参数控制实例恢复中重做程序从属进程的数量。

10.1.3  介质恢复语法变化

RECOVER DATABASE命令新增了一个可选参数用来指定重做程序从属进程的数量。如果指定了该参数，将覆盖默认参数PARALLEL_RECOVERY_MAX_THREADS的值。

RECOVER TABLESPACE命令新增了一个可选参数用来指定重做程序从属进程的数量。如果指定了该参数，将覆盖默认参数PARALLEL_RECOVERY_MIN_THREADS的值。

RECOVER DATAFILE命令新增了一个可选的参数用来指定重做程序从属进程的数量。如果指定了该参数，将覆盖默认参数PARALLEL_RECOVERY_MIN_THREADS的值。

10.2  重做日志 Checksums (v7.2)

日志checksum允许日志在被归档之前先检查一下是否有损坏。目的是为了防止损坏的日志被复制（归档）。这个特色将会和一个新命令 CLEAR LOGFILE 结合使用，用来清除一个损坏的联机日志而不归档。

一个新的初始化参数LOG_BLOCK_CHECKSUM控制了是否激活日志checksum功能。如果设置了，每个日志块从缓冲区中写入到磁盘之前都会计算一个值放在日志块的头部。以后该checksum值将会在归档时或者恢复的时候被验证。如果验证发现该日志块的checksum值不对，则会尝试读取该日志组的其他成员中的日志块（如果有其他成员的话）。如果所有成员都有不可避免的checksum错误，则日志读取操作失败。

如果一个不可恢复的checksum错误导致日志不能被归档，则该日志就不能被使用。最后日志切换以及产生新的日志都会延迟。如果不采取措施，数据库就会停止。CLEAR LOGFILE命令提供了一种方式避免要归档该日志。

10.3  清除日志 (v7.2)

如果一个联机日志组的所有成员都丢失或者损坏（如因为checksum错误或者介质错误等）。重做日志程序可能还可以正常进行直至要重用该日志组的时候。一旦所有线程的检查点都超出了该日志，则该日志可以被重用。但下列情形使得重用失败：

1.      日志因为checksum错误而不能归档，，不能归档又导致该日志不能被重用。

2.      日志切换失败因为该日志不可用（如因为介质失败），该日志可能已归档或未归档。

ALTER DATABASE CLEAR LOGFILE命令用于将一个非活动状态的日志文件（即崩溃恢复不需要的日志文件）从上面这样的情形中解决出来。CLEAR LOGFILE允许有一个非活动状态的日志被清除，如丢弃并初始化，类似于先DROP LOGFILE再ADD LOGFILE。很多情形下用这个命令可以避免不必要的关闭数据库或者重置日志。

注意：CLEAR LOGFILE 不能用于清除崩溃恢复需要的联机日志（如状态为”current”或”active”的日志）。如果这样的联机日志损坏了，则需要以异常方式关闭数据库，然后做不完全恢复并以重置日志选项打开数据库。

使用UNARCHIVED选项使得日志清除过程顺利进行即使是该日志文件还没有归档。该情形下不允许用DROP LOGFILE此外CLEAR LOGFILE允许处理下列情形：

1.      线程中只有两个日志组

2.      在介质失败中所有日志组的成员都丢失或损坏了

3.      要清除的日志是一个已关闭线程的当前日志

上面所有情形都不允许用DROP LOGFILE。

清除未归档的日志文件使得现有的备份都没有用了，因为恢复需要该日志文件。因此建议清除未归档日志后立即对数据库进行全备份。此外，UNRECOVERABLE DATAFILE选项在数据文件脱机且联机前的恢复需要该日志文件时必须结合使用。在CLEAR LOGFILE命令中带上UNRECOVERABLE DATAFILE选项，脱机的数据文件以及相应的表空间必须得从数据库中删除，因为让这个数据文件联机时恢复的日志被清除了且没有备份了。

前台进程在执行CLEAR LOGFILE时分为以下几个步骤：

1.      检查该日志文件不是崩溃恢复需要的，且可以清除

2.      在控制文件中将该日志标记为“正在清除”和“不需要归档”，这样该日志文件就不能够作为日志切换的候选成员了。

3.      重新创建了一个新的日志文件，用多块写将其清零（一个漫长的过程）。

4.      重置“正在清除”的标记。

如果前台进程在执行CLEAR LOGFILE命令中途死掉了，日志将不可用。重做日志程序将会延迟，数据库可能会停止，尤其是在日志切换的时候会发生，因为得等待检查点完成或者归档完成。假如前台进程执行CLEAR LOGFILE时真的死掉了，那应该重新执行一次。另外一个方法就是删除已经清除一部分的日志。CLEAR LOGFILE也可能在清零时因为I/O错误而失败。解决的办法就是删除该日志并重新增加一个以替换它。

系列文章：Oracle恢复内部原理 ?where=nkey&keyword=19824