空间ie脚本错误

脚本错误导致的灾难293DBVERIFY-Verificationstarting:FILE=system01.
dbfDBVERIFY-VerificationcompleteTotalPagesExamined:48640TotalPagesProcessed(Data):26289TotalPagesFailing(Data):0TotalPagesProcessed(Index):4211TotalPagesFailing(Index):0TotalPagesProcessed(Other):15284TotalPagesEmpty:2856TotalPagesMarkedCorrupt:0TotalPagesInflux:0为了简化恢复,抛弃了一些不必要的数据文件:SQL>archiveloglist;DatabaselogmodeArchiveModeAutomaticarchivalEnabledArchivedestination/opt/oracle/admin/MEDIA/arch_optOldestonlinelogsequence19922Nextlogsequencetoarchive19925Currentlogsequence19925SQL>alterdatabasedatafile'/opt/oracle/oradata/MEDIA/indx01.
dbf'offline;Databasealtered.
SQL>alterdatabasedatafile'/opt/oracle/oradata/MEDIA/drsys01.
dbf'offline;Databasealtered.
在不完全恢复尝试打开时,数据库会提示,这些文件在Resetlogs之后会被丢弃,我们先手工将文件DROP:SQL>alterdatabaseopenresetlogs;alterdatabaseopenresetlogs*ERRORatline1:ORA-01245:offlinefile6willbelostifRESETLOGSisdoneORA-01110:datafile6:'/opt/oracle/oradata/MEDIA/indx01.
dbf'294SQL>alterdatabasedatafile'/opt/oracle/oradata/MEDIA/indx01.
dbf'offlinedrop;Databasealtered.
对于从历史备份中恢复的文件,可以通过BBED从其他文件的SCN检查点进行同步,强制修正一致性,这可以参考上一章的做法.
由于控制文件和部分数据文件不符,所以尝试用较旧的控制文件是无法打开数据库的,数据库提示文件较控制文件新,这需要重建控制文件来解决:SQL>alterdatabaseopenresetlogs;alterdatabaseopenresetlogs*ERRORatline1:ORA-01248:file33wascreatedinthefutureofincompleterecoveryORA-01110:datafile33:'/opt/oracle/oradata/MEDIA/media_16.
dbf'重建控制文件之后,强制打开数据库,出现实例崩溃:SQL>alterdatabaseopenresetlogs;alterdatabaseopenresetlogs*ERRORatline1:ORA-03113:end-of-fileoncommunicationchannel但是此时告警日志已经显示了熟悉的信息.
除了几个抛弃的文件之外,就是4194的回滚错误信息:SatApr1023:33:492010SMON:enablingcacherecoverySatApr1023:33:492010DictionarycheckbeginningTablespace'INDX'#5foundindatadictionary,butnotinthecontrolfile.
Addingtocontrolfile.
Tablespace'DRSYS'#6foundindatadictionary,butnotinthecontrolfile.
Addingtocontrolfile.
File#6foundindatadictionarybutnotincontrolfile.
CreatingOFFLINEfile'MISSING00006'inthecontrolfile.
Thisfilecannolongerberecoveredsoitmustbedropped.
File#7foundindatadictionarybutnotincontrolfile.
脚本错误导致的灾难295CreatingOFFLINEfile'MISSING00007'inthecontrolfile.
Thisfilecannolongerberecoveredsoitmustbedropped.
File#22foundindatadictionarybutnotincontrolfile.
CreatingOFFLINEfile'MISSING00022'inthecontrolfile.
Thisfilecannolongerberecoveredsoitmustbedropped.
DictionarycheckcompleteSatApr1023:33:492010SMON:enablingtxrecoverySatApr1023:33:502010Errorsinfile/opt/oracle/admin/MEDIA/bdump/media_smon_3695.
trc:ORA-00600:internalerrorcode,arguments:[4194],[53],[14]RecoveryofOnlineRedoLog:Thread1Group7Seq1Readingmem0Mem#0errs0:/opt/oracle/oradata/MEDIA/redo07.
logSatApr1023:33:512010Errorsinfile/opt/oracle/admin/MEDIA/bdump/media_smon_3695.
trc:ORA-00600:internalerrorcode,arguments:[4194],[53],[14]SMON:terminatinginstanceduetoerror600InstanceterminatedbySMON,pid=3695这个错误通过重建Undo表空间就可以消除,这是一个Oracle8i的数据库,我们在参数文件中设置了如下参数:_allow_resetlogs_corruption=true_corrupted_rollback_segments='RBS0','RBS1','RBS2','RBS3','RBS4','RBS5','RBS6','RBS7','RBS8','RBS9','RBS10','RBS11','RBS12','RBS13','RBS14','RBS15','RBS16','RBS17','RBS18','RBS19','RBS20','RBS21','RBS22','RBS23','RBS24','RBS25','RBS26','RBS27','RBS28','RBS29'_offline_rollback_segments='RBS0','RBS1','RBS2','RBS3','RBS4','RBS5','RBS6','RBS7','RBS8','RBS9','RBS10','RBS11','RBS12','RBS13','RBS14','RBS15','RBS16','RBS17','RBS18','RBS19','RBS20','RBS21','RBS22','RBS23','RBS24','RBS25','RBS26','RBS27','RBS28','RBS29'然后数据库久违的可以重新启动:oracle@v880~/admin/MEDIA/bdump$sqlplus"/assysdba"SQL*Plus:Release8.
1.
7.
0.
0-ProductiononSatApr1023:38:162010(c)Copyright2000OracleCorporation.
Allrightsreserved.
296Connectedtoanidleinstance.
SQL>startupORACLEinstancestarted.
TotalSystemGlobalArea9873338044bytesFixedSize102076bytesVariableSize915955712bytesDatabaseBuffers8955625472bytesRedoBuffers1654784bytesDatabasemounted.
Databaseopened.
SQL>selectnamefromv$datafile;NAME/opt/oracle/oradata/MEDIA/system01.
dbf/opt/oracle/oradata/MEDIA/tools01.
dbf/opt/oracle/oradata/MEDIA/rbs01.
dbf/opt/oracle/oradata/MEDIA/temp01.
dbf/opt/oracle/oradata/MEDIA/users01.
dbf/opt/oracle/product/8.
1.
7.
4/dbs/MISSING00006/opt/oracle/product/8.
1.
7.
4/dbs/MISSING00007/opt/oracle/oradata/MEDIA/media_01.
dbf/opt/oracle/oradata/MEDIA/media_idx_01.
dbf/opt/oracle/oradata/MEDIA/media_02.
dbf/opt/oracle/oradata/MEDIA/media_03.
dbf…………然后删除重建回滚表空间:SQL>droptablespaceRBSincludingcontents;Tablespacedropped.
SQL>CREATETABLESPACErbs2DATAFILE'/opt/oracle/oradata/MEDIA/rbs201.
dbf'SIZE500MREUSEAUTOEXTENDON3NEXT100MMAXSIZE4096M;Tablespacecreated.
脚本错误导致的灾难297再然后数据库可以被成功打开:SQL>startupORACLEinstancestarted.
TotalSystemGlobalArea9873338044bytesFixedSize102076bytesVariableSize915955712bytesDatabaseBuffers8955625472bytesRedoBuffers1654784bytesDatabasemounted.
Databaseopened.
SQL>selectowner,count(*)fromdba_tablesgroupbyowner;OWNERCOUNT(*)AURORA$JIS$UTILITY$14CTXSYS31MDSYS15MED4MEDIA391MID1ORDSYS9OSE$HTTP$ADMIN3OUTLN2PEPSI19PERFSTAT28SYS203SYSTEM5213rowsselected.
在这种情况下,我们建议用户通过导出数据,重建数据库.
千里之堤,溃于蚁穴千丈之堤,溃于蚁穴,以蝼蚁之穴溃;百尺之室,以突隙之烟焚.
——先秦·韩非《韩非子·喻老》300有时候,防守坚固的数据库,可能因为一些微小的误操作、误处理,就走上了毁灭之路,这期间,技术往往是一个次要的环节,缺少规范、管理不善、盲目试错,最终导致了灾难的不可挽回.
本篇内容涉及管理安全方面的变更与上线管理,通过明确的变更规范和流程规范,本篇的几个数据灾难就可以避免:以下的两个案例都是因为微小失误导致的多米诺效应,这些微小的失误最终使数据库陷入灾难.
一个字符引发的灾难大小写字符疏忽导致的维护故障以下是一个字符引发的灾难,不要小看任何一个字符:灾难描述用户是这样描述这次灾难的:1.
进行删除表空间重建的维护,删除某表空间2.
重建表空间后,发现创建有问题,再次尝试删除3.
发现无法删除,提示表空间不存在,再创建提示裸设备已经使用4.
离线、在线操作表空间数据库没问题5.
多次操作后,出现ORA-600错误6.
数据库无法正常运行,灾难形成这个案例在《OracleDBA手记2》中曾经有更为详细的描述,在本书中,我们仅仅作为一个警示收录在这里.
案例警示经过分析处理后我们了解了案情的来龙去脉,问题的根源在于一个本应该大写的K,被写成了小写k,一个字符最后导致了这场数据库的大灾难.
这个案例给我们的警示有:1.
不以规矩不成方圆,规范是技术的保障与补充.
在进行数据库维护,编写脚本时,要注重规范,统一编码,避免不必要的麻烦和风险,有时候规范比技术能力本身更重要.
这些脚本必须经过测试才能够被应用到生产环境,而且,如果是非常重要的维护操作,至少申请一位审核人员对代码进行进一步的检查确认.
302有的规范要靠企业和客户,有的规范来自于DBA自身,一个DBA应该养成自己的良好习惯和规范,避免让自己陷入不可预期的困境.
2.
不要在常规任务中处理超出把握的异常如果你在工作中遇到了类似的情况,当数据库的表征超出了你的预期,那么最好停下来,仔细检查或咨询他人,避免在生产数据库上进行无把握的试错和尝试.
机会喜欢光顾有准备的头脑,灾难喜欢降临在无把握的尝试.
不要在常规的工作任务中,处理毫无把握、超出预期的异常,你的尝试很有可能使得情况越来越糟糕.
3.
事先定制明确的回退方案我们主张在重要的变更之前,准备好回退方案,如果没有,那么至少在你进行无把握的操作前,想一想如果出现不可预期的情况,你应当如何回退.
如果你的脑海中有回退的概念,我想很多灾难就不会发生,或者你根本就不会去走向不可预期.
在这个案例中,不规范的操作是导致灾难的根源.
案情解析最初收到这个案例之后,我们首先分析告警日志文件,理清事件的来龙去脉.
根据用户提供的信息,故障是因为表空间维护导致的,最初出现问题的是一个名称叫做"EMIS116K"表空间.
表空间的创建与删除在告警日志中,这个表空间最初于Apr27创建:TueApr2709:05:272010CREATETABLESPACE"EMIS116K"DATAFILE'/dev/vg02/rlvdata224_8G'SIZE7900MAUTOEXTENDONNEXT23MMAXSIZEUNLIMITEDLOGGINGEXTENTMANAGEMENTLOCALSEGMENTSPACEMANAGEMENTAUTOTueApr2709:11:052010Completed:CREATETABLESPACE"EMIS116K"DATAFILE'/dev/vg02/rlvdata224_8G'一个字符引发的灾难303这个表空间在Jun24被删除,注意这里用户发出的名称"EMIS116k",最后是一个小写的字母,这个小写的k会被数据库强制转换成大写,所以这个删除命令能够成功执行.
但是这一个字母的微小差异,最终造成了数据库无法运行的灾难:ThuJun2416:37:532010DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILESThuJun2416:47:482010Deletedfile/dev/vg02/rlvdata224_8G再然后,一个新的表空间在该文件上建立,表空间名称与原来"相同".
注意这里的相同是加了引号的,用户在这里指定的表空间名称是"EMIS116k",这与原来的"EMIS116K"是不同的.
大小写在引号之中,会存在不同的含义,引号强制了这个小写字母现在创建出来的表空间名称包含了最后一个小写字母k:ThuJun2416:49:012010CREATETABLESPACE"EMIS116k"DATAFILE'/dev/vg02/rlvdata224_8G'SIZE7900MAUTOEXTENDONNEXT20MMAXSIZEUNLIMITEDLOGGINGEXTENTMANAGEMENTLOCALSEGMENTSPACEMANAGEMENTAUTOThuJun2416:53:392010Completed:CREATETABLESPACE"EMIS116k"DATAFILE'/dev/vg02/rlvdata224_8G'SIZE7900MAUTOEXTENDONNEXT20MMAXSIZEUNLIMITEDLOGGINGEXTENTMANAGEMENTLOCALSEGMENTSPACEMANAGEMENTAUTO随后用户向这个表空间创建对象,无法成功,就试图去删除这个表空间,这里仍然给出的是EMIS116k,这个拼写经过Oracle的强制转换,就变成了EMIS116K,这个名字的表空间是不存在的,于是出现了ORA-959错误:ThuJun2416:57:192010DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILESThuJun2416:57:192010ORA-959signalledduring:DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILES.
.
.
ORA-959错误的含义是指定的表空间不存在:ORA-00959tablespace'string'doesnotexistCause:Astatementspecifiedthenameofatablespacethatdoesnotexist.
Action:Enterthenameofanexistingtablespace.
Foralistoftablespacenames,querythedatadictionary.
304由于前面的操作报出的提示是表空间不存在,客户认为该表空间没有创建成功,或是已经被删除,于是接下来继续在同样的裸设备上创建新的表空间,这一次的名称是全部大写的"EMIS116K":ThuJun2419:04:122010CREATETABLESPACE"EMIS116K"DATAFILE'/dev/vg02/rlvdata224_8G'SIZE7900MAUTOEXTENDONNEXT20MMAXSIZEUNLIMITEDLOGGINGEXTENTMANAGEMENTLOCALSEGMENTSPACEMANAGEMENTAUTO由于上一次创建的表空间仍然存在,在同一个裸设备上创建表空间必然不会成功,这一次出现的是ORA-1537号错误:ThuJun2419:04:122010ORA-1537signalledduring:CREATETABLESPACE"EMIS116K"DATAFILE'/dev/vg02/rlvdata224_8G'SIZE7900MAUTOEXTENDONNEXT20MMAXSIZEUNLIMITEDLOGGINGEXTENTMANAGEMENTLOCALSEGMENTSPACEMANAGEMENTAUTO.
.
.
ORA-01537的错误是指,指定的文件已经是数据库的一部分了,不能再次被使用:ORA-01537cannotadddatafile'string'-filealreadypartofdatabaseCause:DuringCREATEorALTERTABLESPACE,afilebeingaddedisalreadypartofthedatabase.
Action:Useadifferentfilename.
客户并没有认识到这样的错误,紧跟着一个创建语句再次被发出,此次的表空间名称又变成了大小写混合的"EMIS116k":ThuJun2419:04:282010CREATETABLESPACE"EMIS116k"DATAFILE'/dev/vg02/rlvdata224_8G'SIZE7900MAUTOEXTENDONNEXT20MMAXSIZEUNLIMITEDLOGGINGEXTENTMANAGEMENTLOCALSEGMENTSPACEMANAGEMENTAUTO这显然也不会成功,这次的错误提示是ORA-1543:ThuJun2419:04:282010ORA-1543signalledduring:CREATETABLESPACE"EMIS116k"DATAFILE'/dev/vg02/rlvdata224_8G'SIZE7900MAUTOEXTENDONNEXT20MMAXSIZEUNLIMITEDLOGGING一个字符引发的灾难305EXTENTMANAGEMENTLOCALSEGMENTSPACEMANAGEMENTAUTO.
.
.
ORA-01543错误是指,要创建的表空间已经存在:ORA-01543tablespace'string'alreadyexistsCause:Anattemptwasmadetocreateatablespacewhichalreadyexists.
Action:Useadifferentnameforthenewtablespace.
好了,到这里打住.
我在此再次要提醒大家的一点是:如果你在工作中遇到了类似的情况,当数据库的表征超出了你的预期,那么最好停下来,仔细检查或咨询他人,避免在生产数据库上进行无把握的试错和尝试.
这次的事情还要继续,接下来两个DROP命令被发出,但是EMIS116K和EMIS116k都不被数据库认可,两次尝试又失败了:ThuJun2419:05:092010DROPTABLESPACEEMIS116KINCLUDINGCONTENTSANDDATAFILESThuJun2419:05:092010ORA-959signalledduring:DROPTABLESPACEEMIS116KINCLUDINGCONTENTSANDDATAFILES.
.
.
ThuJun2419:05:312010DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILESORA-959signalledduring:DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILES.
.
.
数据文件的离线与在线用户开始尝试将该文件离线再Online,试图通过这样的操作消除这个不明原因的无法DROP问题.
这个尝试过程又引入了恢复的环节,还好一切顺利,表空间的数据文件能够被重新Online,这样看起来数据文件是没有问题的:ThuJun2419:20:322010alterdatabasedatafile'/dev/vg02/rlvdata224_8G'offlineThuJun2419:20:332010Completed:alterdatabasedatafile'/dev/vg02/rlvdata224_8G'offline306ThuJun2419:21:022010alterdatabasedatafile'/dev/vg02/rlvdata224_8G'onlineThuJun2419:21:022010ORA-1113signalledduring:alterdatabasedatafile'/dev/vg02/rlvdata224_8G'online.
.
.
ThuJun2419:21:312010ALTERDATABASERECOVERdatafile'/dev/vg02/rlvdata224_8G'ThuJun2419:21:312010MediaRecoveryStartparallelrecoverystartedwith15processesThuJun2419:21:352010MediaRecoveryComplete(cwgk1)Completed:ALTERDATABASERECOVERdatafile'/dev/vg02/rlvdata224_8G'ThuJun2419:21:452010alterdatabasedatafile'/dev/vg02/rlvdata224_8G'onlineThuJun2419:21:452010Completed:alterdatabasedatafile'/dev/vg02/rlvdata224_8G'online再回过头来继续尝试DROP表空间的操作,在没找到根本原因之前,这样的操作当然又失败了:ThuJun2419:48:182010DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILESThuJun2419:48:182010ORA-959signalledduring:DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILES.
.
.
ThuJun2419:48:542010DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILESThuJun2419:48:542010ORA-959signalledduring:DROPTABLESPACEEMIS116kINCLUDINGCONTENTSANDDATAFILES.
.
.
终于客户发现了大小写的问题,尝试将这个小写的EMIS116k更改为大写的EMIS116K名称.
但是注意,不加入双引号,Oracle认为这两者是没有区别的:ThuJun2419:52:522010ALTERTABLESPACEEMIS116kRENAMETOEMIS116K一个字符引发的灾难307ThuJun2419:52:522010ORA-710signalledduring:ALTERTABLESPACEEMIS116kRENAMETOEMIS116K.
.
.
ORA-710是说这两个名字是一样的,无须更改.
ORA-00710newtablespacenameisthesameastheoldtablespacenameCause:Anattempttorenameatablespacefailedbecausethenewnameisthesameastheoldname.
Action:Noactionrequired.
用户继续DROP,仍然是ORA-959.
ThuJun2420:00:042010DROPTABLESPACEEMIS116kThuJun2420:00:042010ORA-959signalledduring:DROPTABLESPACEEMIS116k.
.
.
看着这样的过程,我们是否会有很着急的感觉我相信在现场时,你可能会是焦急!
ORA-006004348错误引发故障终于用户发现了本质问题,发出了带着双引号的删除命令,这本身是没有问题的,可是恰恰此时数据库出了问题,一个异常的ORA-00600错误出现了,4348出现:ThuJun2420:03:592010DROPTABLESPACE"EMIS116k"ThuJun2420:03:592010Errorsinfile/oracle/admin/cwgk/udump/cwgk1_ora_25919.
trc:ORA-00600:internalerrorcode,arguments:[4348],[U],[0],[229]再然后,案情基本成立,任何DROP命令都提示表空间不存在了:ThuJun2420:04:122010DROPTABLESPACE"EMIS116k"ThuJun2420:04:132010ORA-959signalledduring:DROPTABLESPACE"EMIS116k"308.
.
.
ThuJun2420:04:302010DROPTABLESPACE"EMIS116k"ThuJun2420:04:302010ORA-959signalledduring:DROPTABLESPACE"EMIS116k".
.
.
ThuJun2420:04:402010DROPTABLESPACE"EMIS116n"ThuJun2420:04:402010ORA-959signalledduring:DROPTABLESPACE"EMIS116n".
.
.
接下来用户继续尝试创建其他的表空间,此时ORA-0060025013错误出现:FriJun2509:14:002010CREATETABLESPACE"EMIS116N2"DATAFILE'/dev/vg02/rlvdata088_16G'SIZE7900MAUTOEXTENDONNEXT20MMAXSIZEUNLIMITEDLOGGINGEXTENTMANAGEMENTLOCALSEGMENTSPACEMANAGEMENTAUTOFriJun2509:18:402010Errorsinfile/oracle/admin/cwgk/udump/cwgk1_ora_20031.
trc:ORA-00600:internalerrorcode,arguments:[25013],[0],[229],[EMIS116N2],[EMIS116k],[184],[179],[]FriJun2509:18:452010Errorsinfile/oracle/admin/cwgk/bdump/cwgk1_pmon_4050.
trc:ORA-00600:internalerrorcode,arguments:[25015],[229],[179],[184][]FriJun2509:18:472010Tracedumpingisperformingid=[cdmp_20100625091847]FriJun2509:18:472010Errorsinfile/oracle/admin/cwgk/bdump/cwgk1_pmon_4050.
trc:ORA-00600:internalerrorcode,arguments:[kccocx_01]ORA-00600:internalerrorcode,arguments:[25015],[229],[179],[184][]伴随这些错误,有一个新的提示出现,Oracle实例进行事务恢复时遇到600错误,这已经给我们一个暗示,一个字符引发的灾难309数据库内部事务出现了一致性的问题:FriJun2509:19:012010ORACLEInstancecwgk1(pid=30)-Error600encounteredwhilerecoveringtransaction(203,10).
此后,后台进程异常终止,数据库挂起,最后被迫Abort关闭了数据库:FriJun2509:24:062010Errorsinfile/oracle/admin/cwgk/bdump/cwgk1_pmon_4050.
trc:ORA-00474:SMONprocessterminatedwitherrorFriJun2509:24:062010PMON:terminatinginstanceduetoerror474FriJun2509:24:062010Errorsinfile/oracle/admin/cwgk/bdump/cwgk1_lms3_4071.
trc:ORA-00474:SMONprocessterminatedwitherrorFriJun2509:24:062010Errorsinfile/oracle/admin/cwgk/bdump/cwgk1_lms1_4067.
trc:ORA-00474:SMONprocessterminatedwitherrorFriJun2509:24:062010Errorsinfile/oracle/admin/cwgk/bdump/cwgk1_lms0_4065.
trc:ORA-00474:SMONprocessterminatedwitherrorFriJun2509:24:062010Errorsinfile/oracle/admin/cwgk/bdump/cwgk1_lms2_4069.
trc:ORA-00474:SMONprocessterminatedwitherrorFriJun2509:24:082010Shuttingdowninstance(abort)Licensehighwatermark=265FriJun2509:24:122010InstanceterminatedbyPMON,pid=4050FriJun2509:24:132010InstanceterminatedbyUSER,pid=24022接下来用户执行了一系列的恢复尝试,包括重建控制文件,强制Resetlogs打开数据库等,最终导致情况失控.
310我们回过头来分析一下最初的错误出现时机,这里用户执行了正确的语句,但是数据库却不再配合,报出了ORA-006004348错误,这个错误号在Metalink上也没有收录,错误原因未知:ThuJun2420:03:592010DROPTABLESPACE"EMIS116k"ThuJun2420:03:592010Errorsinfile/oracle/admin/cwgk/udump/cwgk1_ora_25919.
trc:ORA-00600:internalerrorcode,arguments:[4348],[U],[0],[229]但是结合后面的出错信息:FriJun2509:19:012010ORACLEInstancecwgk1(pid=30)-Error600encounteredwhilerecoveringtransaction(203,10).
我们猜测,DROPTABLESPACE实质上执行了后台递归操作,但是这个DDL事务因为异常,在失败后没有完成回滚,造成了数据字典不一致.
技术回放要解决这个数据库故障,首先要分析ORA-006004348错误是如何出现的.
明白了所有的内部操作过程,我们又可以继续分析ORA-006004348号错误的成因了:ORA-00600:internalerrorcode,arguments:[4348],[U],[0],[229]我说过,猜测是一种重要的学习能力,现在我们就要运用这种能力了.
通过猜测推演问题这个错误的4384后的第一个代码是U,应该是Update的缩写,更新的应该就是file$,ts$字典表.
这里的229应该就是更新的表空间号,Update出错的可能就是被更新的记录不存在了.
那么更新的记录为什么会不存在这个我猜测可能是某个DBA考虑到是这个表空间的问题,手工执行了对于字典表的Delete操作,这就导致了后面的异常;当然也有可能是Oracle数据库自身丢失了这条记录(这种可能性不大).
一个字符引发的灾难311通过实验验证问题可以验证一下这个猜测,首先通过手工删除一个表空间信息.
当然我们需要严正提示:这些操作仅可在测试环境,或者说属于你自己的测试环境上进行,测试之前请先备份你的数据库.
删除可以通过dba_tablespaces和ts$表进行,我们选择了对ts$表直接操作:SQL>deletefromdba_tablespaceswheretablespace_name='ENMO';已删除1行.
SQL>selectts#,name,online$fromts$;TS#NAMEONLINE$0SYSTEM11UNDOTBS112SYSAUX13TEMP14USERS15UNDOTBS236EYGLE17EYGLe3已选择8行.
SQL>rollback;回退已完成.
SQL>selectts#,name,online$fromts$;TS#NAMEONLINE$0SYSTEM11UNDOTBS112SYSAUX13TEMP14USERS15UNDOTBS236EYGLE13127EYGLe38ENMO1已选择9行.
SQL>deletefromts$wherets#=8;已删除1行.
SQL>commit;提交完成.
删除了字典表信息之后,如果此时再来执行droptablespace的操作,即出现了4348错误,后面的参数8是指表空间号是8,也就是说当试图去Update修改8号表空间的状态时出现了异常,也就是发现这个表空间的信息不存在了,在正常情况下,这种情况绝不应该发生,因为数据库根本不对ts$执行DELETE操作:SQL>droptablespaceenmo;droptablespaceenmo*第1行出现错误:ORA-00600:内部错误代码,参数:[4348],[U],[0],[8]告警日志中也记录了错误信息,并且产生了一个跟踪文件,这里的8号表空间也就是ENMO表空间:MonAug0915:58:102010droptablespaceenmoMonAug0915:58:102010Errorsinfiled:\oracle\admin\enmo\udump\enmo_ora_4736.
trc:ORA-00600:内部错误代码,参数:[4348],[U],[0],[8]MonAug0915:58:112010ORA-600signalledduring:droptablespaceenmo.
.
.
跟踪文件中也显示全部的相关信息,绑定变量等:Cursor#3(04D60CA4)state=BOUNDcuriob=04D7B9B4curflg=5fl2=0par=04D60C24ses=34343FE4sqltxt(3028CDA4)=updatets$setname=:2,online$=:3,contents$=:4,undofile#=:5,undoblock#=:6,blocksize=:7,dflmaxext=:8,dflinit=:9,dflincr=:10,dflextpct=:11,dflminext=:12,dflminle一个字符引发的灾难313n=:13,owner#=:14,scnwrp=:15,scnbas=:16,pitrscnwrp=:17,pitrscnbas=:18,dflogging=:19,bitmapped=:20,inc#=:21,flags=:22,plugged=:23,spare1=:24,spare2=:25wherets#=:1hash=29d4143c7a377b40366bdc581b9a48d1parent=2FED6560maxchild=02plk=31B316ECppn=ncursorinstantiation=04D7B9B4used=1281340689child#0(3028CC60)pcs=2FED6764clk=31B31BBCci=2FED5D00pn=00000000ctx=2F966490kgsccflg=0llk[04D7B9B8,04D7B9B8]idx=0xscflg=a0100426fl2=5000400fl3=2218cfl4=0sharingfailure(s)=10BindbytecodesOpcode=5BindRpiScalarSqlIn(notout)Nocopy…………….
kkscoacdBind#0oacdty=01mxl=32(04)mxlc=00mal=00scl=00pre=00oacflg=18fl2=0001frm=01csi=852siz=32off=0kxsbbbfp=30284552bln=32avl=04flg=09value="ENMO"Bind#1oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d734f4bln=24avl=02flg=05value=2Bind#2~Bind#4value=0Bind#5oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d7345cbln=24avl=03flg=05value=8192Bind#6oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0314kxsbbbfp=04d73438bln=24avl=06flg=05value=2147483645Bind#7oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d73414bln=24avl=02flg=05value=8Bind#8oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d733f0bln=24avl=03flg=05value=128Bind#9oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d733ccbln=24avl=01flg=05value=0Bind#10oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d733a8bln=24avl=02flg=05value=1Bind#11oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d7337cbln=24avl=02flg=05value=8Bind#12~Bind#15value=0Bind#16oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d7284cbln=24avl=04flg=05value=907939一个字符引发的灾难315Bind#17oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d72828bln=24avl=02flg=05value=1Bind#18oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d72804bln=24avl=02flg=05value=8Bind#19oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d727e0bln=24avl=02flg=05value=1Bind#20oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d727bcbln=24avl=02flg=05value=33Bind#21~Bind#23value=0Bind#24oacdty=02mxl=22(22)mxlc=00mal=00scl=00pre=00oacflg=08fl2=0001frm=00csi=00siz=24off=0kxsbbbfp=04d73518bln=22avl=02flg=05value=8Framespfr04D713C0siz=7188efr04D71338siz=7172Cursorframedumpenxt:4.
0x00000404enxt:3.
0x000009b8enxt:2.
0x000001f4enxt:1.
0x00000c54pnxt:2.
0x00000004pnxt:1.
0x0000000ckxscphp04D70064siz=2016inu=0nps=624kxscbhp04D66510siz=2016inu=0nps=1432316Cursor#1(04D60C24)state=BOUNDcuriob=04D74B38curflg=4cfl2=400par=00000000ses=34352EC4childcursor:3sqltxt(04AAFC04)=droptablespaceenmohash=00000000000000000000000000000000parent=04AA2870maxchild=01plk=04AAFD24ppn=ycursorinstantiation=04D74B38used=1281340689child#0(04AA2264)pcs=04AA2684clk=04AA2334ci=04AA2010pn=04AA23A4ctx=04AA1814kgsccflg=0llk[04D74B3C,04D74B3C]idx=0xscflg=c0802276fl2=c000400fl3=2202008fl4=100Framespfr04D74AFCsiz=240efr04D74AACsiz=232Cursorframedumpenxt:1.
0x000000e8pnxt:1.
0x00000008kxscphp04D66020siz=1000inu=0nps=140kxscefhp04D704C0siz=4072inu=0nps=244而如果此时我们尝试去重新创建ENMO表空间,则会出现25013/25015错误,客户的情况完全得以重演.
这里的25015错误跟随着几个参数,其中8指表空间号,新创建的ENMO表空间被重新赋予了8号表空间,第二个参数6是指表空间记录号,5是指数据文件号:SQL>createtablespaceenmodatafilesize10M;createtablespaceenmodatafilesize10M*第1行出现错误:ORA-00603:ORACLEserversessionterminatedbyfatalerrorORA-00600:internalerrorcode,arguments:[25015],[8],[6],[5]ORA-00600:internalerrorcode,arguments:[25015],[8],[6],[5]ORA-00600:internalerrorcode,arguments:[25013],[0],[8],[ENMO],[ENMO],[5],[6],[]进程ID:0会话ID:159序列号:14