ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-8103错误

ORA-8103错误

原创 Linux操作系统 作者:yangtingkun 时间:2012-04-26 23:22:35 0 删除 编辑

最近碰到两次ORA-8103错误,简单总结一下。

 

 

一次是客户的10.2数据库出现了ORA-600[6002]错误,导致的问题是索引出现了逻辑损坏,本来问题很简单,只需要删除索引并重建,或者通过ONLINE REBUILD方式就可以了。但是索引删除后,扫描这张表出现了ORA-8103错误,这说明错误不仅出现在索引上,在数据块上同样存在逻辑错误,从而导致了前面的ORA-600[6002]错误。

第二个问题是11.2.0.2环境中出现的ORA-8103错误,错误发生在统计信息收集过程中:

Fri Mar 30 02:00:00 2012
DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_j000_25932.trc:
ORA-20011: Approximate NDV failed: ORA-08103: object no longer exists

TRACE文件的详细信息内容为:

*** 2012-03-31 14:08:25.269
*** SESSION ID:(485.61983) 2012-03-31 14:08:25.269
*** CLIENT ID:() 2012-03-31 14:08:25.269
*** SERVICE NAME:(SYS$USERS) 2012-03-31 14:08:25.269
*** MODULE NAME:(DBMS_SCHEDULER) 2012-03-31 14:08:25.269
*** ACTION NAME:(ORA$AT_OS_OPT_SY_1501) 2012-03-31 14:08:25.269

----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
skdstdst()+36        call     kgdsdst()            000000000 ? 000000000 ?
                                                   7FFF88CE8488 ? 000000001 ?
                                                   000000001 ? 000000002 ?
ksedst1()+98         call     skdstdst()           000000000 ? 000000000 ?
                                                   7FFF88CE8488 ? 000000001 ?
                                                   000000000 ? 000000002 ?
ksedst()+34          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFF88CE8488 ? 000000001 ?
                                                   000000000 ? 000000002 ?
kteinmap1()+4287     call     ksedst()             000000000 ? 000000001 ?
                                                   7FFF88CE8488 ? 000000001 ?
                                                   000000000 ? 000000002 ?
kteinmap()+6         call     kteinmap1()          2B55FE027010 ? 000000014 ?
                                                   7FFF88CE8488 ? 000000001 ?
                                                   000000000 ? 000000002 ?
kdselget()+13        call     kteinmap()           2B55FE027010 ? 000000014 ?
                                                   7FFF88CE8488 ? 000000001 ?
                                                   000000000 ? 000000002 ?
kdstsnb()+644        call     kdselget()           2B55FE027010 ? 000000014 ?
                                                   7FFF88CE8488 ? 000000001 ?
                                                   000000000 ? 000000002 ?
kdst_fetch()+234     call     kdstsnb()            2B55FE026E08 ? 000000014 ?
                                                   7FFF88CE8488 ? 000000001 ?
                                                   000000000 ? 000000002 ?
kdstf00001010000km(  call     kdst_fetch()         000000001 ? 2B55FE026E08 ?
)+3681                                             7FFF88CED870 ? 000000000 ?
                                                   000000000 ? 000000002 ?
kdsttgr()+110246     call     kdstf00001010000km(  000000032 ? 000000000 ?
                              )                    7FFF88CED870 ? 2B55FE026CF0 ?
                                                   008FD6CF8 ? 000000002 ?
qertbFetch()+2023    call     kdsttgr()            2B55FE026E08 ? 000000000 ?
                                                   96C2800B8 ? 2B55FE026CF0 ?
                                                   96C280128 ? 008FD6CF8 ?
qerandvFetch()+153   call     qertbFetch()         96C2800B8 ? 2B55FE026CF0 ?
                                                   008FD6CF8 ? 7FFF88CEE0D0 ?
                                                   100007FFF ? 2B55FE026D38 ?
qergsFetch()+821     call     qerandvFetch()       96B765418 ? 2B55FE027630 ?
                                                   008E6EDAE ? 7FFF88CEE1E0 ?
                                                   000007FFF ? 2B55FE026D38 ?
.
.
.
******************* End of process map dump ************

*** 2012-03-31 14:08:29.159
ORA-20011: Approximate NDV failed: ORA-08103: object no longer exists

*** 2012-03-31 14:08:29.159

DBMS_STATS: GATHER_STATS_JOB: GATHER_TABLE_STATS('"MMS"','"DBMS_TABCOMP_TEMP_UNCMP"','""', ...)

DBMS_STATS: ORA-20011: Approximate NDV failed: ORA-08103: object no longer exists

导致问题的原因在于收集一张表的统计信息。

其实这两次碰到的ORA-8103问题相差不多,基本上都是表中存在逻辑坏块导致问题的产生。导致这个错误出现的原因是,Oracle根据块头的定位到一个数据块,但是发现这个数据块出现逻辑错误,可能是当前块的类型没有被标记为数据块,也有可能是当前块的DATA_OBJECT_ID存在错误。

如果这个报错发生在索引上,那么非常简单,只需要ONLINE REBUILD索引,或者将索引删除后重建即可。

当前碰到的两次错误,问题都发生在表上。那么在尝试解决问题之前,应该首先清除DB_CACHE,防止是内存中的错误导致问题的产生。

如果问题依旧,如果存在合适的备份可以进行恢复。比如通过RMANBLOCKRECOVER或者通过一个最新的逻辑备份进行恢复。

如果没有备份,则可以考虑利用DBMS_REPAIR包,将错误的BLOCK设置标识,防止随后的查询读取该BLOCK。如果想要直接读取,也可以考虑利用PL/SQL的方式将错误块以外的记录读出来。

关于ORA-8103错误,在MOS文档上ORA-8103 "object no longer exists" / Troubleshooting, Diagnostic and Solution [ID 8103.1]有非常详细的问题诊断和解决的错误,可以进行参考。

 

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

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10389434