latch:shared pool的一点理解

[@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争用多

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24237320/viewspace-1059619/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24237320/viewspace-1059619/