老熊的三分地-Oracle及数据恢复

某客户的一个表在进行分析和建索引一段时间时，均报ORA-8103错误。

让我们先看看ORA-8103错误是个什么样的错误？

[oracle@xty ~]$ oerr ora 8103
08103, 00000, "object no longer exists"
// *Cause: The object has been deleted by another user since the operation
// began, or a prior incomplete recovery restored the database to
// a point in time during the deletion of the object.
// *Action: Delete the object if this is the result of an incomplete
// recovery.

从上面的信息来看，引起这个错误的并不是由于什么对象被删除或者不完全恢复引起的。看来剩下的可能就是BUG或者是坏块了。

select /*+ parallel(a 6) no_index(a) */
count(lrrq) from hz2004.HJXX_RYZPXXB a

由于表很大，100g左右，因此等了好长一段时间，就报了ORA-8103错误。由于不同的SQL语句（建索引、分析表和查询表数据）都报了这个错误，基本可以确定是坏块引起的问题。

由于表中有long raw类型，因此不能通过从主键取得ROWID再根据ROWID读到值以后插入新表，由于查询表有问题，导出也不会成功。因此决定想办法来修复这个问题：

首先要确定是哪个块出现问题：

SQL> alter session set max_dump_file_size=unlimited;
SQL> alter session set db_file_multiblock_read_count=1;
SQL> alter session set events ‘immediate trace name trace_buffer_on level 1048576′;
SQL> alter session set events ‘10200 trace name context forever, level 1′;
SQL> select /*+ no_index(a */ count(*) from hz2004.hjxx_ryzpxxb a;

（注：经测试，在10g中，需要去掉trace_buffer_on那一个语句才会有trace，否则没有trace文件）
再次报错时，检查trace文件，发现如下的信息：

Consistent read started for block 11 : 09c63a9e
env: (scn: 0×0886.245ea878 xid: 0×0000.000.00000000
uba: 0×00000000.0000.00 statement num=0 parent xid:
xid: 0×0000.000.00000000
scn: 0×0000.00000000 0sch: scn: 0×0000.00000000)

从trace文件中可以发现在读文件号39块号408222时报错。

执行：

select * from hz2004.hjxx_ryzpxxb
where rowid=dbms_rowid.rowid_create(1,7415,39,408222,0);

报ORA-08103错误，可以确认是39号文件408222块坏。

然而用dbv命令检查39号文件，没有发现坏块。

通过dd取出39号文件408222块，发现该块居然是一个未格式化的块，但是该块在表的High water mark以下。单从该块来说是一个好的块，所以dbv检查并不会报坏块。

既然如此，我就故意做成一个坏块，然后让oracle跳过这个坏块。关闭库之后，用dd把坏块复制出来保存在一个文件，然后修改该块，使之成为一个坏块（很多的方法，这里我的方法就是修改其checksum值）。然后用dd复制回去。重启库之后，用 dbms_repair.skip_corrupt_blocks过程设置表在读取数据时，跳过坏块。

再次读取该表的所有数据，不再报错。

客户进行建索引和分析时也不再报错，顺利进行。

当然后续的工作，还是需要将数据导出来再导入，这样更稳妥。