oracle 一次row cache lock跑批等待案例

1.等待事件

2.查看历史事件

改时间
select event,p1,snap_id from DBA_HIST_ACTIVE_SESS_HISTORY where event=‘row cache lock’ and sample_time>to_date(‘2022-10-05 16:00:00’,‘yyyy-MM-dd HH24:mi:ss’) and sample_time

或者（去重）
select distinct event,p1,snap_id from DBA_HIST_ACTIVE_SESS_HISTORY where event=‘row cache lock’ and sample_time>to_date(‘2022-10-05 16:00:00’,‘yyyy-MM-dd HH24:mi:ss’) and sample_time

3.查看v$rowcache视图

cache#的值为上面的p1
select * from v$rowcache where cache#=13;

一些建议
根据P1值查询V$ROWCACHE视图（SELECTA.PARAMETERFROMV$ROWCACHE A WHERE CACHE# =P1;），进而确定队列类型。若为DC_SEQUENCES则增大序列的CACHE值；若为DC_USERS则可能是当用户密码错误或密码为空时用户频繁登录导致，进而查询审计来确定（SELECT * FROM DBA_AUDIT_TRAIL WHERE RETURNCODE IN (1017, 1005);。1017代表密码错误，1005代表空密码）；其它类型很可能是Shared Pool过小导致。

4.查看语句（有2个事因为案例里有2个）

查找sql_id
Select distinct sql_id from dba_hist_active_sess_history where snap_id=62106 and event=‘row cache lock’;
Select distinct sql_id from dba_hist_active_sess_history where snap_id=62107 and event=‘row cache lock’;

查找语句
Select sql_fulltext from v$sqlwheresq{l}_{i}d{=}^{\prime }2yjnjrjxb1at{4}^{\prime };Selectsq{l}_{f}ulltextfromv$sql where sql_id=‘9gx452c1q0n3d’;

5.查看ddl语句

确认对象类型及用户
Select owner,object_name from dba_objects where object_name in (‘SEQ_CTR_SCRULE_REF’,‘RL_RULE_EVAL_SEQ’);

查看ddl语句
Select dbms_metadata.get_ddl(‘对象类型’,‘对象名’,‘用户名’) from dual;

Set long 999999
Select dbms_metadata.get_ddl(‘SEQUENCE’,‘SEQ_CTR_SCRULE_REF’,‘FCR51HOST’) from dual;

可以看到创建序列的ddl里，一个是nocache一个是cache20 说明cache值过低，调大cache值
alter sequence 用户.SEQUENCE_NAME cache 30;

⑨ CACHE：使用CACHE选项时，该序列会根据序列规则预生成一组序列号。保留在内存中，当使用下一个序列号时，可以更快的响应。当内存中的序列号用完时，系统再生成一组新的序列号，并保存在缓存中，这样可以提高生成序列号的效率。Oracle默认会生产20个序列号。

⑩ NOCACHE：不预先在内存中生成序列号。
我的理解：每次读取下个序列，都要更改数据字典，如果cache 20，就是每20个序列，更改一次数据字典。

cache的大小建议
在RAC环境中，序列的Cache问题可能会对性能有着决定性的影响，缺省的序列Cache值为20，这对RAC环境远远不够。如果存在序列号使用的竞争，就可能在数据库中看到明显的队列等待：enq: SQ - contention
在RAC情况下，可以将使用频繁的序列Cache值增加到10000，或者更高到50000，这些值在客户的环境中都有采用。基本上cache 大于20的时候性能基本可以接受，最好设置100以上，nocache的时候性能确实很差，最大相差20倍．

常见队列锁类型

行缓冲队列锁等待的调优基于每一个队列锁类型的行为，其中常见的有：
①　DC_SEQUENCES：在使用序列的时候将发生该行缓冲队列锁。调优方式是检查序列是否指定了缓冲选项并确定这个缓冲值可以承受预期的并发insert操作。Check for appropriate caching of sequences for the application requirements.
②　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.
DC_SEQUENCES
For DC_SEQUENCES, consider caching sequences using the cache option.

DC_OBJECTS
Look for any object compilation activity which might require an exclusive lock, blocking other activities

DC_SEGMENTS
Contention here is most likely to be due to segment allocation. Investigate what segments are being created at the time.

DC_USERS
This may occur if a session issues a GRANT to a user and that user is in the process of logging on to the database. Investigate why grants are being made while the users are active.

DC_TABLESPACES
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.

本文部分内容参考51CTO博客小麦苗123