sfscomm 发表于 2015-3-31 18:22:32

awr高library cache & shared pool latch

本帖最后由 sfscomm 于 2015-3-31 21:59 编辑

高峰期表现为当会话数到达一定数量后，就开始hang住。

之前hard parse为60+，soft parse97%左右，version count > 3000 大概有3－4个sql，已经做了优化，version count已经掉下来。

cursor_sharing= force


疑问1：在设定cursor_sharing为force前，sga breakdown diff里显示sql area很大，调整后，sql area减少，但CCursor变得更大。让我感觉从整体shared pool latch去申请内存而言，此消彼长并无增益。

疑问2:在通过优化高version count sql后，version count section显示该issue已经消失，但是高峰期还是hang，感觉优化过后用处不大。(Bug 8865718 : RECURSIVE CURSORS CONTAINING "AS OF SNAPSHOT" CLAUSE ARE NOT SHARED) ,优化的内容主要针对这个bug内容进行，将几个mv改成view绕过。

PS：awr中cluster wait相关的load profile部分可能看起来有点离谱，是因为在hang的时候，有手动kill 过会话，客户端里tns配置了failover，部分会话切换至了另一个节点(默认另一个节点不跑正常业务)

Maclean Liu(刘相兵 发表于 2015-3-31 21:56:47

        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
latch: library cache        119,049        33,273        279        74.4        Concurrency
latch: shared pool        44,985        12,218        272        27.3        Concurrency
CPU time                 3,251                 7.3         
latch free        7,224        1,931        267        4.3        Other
latch: cache buffers chains        16,285        1,566        96        3.5        Concurrency



Parses:        587.07        43.01
Hard parses:        14.39        1.05

cursor_sharing使用FORCE

SQL ordered by Parse Calls
Total Parse Calls: 1,061,334
Captured SQL account for 61.6% of Total
Parse Calls        Executions        % Total Parses        SQL Id        SQL Module        SQL Text
174,652        87,447        16.46        6pwhuakcu5kqq        labcom.exe        select soufull , souid from l_...
148,949        74,596        14.03        f0wzs9nc663bn        labcom.exe        select sysdate from dual
71,048        71,048        6.69        csf1x66vmvd70        BQYF.EXE        Select Nvl(Sum(KuCunSL - Nvl(Y...
66,829        66,829        6.30        2xqt1w0rd1mub        BQYF.EXE        Select Nvl(Sum(KuCunSL - Nvl(Y...
19,482        19,481        1.84        c6fa2u8w4d8bu        MZZJ.EXE        SELECT YINGYONGID||chr(9)||KES...
14,372        14,372        1.35        58nqcgq93qdpp        lis2.exe        SELECT sysdate FROM dual
11,342        11,342        1.07        2p09jrn1gd47b        BQYZ.EXE        begin select SEQ_ZY_JIESUAN2.n...
11,319        11,322        1.07        7hxxth3uzdvh1        BQYZ.EXE        SELECT SEQ_ZY_JIESUAN2.NEXTVAL...
10,061        14,495        0.95        6dtu480vu4auh        w3wp.exe        SELECT b.paiduiph, bingrenxm F...
8,168        8,168        0.77        9h3su635dcp95        w3wp.exe        select shuzhi1, jilusj from tw...

部分SQL使用了绑定变量 更多SQL没有使用绑定变量 而依赖于 force cursor sharing

Maclean Liu(刘相兵 发表于 2015-3-31 21:59:46

shared        library cache        203.15        205.50        1.16
shared        sql area        471.67        501.22        6.27

sql area在半小时内有不少增长， 几种可能：
1、是否之前存在人为的flush shared_pool
2、可能在短期内涌入大量未绑定的sQL 且时间点较为 特殊为 8:30~9：00

sfscomm 发表于 2015-3-31 22:04:48

另外，请教下刘大, Cursors/Session 这部分内容db端有什么方向可以去追查一下，我比较了一下近期的这个值，前段时间正常时约20上下，但是最近出问题期间，这个值已经接近60。

sfscomm 发表于 2015-3-31 22:08:31

Maclean Liu(刘相兵 发表于 2015-3-31 21:59 static/image/common/back.gif
shared        library cache        203.15        205.50        1.16
shared        sql area        471.67        501.22        6.27



1) flush shared pool 应该不太可能；
2）程序也没有变更过。

就如你所说，在这个peak time，hang的现象一阵一阵的，systemstate dump也无法完成。
页: [1]
查看完整版本: awr高library cache & shared pool latch