客户反映登录数据库缓慢，检查v$session_wait视图发现有大量row cache lock等待事件。从ash报告中也可以看到row cache lock等待事件比较明显
Top User Events
Event Event Class % Activity Avg Active Sessions
row cache lock Concurrency 77.90 33.49
cursor: pin S wait on X Concurrency 22.00 9.46
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的等待最为严重，有助于解决问题。
通过ASH报告的主机信息，发现shared pool只有776M，感觉像是共享池过小问题。
CPUs SGA Size Buffer Cache Shared Pool ASH Buffer Size
4 6,144M (100%) 5,216M (84.9%) 776M (12.6%) M (%)
通过检查发现数据库SGA设置为6G，其中BUFFER CACHE设置最小为5G (db_cache_size=5G)。
调整db_cache_size参数为0，让数据库自动调整。该问题解决。
参考资料：
惜分飞的《ROW CACHE LOCK等待事件》
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/11590946/viewspace-1062112/ ，如需转载，请注明出处，否则将追究法律责任。
