awr高library cache & shared pool latch

sfscomm

高峰期表现为当会话数到达一定数量后，就开始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(刘相兵

        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(刘相兵

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

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

sfscomm

Maclean Liu(刘相兵 发表于 2015-3-31 21:59
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也无法完成。