收到业务反馈，查看erp请求时遇到报错，一看居然是坏块。。。-_-||

Oracle 常规坏块处理方法_数据库

 alert日志中也出现相关报错，但还好只有一个坏块

Oracle 常规坏块处理方法_database_02

一、 有备份的处理方法

这一般就非常简单，rman有坏块修复功能

Recover datafile 19 block 44;

如有必要，可同时修复多个文件多个块

Recover
datafile 19 block 44
datafile 19 block 43
datafile 18 block 44,66,150;

二、 无备份的处理方法

因为出问题的是个uat环境，没有备份，所以rman我们用不了。

1. 查看坏块发生的位置

-- 其中48为文件号，2454391为块号
select /*+ parallel(t,8)*/* from dba_extents t where file_id=48 and 2454391 between block_id and block_id+blocks-1;
  • 如果发生在索引，运气不错，删掉重建就好
  • 发生在表，运气一般般，还能跳过
  • 发生在段头等特殊位置，悲剧，常规方法救不了

我们遇到的情况是坏块发生在业务表上。但特殊的点在于，这个表是erp的并发请求基表，上面有大量依赖对象和触发器，不敢重建，只能跳过数据。

并且测试发现，读写操作如果不涉及到坏块就能正常进行，如果读或者写到坏块上，就会报错。

Oracle 常规坏块处理方法_处理方法_03

2. SKIP_CORRUPT_BLOCKS

跳过坏块的原理是给坏块打上标记，以后select就跳过坏块中的数据，导致的后果就是坏块内的数据会全部丢失。

execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('用户名','表名');

跳过坏块之后，你会发现全表扫描已经不会报错。常规的做法是把表中数据导出再重新导入，重建下这个表。

create table orasup_fnd_concurrent_requests as select * from applsys.fnd_concurrent_requests;

但由于erp基表不敢重建，你会发现有个小问题：count的行数比直接查询的行数要多10行，那10行其实就是被标记的坏块里的数据，已经丢失了。

Oracle 常规坏块处理方法_数据库_04

3. move坏块表

skip之后虽然查询不报错了，但如果insert数据刚好插入到坏块，还是会遇到报错

Oracle 常规坏块处理方法_database_05

Oracle 常规坏块处理方法_数据库_06

 查看里面的trace文件发现是个insert语句

于是我们尝试move表，把表放到其他位置，远离坏块。由于问题表是erp基表，操作非常频繁，而move操作会锁表（11g），因此必须要停下业务操作。另外注意11g move表之后索引会失效，需要重建。

alter table t move tablespace tbs1;

move之后，业务暂时没反馈有报错了。

参考

https://blogs.oracle.com/database4cn/oraclecorruption-