如何解决library cache latch冲突？

wing hong

and  I don't think you should even testing the case of setting _wait_for_sync to false,  since that means in the case of instance failure, a committed transaction may not be recoverable. so no point to test  this scenario ,
except you want to cheating in your benchmark testing,  let 's say , for some contract bidding, otherwise, it is no point to do this.

biti_rainy

最初由 wing hong 发布
[B]And if you are sure library cache is very high,  try to set  "session_cached_cursors"  from the default 0 to 200, or 400  , or more,  ( keep testing it , since you have many free memory , you should use some in the PGA ) .

The reason is even you use bind variable, and  all your parse is soft parse, this is still parse,  Oracle still need to confirm the syntax and semantics of the SQL, and this check needs the library cache.

so if you cache the cursor in your PGA by setting the session_cached_cursors to a high number, then it kind of reduce the burdon on the library cache by  geting rid of the soft parse.

HTH [/B]

本想过说 session_cached_cursors  的关系，这个正好适合 大量 soft parse 的情况，但我还是希望他能把 v$latch_children  中的信息给出来再做结论，因为我并不认为  瓶颈 在 这里当然，偶是不到黄河心不死，非看见了，才考虑这个方向。

这是因为他的 statspack 中每秒事务甚至达到2000了，但是我们来看 parse：
User calls: 3,221.75 1.60
Parses: 227.76 0.11
Hard parses: 0.08 0.00
Sorts: 954.04 0.47
Logons: 0.00 0.00
Executes: 14,984.16 7.46
Transactions: 2,009.75


很明显，事务量几乎是 parse (soft  parse) 的 9倍，这从另外一个角度来看，测试中有 pl/sql ，本身可能就回避了parse的问题，比如loop循环内有sql ，就很可能不会产生 soft  parse 。

而对比我们的某个系统
User calls:              1,663.85                 61.75
                     Parses:                171.66                  6.37
                Hard parses:                  0.07                  0.00
                      Sorts:                 68.23                  2.53
                     Logons:                  0.01                  0.00
                   Executes:                592.88                 22.00
               Transactions:                 26.95


所以我根本不会认为资源消耗的重点在 parse
即使表现在 libarary cache 上有等待，那也很可能不是因为 parse 产生的，而可能是其他原因导致 cpu 占用厉害而parse不得不等待。


重点应该放在 事务数量、executions 还有  sort 上
每秒800个sort 消耗资源多还是 227  个 soft  parse 消耗资源多？

zjxs

设置_wait_for_sync的本意是为了验证是否是由于log file sync等待导致的latch冲突，session_cached_cursors设置为100试过，没有任何效果。

这是等待最多的latch和等待时间：
NAME WAIT_TIME
---------------------------------------------------------------- ----------
redo allocation 115350794
library cache pin 135497355
dml lock allocation 183798454
enqueue hash chains 253989608
library cache 480007313

zjxs

Get                            Spin &
Latch Name                       Requests      Misses      Sleeps Sleeps 1->4
-------------------------- -------------- ----------- ----------- ------------
library cache                   6,072,637     119,262      22,215 97309/21692/
                                                                  260/1/0
dml lock allocation             2,705,187      36,174       6,316 29900/6233/4
                                                                  0/1/0
enqueue hash chains             3,599,749      22,744       6,900 15872/6844/2
                                                                  8/0/0
redo allocation                 2,080,408      21,484       5,713 15819/5617/4
                                                                  8/0/0
library cache pin               4,608,684      21,290       5,651 15652/5625/1
                                                                  3/0/0
cache buffers chains           19,036,286      14,689      20,804 0/0/0/0/0
mostly latch-free SCN             335,287      10,605         281 10326/277/2/
                                                                  0/0
session allocation              1,397,161       9,090       2,961 6132/2955/3/
                                                                  0/0
shared pool                     1,060,936       8,557         407 8151/405/1/0
                                                                  /0
messages                        2,509,378       2,712         559 2156/553/3/0
                                                                  /0
enqueues                          699,199       2,159         420 1740/418/1/0
                                                                  /0
undo global data                1,364,432       1,990         519 1471/519/0/0
                                                                  /0
session idle bit                2,062,606       1,776         741 0/0/0/0/0
lgwr LWN SCN                      324,427       1,081           8 1073/8/0/0/0
post/wait queue                   543,419         354         101 258/91/5/0/0
checkpoint queue latch            502,664         192           5 187/5/0/0/0
library cache pin allocati        374,968         159          52 107/52/0/0/0
redo copy                             127         112          97 16/95/1/0/0
Consistent RBA                    322,652          60          11 49/11/0/0/0
row cache objects                  34,709          37          18 19/18/0/0/0
simulator hash latch              408,024           7           1 6/1/0/0/0
row cache enqueue latch            34,655           1           1 0/1/0/0/0

biti_rainy

虽然  library cache pin  排在前面
但是 由于每秒只有200多次 soft  parse ，所以，即使你一次 parse也没有，也不会有多大的性能变化。 所以我坚信 即使这个排在前面，本质上也不是  parse 问题导致的。

因为  dml  lock 的一系列相关操作也是在 shared  pool 中完成的，目前我还不清楚 libarary  cache 是否和lock(transaction) 有相互影响的关系
另外一个疑点：还有就是比如一个sql 在 soft  parse 和  execute 过程中，cpu的使用如果是可切分的，也就是说parse对于cpu使用并不是原子的，那么很可能被其他进程抢了 cpu ，这会否造成 libarary cache 的问题。

所以，也许你可以调整 _spin_count 在 100----4000  范围的几个点中测试一下看看，9204  默认shi  2000
sys@OCN>select  indx from  x$ksppi where   KSPPINM  = '_spin_count';

      INDX
----------
         3

sys@OCN>select KSPPSTVL from  x$ksppsv where  indx = 3;

KSPPSTVL
----------------------------------------------------------------------------------------------------
2000

sys@OCN>


当然不管怎么说我认为问题的关键还是落在其他环节，200多 soft  parse 应该不是问题的根源，libaray  cache 只是一个表象，这可能也未必就仅仅是 parse 一个因素。 你的事务量太大了，每秒居然达到2000个事务,还有Executes每秒 14984，你们生产系统真的有这么多事务，就不能考虑批量插入或者提交？ 从应用上如果下工夫比从系统上来的 简单容易的多。

wing hong

sort counts under CPU or I/O  ?

wing hong

the whole idea of wait event is Oracle must accurately count all  the wait time under different waiting events . so if it counts the bulk of wait time under "latch free" ,  barring from a Oracle bug,  this is the direction we check , isn't it ?

and in this case,   if  library cache latch is still so high after these parameter change,  possibly  this means to me the concurrency requirement is too high ,  too many foreground processes competes,   and the system can't handle it .

biti_rainy

他没有给出 sorts 是 内存 还是 磁盘 的比例，如果是内存，则也要消耗大量的cpu

我一直强调的一个问题是：  即使看起来是  library cache 的问题，可如果 soft parse 只有200多，那一定不是因为  parse 本身导致的问题。而是其他因素导致的。
从这里看起来，可能是事务太多、执行次数太多、排序太多……  

maybe 可是试一下 _spin_count

当然重要的还是应用本身

wing hong

any one know why I can't see the new post,
though from http://www.itpub.net/forum2.html , I can see the 最后发表 is changed.

but if I post  some thing, I can see my post and other one's new post

biti_rainy

因为 cache 的缘故

而主题显示不是静态的


你把你的每页显示设置成 和 标准设置不同的，比如我的是40个帖子一页，就不会被cache的页面一样，则是动态刷新