|
測(cè)試環(huán)境的新建表空間在刪除時(shí)報(bào)錯(cuò)。
數(shù)據(jù)庫(kù)創(chuàng)建一個(gè)新的表空間后執(zhí)行刪除，出現(xiàn)了ORA-600的錯(cuò)誤信息：
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],[],[],[],[]錯(cuò)誤信息為：
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...詳細(xì)信息為：
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 ---------------------可以看到，報(bào)錯(cuò)發(fā)生在刪除一個(gè)表上。而這個(gè)表在數(shù)據(jù)庫(kù)中應(yīng)該是不存在的，或者說(shuō)即使這個(gè)表存在，也不可能建立在這個(gè)表空間。那么導(dǎo)致問題的原因應(yīng)該只有一個(gè)，數(shù)據(jù)字典出現(xiàn)了不一致的狀態(tài)。
SQL>SELECTts#,COUNT(*)FROMseg$GROUPBYts#;
TS#COUNT(*)---------- ----------1116202112645755014296ROWSselected.SQL>SELECTts#,COUNT(*)FROMtab$GROUPBYts#;
TS#COUNT(*)---------- ----------6429119722475544883072073691012210ROWSselected.可以看到，在SEG$中不存在表空間編號(hào)大于6的對(duì)象，但是在TAB$中確存在很多。
SQL>SELECTts#,nameFROMts$WHEREname='ALA_TEST';
TS# NAME---------- ------------------------------9ALA_TEST
SQL>SELECTts#,nameFROMts$;
TS# NAME---------- ------------------------------0SYSTEM1UNDOTBS2SYSAUX3TEMP4TBS_15GGX6USERS7PERFSTAT8STATSPACK9ALA_TEST10ROWSselected.可以看到，表空間目前編號(hào)只到9，而TAB$中記錄的表空間的編號(hào)以及到了12。顯然這就是導(dǎo)致ORA-600錯(cuò)誤的原因。Oracle在刪除表空間的時(shí)候發(fā)現(xiàn)有表存在，但是根據(jù)段信息又找不到對(duì)應(yīng)的記錄，導(dǎo)致刪除無(wú)法完成，從而引發(fā)了這個(gè)錯(cuò)誤。
至于數(shù)據(jù)字典不一致的產(chǎn)生應(yīng)該是測(cè)試環(huán)境通過(guò)imp導(dǎo)入tab$引起的，對(duì)于測(cè)試環(huán)境而言，這個(gè)錯(cuò)誤很容易清除掉，直接刪除不一致的記錄即可，但是對(duì)于產(chǎn)品環(huán)境而言，不推薦這種方式：
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.artduck.net】
服務(wù)器租用/服務(wù)器托管中國(guó)五強(qiáng)！虛擬主機(jī)域名注冊(cè)頂級(jí)提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]
|
0371-60135900
京公網(wǎng)安備41019702002023號(hào)
香港服務(wù)器租用
美國(guó)服務(wù)器租用
電信骨干機(jī)房
聯(lián)通骨干機(jī)房
