前台反应应用连接不上，登录数据库发现大量 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博客

row cache lock案例分析处理

最新文章