Oracle介质恢复（一）

介质恢复是基于物理备份恢复数据，介质恢复技术是 Oracle 数据库出现介质故障时恢复的重要保障。

1.        介质恢复的过程

介质恢复包括块恢复、数据文件恢复、表空间恢复和整个数据库的恢复。介质恢复主要是针对错误类型中的介质失败，如果是少量的块失败，可以使用介质恢复中的块恢复来快速修复；但如果是其它情况的丢失，根据具体情况，可使用数据文件恢复、表空间恢复甚至全库恢复。

介质恢复过程包括还原（RESTORE）和恢复（RECOVER）两个步骤：

还原是将某个时间点数据文件的拷贝再拷贝回去，还原后的数据库处于不一致性的状态，或不是最新的状态，还需要执行恢复操作。恢复就是使用归档Redo日志文件和联机Redo日志文件将不一致的数据库应用到一致性状态。如果是完全恢复，数据库就是最新的一致性状态；如果是不完全恢复，数据库是非最新的一致性状态。

| 注意：还原只是建立在数据库备份的基础版本上，例如，如果数据库备份包括0级备份和很多1级备份，还原只是应用0级备份，恢复过程会根据情况自动应用1级备份或Redo日志将数据库恢复到一致性的状态。 |

数据库的恢复过程又分为完全恢复和不完全恢复：

u  完全恢复

完全恢复是一种没有数据库丢失的恢复方式，能够恢复到最新的联机Redo日志中已提交的数据。在传统恢复方式中，因介质失败破坏了数据文件之后，可以在数据库、表空间和数据文件上执行完全介质恢复。

u  不完全恢复

不完全恢复是一种与完全恢复相反的恢复方式，是一种丢失数据的恢复方式，也称为数据库时间点恢复。通常情况下，若Flashback Database没有启用或者变得无效，可以执行不完全恢复撤销一个用户错误，不完全恢复不一定在原有的数据库环境执行，可以在测试环境下执行不完全恢复，将找回的数据再重新导入生产库中。对于不完全恢复来说，只能执行整个数据库的恢复，不能执行某个数据文件或表空间的不完全恢复。

不完全恢复根据备份情况恢复到与指定时间、日志序列号和SCN具有一致性的数据，之后的数据都将丢失。执行不完全恢复一方面是因为归档Redo日志、联机Redo日志的丢失不得不执行不完全恢复，另一方面可能是因为在某个时刻错误地操作了数据，过了一段时间之后才发现问题，而其它的恢复手段都无法恢复数据，这时也不得不使用不完全恢复来找回数据。

执行不完全恢复必须从备份中还原所有的数据文件，备份文件必须是要恢复的时间点之前创建的。当恢复完成，使用RESTLOGS选项打开数据库，将重新初始化联机Redo日志，创建一个新的日志序列号流，日志序列号从1开始，RESETLOGS之后的SCN还是在递增。

2.        物理坏块和逻辑坏块

Oracle数据文件的坏块可以分为物理坏块和逻辑坏块。物理坏块指的是块格式本身已经损坏，块内的数据没有任何意义。而逻辑坏块，指的是块内的数据在逻辑上存在问题，比如说索引块的索引值没有按从小到大排列导致的逻辑坏块。物理坏块一般是由于内存问题、OS问题、I/O子系统问题或硬件引起的，逻辑坏块一般是有Oracle bug等原因引起的。

各种各样的块损坏通常是通过Oracle的ORA-1578错误报告出来的，详细的损坏描述会在告警日志中打印出来。

l   物理块损坏

块的物理损坏有很多种情况，例如块头（Cache Header）被一个不正确的值替换、块被破坏或变得不完整、块的头和尾不匹配、块的校验和（CHECKSUM）不正确、块错位、块被归零。

n   破裂块

一个破裂块的意思即块是不完整的，块头的信息不能匹配块尾的信息。在告警日志中可能出现如下的日志信息：

Corrupt block relative dba:0x0380e573(file 14,block 58739)

Fractured block found during buffer read

……

n   不正确的校验和

块的校验和也是数据块的一致性检查的依据。块的一致性检查由DB_BLOCK_CHECKSUM和DB_BLOCK_CHECKING两个初始化参数控制。DB_BLOCK_CHECKSUM是一种物理检查，DB_CHECK_CHECKING是一种逻辑检查。

 

参数1 DB_CHECK_CHECKSUM

DB_BLOCK_CHECKSUM只有在写入（DBWn常规写或用户进程直接路径写入）时，根据一个CHECKSUM算法计算数据块的校验和，然后写入数据块的一个特定位置（CACHE HEADER,具体是以0字节算起，块的第16~17字节），在读取块时再进行检验。主要是防止I/O硬件和I/O子系统的错误。

CHECKSUM的算法只是根据块的字节值计算一个校验和，算法比较简单。该参数默认在所有表空间上都起作用。

DB_BLOCK_CHECKSUM参数属性

属性	描述
语法	DB_BLOCK_CHECKSUM={OFF|FALSE|TYPICAL|TURE|FULL}
默认值	TYPICAL
修改范围	ALTER SESSION,ALTER SYSTEM

只有当参数值是TYPICAL或者FULL，并且块的最后一次写是存储了一个校验和时，读取这个块，校验和才会被验证。在FULL模式，Oracle用update/delete语句改变数据之前会验证校验和，改变被应用之后还会重新计算校验和。

从Oracle Database 11g开始，大多数日志校验和都是通过前台进程产生的，同时LGWR执行其余的工作，这是为了更好地发挥CPU和缓存的效率。当这个参数设置为FULL，写日志块到磁盘之前，LGWR验证通过前台进程生成的每个日志块的校验和。在Oracle Database 11g之前的版本中，LGWR独自执行日志块校验和。数据文件块的校验和是由DBWR进程负责计算和管理的。

这个参数设置为OFF时，DBWn只为SYSTEM表空间计算校验和，不为用户表空间计算校验和。另外，此时数据库也不会执行日志的校验工作。

校验和可以使Oracle数据库察觉到磁盘、存储系统或者I/O系统引起的损坏。如果设置为FULL,DB_BLOCK_CHECKSUM也会捕捉在内存中的损坏，并停止它们对磁盘的操作。设置这个参数为TYPICAL值只会引起系统额外的1%~2%的负载，设置为FULL会引起4%~5%的负载。Oracle推荐设置DB_BLOCK_CHECKSUM为TYPICAL。为了保持向后兼容性，TRUE和FALSE值被保留，TRUE等同于TYPICAL，FALSE等同于OFF。

如果DB_BLOCK_CHECKSUM不等于FALSE值，每次读取块，Oracle计算校验和，都与存储在块头中的校验和进行对比。如下例子：

Corrupt block relative dba: 0x0380a58f (file 14,block 42383)

Bad check value found during buffer read

……

参数2 DB_BLOCK_CHECKING

DB_BLOCK_CHECKING参数主要是用于数据块的逻辑一致检查，但只是在块内，不包括块间的逻辑检查。主要用于防止在内存中损坏或数据损坏。

无论该参数如何设置，对SYSTEM表空间来说，逻辑一致检查始终处于“打开”状态，在其他表空间该参数默认是关闭的。

DB_BLOCK_CHECKING参数的属性

参数值	含义
OFF或者FALSE	对于用户表空间没有任何逻辑一致性检查工作
LOW	块的内容在内存中改变之后，执行基本的块头检查，如UPDATE语句、INSERT语句、磁盘读或者在RAC中内部实例之间的块传递之后发生检查工作
MEDIUM	除了索引以外的所有对象执行LOW检查和完全语义检查，由于索引能在遭遇损坏的情况下的重建，所以可以不考虑对它检查
FULL或者TRUE	所有对象执行MEDIUM检查和完全语义检查

Oracle通过遍历在块中的数据来检查一个块，确保它在逻辑上手尾一致。根据系统负载和参数值，块检查通常一起1%~10%的负载。打开块检查，大量的UPDATE或者INSERT将造成更大负载，对于一个繁忙的系统，特别有大量插入或者更新操作的系统来说，性能影响是比较明显的。如果性能负载可以被接受，应该考虑设置DB_BLOCK_CHECKING为FULL。为了保持向后的兼容性，TURE和FALSE参数值同样可以使用，FALSE等同于OFF，TRUE等同于FULL。

如果启用DB_BLOCK_CHECKING参数，在磁盘的块发生逻辑损坏，下一次块更新将作为软损坏标记这个块，之后读取这个块产生ORA-1578的错误。

n   块错位

当Oracle察觉读取块的内容属于不同块但是校验和又是正确的时，会产生错误。

l   逻辑块损坏

若块包含一个正确的校验和，块头以下的结构是损坏的（块内容损坏），这可能引起不同的ORA-600错误。逻辑块损坏的详细损坏描述通常不会打印到告警日志。DBV将报告块具体的逻辑错误。

3.        坏块的检测工具

以下为损坏块的检测工具和使用方法：

l   DBVERIRY坏块验证工具

DBVERIRY不能验证联机Redo日志、归档Redo日志、控制文件和RMAN备份集，只能用于数据文件的块验证。

n   DBV验证传统数据文件

下面是使用DBV工具验证数据文件块的例子：

$ dbv file=/testdb/test01.dbf blocksize=8192

注意：DBV工具除了用于检测数据文件是否有坏块外，也用于获得坏块的详细信息。

n   DBV验证裸设备数据文件

DBV要求file后面跟的必须是一个包含扩展名的文件，所以如果数据库使用裸设备作为存储方式，就必须使用ln命令连接裸设备一个带扩展名的文件，然后使用DBV工具通过对链接文件的验证实现对裸设备数据文件的验证。

n   DBV验证ASM存储的数据文件

如果是验证存储在ASM中的数据文件则需要指定用户名和密码，如果不指定用户名和密码，将收到DBV-00008：USERID must bu specified for OSM files的报错。下面是使用DBV工具验证存储在ASM中的数据文件的块的例子：

$ dbv file=+DATAFILE/testdb/datafile/test.234.648839 userid=sys/oracle

l   ANALYZE命令

Analyze命令的主要目的是通过分析数据库对象，为优化器收集数据库对象的统计量信息，以便优化器生成准确的执行计划。同时，它也能检查某个表或索引是否存在损坏的情况。Analyze执行坏块检查，但是不会标记坏块为corrupt，检测结果保存在USER_DUMP_DEST目录下的用户trace文件中。Analyze语法：

Analyze table/index / validate structure ;

Analyze命令会验证每个数据块、每条记录和索引的完整性。CASCADE关键字表示验证表及其相关的所有索引。与DBVERIFY不同的是，analyze只验证高水位线以下的数据块，analyze不会对未使用的空间进行验证。

SQL> analyze table fengpin.test validate structure;

l   RMAN工具

RMAN是一块备份工具，就像一个过滤器，RMAN需要通过缓存过滤每一个块，其中一个特点就是检查块是否被损坏。如果备份的数据库中包含有坏块，将会收到错误

l   EXP工具

对于包含坏块的表执行导出操作，会收到相关的错误信息。对于这种情况，在非归档模式无法通过块恢复修复块的情况下，有如下两种处理方法：

方法1：启用10231事件

通过设置10231诊断事件可以在导出的时候让Oracle忽略表损坏的块，10231是Oracle的内部诊断事件，设置在全表扫描时跳过坏块的数据块，只导出包含正确块的数据，之后把表删除，再把导出的表数据导入新表，从而修复该表。

1）   启用10231诊断事件

SQL> alter system set events=’10231 trace name context forever,level 10’;

2）   禁用10231诊断事件：

SQL> alter system set events=’10231 trace name context forever,level 0’;

方法2：使用DBMS_REPAIR包标记损坏的块。

可以使用DBMS_REPAIR包标记损坏的数据库对象，这样在对损坏的对象执行全表扫描的时候会跳过损坏的块。语法如下：

SQL> exec dbms_repair.skip_corrupt_blocks(‘’,’tablename’);

EXP坏块检查有一定的局限性，不会发现如下类型的坏块：

ü   HWM（高水位线）以上的坏块

ü   索引中存在的坏块

ü   数据字典中存在的坏块

l   Expdp工具

使用expdp工具不会给出坏块的提示，只会将对象正确的数据导出。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29339097/viewspace-1062281/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29339097/viewspace-1062281/