ROW CACHE ENQUEUE LOCK等待事件研究

作者简介:李晓朋,现就职于北京海天起点技术服务股份有限公司山东办事处,担任数据库工程师,获有OCP11g证书,具有多年数据库运维经验,主要服务于政府部门,熟悉Oracle数据库与linux系统日常维护工作,故障排查。

什么是ROW CACHE ENQUEUE LOCK

官方解释:

The Row Cache or Data Dictionary Cache is a memory area in the shared pool that holds data dictionary information. Row cache holds data as rows instead of buffers.A Row cache enqueue lock is a lock on the data dictionary rows. The enqueue will be on a specific data dictionary object. This is called the enqueue type and can be found in the v$rowcache view.

行缓存(Row Cache)或数据字典缓存(Data Dictionary Cache)是保存数据字典信息的共享池的内存区域。row cache 保存数据时并不是以数据块的形式,而是以行的形式。row cache enqueue 锁是在数据字典行的锁。此 enqueue 是关于特定数据字典对象的。这就是所谓的

enqueue 类型,可以在视图 V$rowcache 中找到。

例如我们提交如下查询脚本:

ROW CACHE ENQUEUE LOCK工作原理分析

当我们试图获得 row cache 锁,这种等待事件将被使用。

row cache 冲突发生时,如果在某个预定时间段内无法获取enqueue,则根据用户或后台进程是否创建跟踪文件,将在user_dump_destbackground_dump_dest中生成跟踪文件。alert.log通常会随着警告和跟踪文件的位置而相应更新。

数据库检测到核心资源被持有太久并通知管理员,从而让这种情况可以得到解决。这也可能伴随着数据库挂起或变慢。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 环境会一直重复,直到不能获得实例锁或者被中断

注意:WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!当达到阈值会引发这个消息,因此,如果未达到阈值它不会被引发。这意味着,不太严重的问题,即使具有相同的原因,也可以不输出该消息。

造成WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK可能的原因有哪些

SGA收缩(shrink/调整大小的操作(resize

解释:如果 SGA 动态地改变大小,需要持有各种 latches 来避免其它进程同时操作,直到操作完成。如果调整大小需要一段时间,或者是经常发生,你会看到WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK的发生。定位这种情况的方法是,有很多‘SGA: allocation forcing component growth’等待事件,或 AWR TOP 列表有类似等待,以及阻塞等待WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK 的会话在等待SGA: allocation forcing component growth

一种解决方案是增加SGA或禁用AMM

bug行为

例如Document 9267837.8 Bug 9267837 – Auto-SGA policy may see larger resizes than needed

row cache enqueue 类型介绍

对于每一个enqueue类型都有对应的一些操作会需要获取这类 enqueue队列的类型,可能给出由于操作可能导致的问题的指示。一些常见的原因如下

  • DC_TABLESPACES:最可能的原因是新 extent 的分配。如果 extent 大小设置过小,那么应用程序可能会不断地要求新的 extent,这可能导致争用。你有很小的 extent 尺寸,正在迅速增长的对象吗?(通过查找具有大量 extents 的对象可以定位它们)。检查 insert/update 活动的trace,查找那些就有很多 extents 的对象
  • DC_SEQUENCES:顾名思义,检查应用程序用到的 sequence cache 的大小
  • DC_USERS:一个会话正在对一个用户执行 GRANT,与此同时此用户正在登录到数据库中,此时可能会发生死锁或导致WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK
  • DC_OBJECT_IDS
  • DC_SEGMENTS:这很可能是 segment 的分配导致的。确定持有锁的用户正在做什么并使用 errorstacks 进行诊断
  • DC_ROLLBACK_SEGMENTS:这可能是由于 rollback 段的分配导致的。正如 dc_segments,确定谁持有锁并收集 errorstack 来进行诊断。在多节点系统(RAC)上,持有者可能在另一节点上,因此需要所有节点的 systemstate
  • DC_TABLE_SCNSDeadlock between Create MVIEW and DML – fixed in 10.2.0.5 ,11.1.07 and 11.2.0.1
  • DC_AWR_CONTROL:此enqueue关系到AWR的控制权。任何操纵 AWR 资料库的操作将持有它. 要分析这个问题,需要查找是那些进程阻塞了它们

收集哪些信息来查明原因

  • Systemstate dump当问题发生时,错误会记入 alert.log,并自动产生一个 systemstate dump 文件
  • AWRADDM ASH 报告:收集两份 AWR 报告,一份有问题时间段的,另一个是没有问题时间段的,因为这些可以帮助我们理解问题发生时数据库的状况 AWRADDMASH 报告,可以相互取长补短,从而更完整地理解整个问题。

 

 

未经允许不得转载:Oracle一体机用户组 » ROW CACHE ENQUEUE LOCK等待事件研究

相关推荐