Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

42

积分

0

好友

1

主题
1#
发表于 2012-7-17 23:39:47 | 查看: 6764| 回复: 5
ORA-00600: 内部错误代码, 参数: [kgscCacheHit]版本:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: HP-UX
Node name: ahpmpdb1
Release: B.11.31
之前的版本是10.2.0.4也有这个问题

现象:
ORA-00600: 内部错误代码, 参数: [kgscCacheHit],出现比较频繁,最近发现出现600错误之后,这个会话就会进入inactive状态,并且其事务占用的资源不会释放,
会blocking其他会话,导致部分业务不能继续。但是始终找不到引起错误的sql语句。
oracle metalink也只能忽悠我升级11g,希望大神分析一下,看看能不能发现引起内部错误的根源在哪。


trace详见附件。谢谢。

600trace.rar

990.5 KB, 下载次数: 1285

2#
发表于 2012-7-18 09:29:48
看一下SESSION_CACHED_CURSORS是多少

回复 只看该作者 道具 举报

3#
发表于 2012-7-19 10:10:07
检查了,是默认的20。
奇怪的是这个应用在几个地方部署后都有这个错误。

回复 只看该作者 道具 举报

4#
发表于 2012-7-19 16:10:00
pmdb1_ora_16679.trc

  1. SO: c00000195dca8ec0, type: 4, owner: c00000195c8af2a0, flag: INIT/-/-/0x00
  2.     (session) sid: 3991 trans: c0000019048a8988, creator: c00000195c8af2a0, flag: (100041) USR/- BSY/-/-/-/-/-
  3.               DID: 0001-0558-00000439, short-term DID: 0001-0558-00000240
  4.               txn branch: 0000000000000000
  5.               oct: 0, prv: 0, sql: 0000000000000000, psql: c000001965a24028, user: 44/SGPMS
  6.     service name: pmdb
  7.     O/S info: user: weblogic, term: , ospid: 1234, machine: ahyxweb18
  8.               program:
  9.     last wait for 'row cache lock' wait_time=0.000439 sec, seconds since wait started=1
  10.                 cache id=b, mode=0, request=3
  11.                 blocking sess=0x0000000000000000 seq=22969
复制代码


pmdb1_ora_20717.trc

  1. SO: c00000195ccec3e0, type: 4, owner: c00000195e8bde70, flag: INIT/-/-/0x00
  2.     (session) sid: 4258 trans: c00000190bd8fc20, creator: c00000195e8bde70, flag: (100041) USR/- BSY/-/-/-/-/-
  3.               DID: 0001-0509-000001B9, short-term DID: 0001-0509-00000007
  4.               txn branch: 0000000000000000
  5.               oct: 0, prv: 0, sql: 0000000000000000, psql: c000001965a24028, user: 44/SGPMS
  6.     service name: pmdb
  7.     O/S info: user: weblogic, term: , ospid: 1234, machine: ahyxweb11
  8.               program:
  9.     last wait for 'row cache lock' wait_time=0.000135 sec, seconds since wait started=1
  10.                 cache id=b, mode=0, request=3
  11.                 blocking sess=0x0000000000000000 seq=23844
复制代码


user: 44/SGPMS - 表示会话使用SGPMS用户登录
flag: (100041) USR/- BSY/-/-/-/-/-  - User Session + Session is busy. It's in a call
sql: 0000000000000000 - 当前无SQL语句执行
psql: c000001965a24028 - 最后调用的SQL,SQL原文如下

  1. insert into S_APP_ELEC_ADDR (APP_ID, ELEC_ADDR_ID, PROVINCE_CODE, CITY_CODE, COUNTY_CODE, STREET_CODE, VILLAGE_CODE, ROAD_CODE, COMMUNITY_CODE, PLATE_NO, APP_ELEC_ADDR_ID) values (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11)
复制代码


照这个线索看看能不能找到出错的应用代码,构造一个可重现的用例,然后我们再来分析触发的必要条件。

回复 只看该作者 道具 举报

5#
发表于 2012-7-19 16:22:52
pmdb1_ora_16679.trc
  1. -----------------------------------------------------------
  2. -------------- Generic Session Cached Cursors Dump --------
  3. -----------------------------------------------------------
  4. hash table=9fffffffbf3c3490 cnt=20 LRU=9fffffffbf3bac90 cnt=20 hit=2095 max=20 NumberOfTypes=4
  5. type#0 name=KQD     count=1
  6. type#1 name=KQD BUN count=0
  7. type#2 name=KKS     count=19
  8. type#3 name=KNT     count=0
复制代码
pmdb1_ora_20717.trc
  1. -----------------------------------------------------------
  2. -------------- Generic Session Cached Cursors Dump --------
  3. -----------------------------------------------------------
  4. hash table=9fffffffbf3c3490 cnt=20 LRU=9fffffffbf3bac90 cnt=20 hit=4649 max=20 NumberOfTypes=4
  5. type#0 name=KQD     count=1
  6. type#1 name=KQD BUN count=0
  7. type#2 name=KKS     count=19
  8. type#3 name=KNT     count=0
复制代码
kgscCacheHit多数是session cursor cache hit的意思,从trc文件中可以看到这两个会话缓存的游标数都已经达到参数定义的上限20了。

我们再依次来看出错信息,首先是16679的
ORA-00600: 内部错误代码, 参数: [kgscCacheHit], [0x000000000], [0x9FFFFFFFBF3E5FC8], [0], [146], [], [], []
  1. Bucket#146 seg=9fffffffbf3c4fe8 nit=4 nal=4 ips=4 sz=32 flg=3 ucnt=0
  2.    0 cob=9fffffffbf3e5fc8 0 flg=0 typ=2 idx=92 cur=0000000000000000 lru=0 flg=0 hdl=0000000000000000
  3.    1 cob=9fffffffbf3e5fe8 0 flg=0 typ=2 idx=10092 cur=0000000000000000 lru=0 flg=0 hdl=0000000000000000
  4.    2 cob=9fffffffbf3e6008 0 flg=0 typ=0 idx=0 cur=0000000000000000 lru=0 flg=0 hdl=0000000000000000
  5.    3 cob=9fffffffbf3e6028 0 flg=0 typ=0 idx=0 cur=0000000000000000 lru=0 flg=0 hdl=0000000000000000
复制代码
参数中的146看来指的bucket#可能性较高,但这个不确定

接下来是20717的
ORA-00600: 内部错误代码, 参数: [kgscCacheHit], [0x000000000], [0x9FFFFFFFBF3E1A70], [0], [146], [], [], []

  1. Bucket#146 seg=9fffffffbf3c4fe8 nit=4 nal=4 ips=4 sz=32 flg=3 ucnt=0
  2.    0 cob=9fffffffbf3e1a70 0 flg=0 typ=2 idx=92 cur=0000000000000000 lru=0 flg=0 hdl=0000000000000000
  3.    1 cob=9fffffffbf3e1a90 0 flg=0 typ=2 idx=10092 cur=0000000000000000 lru=0 flg=0 hdl=0000000000000000
  4.    2 cob=9fffffffbf3e1ab0 0 flg=0 typ=0 idx=0 cur=0000000000000000 lru=0 flg=0 hdl=0000000000000000
  5.    3 cob=9fffffffbf3e1ad0 0 flg=0 typ=0 idx=0 cur=0000000000000000 lru=0 flg=0 hdl=0000000000000000
复制代码
这里我有个疑问,问什么2次出错都涉及到了bucket#146,更奇怪的是bucket146#中并无有效游标,因为hdl=0000000000000000,为什么出错了?
不知道增大SESSION_CACHED_CURSORS是否能缓解?

高手们各抒己见吧~

[ 本帖最后由 clevernby 于 2012-7-19 16:43 编辑 ]

回复 只看该作者 道具 举报

6#
发表于 2012-7-22 19:43:48
ODM DATA:

10.2.0.5.0+ HPUX + RAC

ORA-00600: 内部错误代码, 参数: [kgscCacheHit], [0x000000000], [0x9FFFFFFFBF3E5FC8], [0], [146], [], [], []
No current SQL statement being executed.
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedst()+64          call     ksedst1()            000000000 ? 000000001 ?
ksedmp()+2176        call     ksedst()             000000000 ?
                                                   C000000000000D20 ?
                                                   4000000004029DE0 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ?
ksfdmp()+112         call     ksedmp()             000000003 ?
                                                   9FFFFFFFFFFF47A0 ?
                                                   60000000000BA348 ?
                                                   9FFFFFFFFFFF4D70 ?
                                                   C000000000000999 ?
                                                   4000000004071E50 ?
kgerinv()+304        call     ksfdmp()             9FFFFFFFFFFF5300 ?
                                                   000000003 ?
                                                   9FFFFFFFFFFF4D80 ?
                                                   60000000000BA348 ?
                                                   C000000000000612 ?
                                                   40000000098B5310 ?
kgeasnmierr()+144    call     kgerinv()            60000000000318D0 ?
                                                   4000000001AD82D0 ?
                                                   6000000000032988 ?
                                                   4000000001AD82D0 ?
                                                   9FFFFFFFFFFF5340 ?
$cold_kgscCacheHit(  call     kgeasnmierr()        60000000000318D0 ?
)+128                                              9FFFFFFFBF3A63B0 ?
                                                   9FFFFFFFBF3A63C0 ?
                                                   6000000000032D00 ?
                                                   000000002 ? 000000000 ?
                                                   000000002 ?
                                                   9FFFFFFFBF3E5FC8 ?
kgscFindCursor()+73  call     $cold_kgscCacheHit(  60000000000318D0 ?
6                             )                    000000008 ?
                                                   9FFFFFFFBF3E5FC8 ?
                                                   C000000000000B1B ?
                                                   9FFFFFFFFFFF5470 ?
kkspsc0()+480        call     kgscFindCursor()     60000000000318D0 ?
                                                   000000002 ?
                                                   9FFFFFFFFFFF5450 ?
                                                   9FFFFFFFFFFF5470 ?
                                                   60000000000BA348 ?
                                                   C000000000000EA5 ?
                                                   4000000003064180 ?
                                                   0000282DB ?
kksParseCursor()+35  call     kkspsc0()            9FFFFFFFBF3C1910 ?
2                                                  9FFFFFFFFFFF9FE0 ?
                                                   00000004A ? 000000003 ?
                                                   000000006 ? 0000000A4 ?
                                                   000000000 ?



stack call :

kksParseCursor=>kkspsc0=> kgscFindCursor => cold_kgscCacheHit

就代码来看 是在parse 解析阶段

匹配的bug note:

Hdr: 10300489 10.2.0.5 RDBMS 10.2.0.5 UNKNOWN PRODID-5 PORTID-197 ORA-600
Abstract: ORA-600 [KGSCCACHEHIT] AFTER UPGRADE TO 10.2.0.5 FROM 10.2.0.3


----

PROBLEM:
--------
The problem ORA-600 [kgscCacheHit] on 10.2.0.5 after upgrading from
10.2.0.3.

Complete Error Message
-----------------------

ORA-600: internal error code, arguments: [kgscCacheHit],
[0x9FFFFFFF8AA65550], [0x9FFFFFFF8AA65240], [65587], [65587], [], [], []

DIAGNOSTIC ANALYSIS:
--------------------
The customer is hit by this error whenever they run the below query via their
application on PRODUCT and PRODUCT_TRACKING table

Current SQL
--------------

insert into
PRODUCT_TRACKING(CUSTOMER_ID,PRODUCT_CODE,PRODUCT_ISSUE_NUM,PROD_TRACK_VERSION
,ITEM_ID,CTCR_BATCH_PROG_ID,CTCR_BATCH_PROG_DT,CTCR_ONLINE_OPER_ID,CTCR_ONLINE
_P..
...
..
MDD'),:b101:i101,:b102:i102,:b103:i103,:b104:i104,:b105:i105,:b106:i106,:b107:
i107,:b108:i108,:b109:i109,:b110:i110,:b111:i111,:b112:i112,:b113:i113,:b114:i
114,:b115:i115,:b116:i116)


update PRODUCT PRODUCT  set
PRODUCT.CTCR_BATCH_PROG_ID=:b1:i1,PRODUCT.CTCR_BATCH_PROG_DT=TO_DATE(:b2:i2,'Y
YYYMMDD'),PRODUCT.CTCR_ONLINE_OPER_ID=:b3:i3,PRODUCT.CTCR_ONLINE_PROG_ID=:b4:i
4,
..
..
RODUCT.ESTIMATED_USAGE_BOTS_AMT=:b95:i95 where ((CUSTOMER_ID=:b96 and
PRODUCT_CODE=:b97) and PRODUCT_ISSUE_NUM=:b98)


The issue look similar to BUG  7423771 ( whose base bug is Base Bug 6119017 )
but from the patchsets note for 10.2.0.5 it states , this bug fix is already
included.

WORKAROUND:
-----------
NONE

RELATED BUGS:
-------------
7423771

REPRODUCIBILITY:
----------------

TEST CASE:
----------

STACK TRACE:
------------
Call stack
---------------

ksedst <- ksedmp <- ksfdmp <- kgerinv <- kgeasnmierr
  <- $cold_kgscCacheHit <- kgscGetCursor <- kgscGetCursor2 <- qccsxctt <-
kntxit
   <- kxtrexe <- insart <- $cold_insarp <- insrow <- insdrv
   <- inscovexe <- insExecStmtExecIniE <- ngine <- insexe <- ngine
    <- opiexe <- opiodr <- ttcpip <- opitsk <- opiino
    <- opiodr <- opidrv <- sou2o <- opimai_real <- main
     <- main_opd_entry


stack call 较为相似, 这似乎是在10.2.0.5中伪修复的bug


建议:

1.  减少 hard parse的可能性, 包括使用cursor_sharing session_cached_cursors 等参数
2.  升级到 版本11.2.0.3

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-16 02:28 , Processed in 0.058986 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569