latch free 等待事件说明

1RAW_Value'
                       MINUS
                       SELECT Object_Id
                         FROM Dba_Objects
                       MINUS
                       SELECT Data_Object_Id FROM Dba_Objects)
                  AND Hladdr = '&P1RAW_Value'
                ORDER BY 4;
               
               展开块的方法：
               ◆ 通过ROWID删除并且重新插入一些行
               ◆ 输出表，较大的增加PCTFREE，并且输入数据。这可以最小化每个块的行数量，
                  将他们展开到多个块上。当然这是以存储空间作为代价，并且全表扫描会更慢。
               ◆ 最小化表中每个块的记录数量。这涉及转储少量数据块，用于获得每个块的当
                  前理想行数。手工插入你确定合适的行数，然后发布命令:
                  ALTER TABLE table_name MINIMIZE RECORED_PER_BLOCK。截取表和输入数据。
               ◆ 对于索引，对于较高的PCTFREE值可以重建他们，需要注意的是这种方法可能
                  增加索引的高度。
               ◆ 考虑见效块大小。这将对全表扫描带来极大的负面影响。
               
           ③．cache buffers chains锁存器的争用——长散列链
               多个数据块可能被散列到同一个散列存储桶，他们和指针一起被连接到属于这个
           散列存储桶的散列链上。对于大型数据库，散列链上块的数量可以达到数百个。进程
           不得不顺序的扫描散列以获得所需的块，同时持有cache buffers chains锁存器不变。
           我们称之为“追赶链”。当扫描长链时，锁存器必须被持有更厂的时间，并且可能造
           成另一个进程无法实现她的cache buffers chains锁存器请求。
               一直到Oracle 8.0，我们可以很容易地确定特定的散列链长度，因为散列锁存器、
           散列存储桶和散列链之间的关系是1:1:1，散列链的长度等于有锁存器保护块的数量。
           下面查寻报告每个散列上块的数量，带有10个或更多块的链为长链。
               SELECT Hladdr,
                      COUNT(*)
                 FROM X$bh
                GROUP BY Hladdr
                ORDER BY 2;           
               通过使用_DB_BLOCK_HASH_BUSH_BUCKETS参数增加散列存储桶的数量，可以减少散
           列的长度：
           _DB_BLOCK_HASH_BUCKETS = 128021
           _DB_BLOCK_HASH_LATCHES = 1024
           Ratio = 128021 / 1024 = 125

LATCHES是一种低级的同步锁机制，用以维持某些查询和执行操作得顺序。通过它来达成对系统得SGA中共享内存结构的保护。当请求得到LATCH但它已被其他进程占住时，将产生一条FREE MISS记录。多数LATCH问题关联到不使用绑定变量（LIBRARY CACHE LATCH）,重做日志生成问题（REDO ALLOCATION LATCH）,内存缓冲区竞争问题（CACHE BUFFERS LRU CHAIN）和内存缓冲区中“过热”的数据块（CHCHE BUFFERS CHAIN）。当LATCH错失率超过0.5％时，需要仔细研究下了（METALINK ORACLE.COM/SUPPORT ）。在STATSPACK报告中，等待事件LATCH FREE很高时，下面内容查看有关LATCH的问题。
        在Statspack报告中的Latch Activity 部分将可以得到关于这些Latch的更具体的信息。Get Requests、Pct Get Miss和Avg Slps/Miss（关于睡眠和错失）是针对“Willing－To－Wait”Latches请求的统计，而NoWait Requests和Pct NoWait Miss则是针对“No－Wait”Latches请求。相对于两种Latch请求的Pct Miss都应该接近于0.0。
        分析Latch问题时，v$latch视图十分有帮助，v$latchholder、v$latchname和v$latch_children等视图也很有帮助。
        当Statspack报告中，等待事件一节里的“Latch Free”项很高的数值时，在报告中关于Latch的段落内一定可以发现需要研究的问题。下面内容将可以查看这些有关Latch的问题。
        Library Cache and Shared Pool
        库缓存Latch为对库中对象的访问请求排队，每当执行SQL或PL/SQL存储过程、包、函数和触发器时，这个Latch即被用到。Parse操作中此Latch也会被频繁使用。自9i开始，增加了7个子Latch。共享池太小或SQL语句不能重用时，会发生“Shared Pool”、“Library Cache Pin”或“Library Cache”Latch竞争。SQL语句不可再用往往是因为未使用绑定变量，共享池里随处可见很相像但又不一样的SQL语句，而增加池的大小只会把Latch的问题搞得更糟。可以设置初始化参数CURSOR_SHARING=FORCE 减少绑定变量未使用的问题。然而，共享池和库缓存的Latch问题在后者对需处理的大批SQL语句而言设置太小，需要分配更多内存的情况下也会发生。欲将SQL或PL/SQL语句装入内存而首先释放部分空间的操作占据Latch，令其他用户等待。可以通过增大共享池来减缓此种竞争，还可以通过使用DBMS_Shared_pool.keep存储过程在内存种固定大的SQL或PL/SQL语句来解决这个问题。
        Redo Copy
        重做拷贝Latch的数量在缺省情况下是2*CPU_COUNT，但可通过_LOG_SIMULTANEOUS_COPIES的初始化参数来重新设置。增大此参数可以帮助减缓对重做拷贝Latch的竞争。重做拷贝Latch用来从PGA向重做日志缓冲区重做记录。
        Redo Allocation
        对Redo Allocation Latch（分配重做日志缓冲区中的空间）的竞争可以通过选用NOLOGGING的选项来减缓，该选项可以减轻日志缓冲区的负荷。另外，应当避免不必要的提交。
        Row Cache Objects
        “Row Cache Objects”Latch的竞争通常意味数据字典的竞争，它同时也可能是过度Parsing依赖于公共同义词SQL语句的症状。增大共享池一般可以解决此问题。这个办法往往用来解决库缓存Latch的问题，而在那个问题解决好了的前提下，“Row Cache Objects”Latch的竞争通常就不会成为一个问题。
        Cache Buffers Chains
        扫描SGA中的内存缓冲区时需要内存缓冲区链Latch。缓冲区中“过热”的数据块造成了缓冲区链Latch的问题，“过热”的数据块同时也是可能时调整差的SQL语句所导致的症状。“过热”的记录创建了“过热”的块，也就导致了块里其他记录的问题和映射到该块地址上的hash链的问题。为了定位“热块”，可以查询v$latch_children视图来确定块地址，并通过该视图与x$bh视图的连接来确定此Latch保护下的所有数据块（此将确定受“热块”影响的全部数据块）。以在x$bh视图里找到的file＃和dbablk，可以进而查询dba_extents以确定受影响的对象。如果“热块”在某索引上，转而采用反向关键字索引即可把连续排放的记录搬到其他数据块中，它们也就不再会被“热块”一连串地锁住了。如果“热块”时索引的“根”块，那么反向索引就帮不上忙了，把_db_block_hash_buckets设置成比缓冲区数（DB_CACHE_SIZE/DB_BLOCK_SIZE）的2倍大的最小质数的值通常能够清除此问题的干扰。
        Cache Buffers LRU Chain
        扫描全部内存缓冲区块的LRU（最近最少使用）链时要用到内存缓冲区LRU链Latch。大小的内存缓冲区、过大的内存缓冲区吞吐量、过多的内存中进行的排序操作、DBWR速度跟不上工作负载等全都可能成为导致内存缓冲区LRU链Latch严重竞争的罪魁祸首：调整导致过量逻辑度的查询！可以增大初始化参数DB_BLOCK_LRU_LATCHES以得到多个LRU Latches，如此可减少竞争。非SMP（对称多处理器）系统仅需要惟一的LRU Latch，而在SMP系统的情况下，Oracle自动把LRU Latch的数目设置成1/2CPU数。对于一个数据库写进程，需要分配给它至少一个LRU Latch，如果需要增大数据库写进程的数目，则不能忘记同时增加LRU Latch的数目。