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

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › 大量library cache: mutex X
发新帖
xteitxu

62

积分

0

好友

3

主题

[RAC Clusterware] 大量library cache: mutex X

1#
发表于 2013-7-8 16:04:54 | 查看: 5489| 回复: 19

VERSION:11.1.0.7    OS:  WIN 2008
硬解析不多  ，SQL AREA的RELOADS较大   ，初步分析是ASSM自动内存分配导致的   ，大家有什么问题给提下  谢谢

mdlcnpro_awrrpt_1_28733_28734.zip

57.5 KB, 下载次数: 2684
学海无涯，技术至上！
2#
发表于 2013-7-8 16:08:35
Mutex Type        Location        Sleeps        Wait Time (ms)
Library Cache        kgllkdl1 85        396,004,906        0
Library Cache        kglhdgn1 62        119,599,541        0
Library Cache        kgllkc1 57        74,856,828        0
Library Cache        kglic1 49        7,859,963        0
Library Cache        kglhdgn2 106        1,540,626        0
Cursor Pin        kkslce [KKSCHLPIN2]        46,214        484,227
Cursor Parent        kksfbc [KKSPRTLOC1]        2,698        4
Library Cache        kgldtin1 42        44        0
Library Cache        kglati1 45        19        0
hash table        kkshListChanged [KKSHBKLOC10]        18        0
Library Cache        kglget2 2        6        0
Library Cache        kglabl1 58        5        0
Library Cache        kglkhfs1 52        4        0
Library Cache        kglpnal1 90        4        0
Library Cache        kglobld1 75        2        0

回复 只看该作者 道具 举报

3#
发表于 2013-7-8 16:13:57
Version Count        Executions         SQL Id        SQL Module        SQL Text
3,469                 9s6jy22p0a3jf                 ** SQL Text Not Available **
2,177                 4ht4ya8spqsu4                 ** SQL Text Not Available **
1,007        546        aw1ycdg41bb32         Palladium.Gateway.Window.Service.exe        INSERT INTO RSVAMT_TRACKING (C...
350                 3j9vafm2mjhur                 ** SQL Text Not Available **
320        6,283        0h3dgxrrs9mf3         w3wp.exe        SELECT ESGETCONDDESCCHN(:1, :2...
317                 2ub8db7jmfac7                 ** SQL Text Not Available **
288                 abwz0vhd1b7cz                 ** SQL Text Not Available **
266                 66u8z4rpn0351                 ** SQL Text Not Available **
212                 6wx9cm8knvgx7                 ** SQL Text Not Available **
209                 a39g3nh6hx8m8                 UPDATE EST_QUERY SET UPDBY=:1,...
163        227        d5uz9k7utxukt                 select decode(bitand(a.flags, ...
159        654        4hq04xk6kxmfj         w3wp.exe        INSERT INTO SYP_EVENTLOG (EVEN...
121        954        4xajgf8w1f769                 UPDATE CLAIMS_ALERT SET USER_C...


先查一下 这几个SQL version count高的原因

回复 只看该作者 道具 举报

4#
发表于 2013-7-8 16:27:42
刘大     前三个SQL在日常的操作里VERSION COUNT就那么多  每个SQL更新的列比较多。

回复 只看该作者 道具 举报

5#
发表于 2013-7-8 16:35:01
SQL更新的列都是绑定变量的

回复 只看该作者 道具 举报

6#
发表于 2013-7-8 19:20:00
xteitxu 发表于 2013-7-8 16:27
刘大     前三个SQL在日常的操作里VERSION COUNT就那么多  每个SQL更新的列比较多。 ...

你可以统计一下 那几个SQL 对应 library cache: mutex X 等待事件最多 ，利用ASh

如果不出意外的话 就是这几个

回复 只看该作者 道具 举报

7#
发表于 2013-7-10 16:15:06
9s6jy22p0a3jf  这个SQL :
UPDATE CLAIMS
     SET REFERREDPHYSICIAN            = :1,
         REFERREDPHYSICIANSPECIALTY   = :2,
         REFERREDOPFORMNO             = :3,
         CARD_NO                      = :4,
         PAYOR_CODE                   = :5,
         PHYSICIAN_ID                 = :6,
         AUTHORIZATION_CODE           = :7,
         CLAIM_NO                     = :8,
         PROVIDER_ID                  = :9,
         PROVIDER_TYPE                = :10,
         DOCTOR_NAME1                 = :11,
............................ WHERE CLAIMS_ID = :291
这个SQL不能共享 从v$sql_shared_cursor  看到都是bind_mismatch
听开发人员描述 ，通过CLAIMS_ID做条件从页面调出信息后，然后对CLAIMS表做UPDATE。每个CLAIMS_ID的列信息长度可能不一样，这样就造成了不能绑定的原因吗？

回复 只看该作者 道具 举报

8#
发表于 2013-7-10 16:16:32
我看这个 更大的可能性因为 绑定变量超过了32个

回复 只看该作者 道具 举报

9#
发表于 2013-7-10 17:07:40
刘大  绑定变量数有什么限制？超过32个会造成什么影响呢？没有GOOGLE到你说的这个知识点

回复 只看该作者 道具 举报

10#
发表于 2013-7-10 17:21:24
老大你是指Adaptive Cursor Sharing特性？

回复 只看该作者 道具 举报

11#
发表于 2013-7-10 17:25:39
我在MOS上看了篇文章  设置event='10503 trace name context forever, level 32767'  可以解决  但这个EVENT对系统的影响大吗？

回复 只看该作者 道具 举报

12#
发表于 2013-7-10 19:39:03
我不认为 10503  event会有效 ，如果你这样认为请给出 依据或参考


你可以尝试 设置：

event="106001 trace name context forever, level 100"
_cursor_features_enabled=1026

回复 只看该作者 道具 举报

13#
发表于 2013-7-15 17:33:45
按刘大的方法试了一下  没有明显效果  ，上边提到的10503  event确实也不行  。可能我的SQL本身有问题  绑定变量值太多  搞出太多的VERSION

回复 只看该作者 道具 举报

14#
发表于 2013-7-15 18:00:13
请给出 设置上述参数后的 AWR报告

回复 只看该作者 道具 举报

15#
发表于 2013-7-16 16:49:02
设置我是在测试库做的   我给出的是设置5小时后的AWR

mdlcnuat_awrrpt_1_14454_14455.zip

39.95 KB, 下载次数: 2539

回复 只看该作者 道具 举报

16#
发表于 2013-7-16 16:52:08
测试使用人数少  相应的VERSION COUNT增长较少一些   在生产一旦内存使用量超大，暂时是用sys.dbms_shared_pool.purge游标

回复 只看该作者 道具 举报

17#
发表于 2013-7-16 17:29:01
Elapsed:                  59.17 (mins)                  
DB Time:                  3.21 (mins)                  

DB TIME极低
几乎没有library cache: mutex X等待


Version Count        Executions         SQL Id        SQL Module        SQL Text
44        15        9s6jy22p0a3jf         w3wp.exe        UPDATE CLAIMS SET REFERREDPHYS.

最高的version count 44 ， 不清楚你说的问题在哪里

回复 只看该作者 道具 举报

18#
发表于 2013-7-16 17:49:09
VERSION COUNT 44这是测试库   生产库的AWR就是第一次打包的    生产的该SQL基本5天左右VERSION COUNT就能冲到3000    然后就出现library cache: mutex X等待   FLUSH 共享池后过一段时间问题就依旧  你提到的106001 EVENT暂时没在生产上做，在测试上看效果好像不佳  还是有不少的BIND_MISMATCH的原因不可共享    理解有误的地方请指出  

回复 只看该作者 道具 举报

19#
发表于 2013-7-17 12:15:41
1、不可能让Oracle完全不生成 多个version
2、106001只是限制生成的version count数 从而缓解 library cache:Mutex X，从你后放的AWR看 没有什么效果不佳之说

回复 只看该作者 道具 举报

20#
发表于 2013-7-19 10:56:41
谢谢刘大  还有一个问题请教：这个SQL占用内存较大，我手动dbms_shared_pool.purge游标后，会有什么影响吗？是不是PURGE后，所有的父、子游标重新硬解析？

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

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

GMT+8, 2024-11-16 18:32 , Processed in 0.075582 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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