字典缓存争用需交叉验证：查AWR中row cache lock是否占比超1%或突增，结合dba_hist_system_event总等待次数翻倍、v$rowcache高getmisses/gets比及dc_sequences等modifications上升，并关联DDL变更与shared_pool碎片情况。
字典缓存（row cache）争用在AWR中不会直接标为“row cache lock”，必须从等待事件、统计值和对象变更三处交叉验证，否则容易误判为SQL或I/O问题。
查 row cache lock 等待是否真实升高
AWR报告里「Top 5 Timed Foreground Events」中若出现 row cache lock，且占比超过1%或绝对时间突增，才需深挖。但注意：该事件常被归入“Other”等待类，容易被忽略。
- 单独查该事件在快照区间内的总等待次数和时间：
SELECT event, total_waits, time_waited_ms FROM dba_hist_system_event WHERE event = 'row cache lock' AND snap_id BETWEEN :start AND :end; - 对比相邻两个正常快照，看
total_waits是否翻倍以上——单次报告高可能只是采样噪声 - 若
time_waited_ms高但average_wait_ms
定位具体争用的字典项（dc_XXX）
row cache lock 的 p1 是 cache#，不是文件号或对象号，必须查 v$rowcache 或 v$event_name 映射才能知道是哪个子缓存被卡住。
- 执行：
SELECT parameter, gets, getmisses, modifications FROM v$rowcache WHERE gets > 0 ORDER BY getmisses DESC; - 重点关注
getmisses/gets > 0.1且modifications持续上升的项，如dc_sequences（序列频繁递增）、dc_objects（高频对象访问）、dc_users（连接风暴） - 若
dc_sequences的modifications高，立刻检查应用是否用了无缓存（NOCACHE）序列，或是否在循环中反复SELECT seq.NEXTVAL
关联DDL与对象变更时间点
字典缓存争用往往由隐式或显式 DDL 触发，比如创建同义词、修改表结构、甚至收集统计信息（DBMS_STATS 默认 cascade=true 会级联失效依赖对象）。
- 查最近1小时内变更过的对象：
SELECT object_name, object_type, last_ddl_time FROM dba_objects WHERE last_ddl_time > SYSDATE - 1/24 AND owner NOT IN ('SYS','SYSTEM'); - 查依赖链是否过长：
SELECT referenced_owner, referenced_name, referenced_type FROM dba_dependencies WHERE name = 'YOUR_PROBLEM_OBJECT'; - 特别注意
ORA-04062报错虽不直接出现在AWR，但若它集中出现，大概率对应row cache lock尖峰——因为 timestamp mismatch 会强制重载整个依赖树
shared_pool 设置不当会放大争用
很多人以为加大 shared_pool_size 就能缓解 row cache lock，结果反而更糟：shared pool 过大会拉长 LRU 链查找时间，使 dc_* 查找变慢，进一步延长锁持有时间。
- 检查
v$sgastat中free memory是否长期低于 50MB；若低，说明碎片或对象挤占严重，加内存治标不治本 - 运行
SELECT * FROM v$shared_pool_advice WHERE size_factor = 1;，看estd_parse_time_saved是否为负——为负说明当前大小已最优，再加只会拖慢 - 若确认是
dc_sequences争用，优先改应用：用CACHE 20序列、批量取值、或迁移到IDENTITY列（12c+）
真正难处理的不是看到 row cache lock，而是它藏在 library cache lock 或 enq: SQ - contention 后面——同一类操作可能触发不同锁类型，得靠 p1 和堆栈反推，不能只信事件名。
