当前位置: 首页 > 图文教程 > 数据库 > Oracle > library cache pin与PROCEDURE的重建

Oracle
Excel VBA连接并操作Oracle
Oracle 外连接实现代码
oracle 存储过程和函数例子
Oracle 数据库操作类
ORACLE 分区表的设计
Oracle 用户权限管理方法
Oracle In和exists not in和not exists的比较分析
利用windows任务计划实现oracle的定期备份
ORACLE11g随RHEL5系统自动启动与关闭的设置方法
在oracle 数据库查询的select 查询字段中关联其他表的方法
plsql和tsql常用函数比对
plsql与tsql的语法不同
ASP.NET调用oracle存储过程实现快速分页
执行drop表操作后数据库无法起动
分析Oracle有时会用索引来查找数据的原因
数据从MySQL迁移到 Oracle的注意事项
快速理解Oracle归档模式的命令及参数
在Oracle里加快SQL执行的三种方法
几条常见的数据库分页 SQL 语句
Oracle9I OCP认证过程

Oracle 中的 library cache pin与PROCEDURE的重建


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-10-31   浏览: 163 ::
收藏到网摘: n/a

    前面提到,Oracle10g重建Procedure的处理有所增强,最初看到这个增强的时候,我想这个增强是否可以减少困扰已久的Library Cache的竞争呢?

    我们看一下以下测试,首先在第一个session执行操作:

SQL> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /

Procedure created.

SQL>
SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> create or replace procedure calling
2 is
3 begin
4 pining;
5 dbms_lock.sleep(60);
6 end;
7 /

Procedure created.

SQL>
SQL> col object_name for a30
SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
CALLING 2007-04-02 09:12:57
PINING 2007-04-02 09:12:57

SQL>
SQL> exec calling;

 

此时Calling对于Pining的引用将会在Pining的Body上获得共享Pin,此时在另外一个Session执行重建Procedure的操作:

SQL> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /

 

这个操作将一直挂起,直到第一个session的操作完成,此时在第三个session可以观察到Library Cache Pin的竞争:

SQL> select sid,event from v$session where username='EYGLE'
2 /

SID EVENT
---------- ----------------------------------------------------------------
137 library cache pin
139 PL/SQL lock timer
157 SQL*Net message to client

当第一个session执行完成之后,第二个session的操作随之完成,我们可以看到LAST_DDL_TIME并未改变:

SQL> exec calling;

PL/SQL procedure successfully completed.

SQL>
SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
CALLING 2007-04-02 09:12:57
PINING 2007-04-02 09:12:57

实际上session 2执行了一次无谓的Library Cache Pin,理想的方式应该是,Oracle能够判断之前的Library Cache Pin的模式,如果是共享模式,则可以跳过Pin请求,如果是排他模式,则必须等待,目前的处理并不能从实质上改变竞争。

不过并非全无益处,我们发现,对于另一类DDL操作,Oracle完全可以跳过Library Cache Pin的请求,这类操作是Grant,在以前版本中的行为可以参考:
http://www.eygle.com/archives/2004/10/shared_pool-5.html

在Oracle10g中,Grant授权操作无需再获得Library Cache Pin的排他锁,我们看以下测试:
在Session 1中执行:

09:40:18 SQL> drop procedure calling;

Procedure dropped.

09:40:18 SQL>
09:40:18 SQL> drop procedure pining;

Procedure dropped.

09:40:18 SQL>
09:40:18 SQL> create or replace PROCEDURE pining
09:40:18 2 IS
09:40:18 3 BEGIN
09:40:18 4 NULL;
09:40:18 5 END;
09:40:18 6 /

Procedure created.

09:40:18 SQL>
09:40:18 SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

09:40:18 SQL> create or replace procedure calling
09:40:18 2 is
09:40:18 3 begin
09:40:18 4 pining;
09:40:18 5 dbms_lock.sleep(60);
09:40:18 6 end;
09:40:18 7 /

Procedure created.

09:40:18 SQL>
09:40:18 SQL> col object_name for a30
09:40:18 SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
CALLING 2007-04-02 09:40:18
PINING 2007-04-02 09:40:18

09:40:18 SQL>
09:40:18 SQL> exec calling;

在Session 2执行授权:

SQL> set time on
09:40:22 SQL> grant execute on pining to sys;

Grant succeeded