一次ORA-01410故障的解决

在一个表上建索引时，报ORA-01410错误，我们查询这个表来重现这个错误：

view plain copy to clipboard print ?

1. Connected to:  
2. Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production  
3. With the Partitioning option  
4. JServer Release 9.2.0.6.0 - Production  
5.   
6. SQL> set timing on  
7. SQL> set time on  
8. 14:20:03 SQL> select /*+ full(a) no_index(a) */ count(*) from crm.cust_order a;  
9. select /*+ full(a) no_index(a) */ count(*) from crm.cust_order a  
10.                                                     *  
11. ERROR at line 1:  
12. ORA-01410: invalid ROWID  

ORA-01410错误通常见于通过索引访问表，而索引或表由逻辑上的损坏。而这里显示没有通过索引访问表？那问题出在哪里呢？在这种情况下，这个错误与ORA-08103极其类似，

view plain copy to clipboard print ?

1. 14:27:00 SQL> alter session set max_dump_file_size=unlimited;  
2.   
3. Session altered.  
4.   
5. Elapsed: 00:00:00.01  
6. 14:27:18 SQL> alter session set db_file_multiblock_read_count=1;  
7.   
8. Session altered.  
9.   
10. Elapsed: 00:00:00.00  
11. 14:27:18 SQL> alter session set events 'immediate trace name trace_buffer_on level 1048576';  
12.   
13. Session altered.  
14.   
15. Elapsed: 00:00:00.00  
16. 14:27:18 SQL> alter session set events '10200 trace name context forever, level 1';  
17.   
18. Session altered.  
19.   
20. Elapsed: 00:00:00.00  
21. 14:27:18 SQL> select /*+ full(a) no_index(a) */ count(*) from crm.cust_order a;  
22. ERROR at line 1:  
23. ORA-01410: invalid ROWID  
24.   
25. Elapsed: 00:05:50.82  
26. 14:33:09 SQL> 14:33:09 SQL> alter session set events 'immediate trace name trace_buffer_off';  
27.   
28. Session altered.  

在trace文件的最后，我们可以看到：

view plain copy to clipboard print ?

1. Consistent read started for block 10 : 2489c394  
2.   env: (scn: 0x0a0d.690ff414  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: xid: 0x0000.000.000000  
3. 00  scn: 0x0000.00000000 0sch: scn: 0x0000.00000000)  

这里只有”start“，而没有finish，表明在读2489c394这个块出了问题。
用ODU工具的rdba查看文件号和坏号：

1. ODU> rdba 2489c394  
2.   
3.   rdba   : 0x2489c394=613008276  
4.   rfile# : 146  
5.   block# : 639892  

通过”alter sytem dump datafile 146 block 639892”命令发现块中的object_id与CUST_ORDER表的data object id不同，看起来这就是问题所在（此处不再列出数据）。
看起来有坏块了。不过这个库是个查询库，把表TRUNCATE之后重新从生产库同步过来，发现问题仍然存在，甚至把表DROP之后重建也是如此，均是发生在146/639892这个块上。

而TRUNCATE/DROP表都不能解决问题，显然这个块还在内存中，看起来需要刷新buffer cache了：

view plain copy to clipboard print ?

1. 14:37:07 SQL> alter session set events 'immediate trace name flush_cache level 1';  
2. Session altered.  

刷新buffer cache后，问题解决。

总结：这个问题，与ORA-8103类似，都是出现了逻辑坏块,只不过这次的坏块是发生在内存中的块。至于坏块是怎么进入到内存中，为什么在重建表后还在内存中，这就是个谜了，或者是ORACLE的BUG，或者跟用的同步软件DSG有关。在这个案例中，块的object_id与段的实际的data object id不一致。而object_id不一致有时也会报ORA-600错误。