[@more@]
latch:shared pool
shared pool latch 起到保护堆的作用，为了查找free chunk，检索空闲列，分配适当的chunk，
必要时候分割chunk。这些全部只能在获得shared pool latch之后才能执行。
因此在获得shared pool latch过程中会发生latch:shared pool等待事件.
一般情况下一个实例上只有一个latch:shared pool
harding parse严重时，会发生分割chunk的现象.
---==============================================================
测试latch:shard pool等待事件
创建测试脚本：
create or replace procedure tt_pro is
begin
for i in 1..100000 loop
execute immediate ‘select * from tt where object_id=‘||i;
end loop;
end;
/
同时在三个会话执行这个脚本，查看v$session_event
select * from (
select event,total_waits,time_waited from v$session_event where sid in(12,192,197) order by 2 desc )where rownum<=10
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
latch: shared pool 84996 612
latch: shared pool 57746 500
latch: shared pool 56557 640
cursor: pin S wait on X 9798 9471
cursor: pin S wait on X 8682 8370
library cache: mutex X 471 9
library cache: mutex X 408 12
library cache: mutex X 241 10
library cache lock 231 81
events in waitclass Other 224 675
10 rows selected.
如果发生latch:shared pool等待事件，不应该加大共享池，加大了共享池，
相应的要管理的chunk数量也要增加，检索空闲列的时候，占有
shared pool latch的时间会增大。
---==============================================================
相应的解决方法：
1)oracle9i之后，可以有多个共享池(副池)，最多有7个副池分别管理。
oracle在cpu数位4，共享池大小为250M以上的情况下，通过创建与
_kghdsidx_count值相同量的副池来管理共享池。副池也是独立的共享池结构。
2)减少共享的大小，这样就可以减少占有shared pool latch的时间。
但这回导致ora-04031错误
可以利用dbms_shared_pool.keep指定对象永久置于共享池中，来消除问题
3)cursor sharing
---===============================================================
下面，测试一下，使用过个共享池的情况下，会不会减少latch:shared pool
确认cpu_count大于4，共享池大小大于250M
SQL> show parameter cpu_count
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
cpu_count integer 4
SQL> show sga
Total System Global Area 626327552 bytes
Fixed Size 2178336 bytes
Variable Size 461374176 bytes
Database Buffers 155189248 bytes
Redo Buffers 7585792 bytes
SQL> alter system set "_kghdsidx_count"=4 scope=spfile;
System altered.
SQL> select name,gets from v$latch_children where name=‘shared pool‘;
NAME GETS
-------------------- ----------
shared pool 19
shared pool 19
shared pool 19
shared pool 27058
shared pool 27862
shared pool 31982
shared pool 27345
可以看出，4个shared pool latch 被激活
然后再在三个会话中重新执行tt_pro脚本，看看情况
SQL> select * from (
2 select event,total_waits,time_waited from v$session_event where sid in(9,10,199) order by 2 desc )where rownum<=10
3 ;
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
latch: shared pool 23120 126
cursor: pin S wait on X 18792 18766
latch: shared pool 14996 68
cursor: pin S wait on X 13740 13490
latch: shared pool 9860 70
library cache lock 716 256
library cache lock 705 262
library cache: mutex X 692 35
library cache: mutex X 605 41
library cache load lock 479 2
10 rows selected.
相应的latch:shared pool减少很多.
---====================================================
hard parse引起的library cache争用比shared pool争用多
