http://www.oraclefans.cn/forum/showtopic.jsp?rootid=4806
ROW CACHE LOCK等待事件是一个共享池相关的等待事件。是由于对于字典缓冲的访问造成的。
P1 - Cache Id
P2 - Mode Held
P3 - Mode Requested
mode 和REQUEST的取值：
KQRMNULL 0 null mode - not locked
KQRMS 3 share mode
KQRMX 5 exclusive mode
KQRMFAIL 10 fail to acquire instance lock
如果是RAC/OPS环境，前台进程发出锁请求，LCK0进程发出锁请求。如果是单实例模式，由前台进程直接发出锁请求。
在RAC/OPS环境下，前台进程会循环等待锁的获取，最多会等待60秒钟。在单实例环境，前台进程会循环1000次，等待3秒钟。PMON进程无论在哪种模式，都会等待5秒钟。
要注意的是单实例模式下和多实例模式下申请该锁调用的模块是不同的（kqrget()- 单实例，kqgigt()- 多实例）。
如果发现这个等待十分高，一般来说可能由于2种原因，一是共享池太小了，需要增加共享池，另外一种情况是SQL分析过于频繁，对于共享池的并发访问量过大。对于任何一种情况，绝大多数情况下加大共享池会有助于降低该等待，不过加大共享池的时候也要注意，并不一定所有的情况下增加共享池都会有明显的效果，特别是对于第二种情况，精确的分析十分重要。另外进一步分析，弄清楚哪些ROW CACHE的等待最为严重，有助于解决问题。
比如说如果发现dc_sequences等待比较严重，那么单纯的增加共享池的大小是起不到应有的作用的,而是要通过优化SEQUENCE的访问性能（比如CACHE,NOORDER等）来达到目的。对于早期的版本（7,8.0)，SEQUENCE_CACHE_ENTRIES参数的调整也十分关键。
如果dc_sequences等待比较严重，而且系统中有很多sequences，怎么判断那个需要调整呢？我调整了一个频繁调用的sequence的cache，可是还是很高
Get Pct Scan Pct Mod Final
Cache Requests Miss Reqs Miss Reqs Usage
------------------------- ------------ ------ ------- ----- -------- ----------
dc_histogram_data 5,164 0.2 0 0 1,852
dc_histogram_data_values 940 0.0 0 0 396
dc_histogram_defs 7,665 0.5 0 0 8,472
dc_object_ids 21,806 0.2 0 0 5,849
dc_objects 131,786 0.1 0 1 2,389
dc_profiles 259,782 0.0 0 0 2
dc_rollback_segments 59,880 0.1 0 34 956
dc_segments 6,136 1.0 0 0 6,533
dc_sequences 835 72.8 0 835 50
dc_table_scns 185 2.7 0 3 2
dc_tablespace_quotas 5 40.0 0 5 1