9.2.0.8全天都有latch free等待事件，是BUG吗？

huagan0523

OS版本:HP-UX g4ah1080 B.11.23 U ia64
DB版本:9.2.0.8

ACTION_TIME                    ID         ACTION               VERSION    COMMENTS
------------------------------ ---------- -------------------- ---------- ----------------------------------------
18-OCT-09                      8290549    CPU                             CPUApr2009

该库整体描述：
全天都存在latch free等待事件，从statspact报告来看latch free的小类主要为cache buffers chains。通过v$latch视图与v$session视图抓取的SQL，并非同一条，而且SQL变化频率较快。个人感觉是由于某个程序并发太多导致这种情况出现。但未找出实质的证据，发现TOP SQL中执行了一个包程序，RULE_MANAGE.RULE_MANAGER(:1,:2,:3,:4,:5,:6,:7,:8,:9);
目前监控到该程序的SQL次数一直是2，应用还未反馈，同时存在2个RULE_MANAGE.RULE_MANAGER(:1,:2,:3,:4,:5,:6,:7,:8,:9)包在执行是否属于异常情况。

以下是latch free:
select a.EVENT,b.SID,b.STATUS,b.MACHINE,b.PROGRAM,c.NAME,c.GETS,c.MISSES,b.SQL_HASH_VALUE
from v$session_wait a,v$session b,v$latch c where a.event = 'latch free' and a.SID=b.SID and a.P2=c.LATCH#;


latch free        110        ACTIVE        cnsz031526                cache buffers chains        5144821557273        4689472725        56083773
latch free        152        ACTIVE        cnsz031526                cache buffers chains        5144821557273        4689472725        56083773
latch free        213        ACTIVE        cnsz031525                cache buffers chains        5144821557273        4689472725        0
latch free        347        ACTIVE        cnsz031526                cache buffers chains        5144821557273        4689472725        1217994613
latch free        1344        ACTIVE        cnsz031527                cache buffers chains        5144821557273        4689472725        2212428750
latch free        616        ACTIVE        cnsz031526                cache buffers chains        5144821557273        4689472725        56083773

请牛人们帮忙看一下，有何建议，或是否为BUG？

Maclean Liu(刘相兵

Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:          2,323,113.90              1,240.57
              Logical reads:            245,987.67                131.36
              Block changes:             13,291.53                  7.10
             Physical reads:                902.27                  0.48
            Physical writes:                598.29                  0.32
                 User calls:              7,242.54                  3.87
                     Parses:              1,750.30                  0.93
                Hard parses:                  0.01                  0.00
                      Sorts:              1,410.93                  0.75
                     Logons:                  0.54                  0.00
                   Executes:             10,195.11                  5.44
               Transactions:              1,872.62




Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:          2,564,588.18              1,511.67
              Logical reads:            664,713.87                391.81
              Block changes:             14,425.29                  8.50
             Physical reads:              4,498.52                  2.65
            Physical writes:                902.03                  0.53
                 User calls:              8,173.73                  4.82
                     Parses:              3,856.49                  2.27
                Hard parses:                  6.50                  0.00
                      Sorts:              1,914.71                  1.13
                     Logons:                  1.09                  0.00
                   Executes:             13,993.40                  8.25
               Transactions:              1,696.52



664,713* 8k=  5G
245,987.67 * 8k => 1.8G

逻辑读量还是不少的

白天10:00:02~11:00:04 的逻辑读更多 体现在 多了很多大表扫描
table scans (long tables)                     18,356            5.1          0.0
table scans (long tables)                          2            0.0          0.0


table scans (short tables)                 7,591,367        2,107.5          1.2
table scans (short tables)                 5,362,226        1,488.7          0.8


不认为 这个latch free是不合理的， 你该做的是减少 全表扫描和 逻辑读高的语句

huagan0523

恩，SQL方面是有许多需要优化的地方。虽然latch free比较多，但是整体的CPU使用率一般在50%-60%，还抗得住，

huagan0523

不过单看2013-7-16号晚上22点-23点的报告，逻辑读和long table的全表扫描并不多，个人感觉还是不应该出现latch free啊。不过从业务上来说，这个点出现了latch free，也没有对业务造成什么太大的影响，并未收到业务慢的反馈。