row cache lock等待是真实的数据字典缓存争用，需通过v$rowcache或v$active_session_history定位具体争用项（如dc_sequences、dc_users、dc_objects），再针对性优化序列缓存、拦截错误登录或错峰ddl。
row cache lock 等待不是锁坏了，而是真实的数据字典缓存被高频争用——只要它持续出现，就说明有会话正在反复修改或验证某类元数据（比如序列值、用户权限、对象定义），其他会话被迫排队等读。
怎么快速定位是哪类字典缓存被争用
别只看等待事件总数，必须查 v$rowcache 或 v$active_session_history 找出具体缓存项：
- 查
v$rowcache中GETMISSES和MODIFICATIONS同时偏高的项：SELECT parameter, gets, getmisses, modifications FROM v$rowcache WHERE getmisses > 1000 ORDER BY getmisses DESC;
重点关注dc_sequences（高频 NEXTVAL）、dc_users（错误登录/GRANT）、dc_objects（DDL 集中执行） - 用
v$active_session_history快速锁定 cache#：SELECT p1, COUNT(*) c FROM v$active_session_history WHERE event = 'row cache lock' AND sample_time > SYSDATE - 1/24 GROUP BY p1 ORDER BY c DESC;
拿到最高频的p1（如 8），再查对应名称：SELECT parameter FROM v$rowcache WHERE cache# = 8;
为什么 dc_sequences 争用最常见？
本质是 NOCACHE 序列在高并发下主动制造阻塞：每次 NEXTVAL 都要更新 seq$ 表并持 SSX 锁，所有请求全卡在 dc_sequences 上。
-
ALTER SEQUENCE order_seq CACHE 1000;—— RAC 环境最低建议 1000，单实例可从 500 起步 - 禁用
ORDER（除非业务真要求跨实例严格连续）：CREATE SEQUENCE log_id NOORDER CACHE 1000; - Oracle 12c+ 可加 SESSION 级缓存，彻底隔离竞争：
ALTER SEQUENCE seq_name CACHE 1000 SESSION; - 避免在 PL/SQL 循环里反复
SELECT seq.NEXTVAL INTO，改用单次INSERT ... VALUES (seq.NEXTVAL)
为什么 dc_users 争用容易被忽略？
Oracle 11g+ 默认启用登录延迟机制：同一用户连续 3 次输错密码后，后续所有连接（含正确密码）都会卡在 dc_users 的 row cache lock 上，且延迟时间指数增长。
- 确认是否为此原因：
SELECT username, returncode, COUNT(*) FROM dba_audit_trail WHERE returncode = 1017 AND timestamp > SYSDATE - 1/24 GROUP BY username, returncode ORDER BY 3 DESC; - 临时绕过（仅限紧急排障）：
ALTER SYSTEM SET EVENTS '28401 trace name context forever, level 1';（重启失效，且暴露暴力破解风险） - 根本解法：定位客户端 IP 和应用账户，修复硬编码密码；或收紧
FAILED_LOGIN_ATTEMPTS并启用账户锁定策略
真正难处理的从来不是等待本身，而是把 row cache lock 当成“性能问题”去调共享池大小——它背后一定是某个具体字典项被高频触发，而这个触发源往往藏在应用层逻辑、部署脚本或安全配置里，不挖到 p1 对应的 parameter 名，所有优化都是蒙眼干活。
