文档介绍：Oracle 坏块总结收藏 Oracle 数据库出现坏块现象是指:在 Oracle 数据库的一个或多个数据块(一个数据块的容量在创建数据库时由 db_block_size 参数指定, 缺省为 8K ) 内出现内容混乱的现象。由于正常的数据块都有固定的合法内容格式, 坏块的出现, 导致数据库进程无法正常解析数据块的内容,进而使数据库进程报错乃至挂起,并级联导致整个数据库实例出现异常。: 硬件问题 Oracle 进程在处理一个数据块时, 首先将其读入物理内存空间, 在处理完成后, 再由特定进程将其写回磁盘;如果在这个过程中,出现内存故障, CPU 计算失误,都会导致内存数据块的内容混乱,最后反映到写回磁盘的数据块内容有误。同样,如果存储子系统出现异常, 数据块损坏也就随之出现了。操作系统 BUG 由于 Oracle 进程对数据块的读写,都是以操作系统内核调用( system call )的方式完成的, 如果操作系统在内核调用存在问题,必然导致 Oracle 进程写入非法的内容。操作系统的 I/O 错误或缓冲问题内存或 paging 问题 Oracle 软件 BUG Oracle 软件特定版本上,可能出现导致数据块的内容出现异常 BUG 。非 Oracle 进程扰乱 Oracle 共享内存区域如上文所述, 在当数据块的内容被读入主机的物理内存时, 如果其他非 Oracl e 进程,对 Oracl e 使用的共享内存区域形成了扰乱,最终导致写回磁盘的数据块内容混乱。异常关机,掉电,终止服务异常关机,掉电,终止服务使进程异常终止,而破坏数据块的完整性,导致坏块产生。注:这也是为什么突然断电会导致数据库无法启动由上可见, 坏块的形成原因复杂。当出现坏块时, 为了找到确切的原因, 需要大量的分析时间和排查操作, 甚至需要多次重现才能找出根本原因。但当故障发生在生产系统上, 我们为了减少停机时间,会尽快实施应急权变措施以保证系统的可用性,这样就破坏了故障现场, 对根本原因的分析因而也更加困难了。,但并非不可预防。在 Metalink. 网站, Oracle 定期发布基于特定软件版本的“已知问题(known issues) 说明”。对于可能导致坏块的 Oracle 软件 BUG ,在 Oracle 公司内部, 是作为高严重级别的问题进行处理,在“已知问题(known issues) 说明”中,这些 BUG 以严重( Noticable ) 问题标出( 标记为*或+) ,部分问题, Oracle 还会发布警告(Alert) 通告。在文档中, Oracle 会提供相应的补丁或应对措施。 Oracle 提供备份恢复工具- Recovery Manager ,提供了扫描文件检查坏块的功能。在 Recovery Manager 界面中,使用: RMAN> BACKUP CHECK LOGICAL VALIDATE DATAFILE n; 可以检查数据文件是否包含坏块,同时并不产生实际的备份输出。 Dbv 工具检查注:因为 dbv 要求 file 后面跟的必须是一个文件扩展名,所以如果用裸设备存储的,就必须使用 ln 链接裸设备到一个文件,然后再用 dbv 对这个链接文件进行检查。 ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE 它执行坏块的检查,但是不会标记坏块为 corrupt ,检测的结果保存在 USER_DUMP_DES T 目录下的用户 trace 文件中。利用 exp 工具导出整个数据库可以检测坏块对以下情况的坏块是检测不出来的: HWM 以上的坏块是不会发现的索引中存在的坏块是不会发现的数据字典中的坏块是不会发现的结合数据库性能综合考虑 db_block_checksum 和 db_blockchecking 参数。当我们使用 Recovery Manager 进行实际的数据库备份时,同时也就进行了坏块检查。但要注意的是,在线使用 Recovery Manager 扫描坏块和备份时,需要数据库运行在归档模式( archive log ) ,否则只能在数据库未打开的情况下进行。对于操作系统问题和硬件故障,则需要相应厂商的配合支持。同时,避免在数据库主机运行其他用户进程,避免异常停机,也会减少坏块发生的几率。,数据库的异常表现通常有: 报告 ORA-01578 错误。报告 Ora-1110 错误。报告 ORA-0060 0 错误, 其中, 第一个参数为 2000-8000 , Cache lay