ROW CACHE LOCK

作者简介:张立,现就职于北京海天起点,获有12c OCP、MYSQL OCP认证,具有多年oracle数据库和goldengate管理维护经验,并且对于mysql的主从搭建、升级、日常维护也具有丰富实践经验。主要从事客户的现场维护,服务对象覆盖电信、国家税务局等大型企事业单位,擅长数据库故障分析,性能调优等。

共享池(Shared Pool)包含library cache和dictionary cache,以减少磁盘的I/O访问。数据字典信息以行缓存(Row Cache)或数据字典缓存(Data Dictionary Cache)的形式保存在共享池的dictionary cache区域,并允许对行进行加锁。row cache 保存数据就是以行的形式。row cache lock就是在数据字典行的锁。

行高速缓冲区位于共享池区域,可通过如下命令进行确认。

运行DDL必须请求一个行缓冲锁(row cache lock)来锁住数据字典(Data Dictionary)信息。数据字典行锁被叫做行缓冲队列锁(Row Cache Enqueue Locks)。这个队列锁结构从共享池中按需求分配,当这些请求在等待并超时就会看到行缓冲队列锁。row cache lock等待事件是一个共享池相关的等待事件,是由于对字典缓冲的访问造成的。每一个行缓冲队列锁都对应一个特定的数据字典对象,这被叫做队列锁类型,并可以在V$ROWCACHE视图中找到。

在以下的示例就是对应数据字典对象的常见队列锁类型

这类属于latch类的资源竞争,相当耗CPU,如果并发量大的话,极容易引发down机。如果发现这类等待十分高,简单来说就是两个原因,一是共享池太小了,需要增加共享池,另外一种情况就是对于共享池的并发访问量过大(道理就像堵车,要么是路不够宽,要么就是车太多)。

如果是路不够宽,问题就简单多了,所以解决row cache lock等待事件首先要检查数据库的参数配置是否合理,对于不合理的参数配置,加大共享池有助于降低该等待。

当然绝大多数情况下加大共享池并无助于降低该等待,毕竟大多数堵车也不是因为路不够宽,此时精确的分析十分重要。特别是对于第二种情况,。进一步分析,弄清楚哪些ROW CACHE的等待最为严重,有助于解决问题。

通过关联v$session和v$rowcache可以查询出争用的row cache类型

例:

查询v$rowcache

我们也可以通过awr,ash报告,hang analyze等手段获取row cache lock的相关信息

不同的队列锁类型,产生row cache lock的原因不同,解决方法也不同,其中最具代表性的是sequence,在获取sequence的nextval过程中需要修改数据字典信息时,应该对row cache object以SSX获得row cache lock。SSX模式之间因为不存在共享性,所以多个进程同时对相同sequence调用nextval时,发生对于row cache lock的争用。若在获取row cache lock过程中发生争用,则等待row cache lock事件。

许多进程同时使用没有赋予cache属性的sequence时,可能大量发生row cache lock事件等待。对没有使用cache的sequence,如果调用nextval,则每次数据字典信息都应该被修改,所以应该以SSX模式获得row cache lock。因为SSX之间不存在共享性,所以在此过程中发生争用。因此,出现row cache等待时,需要确认sequence上是否赋予了nocache属性。赋予cache属性的sequence上,不会发生row cache lock争用引起的性能问题。

生产环境下除了sequence之外,常见的row cache类型还有DC_USERS,对于此类故障,ORACLE给出的官方解释是因为某一账户使用错误密码的并发登录触发的bug (路上有坑),Remote Connections Fails In ORA-03135 With Contention On DC_USERS During Login (文档 ID 1212224.1),由于各平台补丁不全,所以解决此类故障的方法就只有找到配错口令的客户端,并为其保存正确的密码。

以下是常见row cache类型的故障原因和处理建议:

① DC_SEQUENCES:在使用序列的时候将发生该行缓冲队列锁。调优方式是检查序列是否指定了缓冲选项并确定这个缓冲值可以承受预期的并发insert操作。

② DC_USED_EXTENTS和DC_FREE_EXTENTS:该行缓冲队列锁可能在空间管理碰到表空间分裂或者没有足够区大小时发生。调优方法是检查表空间是否分裂了、区大小是否太小或者表空间是人工管理。

③ DC_TABLESPACES:该行缓冲队列锁会在分配新区是发生。如果区大小设置得过小,程序将经常申请新区,这将导致冲突。调优方法是快速地增加区的数量。Probably the most likely cause is the allocation of new extents. If extent sizes are set low then the application may constantly be requesting new extents and causing contention. Do you have objects with small extent sizes that are rapidly growing? (You may be able to spot these by looking for objects with large numbers of extents). Check the trace for insert/update activity, check the objects inserted into for number of extents.

④ DC_OBJECTS:该行缓冲队列锁会在重编译对象的时候发生。当对象编译时将申请一个排他锁阻塞其他行为。通过检查非法对象和依赖关系来调优。

⑤ DC_SEGMENTS:该行缓冲队列锁会在段分配的时候发生,观察持有这个队列锁的会话在做什么。This is likely to be down to segment allocation. Identify what the session holding the enqueue is doing and use errorstacks to diagnose.

⑥ DC_USERS:Deadlock and resulting “WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!” can occur if a session issues a GRANT to a user, and that user is in the process of logging on to the database.dc_users是和用户用错误密码登陆有关,In 11g there is an intentional delay between allowing failed logon attempts to retry密码延迟验证. For some specific application types this can cause a problem as the row cache entry is locked for the duration of the delay . This can lead to excessive row cache lock waits for DC_USERS for specific users / schemas.

After 3 successive failures a sleep delay is introduced starting at 3 seconds and extending to 10 seconds max. During each delay the user X row cache lock is held in exclusive mode preventing any concurrent logon attempt as user X (and preventing any other operation which would need the row cache lock for user X).

⑦ DB_ROLLBACK_SEGMENTS:This is due to rollback segment allocation. Just like dc_segments,identify what is holding the enqueue and also generate errorstacks. Remember that on a multi-node system (RAC) the holder may be on another node and so multiple systemstates from each node will be required.

⑧ DC_AWR_CONTROL:This enqueue is related to control of the Automatic Workload Repository. As such any operation manipulating the repository may hold this so look for processes blocking these.

以上的分析不难看出产生row cache lock的原因十分错综复杂,但是一切复杂事物都是基本元素通过简单规则的无限涌现,其实对于此类问题,只要我们找到row cache类型,确定争用的资源类型,做好数据库的交通调配,问题也就迎刃而解了。

未经允许不得转载:Oracle一体机用户组 » ROW CACHE LOCK

相关推荐