行缓存(Row Cache)或数据字典缓存(Data Dictionary Cache)是保存数据字典信息的共享池的内存区域。 row cache 保存数据时并不是以数据块的形式,而是以行的形式。row cache enqueue 锁是在数据字典行的锁。此 enqueue 是关于特定数据字典对象的。这就是所谓的 enqueue 类型,可以在视图 V$rowcache 中找到。
官方给出的获取该锁信息的脚本:
set pages 1000 column cache# format 99999 column name format a33 column latch# format 999999 select distinct s.kqrstcln latch#,r.cache#,r.parameter name,r.type,r.subordinate# from v$rowcache r,x$kqrst s where r.cache#=s.kqrstcid order by 1,4,5;
当试图去获得 row cache 锁时,这种等待事件将被使用。
当 row cache 冲突发生时,如果不能在一个预定的时间周期内得到 enqueue,将在user_dump_dest 或 background_dump_dest 目录下生成一个跟踪文件(
这两个目录的选择取决于是用户还是后台进程创建的跟踪文件。alert.log 通常会相应的更新警告消息和跟踪文件的位置)。
数据库检测到核心资源被持有太久并通知DBA,从而让这种情况可以得到解决。这也可能使数据库挂起或变慢alert.log 的消息和生成的跟踪文件包含以下信息:
> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! <<<
如果不能立即获取 rowcache entry 锁,那么进入一个循环,先释放 row cache 对象闩锁,等待上述等待事件,重新获得闩锁,然后再次尝试获取 rowcache 锁。在单实例模式,会重复 1000次直到进程报错“WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK”。在 RAC 环境会一直重复,直到不能获得实例锁或者被中断。
Systemstate dump 可以提供一些有用的信息诊断争用的原因。
注:
The "WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 当达到阈值会引发这个消息,因此, 如果未达到阈值它不会被引发。由此可知,对于不太严重的问题,即使具有相同的原因,也可以不输出该消息。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/69992972/viewspace-2952681/ ,如需转载,请注明出处,否则将追究法律责任。