亲历数据仓库ORA-01578:ORACLE data block corrupted错误的处理过程

环境介绍：某数据仓库，数据大小约40Tb，exdata,linux ,oracle 11.2.0.4 rac 数据版本 
问题描述：上周五完成从生产rman恢复到该环境，周三客户应用人员反映执行批处理时提示错误，错误日志如下：

1. ERROR at line 1:
   
2. ORA-12801:error signaled in parallel query server P073,instance
   
3. edw3db01***************************
   
4. ORA-01578：ORACLE data block corrupted (file# 29,block # 23563007)
   
5. ORA-27616:ASM Allocation Unit:175144
   
6. ORA-01110:data file 29: '+DATA_EDW3/edw/datafile/tbs_iml_h.416.3333221113';

而错误的报错点是一条insert 语句： INSERT /*append */ INTO VT_CM_PT_CORP_CUST_PFMC_03 nologging * 。
查询alert 日志，发现从周日开始就开始报ORA-01578错误，统计了一下，该错误一共被触发了好几十次 ，所有的错误都在提示在29号数据文件上，而该文件是bigfile ，大小约2.8T左右 。这下不好玩了。

问题解决过程：
上午接近下班，客户丢来问题，由于没怎么处理过这样的问题，我只能先进行查看，中午主要对alert 日志，坏块的对象进行查看，
客户说，可以打电话给oracle 400,于是下午打了oracle 400,那边的工程师回了几封邮件，丢来了一大堆要采集的信息，一整下午反而浪费时间在收集信息上了，唉，人家的服务流程咱也不好评价。
刚好下午有另个负责其他的oracle 原厂工程师在现场，但那位工程师处理这样案例的经验应该不多，建议使用  rman 的recoverblock 进行恢复，但此方法不生效。
现在详述过程：
14：38分
将错误问题发给oracle 服务邮箱，并致电400服务电话，简单与那边工程师描述，那边反馈需要采集信息，详细邮邮件回复。

大约20分钟之后 
邮件回复，于是根据其采集相关信息，其中主要是 1.dbv 2.rman backup check validate 3.analyze table 4.exdata cell 两个节点相关信息，（因为在邮件中我也将 ora-27603，ora-27626 exdata 相关io错误也描述了） 5.数据库节点主机信息等 6.alert 日志中报错生成的trace 文件。

以上做dbv 是一直得到的结果都是0，后来花时间测试一个小点的文件，可以得到结果，难道是因为该数据文件太大无法dbv？
做完以上回邮件大约花费了一个小时。

16：00左右
以上提到的  在现场的oracle 原厂工程师一堆查，都一直未动手。

16：20左右    
准备使用list failure，advise failure; repair failure; 进行修复，  却在list failure 时提示了该操作无法在RAC下使用，于是放弃这种方法。

17：00左右                                                                                                                                            
 ORACLE原厂工程师，说可以使用 recoverblock 进行恢复，但最好是等400电话的工程师确认，但400那边的工程师一直未给出建议，于是就直接采用该方法了。

1. set linesize 200
   
2. select * from v$database_block_corruption;
   
3. 
   
4. rman target /
   
5. 
   
6. run{
   
7.     allocate channel d1 type disk;
   
8.     backup check logical validate datafile 29;
   
9.     release channel d1;
   
10. };
    
11. 
    
12. select * from v$database_block_corruption;

检测出了 478处坏块。。
选择一个块进行recoverblock

1. rman target /
   
2. RMAN> blockrecover datafile 29 block 23563007;

1. set linesize 100;
   
2. set pagesize 9999;
   
3. col owner for a10;
   
4. col segment_name for a30;
   
5. col segment_type for a15;
   
6. col tablespace_name for a20;
   
7. alter session force parallel query parallel 32;
   
8. select owner,segment_name,segemnt_type,tablespace_name from dba_extents where file_id=29 and 23563007 between block_id and block_id+blocks-1;
   
9. 
   
10. analyze table IML.XXXXXX validate structure;

对表进行alalyze 时 仍提示ora-01578错误，而且损坏的块号仍是   23563007 ；                                                               

rman 下使用 blockrecover corruption list 进行全部恢复，不到一秒结束，只提示使用介质恢复，仍然无法修复。此时花了一段时间，在查rman 为何无法调用备份集，难道是之前 使用了catelog start wit导致的？
后来这种方法也放弃了。

现场的oracle 原厂工程师因今天过来因为是负责其他事的，临时被我们拉过来处理的，现在着急着走，值得尊重的是，他走了又折返还是不放心这边，但最后走了仍未解决问题。400电话那边oracle 工程师仍未回复便不了了之。

直到晚上8：00，想到了另一种方法就是先设置事件 SQL> alter system set events='10231 trace name context forever,level 10';      使用数据泵 跳过坏块将 相关的表导出，之后删除表再导回去，这样的问题就是可能会丢失一些数据，由于现在还只是演练环境，所以丢失也没办法，将此方法发邮件回复应用人员，准备第二天再看，但那边催得紧，回复是否可以从生产。我们回复可以，便决定从生产导出表再导入。

此时我已经准备脚本查询478个坏块相对应的对象，只是查询 

1. select owner,segment_name,segemnt_type,tablespace_name from dba_extents where file_id=29 and 23563007 between block_id and block_id+blocks-1;

非常慢，于是采用 create  table  as select ****重建一个表，建上索引，很快就将结果查出了。
一共是 73个表有坏块。

查询完，晚上九点多，便去吃晚饭，其间是各种电话以及牢骚，当然电话是打给客户的。

大约22：00
便开始整理 数据泵导出脚本，这七十三张表还好只有 200多GB。    

整理完约23：00,便到生产环境操作区进行导出，这里的生产主机和演练主机都挂着同一个NFS，导出是一个相对顺利的过程，由于数据量也不多，大约不大一个小时便导出了一部分表（我们是分每20张表分开导出）。

凌晨12：00之后便开始实施导入工作 ，其间比较不顺利的是 导入时一直提示 ORA-39002: invalid operation
ORA-39070: Unable to open the log file. 错误，此时发现 演练主机这边的该NFS无论怎么授权都只有 read-only权限，即使导入时去掉logfile项也同样提示该问题，于是果断将 dmp文件 拷贝到本地文件系统，扩充了本地文件系统空间开始进行导入，直到凌晨4点多，数据泵导入差基本完成。对其中已导入的表做analyze，可以正常分析，  再做 坏块检测，便先去睡觉了。


早上6点多 ，查询检测结果，发现仍然是478处坏块，但根据坏块去查对象时，并未查到对象，就是说原来的坏块仍然存在，只是现在是空的数据块。我担心是我未将表删除干净，于是 清空回收站 purge dba_recyclebin;再次跑了检测脚本。此时已经非常疲惫，已经能确保不影响明天的业务了，便无心无力做其他操作，便回去大睡一天。


后记：此次产生这边多坏块可能是应 nologging操作引起。因为是数据仓库，开发人员习惯性在操作都加上nologging以防止产生太多归档。
                                                                                                                                                                                                                                                                                                                                                                                                                            

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

转载于:http://blog.itpub.net/29863023/viewspace-1784981/