ORA-00600: 內部錯誤程式碼, 引數: [kcblasm_1], [103], [], [], [], [], [], []

dcswinner發表於2012-10-13

今天在一生產資料庫上再次出現ORA-00600: 內部錯誤程式碼, 引數: [kcblasm_1], [103], [], [], [], [], [], []錯誤。

檢視alert日誌資訊如下:

Thread 1 advanced to log sequence 72405 (LGWR switch)
  Current log# 5 seq# 72405 mem# 0: +DATA/emsbusi/onlinelog/group_5.384.760317947
Fri Oct 12 17:52:58 CST 2012
Errors in file /home/oracle/admin/emsbusi/udump/emsbusi1_ora_18210.trc:
ORA-00600: 內部錯誤程式碼, 引數: [kcblasm_1], [103], [], [], [], [], [], []
Fri Oct 12 17:53:14 CST 2012
Trace dumping is performing id=[cdmp_20121012175314]
Fri Oct 12 17:54:23 CST 2012
Thread 1 advanced to log sequence 72406 (LGWR switch)
  Current log# 1 seq# 72406 mem# 0: +DATA/emsbusi/onlinelog/group_1.508.760317925
Fri Oct 12 17:58:14 CST 2012
Thread 1 advanced to log sequence 72407 (LGWR switch)
  Current log# 2 seq# 72407 mem# 0: +DATA/emsbusi/onlinelog/group_2.419.760317931
Fri Oct 12 17:59:44 CST 2012

檢視trace檔案資訊:

*** ACTION NAME:(SQL Window - 新增線下使用者.sql) 2012-10-12 17:52:58.581
*** MODULE NAME:(PL/SQL Developer) 2012-10-12 17:52:58.581
*** SERVICE NAME:(SYS$USERS) 2012-10-12 17:52:58.581
*** SESSION ID:(631.14032) 2012-10-12 17:52:58.581
*** 2012-10-12 17:52:58.581
ksedmp: internal or fatal error
ORA-00600: 內部錯誤程式碼, 引數: [kcblasm_1], [103], [], [], [], [], [], []
Current SQL statement for this session:
select  * from view_api_orders
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ssd_unwind_bp: unhandled instruction at 0x3d12cfe instr=f
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFF6A4CF040 ? 7FFF6A4CF0A0 ?
                                                   7FFF6A4CEFE0 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7FFF6A4CF040 ? 7FFF6A4CF0A0 ?
                                                   7FFF6A4CEFE0 ? 000000000 ?
ksfdmp()+63          call     ksedmp()             000000003 ? 000000001 ?
                                                   7FFF6A4CF040 ? 7FFF6A4CF0A0 ?
                                                   7FFF6A4CEFE0 ? 000000000 ?
kgerinv()+161        call     ksfdmp()             006AE9A20 ? 000000003 ?
                                                   7FFF6A4CF040 ? 7FFF6A4CF0A0 ?
                                                   7FFF6A4CEFE0 ? 000000000 ?
kgeasnmierr()+163    call     kgerinv()            006AE9A20 ? 2AFE5EA40040 ?
                                                   7FFF6A4CF0A0 ? 7FFF6A4CEFE0 ?
                                                   000000000 ? 000000000 ?
kcblasm1()+113       call     kgeasnmierr()        006AE9A20 ? 2AFE5EA40040 ?
                                                   7FFF6A4CF0A0 ? 7FFF6A4CEFE0 ?
                                                   000000000 ? 000000067 ?
kcblasm()+52         call     kcblasm1()           2AFE5EF5EDF8 ? 7FFF6A4CEFE0 ?
                                                   7FFF6A4CF0A0 ? 7FFF6A4CEFE0 ?
                                                   000000000 ? 000000067 ?
kxhfFndFreeSlot()+2  call     kcblasm()            2AFE5EF5EDF8 ? 000001000 ?
65                                                 7FFF6A4CF0A0 ? 7FFF6A4CEFE0 ?
                                                   000000000 ? 000000067 ?
發現這個錯誤是有一個同事執行一個sql引起,這個sql中涉及到幾張很大的表做關聯。

檢視metalink資訊:

Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.5.0 and later   [Release: 10.2 and later ]
Information in this document applies to any platform.


Symptoms
When executing a statement using a SELECT getting:
ORA-00600: internal error code, arguments: [kcblasm_1], [103], [], [], [], [], [], []
The execution plan from the ORA-600 trace file is showing hash join is used.
Call Stack is including:
kcblasm1 kcblasm kxhfFndFreeSlot kxhfNewBuffer qerhjGetNewBuffer ksxb1bqb kxhrPack
Cause
The issue was investigated in:
Bug 9800302 - 10.2.0.5 GETTING ORA-00600 [KCBLASM_1]
closed as duplicate of:Bug 7612454 - Abstract: DSS:PERF REGRESSIONS IN SERIAL DIRECT READS fixed in 11.2.
As per development team the number of slots available for direct I/Os (limited to 4096) forced the hash-join algorithm to operate on fewer number of slots and resulted in more spills to disk. This caused:
    direct path IO to perform. worse in 10.2.0.5 than earlier releases with more "direct path read" operations or
    ORA-600 [kcblasm_1] errors.

Solution
1. Upgrade the database to 11.2.
OR
2. Apply &incFamilyProds=false&flag=search))" target=_blank>Patch 7612454 available on MOS. If a patch is not currently available on top of your database version and/or platform. please raise a Service Request to request for it.
Please be sure that your database version qualifies for getting a new patch as per Note 209768.1 and Note 742060.1.
OR
3. Use the workaround of setting:
"_hash_join_enabled"= false

這個資料庫的版本正是10.2.0.5.0,報錯的資訊和metalink的資訊一致,因此應該說是這個資料庫遇到bug了,按照metalink提供的辦法,只能做升級或者改隱含引數了。

升級在段時間內是不能完成,只能考慮改隱含引數了。給客戶報告後等客戶恢復即可調整了。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/12129601/viewspace-746350/,如需轉載,請註明出處,否則將追究法律責任。

相關文章