个人简介
偶尔有空上来看看
文章分类
文章存档
最近访客
相关博文
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： oracle
2022-03-26 16:02:04
告警日志中看到这个信息，往往心情一沉
你应当知道的是：
通常情况下， row cache enqueue 是一系列事件的一部分，阻塞了申请 row cache enqueue 的进程的进程很可能被另一个进程阻塞。row cache enqueue 经常是问题的表象。
还应当知道的是：
当达到阈值会引发 "waited too long for a row cache enqueue lock!" 这个消息，因此，如果未达到阈值它不会被引发。这意味着，不太严重的问题，即使具有相同的原因，也可以不输出该消息。
概念：
行缓存（row cache）或数据字典缓存（data dictionary cache）是保存数据字典信息的共享池的内存区域。row cache 保存数据时并不是以数据块的形式，而是以行的形式。row cache enqueue 锁是在数据字典行的锁。此 enqueue 是关于特定数据字典对象的。这就是所谓的 enqueue 类型，可以在视图 v$rowcache 中找到。
缘由：
当我们试图获得 row cache 锁，这种等待事件将被使用。
当 row cache 冲突发生时，如果不能在一个预定的时间周期内得到 enqueue，将在 user_dump_dest 或 background_dump_dest 目录下生成一个跟踪文件，这取决于是用户还是后台进程创建的跟踪文件。alert.log 通常会相应的更新警告消息和跟踪文件的位置。
数据库检测到核心资源被持有太久并通知管理员，从而让这种情况可以得到解决。这也可能伴随着数据库挂起或变慢。
首要排查：
sga 的shrink/resize
定位这种情况的方法是，有很多'sga: allocation forcing component growth'等待事件，或 awr 的 top 列表有类似等待,以及阻塞等待"waited too long for a row cache enqueue lock!" 的会话在等待'sga: allocation forcing component growth'
或者
row cache enqueue 类型：
dc_tablespaces:最可能的原因是新 extent 的分配
dc_sequences:序列缓存太少了，现在比较少见了
dc_users:用户授权
dc_rollback_segments:由于 rollback 段的分配导致的
dc_awr_control:可能是生成awr遇到问题
深入诊断：
当问题发生时，错误会记入 alert.log，并自动产生一个 systemstate dump 文件（多贴心，国产库好好学学），还需要3a报告，19c的库一个awr即可（一键三连了）。
示例：
参考：
故障排除："waited too long for a row cache enqueue lock! " (doc id 2016422.1)
你应当知道的是：
通常情况下， row cache enqueue 是一系列事件的一部分，阻塞了申请 row cache enqueue 的进程的进程很可能被另一个进程阻塞。row cache enqueue 经常是问题的表象。
还应当知道的是：
当达到阈值会引发 "waited too long for a row cache enqueue lock!" 这个消息，因此，如果未达到阈值它不会被引发。这意味着，不太严重的问题，即使具有相同的原因，也可以不输出该消息。
概念：
行缓存（row cache）或数据字典缓存（data dictionary cache）是保存数据字典信息的共享池的内存区域。row cache 保存数据时并不是以数据块的形式，而是以行的形式。row cache enqueue 锁是在数据字典行的锁。此 enqueue 是关于特定数据字典对象的。这就是所谓的 enqueue 类型，可以在视图 v$rowcache 中找到。
缘由：
当我们试图获得 row cache 锁，这种等待事件将被使用。
当 row cache 冲突发生时，如果不能在一个预定的时间周期内得到 enqueue，将在 user_dump_dest 或 background_dump_dest 目录下生成一个跟踪文件，这取决于是用户还是后台进程创建的跟踪文件。alert.log 通常会相应的更新警告消息和跟踪文件的位置。
数据库检测到核心资源被持有太久并通知管理员，从而让这种情况可以得到解决。这也可能伴随着数据库挂起或变慢。
首要排查：
sga 的shrink/resize
定位这种情况的方法是，有很多'sga: allocation forcing component growth'等待事件，或 awr 的 top 列表有类似等待,以及阻塞等待"waited too long for a row cache enqueue lock!" 的会话在等待'sga: allocation forcing component growth'
或者
-
alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
-
set pagesize 900
-
set linesize 255
-
col component format a30
-
col initial_size format a10
-
col final_size format a10
-
spool asmm_resize.txt
-
select start_time, component, oper_type, oper_mode, initial_size/1024/1024 "initial", final_size/1024/1024 "final", end_time
-
from v$sga_resize_ops
-
where component in ('default buffer cache', 'shared pool')
-
and status = 'complete'
-
order by start_time, component;
- spool off
row cache enqueue 类型：
dc_tablespaces:最可能的原因是新 extent 的分配
dc_sequences:序列缓存太少了，现在比较少见了
dc_users:用户授权
dc_rollback_segments:由于 rollback 段的分配导致的
dc_awr_control:可能是生成awr遇到问题
深入诊断：
当问题发生时，错误会记入 alert.log，并自动产生一个 systemstate dump 文件（多贴心，国产库好好学学），还需要3a报告，19c的库一个awr即可（一键三连了）。
-
col parameter for a32
-
col type for a12
-
-
select * from (select parameter,cache#,count,gets,getmisses from v$rowcache order by getmisses desc) where rownum<11
-
- select cache#,parameter,type,subordinate#,count,round(getmisses/gets*100,1) miss_percent from v$rowcache where cache#=&cache;
-
示例：
参考：
故障排除："waited too long for a row cache enqueue lock! " (doc id 2016422.1)
给主人留下些什么吧！~~