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，部分会话切换至了另一个节点(默认另一个节点不跑正常业务)

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也无法完成。