我的ORACLE版本11.1.0.7
构造一个查询,查询的对象列表400个。可以根据all_tables去构造。主要目的是让语句的解析时间足够长。
select count(*) from a,b,c.....(400个) where 1=0;
在session1和session2分别执行上面的语句。观察两个session的等待事件:
等待事件的语句如下:
col event for a30
select event,total_waits,time_waited from
v$session_event
where sid=(select sid from v$mystat where rownum=1)
order by 3 desc;
session1的等待事件:
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
SQL*Net message from client 25 7149
SQL*Net message to client 26 0
session2的等待事件:
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
SQL*Net message from client 24 33047
cursor: pin S wait on X 810 792
SQL*Net message to client 25 0
可以看到session2的等待事件比session1只多了cursor: pin S wait on X等待。这个等待是由于硬解析导致的,session1硬解析期间需要获得cursor的x锁。session2执行同样的SQL,需要获得cursor的S锁,两种锁不兼容,导致出现cursor: pin S wait on X 。
再看看10G的情况。
构造一个查询,查询的对象列表400个。可以根据all_tables去构造。主要目的是让语句的解析时间足够长。
select count(*) from a,b,c.....(400个) where 1=0;
在session1和session2分别执行上面的语句。观察两个session的等待事件:
session1的等待事件:
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
SQL*Net message from client 17 1509
db file sequential read 53 47
SQL*Net more data from client 2 0
SQL*Net message to client 18 0
session2的等待事件:
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
SQL*Net message from client 17 1490
library cache pin 5 1254
SQL*Net more data from client 2 0
SQL*Net message to client 18 0
明显看到了11G与10G的不同。10G 的等待事件出现的是library cache pin ,而不是cursor: pin S wait on X 。10G的时候,编译SQL的时候,需要在handler上获得S模式的library cache lock,然后获得对象HEAP上的x模式的library cache pin,解析的时候,如果有同样的SQL需要执行,需要获得S模式的library cache lock,由于都是请求的S模式,这个是可以获得。继而需要获得s模式的library cache pin,由于跟之前的x模式是互斥的,于是产生等待library cache pin。
11G以后,采用了mutex机制,对于cursor上的pin等待,用cursor: pin S wait on X 来代替了。对于mutex机制,还没看到什么比较详尽的文档。
再看看表修改(DDL)与select是否会产生cursor: pin S wait on X。
10G的情况:
session1执行如下DDL;
begin
for idx in 1 .. 100000 loop
execute immediate 'alter table test enable all triggers';
end loop;
end;
/
session2执行如下查询:
declare
v_value number;
begin
for idx in 1 .. 50000 loop
select 1 into v_value from test where rownum=1;
end loop;
end;
/
session1的等待:
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
SQL*Net message from client 22 37319
log file sync 12387 4344
library cache lock 10051 1528
latch: library cache 239 3
session2的等待:
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
SQL*Net message from client 20 5077
library cache lock 5902 351
db file scattered read 5390 301
db file sequential read 377 15
SQL*Net message to client 21 0
latch: shared pool 16 0
latch: library cache 57 0
我们都看到了library cache lock ,DDL会获得handler上X模式的library cache lock ,有查询请求的时候,需要获得s模式的library cache lock ,两者不能共享,因此出现library cache lock 。反过来也一样。
11G又会如何:
session1的等待:
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
SQL*Net message from client 20 5285
library cache load lock 9685 531
library cache lock 10 5
latch: shared pool 31 1
events in waitclass Other 2 0
library cache: mutex X 9 0
SQL*Net message to client 21 0
log file sync 1 0
session2 的等待:
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
SQL*Net message from client 20 7131
library cache lock 4968 477
library cache load lock 94 9
events in waitclass Other 1 0
library cache: mutex X 26 0
SQL*Net message to client 21 0
latch: row cache objects 1 0
latch: shared pool 17 0
也看到了library cache lock, 知道竞争都是handler上的。跟10G差不多。仔细观察,还多了library cache: mutex X 事件,这个事件其实就是10G的latch: library cache 。还多了library cache load lock ,不是很清楚做什么用的。
看来11G,通过cursor: pin S wait on X 取代了10G之前的cursor上的library cache pin等待事件。通过library cache: mutex X 取代了10G之前的latch: library cache(没详细证明,有事件做个实验证明下)。
还有需要说明的是,这种library cache lock 争用是发生在table的headler上的,而不是发生在cursor的headler上。
select kglnaobj from x$kglob where kglhdadr='0000000069CBB7E0';
KGLNAOBJ
------------------------------
TEST
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22034023/viewspace-681091/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/22034023/viewspace-681091/