当前位置: 首页 > Oracle, oracle 10g, oracle 11g > 正文

ORA-00600 [4553]错误

昨晚处理客户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的建议,把索引删掉后重建,问题解决。

本文固定链接: http://www.dbdream.com.cn/2013/09/ora-00600-4553%e9%94%99%e8%af%af/ | 信春哥,系统稳,闭眼上线不回滚!

该日志由 dbdream 于2013年09月12日发表在 Oracle, oracle 10g, oracle 11g 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: ORA-00600 [4553]错误 | 信春哥,系统稳,闭眼上线不回滚!
关键字: , , , ,

ORA-00600 [4553]错误:等您坐沙发呢!

发表评论

快捷键:Ctrl+Enter