Library cache latch 竞争的解决 - 人生如炼狱，不得不修行

诊断
1. v$latch：查询v$latch 获得相关的latch 等待信息：
  select * from v$latch where sleeps>0 order by sleeps desc;
  通过该查询，我们可以获得系统中所有关于latch的等待信息，密切关注library cache在排序中的位置
  然后我们可以查询 v$latch_holder来获得OS级别的进程号：
  select a.name,pid from v$latch a , V$latchholder b
  where a.addr=b.laddr
  and a.name = 'library cache%';
2. v$session_wait：在系统繁忙的时候，查询该视图，如果有3-4个session都在等待同一个等待事件，那么就有可能有问题发生
  select count(*) number_of_waiters
  from v$session_wait w, v$latch l
  where w.wait_time = 0 --表示当前正在等待
  and w.event = 'latch free'
  and w.p2 = l.latch#
  and l.name like 'library%';
  
  确定系统慢的原因：
  select * from v$session_wait
  where event != 'client message'
  and event not like '%NET%'
  and wait_time = 0
  and sid > 5;
解决：
1. 大部分的 library cache的竞争都是因为library cache中的碎片造成的，一般情况下会发生ora4031错误 Note 146599.1
2. 绑定变量，增加sql语句的共享：执行以下语句，查看共享：
  select gethitratio from v$librarycache where namespace = 'SQL AREA';
3. 减少解析：查看解析和执行sql的情况：
  select sql_text, parse_calls, executions from v$sqlarea
  where parse_calls > 100 and executions < 2*parse_calls;
  再检查select name, value from v$sysstat where name like 'parse count%'; 如果每隔10秒这个值都会有大的变化，就说明有问题
4. CURSOR_SPACE_FOR_TIME 参数的调整：设置该参数为TRUE，能够减少 library cache的竞争。但是，设置该参数，需要消耗更多的内存，所以再设置该参数时，要确保有空闲内存，并且每分钟的hard page fault 的值要低
5. SESSION_CACHED_CURSORS ：将执行很多次的sql 语句，保存再内存
6. instead of saying 'select * from emp', say 'select * from scott.emp'.