ORA-00600 [3756]内部错误一例

一套Linux上的10.2.0.4系统出现3756内部错误:

Wed Sep  2 23:56:51 2009
ORA-00600: internal error code, arguments: [3756], [1], [2], [2149767406], [2], [2149796313], [], []
ORA-600 signalled during: ALTER DATABASE OPEN...

/*   详细的trace文件内容   */

Successfully allocated 2 recovery slaves
Using 550 overflow buffers per recovery slave
Thread 1 checkpoint: logseq 139, block 125089, scn 10739730905
cache-low rba: logseq 139, block 125185
on-disk rba: logseq 139, block 125195, scn 10739731787
start recovery at logseq 139, block 125185, scn 0
----- Redo read statistics for thread 1 -----
Read rate (ASYNC): 0Kb in 0.10s => 0.00 Mb/sec
Total physical reads: 4096Kb
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 0
Average hash chain = 0/0 = 0.0
Max compares per lookup = 0
Avg compares per lookup = 0/0 = 0.0
----------------------------------------------
*** 2009-09-02 23:56:50.288
KCRA: start recovery claims for 0 data blocks
*** 2009-09-02 23:56:50.288
KCRA: blocks processed = 0/0, claimed = 0, eliminated = 0
*** 2009-09-02 23:56:50.289
Recovery of Online Redo Log: Thread 1 Group 10 Seq 139 Reading mem 0
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 0
Average hash chain = 0/0 = 0.0

Max compares per lookup = 0
Avg compares per lookup = 0/0 = 0.0
----------------------------------------------
*** 2009-09-02 23:56:50.289
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [3756], [1], [2], [2149767406], [2], [2149796313], [], []
Current SQL statement for this session:
ALTER DATABASE OPEN
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
7FFF45294410 ? 7FFF45294470 ?
7FFF452943B0 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
7FFF45294410 ? 7FFF45294470 ?
7FFF452943B0 ? 000000000 ?
ksfdmp()+21          call     ksedmp()             000000003 ? 000000001 ?
7FFF45294410 ? 7FFF45294470 ?
7FFF452943B0 ? 000000000 ?
kgeriv()+176         call     ksfdmp()             000000003 ? 000000001 ?
7FFF45294410 ? 7FFF45294470 ?
7FFF452943B0 ? 000000000 ?
kgesiv()+119         call     kgeriv()             0068966E0 ? 007448630 ?
000000000 ? 000000000 ?
7FFF452943B0 ? 000000000 ?
ksesic5()+215        call     kgesiv()             0068966E0 ? 007448630 ?
000000EAC ? 000000005 ?
7FFF45295190 ? 000000000 ?
kctrec()+4141        call     ksesic5()            000000EAC ? 000000000 ?
000000001 ? 000000000 ?
000000002 ? 000000000 ?
kcvcrv()+4760        call     kctrec()             7FFF4529EBB0 ? 000000000 ?
007422F00 ? 007423568 ?
2AED1E397E00 ? 000000000 ?
kcfopd()+876         call     kcvcrv()             7FFF4529F358 ? 000000000 ?
000000006 ? 007423568 ?
2AED1E397E00 ? 000000000 ?
adbdrv()+56506       call     kcfopd()             000000000 ? 000000000 ?
000000000 ? 000000000 ?
2AED1E397E00 ? 000000000 ?
opiexe()+13505       call     adbdrv()             000000000 ? 000000000 ?
0F6FFF9B0 ? 000000000 ?
2AED1E397E00 ? 000000000 ?

该错误一般不会导致实例crash，大多数情况下可以通过重建控制文件规避。本文出自 “Ask Maclean Liu Oracle” 博客，请务必保留此出处http://maclean.blog.51cto.com/2923249/1276848