一套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，大多数情况下可以通过重建控制文件规避。