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,大多数情况下可以通过重建控制文件规避。
posted on 2009-09-02 10:35 Oracle和MySQL 阅读(441) 评论(0) 编辑 收藏 举报