还是一个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，来避免坏块或逻辑错误的隐患。