ORA-01410故障的解决---摘抄

 

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

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

ORA-01410错误通常见于通过索引访问表,而索引或表由逻辑上的损坏。而这里显示没有通过索引访问表?那问题出在哪里呢?在这种情况下,这个错误与ORA-08103极其类似,参照《记一次ORA-8103错误的处理》:
   
    14:27:00 SQL> alter session set max_dump_file_size=unlimited;  
     
    Session altered.  
   
    14:27:18 SQL> alter session set db_file_multiblock_read_count=1;  
     
    Session altered.  

    14:27:18 SQL> alter session set events 'immediate trace name trace_buffer_on level 1048576';  
     
    Session altered.  

    14:27:18 SQL> alter session set events '10200 trace name context forever, level 1';  
     
    Session altered.  
     
    14:27:18 SQL> select /*+ full(a) no_index(a) */ count(*) from crm.cust_order a;  
    ERROR at line 1:  
    ORA-01410: invalid ROWID  
     
    14:33:09 SQL> 14:33:09 SQL> alter session set events 'immediate trace name trace_buffer_off';  
     
    Session altered. 
   
在trace文件的最后,我们可以看到:

    Consistent read started for block 10 : 2489c394  
      env: (scn: 0x0a0d.690ff414  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: xid: 0x0000.000.000000  
    00  scn: 0x0000.00000000 0sch: scn: 0x0000.00000000) 
   
这里只有”start“,而没有finish,表明在读2489c394这个块出了问题。
用ODU工具的rdba查看文件号和坏号:

    ODU> rdba 2489c394  
     
      rdba   : 0x2489c394=613008276  
      rfile# : 146  
      block# : 639892 
   

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

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

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


刷新buffer cache后,问题解决。

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

http://www.laoxiong.net/ora-01410-problem-resolved.html

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

转载于:http://blog.itpub.net/22878696/viewspace-689500/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值