Oracle 11g ORA-600 [kjbrcrcvt:lms] 問題處理
環境描述： Redhat Enterprise 7.9 Oracle 11.2.0.4 RAC 3節點
問題描述：資料庫節點3出現hang，等待事件為ges cgs registration。
問題原因：觸發Bug 30562200 - RAC instance crash due to ORA-600 [kjbrcrcvt:lms] ，RAC例項的LMS由於ORA-600 [kjbrcrcvt:lms]而出現故障
解決方案：應用補丁Bug 31321944 - Database Hang with 'gc current request'<='gc buffer busy acquire'
分析過程：
1、資料庫節點3日誌：
alertnode3 log: Errors in file /u01/app/oracle/diag/rdbms/prod/prod3/trace/prod3_lmse_48530_i169417.trc: ORA-00600: internal error code, arguments: [kjbrcrcvt:lms], [], [], [], [],[], [], [], [], [], [], [] ... *** 2022-10-10 14:07:06.629 *** SESSION ID:(649.1) 2022-10-10 14:07:06.629 *** CLIENT ID:() 2022-10-10 14:07:06.629 *** SERVICE NAME:(SYS$BACKGROUND) 2022-10-10 14:07:06.629 *** MODULE NAME:() 2022-10-10 14:07:06.629 *** ACTION NAME:() 2022-10-10 14:07:06.629 Dump continued from file: /u01/app/oracle/diag/rdbms/prodbprodb3/trace/prodb3_lmse_48530.trc ORA-00600: internal error code, arguments: [kjbrcrcvt:lms], [], [], [], [], [], [], [], [], [], [], [] ========= Dump for incident 169417 (ORA 600 [kjbrcrcvt:lms]) ======== ----- Beginning of Customized Incident Dump(s) ----- GCS RESOURCE 0xd889af92f0 hashq [0xd9f14cf3b0,0xd88f4287c0] name[0x115fe8.3f1] pkey 224175.0 grant 0xd590794580 cvt 0xd4c9dbc160 send 0xd590794580@0,148 write (nil),0@65536 *** 2022-10-10 14:07:06.645 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0) ----- SQL Statement (None) ----- Current SQL information unavailable - no cursor. ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- skdstdst()+41 call kgdsdst() 000000000 ? 000000000 ? 7FFCDB61CCA0 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? ksedst1()+103 call skdstdst() 000000000 ? 000000000 ? 7FFCDB61CCA0 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? ksedst()+39 call ksedst1() 000000000 ? 000000001 ? 7FFCDB61CCA0 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? dbkedDefDump()+2746 call ksedst() 000000000 ? 000000001 ? 7FFCDB61CCA0 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? ksedmp()+41 call dbkedDefDump() 000000003 ? 000000002 ? 7FFCDB61CCA0 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? ksfdmp()+69 call ksedmp() 000000003 ? 000000002 ? 7FFCDB61CCA0 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? dbgexPhaseII()+1764 call ksfdmp() 000000003 ? 000000002 ? 7FFCDB61CCA0 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? dbgexExplicitEndInc call dbgexPhaseII() 7F854B219748 ? 7F8547E37A98 ? ()+755 7FFCDB625AB8 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? dbgeEndDDEInvocatio call dbgexExplicitEndInc 7F854B219748 ? 7F8547E37A98 ? nImpl()+769 () 7FFCDB625AB8 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? dbgeEndDDEInvocatio call dbgeEndDDEInvocatio 7F854B219748 ? 7F8547E37A98 ? n()+52 nImpl() 7FFCDB625AB8 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? kjbrrefping()+4118 call dbgeEndDDEInvocatio 7F854B219748 ? 7F8547E37A98 ? n() 7FFCDB625AB8 ? 7FFCDB61CD78 ? 7FFCDB621820 ? 000000002 ? kjbmprefuse()+2177 call kjbrrefping() D889AF92F0 ? D4D7FF9948 ? 7FFCDB625AB8 ? FFFFFFFF89AF9340 ? E5E37600010301 ? 1000800000000 ? kjmxmpm()+1014 call kjbmprefuse() 7F8543C141F8 ? D4D7FF9948 ? 7FFCDB625AB8 ? FFFFFFFF89AF9340 ? E5E37600010301 ? 1000800000000 ? kjmpbmsg()+4706 call kjmxmpm() 7F8543C141F8 ? D4D7FF9948 ? 7FFCDB625AB8 ? FFFFFFFF89AF9340 ? E5E37600010301 ? 1000800000000 ? kjmsm()+8021 call kjmpbmsg() 7F8543C141F8 ? D4D7FF9948 ? 7FFCDB625AB8 ? FFFFFFFF89AF9340 ? E5E37600010301 ? 1000800000000 ? ksbrdp()+1045 call kjmsm() 7F8543C141F8 ? D4D7FF9948 ? 7FFCDB625AB8 ? FFFFFFFF89AF9340 ? E5E37600010301 ? 1000800000000 ? opirip()+623 call ksbrdp() 7F8543C141F8 ? D4D7FF9948 ? 7FFCDB625AB8 ? FFFFFFFF89AF9340 ? E5E37600010301 ? 1000800000000 ? opidrv()+603 call opirip() 000000032 ? 000000004 ? 7FFCDB628448 ? FFFFFFFF89AF9340 ? E5E37600010301 ? 1000800000000 ? sou2o()+103 call opidrv() 000000032 ? 000000004 ? 7FFCDB628448 ? FFFFFFFF89AF9340 ? E5E37600010301 ? 1000800000000 ? opimai_real()+250 call sou2o() 7FFCDB628420 ? 000000032 ? 000000004 ? 7FFCDB628448 ? E5E37600010301 ? 1000800000000 ? ssthrdmain()+265 call opimai_real() 000000000 ? 7FFCDB628610 ? 000000004 ? 7FFCDB628448 ? E5E37600010301 ? 1000800000000 ? main()+201 call ssthrdmain() 000000003 ? 7FFCDB628610 ? 000000001 ? 000000000 ? E5E37600010301 ? 1000800000000 ? __libc_start_main() call main() 000000003 ? 7FFCDB6287B0 ? +245 000000001 ? 000000000 ? E5E37600010301 ? 1000800000000 ? _start()+41 call __libc_start_main() 000A177F0 ? 000000001 ? 7FFCDB6287A8 ? 000000000 ? E5E37600010301 ? 1000800000000 ? --------------------- Binary Stack Dump --------------------- 參考文件：Bug 31321944 - Database Hang with 'gc current request'<='gc buffer busy acquire' (Doc ID 31321944.8) Bug 30562200 - RAC instance crash due to ORA-600 [kjbrcrcvt:lms] -- Fix has regressed and replaced with fix in 31321944.8 (Doc ID 30562200.8)
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28373936/viewspace-2918601/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- ORA-600 733 問題處理案例分享
- ORACLE 11G EM 配置命令及問題處理Oracle
- 【ERROR】儲存鏈路問題造成oracle錯誤，ora-600[4193] 問題處理ErrorOracle
- redhat7 搭建oracle 11g RAC 問題與處理RedhatOracle
- Oracle啟動問題處理Oracle
- Oracle壞塊問題處理Oracle
- crontab對oracle操作問題處理Oracle
- oracle SP2-問題處理Oracle
- ORACLE問題處理十個指令碼Oracle指令碼
- Oracle delete 高水位線處理問題Oracledelete
- Oracle資料庫 ORA-600 [13013]故障處理Oracle資料庫
- oracle ora-600 Ktspgsb-1 錯誤處理案例Oracle
- Oracle日常問題處理ORA-04031Oracle
- oracle taf unknown 問題處理過程Oracle
- ORA-600 [2662]故障處理
- ORACLE懸疑分散式事務問題處理Oracle分散式
- linux處理oracle問題常用命令LinuxOracle
- Oracle CPU使用率過高問題處理Oracle
- Oracle_dg歸檔丟失問題處理Oracle
- Oracle資料庫無效物件問題處理Oracle資料庫物件
- 【故障處理】ORA-600:[13013],[5001]故障處理
- oracle 11g ASM問題OracleASM
- ORA-600 [15160]的處理
- 處理問題的方法
- perl中文處理問題
- 漢字處理問題？
- xml處理的問題XML
- 貨品問題處理
- [git] git問題處理Git
- oracle系統表空間過大問題處理Oracle
- Oracle資料庫中的逐行處理問題NEOracle資料庫
- 近期處理的Oracle資料庫問題總結Oracle資料庫
- oracle bdump 下.trc檔案過大問題處理Oracle
- ORA-600[6122]錯誤處理
- 一次ORA-600故障的處理
- Oracle日常問題處理-資料庫無法啟動Oracle資料庫
- pyinstaller打包cx_Oracle庫問題處理記錄Oracle
- Oracle 記一次ORA-00001問題處理Oracle