ORA-600(ktecgeb-2)错误

还是一个ORA-600错误，这个错误出现在10.2环境中。

 

 

客户的DATA GUARD环境中的物理备库，由于要进行测试，因此设置了FLASHBACK ON，创建了恢复点，然后激活成主库并打开，准备进行测试，但是发现在后台告警日志中出现了这个错误，详细的错误信息如下：

Completed: ALTER DATABASE OPEN
Wed Oct 26 22:08:27 2011
Errors in file /oracle/admin/standdb/bdump/standdb_j003_446902.trc:
ORA-00600: internal error code, arguments: [ktecgeb-2], [788585233], [0], [], [], [], [], []
Wed Oct 26 22:08:33 2011
Errors in file /oracle/admin/standdb/bdump/standdb_j003_446902.trc:
ORA-00600: internal error code, arguments: [ORA-00600: internal error code, arguments: [ktecgeb-2], [788585233], [0], [], [], [], [], []
ORA-06512: at "SYS.PRVT_ADVISOR", line 1624
ORA-06512: at "SYS.DBMS_ADVISOR", line 186
ORA-06512: at "SYS.DBMS_SPACE", line 1500
ORA-06512: at "SYS.DBMS_SPACE", line 1566
], [], [], [], [], [], [], []

显然导致错误产生的原因是后台JOB的运行，而这个JOB跑的任务是检查对象空间使用情况。继续检查详细TRACE信息：

oracle@srv4:/oracle/admin/standdb/bdump/more /oracle/admin/standdb/bdump/standdb_j003_446902.trc
/oracle/admin/standdb/bdump/standdb_j003_446902.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/product/db10gr2
System name:    AIX
Node name:      srv4
Release:        3
Version:        5
Machine:        0055053E4C00
Instance name: standdb
Redo thread mounted by this instance: 1
Oracle process number: 20
Unix process pid: 446902, image: oracle@srv4 (J003)

*** ACTION NAME:(AUTO_SPACE_ADVISOR_JOB) 2011-10-26 22:08:27.409
*** MODULE NAME:(DBMS_SCHEDULER) 2011-10-26 22:08:27.409
*** SERVICE NAME:(SYS$USERS) 2011-10-26 22:08:27.409
*** SESSION ID:(1081.3) 2011-10-26 22:08:27.409
*** 2011-10-26 22:08:27.409
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ktecgeb-2], [788585233], [0], [], [], [], [], []
Current SQL statement for this session:
SELECT STATUS FROM TABLE( DBMS_SPACE.VERIFY_SHRINK_CANDIDATE_TBF( :B1 , :B2 , :B3 , :B4 , :B5 ))
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
700000243900620      1788  package body SYS.DBMS_SPACE
700000243900620      1806  package body SYS.DBMS_SPACE
700000242c6dc98         1  anonymous block
700000242ea5808      1698  SYS.WRI$_ADV_OBJSPACE_TREND_T
700000242fce6c0      1535  package body SYS.PRVT_ADVISOR
700000242fce6c0      1618  package body SYS.PRVT_ADVISOR
700000242fed300       186  package body SYS.DBMS_ADVISOR
700000243900620      1500  package body SYS.DBMS_SPACE
700000243900620      1566  package body SYS.DBMS_SPACE
----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
ksedst+001c          bl       ksedst1              000000000 ? FFFFFFFFFFE5C14 ?
ksedmp+0290          bl       ksedst               104A557A8 ?
ksfdmp+0018          bl       03F4CD24            
kgerinv+00dc         bl       _ptrgl              
kgeasnmierr+004c     bl       kgerinv              000000000 ? FFFFFFFFFFE67D0 ?
                                                   FFFFFFFFFFE6328 ? 02F00DB14 ?
                                                   FFFFFFFFFFE6250 ?
ktecgeb+01bc         bl       kgeasnmierr          1101957F8 ? 1104C40E0 ?
                                                   104D81670 ? 200000002 ?
                                                   000000000 ? 02F00DB11 ?
                                                   000000000 ? 000000000 ?
kteinlast+01b4       bl       ktecgeb              104D816C0 ? 104D816B0 ?
                                                   104D816A0 ? 104D81698 ?
ktsa_verify_shrink_  bl       kteinlast            FFFFFFFFFFE6730 ?
candidate+02f4                                     FFFFFFFFFFE6780 ? 100000000 ?
                                                   700000242C6DC98 ?
ktsaps_verify_shrin  bl       ktsa_verify_shrink_  FFFFFFFFFFE6730 ?
k_candidate+0418              candidate            FFFFFFFFFFE6780 ? 110195978 ?
                                                   02D8C0274 ? 700000242C6DC98 ?
pevm_icd_call_commo  bl       _ptrgl              
n+03f8                                            
pfrinstr_ICAL+00c8   bl       pevm_icd_call_commo  1109064B0 ? 000000000 ?
                              n                    1438BD4EF ? 6000000000000 ?
                                                   6000000000008 ? 0FFFE70A0 ?
                                                   110900230 ?
pfrrun_no_tool+005c  bl       _ptrgl              
pfrrun+1014          bl       pfrrun_no_tool       FFFFFFFFFFE70C0 ?
                                                   7000002421FC0E8 ?
                                                   7000002421FC0E8 ?
plsql_run+06b4       bl       pfrrun               1109064B0 ?
peicnt+0224          bl       plsql_run            1109064B0 ? 100007FFFFFFF ?
                                                   000000000 ?
kkxuexe+0360         bl       peicnt               1108BC3B8 ? 1109064B0 ?
kkxmpsexe+029c       bl       03F4AB20            
kgmexwi+056c         bl       _ptrgl              
kgmexec+0bcc         bl       kgmexwi              1101957F8 ? 000000000 ?
                                                   FFFFFFFFFFE9320 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   07FFFFFF8 ? 000000000 ?

从TRACE文件不难看出，Oracle在验证数据文件是否空间收缩的候选对象时报错。根据metalink记录的bug，并没有和当前现象吻合的记录，不过大部分问题都与ASSM管理表空间有关。

对于这个错误而言，对于备库可以简单的忽略，对于引起错误的JOB也可以停用，但是这个错误反映出备库的状态不正常，因此这个备库作为主库的备份是不安全的，应该通过DBV之类的工具检查数据文件是否存在坏块，建议对报错的数据文件重新从主库获取COPY，来避免坏块或逻辑错误的隐患。

 

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

转载于:http://blog.itpub.net/4227/viewspace-709933/