|
測試環境的新建表空間在刪除時報錯。
數據庫創建一個新的表空間后執行刪除，出現了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.
本文出自：億恩科技【www.zuiquanben.com】
服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]
|
0371-60135900
京公網安備41019702002023號
香港服務器租用
美國服務器租用
電信骨干機房
聯通骨干機房
