row cache lock案例分析处理

row cache lock案例分析处理

 

 

前台反应应用连接不上，登录数据库发现大量 row cache lock 等待事件

 

 

查看发现对应的sql为：

INSERT INTO t_pdam_position

  (id,

   userCode,

   longitude,

   latitude,

   positionTime,

   insertTime,

   uuid,

   orderid)

VALUES

  (sys_guid(), :1, :2, :3, :4, sysdate, :5,  sq_t_pdam_position.nextval)

通过sql初步判断可能是序列加载导致

 

 

---通过 v$rowcache_parent视图 查看row cache lock对应的cache_name

 

select cache#, cache_name, lock_mode, lock_request, saddr

  from  v$rowcache_parent

 where lock_mode <> 0;

   CACHE#  CACHE_NAME             LOCK_MODE  LOCK_REQUEST  SADDR           

---------- -------------------------- --------- ------------ ----------------

       13     dc_sequences                      5           0           0000000BE1DF0180

      15     global database name        3           0           0000000BCA3BB160

      15     global database name        3           0           0000000BC1801938

 

---也可以通过 v$rowcache 视图进行查看，parameter为cache的类型

 

select parameter, gets, getmisses, MODIFICATIONS

  from  v$rowcache

 where cache# in

       (select distinct p1 from v$session where event = 'row cache lock');

 

关于不同类型的row cache lock问题解决方法可以参考MOS文档：

故障排除："WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! " (文档 ID 2016422.1)

 

---查看序列情况：

set lines 200

select SEQUENCE_OWNER,SEQUENCE_NAME,INCREMENT_BY,CACHE_SIZE from dba_sequences where SEQUENCE_NAME = upper('sq_t_pdam_position');

 

SEQUENCE_OWNER               SEQUENCE_NAME              INCREMENT_BY   CACHE_SIZE

------------------------------ ------------------------------ ------------            ----------

PDABASE                              SQ_T_PDAM_POSITION             1                        0

 

---修改序列cache_size值后问题解决

SQL> alter sequence PDABASE.SQ_T_PDAM_POSITION cache 20;

 

---

通过AWR分析思路如下：

参考： http://www.itpub.net/thread-1621524-1-1.html

 

1、DB Time相比平时明显是异常的

 

2、通过Load Profile节看到对于当前系统而言每秒的请求数是不正常的

 

3、继续分析报告，从Top 5中看到排在第一的等待事件是row cache lock，并且该等待事件的平均等待达到3234ms。

       ROW CACHE LOCK等待事件是一个共享池相关的等待事件，是由于对于字典缓冲的访问造成的。通常直接的解决办可以通过调大共享池来解决，但是，并非在所有场景下都凑效。

 

 

 

4、基于时间的统计信息中，加载序列sequence的耗时排在了第二位。

 

 

 

 

5、可以看对应执行最消耗时间的sql

 

 

 

6、通过Dictionary Cache Statistics，取值失败率几乎高达60%，在RAC层100%的取值冲突。

 

 

 

7、查看具体语句对应的sequence情况，并进行调整

 

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