ORA-600(kcbshlc_1)和ORA-7445(kggchk)錯誤
以前同時記錄兩個ORA-600錯誤，多半是由於這個兩個錯誤在同時，是同一次故障的不同表現，而這次兩個錯誤則是分別出現。
客戶的10.2.0.4的邏輯STANDBY備庫上前後幾次出現了這兩個錯誤：
Thu Jun 16 13:45:05 2011
Errors in file /u01/app/oracle/admin/db/bdump/db_pmon_27660.trc:
ORA-07445: exception encountered: core dump [kggchk()+77] [SIGSEGV] [Address
not mapped to object] [0x000000000] [] []
Thu Jun 16 13:45:13 2011
CKPT: terminating instance due to error 472
Instance terminated by CKPT, pid = 27670
.
.
.
Sat Jun 25 01:44:02 2011
Errors in file /u01/app/oracle/admin/db/bdump/db_pmon_18907.trc:
ORA-00600: internal error code, arguments: [kcbshlc_1], [5], [], [], [], [],
[], []
Sat Jun 25 01:44:04 2011
Errors in file /u01/app/oracle/admin/db/bdump/db_pmon_18907.trc:
ORA-00600: internal error code, arguments: [kcbshlc_1], [5], [], [], [], [],
[], []
Sat Jun 25 01:44:04 2011
PMON: terminating instance due to error 472
Sat Jun 25 01:44:04 2011
krvxerpt: Errors detected in process 20, role reader.
Sat Jun 25 01:44:04 2011
krvxmrs: Leaving by exception: 472
Sat Jun 25 01:44:04 2011
Errors in file /u01/app/oracle/admin/db/bdump/db_p000_19090.trc:
ORA-00472: PMON process terminated with error
LOGSTDBY status: ORA-00472: PMON process terminated with error
.
.
.
Mon Oct 31 23:23:03 2011
Errors in file /u01/app/oracle/admin/db/bdump/db_pmon_20147.trc:
ORA-07445: exception encountered: core dump [kggchk()+77] [SIGSEGV] [Address
not mapped to object] [0x000000000] [] []
Mon Oct 31 23:23:07 2011
CJQ0: terminating instance due to error 472
Mon Oct 31 23:23:07 2011
krvxerpt: Errors detected in process 20, role reader.
Mon Oct 31 23:23:07 2011
krvxmrs: Leaving by exception: 472
Mon Oct 31 23:23:07 2011
Errors in file /u01/app/oracle/admin/db/bdump/db_p000_20224.trc:
ORA-00472: PMON process terminated with error
LOGSTDBY status: ORA-00472: PMON process terminated with error
Mon Oct 31 23:23:07 2011
Errors in file /u01/app/oracle/admin/db/bdump/db_psp0_20149.trc:
ORA-00472: PMON process terminated with error
之所以將兩個錯誤合在一起是有原因的，一方面無論是ORA-600(kcbshlc_1)錯誤，還是ORA-7445(kggchk)錯誤，錯誤都出現在PMON程式上，而且都直接導致了資料庫的崩潰；其二，邏輯STANDBY的應用一般都是隻讀應用，一般來說出錯機率最大的都是應用程式，而這兩個錯誤在這方面的表相是一樣的，雖然都導致了資料庫崩潰，但是資料庫重啟之後，錯誤並不會馬上重現，日誌的應用可以順利的執行，這說明錯誤和日誌應用沒有必然的因果關係；其三，也是最重要的一點，在ORA-7445的詳細trace中，在kggchk函式之前出現的就是kcbshlc函式：
*** 2011-10-31 23:23:03.108
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [kggchk()+77] [SIGSEGV] [Address
not mapped to object] [0x000000000] [] []
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31 call ksedst1() 000000000 ? 000000001 ?
2A97172D50 ?
2A97172DB0 ?
2A97172CF0 ? 000000000 ?
ksedmp()+610 call ksedst() 000000000 ? 000000001 ?
2A97172D50 ? 2A97172DB0 ?
2A97172CF0 ? 000000000 ?
ssexhd()+629 call ksedmp() 000000003 ? 000000001 ?
2A97172D50 ? 2A97172DB0 ?
2A97172CF0
? 000000000 ?
__funlockfile()+64 call ssexhd() 00000000B ? 2A97173D70 ?
2A97173C40 ? 2A97172DB0 ?
2A97172CF0 ? 000000000 ?
kggchk()+77 signal __funlockfile() 0066876E0 ? 000000000 ?
000000018 ? 0010F4468 ?
000000000 ? 0052EBEA0 ?
kcbshlc()+105 call kggchk() 0066876E0 ? 000000000 ?
000000018 ? 0010F4468 ?
000000000 ? 0052EBEA0 ?
kslilcr()+770 call kcbshlc() 0066876E0 ? 84EC40698 ?
000000018 ? 0010F4468 ?
000000000 ? 0052EBEA0 ?
ksl_cleanup()+1567 call kslilcr() 0010F4468 ? 000000000 ?
000000000 ? 84EC40698 ?
0066876E0 ? 0052EBEA0 ?
ksuxfl()+492 call ksl_cleanup() 000000000 ? 000000000 ?
000000000 ? 84EC40698 ?
0066876E0 ? 0052EBEA0 ?
ksuxda()+55 call ksuxfl() 85F3A6168 ? 000000000 ?
000000000
? 84EC40698 ?
0066876E0 ? 0052EBEA0 ?
ksucln()+1390 call ksuxda() 85F3A6168 ? 000000000 ?
000000000 ? 84EC40698 ?
0066876E0 ? 0052EBEA0 ?
ksbrdp()+794 call ksucln() 060008100 ? 000000000 ?
043FC1A0B ? 84EC40698 ?
0066876E0 ? 0052EBEA0 ?
opirip()+616 call ksbrdp() 060008100 ? 000000000 ?
000000001 ? 060008100 ?
0066876E0 ?
0052EBEA0 ?
opidrv()+582 call opirip() 000000032 ? 000000004 ?
7FBFFFF738 ? 060008100 ?
0066876E0 ? 0052EBEA0 ?
sou2o()+114 call opidrv() 000000032 ? 000000004 ?
7FBFFFF738 ? 060008100 ?
0066876E0 ? 0052EBEA0 ?
opimai_real()+317 call sou2o() 7FBFFFF710 ? 000000032 ?
000000004 ? 7FBFFFF738 ?
0066876E0 ? 0052EBEA0 ?
main()+116 call opimai_real() 000000003 ? 7FBFFFF7A0 ?
000000004 ? 7FBFFFF738 ?
0066876E0 ? 0052EBEA0 ?
__libc_start_main() call main() 000000003 ? 7FBFFFF7A0 ?
+219
000000004 ? 7FBFFFF738 ?
0066876E0 ? 0052EBEA0 ?
_start()+42 call __libc_start_main() 000713988 ? 000000001 ?
7FBFFFF8E8 ? 005288D00 ?
000000000 ? 000000003 ?
--------------------- Binary Stack Dump ---------------------
根據上面三點進行判斷，這兩個錯誤應該是同一個BUG引發的，根據MOS查詢ORA-600 [kcbshlc_1] [ID 1274837.1]文件記錄的資訊最為接近，要解決這個問題可以透過將資料庫版本升級到10.2.0.4.3或10.2.0.5。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/4227/viewspace-713527/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- ORA-600(kcblasm_1)和ORA-7445(kxhfNewBuffer)錯誤ASM
- ORA-600(1403)和ORA-7445($cold_kslgetsl)錯誤
- 資料字典不一致造成大量ORA-600和ORA-7445錯誤
- ORA-7445(opipls)錯誤
- ORA-7445(_kkqtnloCbk)錯誤QT
- ORA-7445(kglLockIterator)錯誤
- ORA-7445(kkfipbr)錯誤
- ORA-600(kghfremptyds)和ORA-600(kghasp1)錯誤REM
- ORA-7445(qerixGetKey)錯誤
- ORA-7445(opitca)錯誤
- ORA-7445(kqlSubheapPin)錯誤APP
- sql出現結果集錯誤以及出現ora-600或者ora-7445錯誤的解決方法思路SQL
- ora-600 / ora-7445 loopOOP
- ORA-7445(ksxpsigosderr)錯誤Go
- ORA-600(KSFD_DECAIOPC)和ORA-600(kfioReapIO00)錯誤AIAPI
- ORA-600(kffmXpGet)錯誤
- ORA-7445(_intel_fast_memcpy.A)錯誤IntelASTmemcpy
- ORA-600(kcbchg1_12)和ORA-600(kdifind:kcbget_24)錯誤
- ORA-600(ktfbbsearch-8)和ORA-600(kewrose_1)錯誤ROS
- ORA-600(kjbrchkpkeywait:timeout)和ORA-600(kclcls_8)錯誤AI
- 儲存故障時的ORA-7445錯誤
- ORA-7445(dbgrmqmqpk_query_pick_key)錯誤MQ
- ORA-600 kcblasm_1和kghasp1錯誤ASM
- ORA-600(kgh_heap_sizes:ds)和ORA-600(kghGetHpSz1)錯誤
- ORA-600(kcbgcur_1)錯誤GC
- ORA-600 [ttcgcshnd-1 ]錯誤GC
- ORA-600(kclgclk_7)錯誤GC
- ORA-600(kcbnew_3)錯誤
- ORA-600(qersqCloseRem-2)錯誤REM
- ORA-600(qctopn1)錯誤
- ORA-600(kcblasm_1)錯誤ASM
- ORA-600(qkaffsindex5)錯誤Index
- ORA-600(kghuclientasp_03)錯誤client
- ORA-600(ttcgcshnd-2)錯誤GC
- ORA-600(kolaslGetLength-1)錯誤
- ORA-600(kssadd: null parent)錯誤Null
- ORA-600(504)(row cache objects)錯誤Object
- ORA-600(ktrgcm_3)錯誤GC