ORACLE ORA-00600錯(cuò)誤不是你的程序錯(cuò)誤.是ORACLE內(nèi)部的錯(cuò)誤,一般來(lái)說(shuō),大部分的ORA-00600錯(cuò)誤均是由ORACLE
軟件的bug所導(dǎo)致，因此對(duì)于這樣的錯(cuò)誤需要及時(shí)聯(lián)系ORACLE技術(shù)支持工程師.對(duì)于這種類(lèi)型的ORA-00600錯(cuò)誤，
一個(gè)簡(jiǎn)單的處理方式就是打補(bǔ)丁，將數(shù)據(jù)庫(kù)升級(jí)到一個(gè)穩(wěn)定的版本，另外建議屏蔽某些ORACLE特性，諸如MTS
（MultiThread Server）。但也有部分錯(cuò)誤是由
數(shù)據(jù)庫(kù)內(nèi)部的表或索引（包括應(yīng)用的）結(jié)構(gòu)被損壞所或其他原因所造成。

1：ORA-600[12700]表示執(zhí)行SQL語(yǔ)句時(shí)對(duì)應(yīng)的某些實(shí)體（表/索引）損壞；該
錯(cuò)誤的處理方法為：
? 修改init$ORACLE_SID.ora文件，增加如下幾行：
event = “10210 trace name context forever level 10”
event = “10211 trace name context forever level 10”
event = “10231 trace name context forever level 10
? 執(zhí)行以下語(yǔ)句：
analyze table/index/cluster [name] validate structure;
? 如果懷疑是數(shù)據(jù)字典損壞，則不能采用以上的方法對(duì)表進(jìn)行分析，
因?yàn)樵谀承┢脚_(tái)上執(zhí)行以上操作將引起系統(tǒng)癱瘓，執(zhí)行如下存儲(chǔ)過(guò)程：
DBMS_UTILITY.ANALYZE_SCHEMA
例2：在對(duì)數(shù)據(jù)庫(kù)進(jìn)行讀寫(xiě)操作時(shí)出現(xiàn)錯(cuò)誤：ORA-00600:internal error
code,arguments:[4519],[6711],[2],…表示執(zhí)行SQL語(yǔ)句時(shí)的對(duì)應(yīng)的實(shí)體數(shù)據(jù)
塊[6711]的結(jié)構(gòu)被破壞所引起。該錯(cuò)誤的處理方法為：
? 執(zhí)行如下的package進(jìn)行分析：
svrmgrl > select dbms_utility.data_block_address_file(6711) from dual;
svrmgrl > select dbms_utility.data_block_address_block(6711) from dual;
查找其對(duì)應(yīng)的block_id和file_id。
? 通過(guò)如下的sql命令查找出被破壞的實(shí)體類(lèi)型、owner等：
svrmgrl > select segment_name,segment_type,owner
? from dba_extents
? where file_id=file# and block# between
? block_id and block_id+blocks-1;
? 如果被破壞的對(duì)象并非系統(tǒng)表或索引，則可以通過(guò)對(duì)該數(shù)據(jù)庫(kù)對(duì)象\r
進(jìn)行備份后重新創(chuàng)建實(shí)體的方法進(jìn)行。如果出現(xiàn)的錯(cuò)誤為系統(tǒng)表或索引，則需要
根據(jù)實(shí)際情況進(jìn)行處理。


另外,用ResultSet來(lái)執(zhí)行插入,更新,刪除原則上是可行的,但效率很低,而且無(wú)法測(cè)試操作是否成功.