收到业务反馈，查看erp请求时遇到报错，一看居然是坏块。。。-_-||
alert日志中也出现相关报错，但还好只有一个坏块
一、 有备份的处理方法
这一般就非常简单，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的并发请求基表，上面有大量依赖对象和触发器，不敢重建，只能跳过数据。
并且测试发现，读写操作如果不涉及到坏块就能正常进行，如果读或者写到坏块上，就会报错。
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行其实就是被标记的坏块里的数据，已经丢失了。
3. move坏块表
skip之后虽然查询不报错了，但如果insert数据刚好插入到坏块，还是会遇到报错
查看里面的trace文件发现是个insert语句
于是我们尝试move表，把表放到其他位置，远离坏块。由于问题表是erp基表，操作非常频繁，而move操作会锁表（11g），因此必须要停下业务操作。另外注意11g move表之后索引会失效，需要重建。
alter table t move tablespace tbs1;move之后，业务暂时没反馈有报错了。
参考
