Diagnosing Contention for Latches

Diagnosing Contention for Latches

 

1、对于闩（Latches）的概览
Latches是为了保护SGA中的共享数据结构而创建的简单的底层的序列化机制，是轻量级的锁。server或后台进程为了操作或是查看共享数据结构必 须先申请Latches，当操作结束，需要释放Latches。Latches的争用是不用tuning的，它是不合理使用SGA资源的征兆，需要 tuning内部的争用。仅仅是观察v$LATCH是不足的，但可以将其看做是诊断工具，查找SGA资源争用的位置。
1）Latches的目的：
*  控制序列化访问：保护SGA中的数据结构；保护共享内存的分配。
*  序列化执行某些操作：避免同时执行某些关键的临界code；避免corruptions。
2）等待Latch
尽管latch的实现根据不同的OS和平台而不同，但是其都是内存中的一块地址空间，当latch空闲时是0，已经被申请了时为非0值。
在单cpu中，当进程p1申请的latch被占用，p1将释放cpu，sleep一小段时间，等待latch被释放。
在多cpu中，如果进程p1申请的latch被p2占用，很可能p2在其他的cpu上，则p1不会释放cpu，而是spin计数，重试，spin计数，重试，直到重试次数达到设置数，仍未成功，才会释放cpu，但这种可能比较小。
3）Latch的请求类型：
latch的请求方式有两类：willing-to-wait和immediate。
willing-to-wait：当进程申请一个latch时，如果当前latch已经被占用，该进程会等待片刻再重试，等待-重试，直到获得latch，这是一般普遍的latch申请方式。
immediate：如果进程申请的latch不能获得，该进程会继续执行后续的指令。
4）latch 冲突：latch的申请释放都是Oracle自动实现的，所以速度比较快。latch的资源是有限的。
在诊断latch时，可利用视图v$latch，该视图中主要columns的意义：
• gets: Number of successful willing-to-wait requests for a latch
• misses: Number of times an initial willing-to-wait request was unsuccessful
• sleeps: Number of times a process waited after an initial willing-to-wait request
• wait_time: Number of milliseconds waited after willing-to-wait request
• cwait_time: A measure of the cumulative wait time including the time spent spinning and sleeping, the overhead of context switches due to OS time slicing and page faults and interrupts
• spin_gets: Gets that missed first try but succeeded after spinning
• immediate_gets: Number of successful immediate requests for each latch.
• immediate_misses: Number of unsuccessful immediate requests for each latch.
在使用statspack是，可先查看其report的top 5 wait events部分，是否有latch free事件，如果有再进行后续的分析。

2、降低Latches的冲突
一般，DBA不应该调节latches的数目，自9i以来，Oracle已经可以自己进行latches数量的调节了，这主要是根据DB在建立时设置的初始参数和OS的环境。
latches的冲突是性能问题的表现。最好的解决latches冲突问题的方法是修改application行为。此外，如果观察到是buffer或shared poolsize的问题，也需要进行适当的修改。

3、对DBA而言，几个重要的latches
1）shared pool latch和library cache latch：如果冲突出现在这两类latch上，则表示sql或是pl/sql命令没有被有效重用，可能是没有有效的使用绑定变量，或是cursor cache不足。如果是Oracle Shared server模式，如果没有设置large pool，也可能导致Shared pool Latch的冲突，则需要考虑设置large pool。
2）cache buffer lru chain latch：当dirty blocks被写入disk或server进程查找blocks用于写入操作时会request此latch。如果它存在较大冲突，则表示buffer cache任务繁重，可能存在较多的cache-based sorts、低效的SQL（使用了不正确的迭代索引）或是较多的全表扫描。此外，也可能是由于DBWn的写速度跟不上data blocks的变化速度。使得访问进程不得不为了找到buffer中的free blocks等待。对这个latch的冲突，应该从buffer cache或DBWn的调节入手。
3）cache buffers chains latch：当user进程试图分配buffer cache中的data blocks时，需要申请此latch。它的冲突反映了某些热块被重复访问的情况。

4、共享池和library cache latch冲突：如上所述，此类冲突的一个主要原因是不必要的解析。其调节方法已经在之前介绍过了。
1）辨识因为拼写方式而造成的多次解析：
select sql_text from v$sqlarea where executions=1 order by upper(sql_text);
2）查看是否有不必要的重复解析。
select sql_text, parse_calls, executions from v$sqlarea order by parse_calls;