The wait for the main event are the following:
1.l atch free
Three parameters Latch free wait event: p1-latch address; p2-latch number; p3- requests. From oracle10g since, latchfree no longer contains all the latch wait, wait some latch wait may appear as a separate event, this later mentioned some of these wait events, under normal circumstances we collectively latch free wait event.
If we find in v $ session_wait There latch free wait event, it means that, in the process of requesting a willing_to_wait mode latch, latch did not get a _spin_count after the retry times, and then transferred to a sleep state. If the latch contention serious, will lead to a result of constant spin cpu resource constraints, thereby increasing the system response time.
2.latch: shared pool 和 latch: library cache
Shared pool latch are used to prevent the shared pool of memory structures when shared pool memory allocated or released need to get the latch. For example, when a new sql statement or pl / sql procedures, functions, packages, triggers dispensing space (hard analysis), or to swap out, clearing certain memory block, in order to make room for the new object , the need to obtain shared pool latch. The main library cache saved cursor, sql statements, execution plans, analysis trees. These structures are protected by the library cache latch. When the process to modify oracle, checking pin connector (pinning), locking, load, or performs the library cache structure, you are required to obtain a library cache latch. You can know the current number of instances of the sub-latch library cache by querying v $ latch_children.
Pictures reproduced https://blog.51cto.com/tiany/1575964
当出现Latch竞争严重的时候:
(1).如果同时出现大量的 Share Pool Latch 和 Library Cache Latch 的话,根据上面的逻辑那说明数 据库中存在大量的硬解析,这个时候就要查找那些 SQL 没有绑定变量。
(2).如果只是出现大量的 Library Cache Latch 的话,那么可能有两种情况:
1) 当持有 Library Cache Latch 查找 Bucket 对应的 Chain 时候,发现存在高 Version 的 SQL,这个时候就要扫描这些对应的子游标,整个过程将一直持有 Latch,导致其他会话获取不到 Latch 进行操作。
2) 大量的并发请求,而且不能实现 SQL 一次 Parse Call 多次 Execution。
3.
(1).library cache pin ,library cache lock
1).Lock 与 pin 都用于访问在 library cache 中的对象。Lock 管理不同进程间的并发，pin 则管理缓冲区的一致性。为了访问一个对象，进程必须首先锁定（lock）这个对象的句柄(handle)，然后它自己 pin 住对象的内存堆。
2).Lock 与 pin 请求会一直等待直到获得为止，这是一个引起争用的可能的原因，因为它没有 NOWAIT 请求模式。
3).Oracle 在分析/编译 Package/Procedure/Function/View 时需要 Library Cache Lock 和 Library Cache Pin。这是为了确保在分析/编译期间, 没有其它人可以对这些对象的定义进行改变，或者删除、重建这个对象。
4).当一个 SQL 语句被一个 session 硬解析时，这个 session 需要获得一个 library cache lock 以便阻止其它 session 去访问或修改同一个对象。如果这个事件等待很长时间。这表明可能 shared pool 过小或经常发生对象被 flush 出去的情形。这表明数据库对象被经常修改。
5).除了硬解析，如果一个 session 要更改被 SQL 语句引用的对象的定义或对其做任何更改，就必须获得一个 library cache lock 和 library cache pin。需要 Pin 的原因是需要加载数据字典信息到内存中来修改这个对象。
6).如何降低 library cache lock 等待
我们首先要确认的是 library cache 的竞争是整个系统层面的还是只发生在某个或某些 SQL 语句上。这个"library cache lock"是被一个特定的 SQL 持有很长的时间吗？或者总是在等待某个特定的对象？还是说这个锁在短时间内被请求的次数很多从而造成的竞争？
- 如果问题是在整个系统层面发生的，一般来说是由于 shared pool 太小或 SQL 语句不共享造成的。一些解决竞争的方法：
增大 shared pool 从而减少 reload 的次数，这是因为 shared pool 过小会造成获取锁的时间加长。
- 如果您发现是某条或某些SQL产生的问题，那么需要检查为什么它持有锁的时间会那么长。
以下文档可以用来找到谁在持有锁以及在哪个对象上：
Note 122793.1 How to Find which Session is Holding a Particular Library Cache Lock
7).如何降低 library cache pin 等待
如果"library cache pin"等待的时间很长那么很重要的一点就是判断是只有一两个 process 在等待还是有很多的 process 都在等待。
如果说只是一两个 process 被另一个 process 阻塞的话，那么需要检查持有这个 pin 的 process 为什么这么长时间不释放。
如果说等待是大范围的那么说明 shared pool 需要优化。
(2).library cache load lock
如果一个对象不在内存中，那么我们不能对其申请 library cache lock。因此，需要将这个对象加载到内存中。然后，session 尝试找到数据库对象的 load lock，以便它能载入这个对象。为了阻止多进程同时请求加载同一个对象，其它同样请求的 session 将等待 library cache load lock 因为这个对象正在被加载到内存中。等待 library cache load lock 是由于对象在内存中是不存在的。 Library cache 中的对象不存在，是由于 shared pool 过小引起的频繁重新装载，或太多的硬解析缘于不共享的 SQL。
解决方法：
- 增加 shared pool(避免 reload).
- 增加 session cached cursors(避免 cursor 被刷出 shared pool)
- 设置 cursor_sharing 为 force(减少硬解析)。---可能改变执行计划与查询的性能，所以要作充分的测试。
4.latch: row cache objects
用来保护数据字典缓冲区（row cache的名字主要是因为其中的信息是按行存储的，而不是按块存储）。进程在装载、引用或者清除数据字典缓冲区中的对象时必须获得该latch。在oracle8i之前，这是一个独立latch。从oracle9i起，由于引入了多个子共享池的新特性，存在多个row cacheobjects子latch。Oracle10g中，该latch也有了一个独立的等待事件：rowcache objects。
解决方法：
(1).确认SGA 中的share pool 是否还有空闲空间
select POOL,BYTES/1024/1024 FREE_MB from v$sgastat a where a.NAME like 'free%';
(2).查询ROW CACHE中的GET量及命中率
SELECT r.cache#,r.parameter name,r.TYPE,r.subordinate#,r.gets,r.GETMISSES,round((1 - r.GETMISSES/r.gets)*100,2) SUC_PCT FROM v$rowcache r where r.gets <>0 ORDER BY 5 desc;
SQL解析到底哪一步访问了ROWCACHE，哪一步争用的latch?
这个问题我查询了好久，我之前以为只是在语义检查需要到row cache，其实是在生成执行计划的时候需要访问的数据字典次数更多，争用latch也就更频繁了，所以这里才是最慢的。
5.cache buffers chains
http://blog.itpub.net/15412087/viewspace-2148426/
郑州妇科医院：http://jbk.39.net/yiyuanzaixian/sysdfkyy/
6.latch: cache buffers lru chain
一般来讲，当进程需要查找可用的缓存空间时，需要访问lru列表。后台进程DBWn则会将lruw列表中的干净块移到lru列表中，也会将lru中的脏块移到lruw列表中。在一个工作集中进行以上的任何操作都需要先获得cache bufferslru chain latch。
Each data buffer (buffer comprising different block sizes, and Keep cell recycle tank), each buffer needs to have at least a cache buffers lruchain latch, and the process may require multiple DBWn a latch. Otherwise, a working set can become very long. In the oracle9i and oracle10g, cache buffers lru chain latch is 4 times the number of cpu default number, if, db_writer_processes greater than 4, is then equal to the number of cpu multiplied db_writer_processes. You may adjust the number of cache buffers lru chain latch by implicit parameter _db_block_lru_latches.
Cache buffers laru cahin latch contention, mainly because of inefficient sql statement causes the data buffer hyperactivity. Full table scan and repeated scanning of some poor selectivity index is the main reason for the large cache buffers laru cahin latch contention. The solution is to look for latch free wait event sql statement on cache buffers lru chain latch-related (in oracle10g has been turned into a separate cache buffers lru chain waiting for an event), these sql optimization, reducing its physical reads and logical reads .