oracle解析相关的等待事件(Shared Pool latch/library cache: mutex X/cursor: pin S)

 

Shared Pool/Library Cache Latch Contention
可能的原因
sql语句不能被重用,语句没有使用绑定变量,不合适的应用游标缓存大小,频繁的登入或登出,数据库对象上做过ddl操作,共享池太小等
在会话级别
V$SESSTAT
parse time CPU
parse time elapsed
Ratio of parse count (hard) / execute count
Ratio of parse count (total) / execute count
在游标缓存(V$SQLAREA/V$SQLSTATS)
高的PARSE_CALLS / EXECUTIONS
EXECUTIONS = 1 differing only in literals in the WHERE clause (that is, no bind variables used)
High RELOADS(高的重载次数)
High INVALIDATIONS(高的失效次数,ddl等操作造成对象失败需要重新解析)
Large (> 1mb) SHARABLE_MEM

共享池或库缓存latch 争用的主要原因是由于解析,有很多技术可以避免没必要的解析。
1.手工检查只执行次数很少的sql语句是不是相似的。

SELECT SQL_TEXT FROM V$SQLSTATS WHERE EXECUTIONS < 4 ORDER BY SQL_TEXT;

2.由于很多语句在select部分是一样的,而在where之后条件不一致,根据这种情况,可以截取语句的前半部分区汇总,得到相似的语句。

SELECT SUBSTR(SQL_TEXT, 1, 60), COUNT(*)
  FROM V$SQLSTATS
 WHERE EXECUTIONS < 4
 GROUP BY SUBSTR(SQL_TEXT, 1, 60)
HAVING COUNT(*) > 1;

3.查询不同的语句但使用了相同的执行计划,这些语句使用的是字面值而不是绑定变量。

SELECT SQL_TEXT
  FROM V$SQLSTATS
 WHERE PLAN_HASH_VALUE IN (SELECT PLAN_HASH_VALUE
                             FROM V$SQLSTATS
                            GROUP BY PLAN_HASH_VALUE
                           HAVING COUNT(*) > 4)
 ORDER BY PLAN_HASH_VALUE;

检查V$SQLSTATS视图

SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS
  FROM V$SQLSTATS
 ORDER BY PARSE_CALLS;

当执行次数和解析次数相近时,这证明这些语句解析频率很高,这些语句应该是调优的对象。
识别没必要的解析调用,这可能是特定的批处理程序或特定类型的应用做了对多的解析,根据如下查询识别

SELECT pa.SID, pa.VALUE "Hard Parses", ex.VALUE "Execute Count"
  FROM V$SESSTAT pa, V$SESSTAT ex
 WHERE pa.SID = ex.SID
   AND pa.STATISTIC# =
       (SELECT STATISTIC# FROM V$STATNAME WHERE NAME = 'parse count (hard)')
   AND ex.STATISTIC# =
       (SELECT STATISTIC# FROM V$STATNAME WHERE NAME = 'execute count')
   AND pa.VALUE > 0;  

硬解析的测试 

代码如下:

create or replace procedure p1 as
  v_cursor number;
  v_sql    varchar2(100);
  v_stat   number;
begin
  for x in 1 .. 10000 loop
    v_sql    := 'insert into t9 values (' || x || ')';
    v_cursor := dbms_sql.open_cursor; --????????
    dbms_sql.parse(v_cursor, v_sql, dbms_sql.native);
    v_stat := dbms_sql.execute(v_cursor);
    dbms_sql.close_cursor(v_cursor);
  end loop;
  commit;
end;

 开两个会话同时执行调用存储过程p1:(预先查询sid为12,70) ;

查询结果 

select * from v$session_wait_history  where sid in ('12','70')

oracle解析相关的等待事件(Shared Pool latch/library cache: mutex X/cursor: pin S)_第1张图片

可见很多都是 shared pool latch的争用 。

与解析相关的其它锁,不是latch
library cache pin
该事件管理库缓存争用,pin住一个对象导致heaps 被laods进入内存,如果client想要修改或检查object,client必须获取一个pin在库缓存对象上。
library cache lock
这个事件控制clients 的争用,它会获取一个锁在对象句柄上。
一个clients能阻止其它clients 访问相同的对象。
客户端能够维护一个长时间的依赖关系不允许其它clients 修改对象。
这个锁也用来搜索对象在库缓存中。

对软解析的测试

代码如下

create or replace procedure p3 as
  v_cursor number;
  v_sql    varchar2(100);
  v_stat   number;
begin
 -- execute immediate 'alter session set session_cached_cursors=1000';
  v_sql := 'insert into t9 values (:a)';
  for x in 1 .. 1000000 loop
    v_cursor := dbms_sql.open_cursor; --????????
    dbms_sql.parse(v_cursor, v_sql, dbms_sql.native);
    dbms_sql.bind_variable(v_cursor, ':a', x);
    v_stat := dbms_sql.execute(v_cursor);
    dbms_sql.close_cursor(v_cursor);
  end loop;
  commit;
end;

  开两个会话同时执行调用存储过程p3:(预先查询sid为12,70) ;

查询结果 

select * from v$session_wait_history  where sid in ('12','70')

oracle解析相关的等待事件(Shared Pool latch/library cache: mutex X/cursor: pin S)_第2张图片

可见软解析几乎都是ibrary cache: mutex X/cursor: pin S的等待。

  

 

转载于:https://www.cnblogs.com/wangxingc/p/6203288.html

你可能感兴趣的:(数据库)