ora-00600[733]等错误解决---转载，抱着谨慎态度，不可尽信 -

lancezhcj

浏览: 48758 次
性别:
来自: 衡阳

最近访客更多访客>>

u012363178

pengfeifei26

xiaolong0211

skyuck

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

ora-00600[733]等错误解决---转载，抱着谨慎态度，不可尽信

Oracle SQL 脚本

错误描述：
Alert日志不断报错如下：
ORA-00600: internal error code, arguments: [733], [1073732408], [top call heap], [], [], [], [], []
Mon Oct 30 23:23:40 2006
Errors in file /oracle/app/oracle/admin/ora9i/udump/ora9i_ora_10144.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Mon Oct 30 23:27:13 2006
ORACLE Instance ora9i (pid = 6) - Error 600 encountered while recovering transaction (2, 23) on object 821401.
Mon Oct 30 23:27:13 2006
Errors in file /oracle/app/oracle/admin/ora9i/bdump/ora9i_smon_9648.trc:
ORA-00600: internal error code, arguments: [6006], [1], [], [], [], [], [], []
Trace文件暴涨。达到10G，摘录部分错误如下：
trace之一：
*** 2006-10-27 12:23:51.414
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [733], [1073732408], [top call heap], [], [], [], [], []
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+328 CALL ksedst()+0 FFFFFFFF7FFF7510 ?
000000000 ? 000000000 ?
00000003E ?
FFFFFFFF7FFF7DA8 ?
10305F988 ?
kgeriv()+208 PTR_CALL 0000000000000000 000000000 ? 000103400 ?
00010345F ? 000102C00 ?
10345F000 ? 10345FE70 ?
kgesiv()+108 CALL kgeriv()+0 1034600D0 ? 10357E828 ?
000000258 ? 0000013C8 ?
FFFFFFFF7FFF86D8 ?
1034614A0 ?
ksesic2()+92 CALL kgesiv()+0 1034600D0 ? 10357E828 ?
0000002DD ? 000000002 ?
FFFFFFFF7FFF86D8 ?
000000000 ?
ksmarfg()+372 CALL ksesic2()+0 0000002DD ? 000000000 ?
03FFFDB38 ? 000000001 ?
00000000D ? 103463514 ?
kghgex()+1072 PTR_CALL 0000000000000000 1034600D0 ? 00000FFFF ?
03FFFDB38 ? 03FFFDB38 ?
103463510 ? 103463508 ?
kghfnd()+548 CALL kghgex()+0 000072FFF ? 0000000B8 ?
000007FFF ? 103463514 ?
000002000 ? 000001000 ?
kghalo()+520 CALL kghfnd()+0 1034636D0 ? 1034636E8 ?
1034600D0 ? 03FFFDB28 ?
03FFFDB28 ? 000000000 ?
kghgex()+332 CALL kghalo()+0 000000000 ? 000000018 ?
1034600D0 ? 000001000 ?
000000000 ? 000000000 ?
kghalf()+616 CALL kghgex()+0 000072FFF ? 000007FFF ?
000007FFF ? 1034628EC ?
000002000 ? 000000000 ?
kdxd4ckf()+68 PTR_CALL 0000000000000000 1034600D0 ? 103462940 ?

trace之二：
Dump kdilk : itl=3, kdxlkflg=0x1 sdc=0 indexid=0x1c40500c block=0x1c426763
purge leaf row
(11): 03 c2 02 16 06 23 81 2a e5 00 1c
dump block being looked at now
Block header dump: 0x1c426763
Object id on Block? Y
seg/obj: 0xc8899 csc: 0x81b.d4c5daee itc: 3 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x1c42640c ver: 0x01
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000f.000.0006cca6 0x2304caa1.000f.01 CB-- 0 scn 0x081b.b862f84d
0x02 0x000f.02d.0006c169 0x2304cb21.000f.1b C-U- 0 scn 0x081b.d4c4e4cc
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

Leaf block dump
===============
header address 19375988860=0x482e6207c
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y

该错误没有造成业务中断，但trace文件增长很快，在10小时的观察中trace文件增大了几个GB,
诊断结果：
由于系统原先是采用pfile启动数据库，为了方便将来的使用与维护，我们把系统改为了使用spfile来启动数据库，操作如下：
　Create spfile from pfile;
查看系统参数，发现pga_aggregate_target大小仅为20M。
分析alert日志连同trace文件后，发现ORA-00600: internal error code, arguments: [733], [1073732408], [top call heap], [], [], [], [], []错误是由pga在内存分配时出现的一个错误。此错误为oracle9201上的一个bug#: 3299546。但可避免此BUG的触发。解决方法为增大PGA 的大小，在此基础上，将初始化参数pga_aggregate_target修改为2GB后错误消失，此操作过程为：
Alter system set pga_aggregate_target='2000M' scope=both;

而ORA-00600: internal error code, arguments: [6006], [1], [], [], [], [], [], []错误则主要是object_id为821401这个对象出现了逻辑损坏，我们根据dba_objects查看该object为一个index, 将此索引进行rebuild后，该600错误消除,将该索引rebuild的脚本为：

SQL> col owner format a10
SQL> col object_type format a10
SQL> col object_name format a30
SQL> select owner,object_type,object_name from dba_objects where object_id=821401;
OWNER OBJECT_TYP OBJECT_NAME
---------- ---------- ------------------------------
LBAS INDEX IDX_BSA_ACCT_ITEM_TYPE_ID[size=small][/size]
SQL>alter index lbas.IDX_BSA_ACCT_ITEM_TYPE_ID rebuild
重建完该索引，观察系统两天没有出现任何错误。

分享到：