删除表空间报错ORA-600(ktssdrp1)错误
删除表空间报错ORA-600(ktssdrp1)错误
测试环境的新建表空间在删除时报错。
数据库创建一个新的表空间后执行删除，出现了ORA-600的错误信息：
SQL>SELECTtablespace_nameFROMdba_tablespaces;
TABLESPACE_NAME------------------------------SYSTEM
UNDOTBS
SYSAUX
TEMP
TBS_1
GGX
USERS
PERFSTAT
STATSPACK
ALA_TEST10ROWSselected.SQL>DROPtablespace ala_test including contentsANDdatafiles;DROPtablespace ala_test including contentsANDdatafiles*ERROR at line1:
ORA-00600: internal error code,arguments:[ktssdrp1],[9],[13],[11],[],[],[],[]错误信息为：
Tue Mar1318:11:14CST2012DROPtablespace ala_test including contentsANDdatafiles
Tue Mar1318:11:14CST2012ErrorsINfile/u01/app/Oracle/admin/orcl10g/udump/orcl10g_ora_7838.trc:
ORA-00600: internal error code,arguments:[ktssdrp1],[9],[13],[11],[],[],[],[]Tue Mar1318:11:18CST2012ORA-600signalled during:DROPtablespace ala_test including contentsANDdatafiles...详细信息为：
Dump file/u01/app/oracle/admin/orcl10g/udump/orcl10g_ora_7838.trc
OracleDATABASE10g Enterprise Edition Release 10.2.0.5.0-64bit ProductionWITHthe Partitioning,OLAP,DATAMiningANDREALApplication Testing options
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
System name: Linux
Node name: hpserver2.enmotech.com
Release: 2.6.32-100.28.5.el6.x86_64
Version: #1SMP Wed Feb218:40:23EST2011Machine: x86_64
Instance name: orcl10g
Redo thread mountedBYthis instance:1Oracle processNUMBER:13Unix process pid:7838,image: oracle@hpserver2.enmotech.com(TNS V1-V3)***ACTION NAME:()2012-03-1318:11:14.802***MODULE NAME:(sqlplus@hpserver2.enmotech.com(TNS V1-V3))2012-03-1318:11:14.802***SERVICE NAME:(SYS$USERS)2012-03-1318:11:14.802***SESSIONID:(30.124)2012-03-1318:11:14.802***2012-03-1318:11:14.802ksedmp: internalORfatal error
ORA-00600: internal error code,arguments:[ktssdrp1],[9],[13],[11],[],[],[],[]CURRENTSQLstatementFORthisSESSION:DROPTABLE"APP"."SERVICE"cascade constraints purge----- Call Stack Trace -----callingCALLentry argumentVALUESINhex
locationTYPEpoint(? means dubiousVALUE)-------------------- -------- -------------------- ----------------------------ssd_unwind_bp: unhandled instruction at 0x3d12d3e instr=f
ssd_unwind_bp: unhandled instruction at 0x1344b61 instr=f
ksedst()+31CALLksedst1()000000000 ? 000000001 ?
7FFFA35C05C0 ? 7FFFA35C0620 ?
7FFFA35C0560 ? 000000000 ?
ksedmp()+610CALLksedst()000000000 ? 000000001 ?
7FFFA35C05C0 ? 7FFFA35C0620 ?
7FFFA35C0560 ? 000000000 ?
ksfdmp()+63CALLksedmp()000000003 ? 000000001 ?
7FFFA35C05C0 ? 7FFFA35C0620 ?
7FFFA35C0560 ? 000000000 ?
kgerinv()+161CALLksfdmp()006AE9A40 ? 000000003 ?
7FFFA35C05C0 ? 7FFFA35C0620 ?
7FFFA35C0560 ? 000000000 ?
kgeasnmierr()+163CALLkgerinv()006AE9A40 ? 008754D28 ?
7FFFA35C0620 ? 7FFFA35C0560 ?
000000000 ? 000000000 ?
ktssdrp_segment()+2CALLkgeasnmierr()006AE9A40 ? 008754D28 ?2897FFFA35C0620 ? 7FFFA35C0560 ?
000000000 ? 000000009 ?
dtbdrp()+1736CALLktssdrp_segment()7FFFA35C2998 ? 008754D28 ?
7FFFA35C0620 ? 7FFFA35C0560 ?
000000000 ? 000000009 ?
dtbdrv()+2732CALLdtbdrp()7FFFA35C2998 ? 0779C1148 ?
074FB4318 ? 7FFFA35C2CB0 ?
000000000 ? 7FFFA35C2CE8 ?
opiexe()+13175CALLdtbdrv()7FFFA35C2998 ? 0779C1148 ?
000000000 ? 7FFFA35C2CB0 ?
000000000 ? 7FFFA35C2CE8 ?
opiosq0()+3398CALLopiexe()000000004 ? 000000000 ?
7FFFA35C3F2C ? 000000005 ?
000000000 ? 7FFFA35C2CE8 ?
opiosq()+14CALLopiosq0()000000003 ? 00000000F ?
7FFFA35C5600 ? 000000000 ?
000000000 ? 000000041 ?
opiodr()+1184CALLopiosq()000000003 ? 00000000F ?
7FFFA35C5600 ? 000000000 ?
000000000 ? 000000041 ?
ssd_unwind_bp: unhandled instruction at 0x24168a7 instr=f
rpidrus()+196CALLopiodr()00000004A ? 00000000F ?
7FFFA35C5600 ? 000000005 ?
005BEBA90 ? 000000041 ?
skgmstack()+158CALLrpidrus()7FFFA35C4E58 ? 00000000F ?
7FFFA35C5600 ? 000000005 ?
005BEBA90 ? 000000041 ?
rpidru()+116CALLskgmstack()7FFFA35C4E30 ? 006AE9620 ?
00000F618 ? 002419628 ?
7FFFA35C4E58 ? 000000041 ?
rpiswu2()+409CALLrpidru()7FFFA35C54F8 ? 006AE9620 ?
00000F618 ? 002419628 ?
7FFFA35C4E58 ? 000000041 ?
rpidrv()+1516CALLrpiswu2()07F1AEA58 ? 000000000 ?
7FFFA35C54D8 ? 000000002 ?
7FFFA35C5540 ? 000000000 ?
rpispl()+406CALLrpidrv()000000005 ? 00000004A ?
7FFFA35C5600 ? 000000008 ?
7FFFA35C5540 ? 000000000 ?
tbsdrac()+4341CALLrpispl()000000005 ? 000000000 ?
0087315C0 ? 000000041 ?
000000000 ? 000000000 ?
dtsdrv()+2882CALLtbsdrac()000000009 ? 000000000 ?
000000000 ? 000000001 ?
000000000 ? 000000000 ?
opiexe()+14347CALLdtsdrv()000000009 ? 000000000 ?
000000000 ? 000000001 ?
000000000 ? 000000000 ?
opiosq0()+3398CALLopiexe()000000004 ? 000000000 ?
7FFFA35C7B3C ? 000000002 ?
000000000 ? 000000000 ?
kpooprx()+318CALLopiosq0()000000003 ? 00000000E ?
7FFFA35C7E68 ? 0000000A4 ?
000000000 ?600000039?
kpoal8()+783CALLkpooprx()7FFFA35CB04C ? 7FFFA35C9078 ?
000000039 ? 000000001 ?
000000000 ?600000039?
opiodr()+1184CALLkpoal8()00000005E ? 000000017 ?
7FFFA35CB048 ? 000000001 ?
000000001 ?600000039?
ttcpip()+1226CALLopiodr()00000005E ? 000000017 ?
7FFFA35CB048 ? 000000000 ?
005BEBDB0 ?600000039?
opitsk()+1310CALLttcpip()006AF1FD0 ? 0054A67A0 ?
7FFFA35CB048 ? 000000000 ?
7FFFA35CAB48 ? 7FFFA35CB1B0 ?
opiino()+1024CALLopitsk()000000003 ? 000000000 ?
7FFFA35CB048 ? 000000001 ?
000000000 ? 6AF000900000001 ?
opiodr()+1184CALLopiino()00000003C ? 000000004 ?
7FFFA35CC248 ? 000000001 ?
000000000 ? 6AF000900000001 ?
opidrv()+548CALLopiodr()00000003C ? 000000004 ?
7FFFA35CC248 ? 000000000 ?
005BEB860 ? 6AF000900000001 ?
sou2o()+114CALLopidrv()00000003C ? 000000004 ?
7FFFA35CC248 ? 000000000 ?
005BEB860 ? 6AF000900000001 ?
opimai_real()+163CALLsou2o()7FFFA35CC220 ? 00000003C ?
000000004 ? 7FFFA35CC248 ?
005BEB860 ? 6AF000900000001 ?
main()+116CALLopimai_real()000000002 ? 7FFFA35CC2B0 ?
000000004 ? 7FFFA35CC248 ?
005BEB860 ? 6AF000900000001 ?
__libc_start_main()CALLmain()000000002 ? 7FFFA35CC2B0 ?+253000000004 ? 7FFFA35CC248 ?
005BEB860 ? 6AF000900000001 ?
_start()+41CALL__libc_start_main()00072D134 ? 000000002 ?
7FFFA35CC408 ? 000000000 ?
005BEB860 ? 6AF000900000001 ?--------------------- Binary Stack Dump ---------------------可以看到，报错发生在删除一个表上。而这个表在数据库中应该是不存在的，或者说即使这个表存在，也不可能建立在这个表空间。那么导致问题的原因应该只有一个，数据字典出现了不一致的状态。
SQL>SELECTts#,COUNT(*)FROMseg$GROUPBYts#;
TS#COUNT(*)---------- ----------1116202112645755014296ROWSselected.SQL>SELECTts#,COUNT(*)FROMtab$GROUPBYts#;
TS#COUNT(*)---------- ----------6429119722475544883072073691012210ROWSselected.可以看到，在SEG$中不存在表空间编号大于6的对象，但是在TAB$中确存在很多。
SQL>SELECTts#,nameFROMts$WHEREname='ALA_TEST';
TS# NAME---------- ------------------------------9ALA_TEST
SQL>SELECTts#,nameFROMts$;
TS# NAME---------- ------------------------------0SYSTEM1UNDOTBS2SYSAUX3TEMP4TBS_15GGX6USERS7PERFSTAT8STATSPACK9ALA_TEST10ROWSselected.可以看到，表空间目前编号只到9，而TAB$中记录的表空间的编号以及到了12。显然这就是导致ORA-600错误的原因。Oracle在删除表空间的时候发现有表存在，但是根据段信息又找不到对应的记录，导致删除无法完成，从而引发了这个错误。
至于数据字典不一致的产生应该是测试环境通过imp导入tab$引起的，对于测试环境而言，这个错误很容易清除掉，直接删除不一致的记录即可，但是对于产品环境而言，不推荐这种方式：
SQL>SELECTts#,COUNT(*)FROMind$GROUPBYts#;
TS#COUNT(*)---------- ----------623911611310323324983108587ROWSselected.SQL>DELETEtab$WHEREts#=9;10ROWSdeleted.SQL>commit;
Commit complete.SQL>DROPtablespace ala_test including contentsANDdatafiles;
Tablespace dropped.
评论暂时关闭