ORA-00600 [4553]错误
Sep122013
昨晚处理客户ORA-00600错误导致无法向一张表中插入数据的问题,客户环境是ORACLE 10.2.0.4.0 for LINUX,下面是错误信息。
OCI0000226 - Unable to execute - INSERT INTO XXXX (COL1, COL2, COL3,COL4, COL5, COL6) VALUES (:BND1,:BND2,:BND3,:BND4,:BND5,:BND6) in buffered mode (record 1 of 1) 5868/5980 WRK:TYJIQQ_088EF828_P5903B11 Sun Sep 08 16:12:50.015001 dbperfrq.c572 OCI0000227 - Error - ORA-00600: internal error code, arguments: [4553], [2], [0], [], [], [], [], []
由于之前存储厂商的人把客户的存储弄挂了,导致数据库宕机,重启后只能启动到mount状态,后来存储厂商的人把存储恢复到故障点,数据库可以OPEN,但是出现了这个问题。
查看MOS,没有找到完全一样的文章,但是MOS上类似的文章说是索引或存储故障引起的。下面是MOS的描述。
Hdr: 4450791 9.2.0.6 RDBMS 9.2.0.6 BUFFER CACHE PRODID-5 PORTID-23 ORA-600 Abstract: ORA-600 [4553] CORRUPT BLOCKS FOUND IN INDEX SEGMENTS *** 06/22/05 05:21 pm *** TAR: ---- 4463749.992 PROBLEM: -------- ORA-600 [4553] errors and corrupt block errors found in the alert log. DBV on the datafiles found many corrupt blocks. ORA-600: internal error code, arguments: [4553], [2], [0], [], [], [], [], [] Corrupt block relative dba: 0x0182292e (file 6, block 141614) Fractured block found during buffer read Data in bad block - type: 6 format: 2 rdba: 0x0182292e last change scn: 0x026f.a4d4f518 seq: 0x1 flg: 0x06 consistency value in tail: 0x8de40601 check value in block header: 0x365b, computed block checksum: 0x2b59 spare1: 0x0, spare2: 0x0, spare3: 0x0 *** Reread of rdba: 0x0182292e (file 6, block 141614) found same corrupted data Tue Jun 21 14:59:00 2005 DIAGNOSTIC ANALYSIS: -------------------- It was determined that all the bad blocks belonged to index segments. OS dd dumps were taken of 3 of the corrupt blocks as well as oracle dumps. The indices were dropped and recreated and the errors did not resurface. The customer would like to see if it can be determined whether the problem was OS related or due to Oracle. They do not have backups so redo logs are not available. All the blocks belong to the same volume. Their SE is working on doing hardware diagnosis. WORKAROUND: ----------- Drop and recreate the objects. RELATED BUGS: ------------- REPRODUCIBILITY: ---------------- Cannot reproduce corruption. TEST CASE: ---------- STACK TRACE: ------------ *** ID:(444.65047) 2005-06-21 15:05:12.710 *** 15:05:12.709 ksedmp: internal or fatal error ORA-600: internal error code, arguments: [4553], [2], [0], [], [], [], [], [] Current SQL statement for this session: INSERT INTO STATS$SQL_SUMMARY ( SNAP_ID , DBID , INSTANCE_NUMBER , TEXT_SUBSET , SHARABLE_MEM , SORTS , MODULE , LOADED_VERSIONS , FETCHES , EXECUTIONS , LOADS , INVALIDATIONS , PARSE_CALLS , DISK_READS , BUFFER_GETS , ROWS_PROCESSED , COMMAND_TYPE , ADDRESS , HASH_VALUE , VERSION_COUNT , CPU_TIME , ELAPSED_TIME , OUTLINE_SID , OUTLINE_CATEGORY , CHILD_LATCH ) SELECT :B9 , :B8 , :B7 , SUBSTRB(SQL_TEXT,1,31) , SHARABLE_MEM , SORTS , MODULE , LOADED_VERSIONS , FETCHES , EXECUTIONS , LOADS , INVALIDATIONS , PARSE_CALLS , DISK_READS , BUFFER_GETS , ROWS_PROCESSED , COMMAND_TYPE , ADDRESS , HASH_VALUE , VERSION_COUNT , CPU_TIME , ELAPSED_TIME , OUTLINE_SID , OUTLINE_CATEGORY , CHILD_LATCH FROM STATS$V$SQLXS WHERE IS_OBSOLETE = 'N' AND ( BUFFER_GETS > :B6 OR DISK_READS > :B5 OR PARSE_CALLS > :B4 OR EXECUTIONS > :B3 OR SHARABLE_MEM > :B2 OR VERSION_COUNT > :B1 ) ----- PL/SQL Call Stack ----- object line object handle number name 4539507d0 1361 package body PERFSTAT.STATSPACK 4539507d0 2471 package body PERFSTAT.STATSPACK 4539507d0 91 package body PERFSTAT.STATSPACK 45395f980 1 anonymous block ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedmp()+328 CALL ksedst() 00000000B ? 000000000 ? 000000000 ? 00000004A ? FFFFFFFF7FFE07B8 ? 1033136F8 ? kgeriv()+208 PTR_CALL 0000000000000000 00010373D ? 10373D000 ? 10373DD68 ? 103742000 ? 000102C00 ? 000000000 ? kgeasi()+180 CALL kgeriv() 10373DFC8 ? 103889D78 ? 000000258 ? 0000013C8 ? FFFFFFFF7FFE40D8 ? 10373F398 ? ktbtas()+136 CALL kgeasi() 10373DFC8 ? 103889D78 ? 0000011C9 ? 000000002 ? 000000002 ? 000000004 ? ktbair()+572 CALL ktbtas() 41B7FE014 ? 000000030 ? 380015000 ? 000000001 ? 000000184 ? 000000000 ? kdxlne()+212 CALL ktbair() 41B7FE014 ? 000000000 ? 1038C5610 ? 000000001 ? 000000000 ? 000000000 ? kcoapl()+608 PTR_CALL 0000000000000000 1038C55A8 ? 1038C5602 ? 000000000 ? 41B7FE014 ? 00000003C ? 00000003B ? kcbapl SUPPORTING INFORMATION: ----------------------- Alert log, dbverify output, and trace files are located on ess30. 24 HOUR CONTACT INFORMATION FOR P1 BUGS: ---------------------------------------- DIAL-IN INFORMATION: -------------------- IMPACT DATE: ------------ *** 06/23/05 12:25 am *** *** 06/23/05 12:56 am *** (CHG: Sta->10) *** 06/23/05 12:56 am *** *** 07/04/05 03:30 am *** (CHG: Sta->95 SubComp->BUFFER CACHE) *** 07/04/05 03:30 am ***
查看trace文件发现大量的enq: TX – index contention等待事件,参考MOS猜测可能是索引出了问题,而客户说他已经把这个表上的所有索引都rebuild了,还是不行,后来根据MOS的建议,把索引删掉后重建,问题解决。
本文固定链接: https://www.dbdream.com.cn/2013/09/ora-00600-4553%e9%94%99%e8%af%af/ | 信春哥,系统稳,闭眼上线不回滚!