客户数据库出现ORA-600[729]错误。
详细信息如下:
Sun Oct 16 04:31:31 2011
Errors in file /u01/app/oracle/admin/db1/udump/db1_ora_6459722.trc:
ORA-00600: internal error code, arguments: [729], [360], [space leak], [], [], [], [], []
这个ORA-600的三个参数的含义分别为:729是错误的编号,729的错误和内存泄漏相关;360是内存泄漏的字节数;space leak:对于729错误,第三个参数永远是space leak,表明这是一个内存泄漏的问题。
正常情况下,Oracle的进程会自动管理当前进程内存的分配和释放,只有当进程结束的时候,Oracle会接管进程的内存,将其全部释放。在Oracle释放进程的内存时,会检查每个内存chunk的状态,正常情况下所有的状态都是free和permanent,如果出现了其他状态,比如FREEABLE或者RECREATABLE等,说明进程没有及时的释放一些内存chunk,这就是所谓的内存泄漏。
详细的TRACE如下:
*** 2011-10-16 04:31:31.115
*** SERVICE NAME:(SYS$USERS) 2011-10-16 04:31:31.114
*** SESSION ID:(6191.1172) 2011-10-16 04:31:31.114
******** ERROR: UGA memory leak detected 360 ********
******************************************************
HEAP DUMP heap name="session heap" desc=1104473d8
extent sz=0xff80 alt=32767 het=32767 rec=0 flg=2 pc=3
parent=110198a30 wner=7000013ff452bf0 nex=0 xsz=0xff80
EXTENT 0 addr=110490080
Chunk 110490090 sz= 7800 perm "perm " alo=4480
Chunk 110491f08 sz= 57592 free " "
EXTENT 1 addr=110480080
Chunk 110480090 sz= 16184 free " "
Chunk 110483fc8 sz= 192 perm "perm " alo=192
Chunk 110484088 sz= 22136 free " "
Chunk 110489700 sz= 360 freeable "K2I iter "
Dump of memory from 0x0000000110489700 to 0x0000000110489868
110489700 00B38F00 00000169 00000001 10484088 [.......i.....H@.]
110489710 00000001 04DEFFC0 0000BEA1 0000000A [................]
110489720 00000008 00000000 00000001 104897E4 [.............H..]
110489730 00000001 10489824 00000000 00000000 [.....H.$........]
.
.
.
110489860 00000000 00000000 [........]
Chunk 110489868 sz= 26520 free " "
EXTENT 2 addr=110460080
Chunk 110460090 sz= 2200 perm "perm " alo=2200
Chunk 110460928 sz= 63192 free " "
EXTENT 3 addr=110450098
Chunk 1104500a8 sz= 41392 perm "perm " alo=41392
Chunk 11045a258 sz= 23976 free " "
Total heap size = 261544
FREE LISTS:
Bucket 0 size=56
Bucket 1 size=88
Bucket 2 size=152
Bucket 3 size=168
Bucket 4 size=280
Bucket 5 size=432
Bucket 6 size=536
Bucket 7 size=1048
Bucket 8 size=2072
Bucket 9 size=4120
Bucket 10 size=8216
Chunk 110480090 sz= 16184 free " "
Bucket 11 size=16408
Chunk 11045a258 sz= 23976 free " "
Chunk 110489868 sz= 26520 free " "
Chunk 110484088 sz= 22136 free " "
Bucket 12 size=32792
Chunk 110460928 sz= 63192 free " "
Chunk 110491f08 sz= 57592 free " "
Bucket 13 size=65560
Bucket 14 size=131096
Bucket 15 size=262168
Bucket 16 size=524312
Bucket 17 size=2097176
Total free space = 209600
UNPINNED RECREATABLE CHUNKS (lru first):
PERMANENT CHUNKS:
Chunk 110490090 sz= 7800 perm "perm " alo=4480
Chunk 110483fc8 sz= 192 perm "perm " alo=192
Chunk 110460090 sz= 2200 perm "perm " alo=2200
Chunk 1104500a8 sz= 41392 perm "perm " alo=41392
Permanent space = 51584
******************************************************
*** 2011-10-16 04:31:31.116
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [729], [360], [space leak], [], [], [], [], []
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst+001c bl ksedst1 088424844 ? 041124844 ?
ksedmp+0290 bl ksedst 104A506E8 ?
ksfdmp+0018 bl 03F4BE78
kgeriv+0108 bl _ptrgl
kgesiv+0080 bl kgeriv 10008FD0C ? 1100CAFF0 ?
000000000 ? 00000000A ?
1100CB230 ?
ksesic2+0060 bl kgesiv 110000BF8 ? 104B032A8 ?
FFFFFFFFFFF9260 ? 000000000 ?
7000013FF453A10 ?
ksmuhe+02dc bl ksesic2 2D9000002D9 ? 000000000 ?
000000168 ? 000000001 ?
00000000A ? 104A4F2D8 ?
000000000 ? 000000000 ?
ksmugf+01b8 bl 03F49FA0
ksuxds+0c04 bl 01FB5D60
ksudel+0054 bl ksuxds 7000013FF452BF0 ? 104B032A8 ?
opilof+0c7c bl 03F49D84
opiodr+0ae0 bl _ptrgl
ttcpip+1020 bl _ptrgl
opitsk+1124 bl ttcpip 1100CB0D8 ? FFFFFFFFFFFBBB0 ?
000000001 ? 000000000 ?
FFFFFFFFFFFBB30 ? 1100E0428 ?
000000000 ? 1104B0B70 ?
opiino+0990 bl opitsk 000000000 ? 000000000 ?
opiodr+0ae0 bl _ptrgl
opidrv+0484 bl 01FB7E64
sou2o+0090 bl opidrv 3C02AB90DC ? 440660000 ?
FFFFFFFFFFFF9D0 ?
opimai_real+01bc bl 01FB5C2C
main+0098 bl opimai_real 000000000 ? 000000000 ?
__start+0098 bl main 000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------
在TRACE文件中,这个记录信息表明了内存泄漏的存在:
Chunk 110489700 sz= 360 freeable "K2I iter "
而在TRACE文件中,还存在opilof函数,说明找个会话在进行LOGOFF操作。其实对于4000以下的内存泄漏,被认为是安全的,Oracle甚至提供了EVENTS 10262可以屏蔽这个错误的产生。而如果在alert文件中发现这个错误时,曾经泄漏的内存已经被释放,因此这个问题不会对实例的运行造成影响。
如果错误频繁发生,或者泄漏的空间超过4000或更高,可以进一步去分析,或者去寻找专门的补丁,Metalink文档Understanding and Diagnosing ORA-600 [729] Space Leak Errors [ID 403584.1]介绍了space leak相关的内容。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-709392/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-709392/