row cache lock大量出现明确指向数据字典缓存争用，需通过p1值查v$rowcache定位具体缓存项（如dc_sequences、dc_users等），再结合错误登录审计、序列CACHE设置及回收站清理排查三类高频原因。

row cache lock 在 Oracle 11g 的 AWR 报告中大量出现，不是偶然现象，而是明确指向某类元数据争用——*你正在高频修改或反复查询数据字典缓存项（dc_），且当前并发压力已超出其锁粒度承载能力**。

---

怎么快速确认是哪个缓存项在扛不住

row cache lock 等待本身不告诉你“谁在卡”，只告诉你“卡在哪一级缓存”。必须结合 p1 值反查：

• 查当前活跃会话的 p1：

  SELECT sid, event, p1 FROM v$session WHERE event = 'row cache lock' AND status = 'ACTIVE';

• 根据 p1 查缓存名：

  SELECT parameter FROM v$rowcache WHERE cache# = <p1_value>;

常见高危项：

• dc_sequences：序列没设 CACHE 或设得太小（比如 CACHE 1）
• dc_users：错误密码频繁登录（尤其从 10g 升级到 11g 后未同步改客户端密码）
• dc_objects：批量 DDL（如自动化脚本反复 DROP/CREATE TABLE）
• dc_realtime_tabst（11gR2+）：实时统计信息自动收集被触发，但表变更太频繁

---

为什么 11g 特别容易暴露这个问题

Oracle 11g 引入了两个关键变化，让原本“安静”的争用突然显性化：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

• 密码验证延迟机制（delayed failed logins）默认开启：每次错误登录都会在 dc_users 上持短暂排他锁，失败次数越多，锁持有时间越长；
• library cache lock 和 row cache lock 在 11.2+ 中对登录失败的归类更细，大量 RETURNCODE = 1017（用户名/密码错误）会直接堆在 dc_users 上；

你看到的 AWR 里 row cache lock 平均等待时间动辄几百毫秒，大概率不是业务 SQL 写得差，而是后台有台应用服务器还在用旧密码轮询登录。

---

别急着调大 shared pool —— 先排除这三类低级但高频原因

• 客户端密码失效

  • 查审计：

    SELECT userhost, username, COUNT(*) c FROM dba_audit_trail WHERE returncode = 1017 AND timestamp > SYSDATE - 1/24 GROUP BY userhost, username ORDER BY c DESC;

  • 解法：停掉对应客户端，或临时禁用延迟（ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE=SPFILE）

• 序列定义裸奔

  • 查 NOCACHE 或 CACHE 1 序列：

    SELECT sequence_owner, sequence_name, cache_size FROM dba_sequences WHERE cache_size <= 1;

  • 解法：对主键类序列统一设 CACHE 20–200，避免每次 NEXTVAL 都刷 seq$ 表

• 回收站（recyclebin）自动清理

  • 查是否在跑 DELETE FROM RECYCLEBIN$ 类语句（AWR Top SQL 里常藏得深）
  • 解法：手动清空回收站（PURGE RECYCLEBIN），或关掉自动清理（ALTER SYSTEM SET "_recyclebin_cleanup_interval" = 0）

---

真正棘手的从来不是参数怎么调，而是你花一小时查 v$rowcache，结果发现罪魁祸首是一台三年前部署、没人维护的监控脚本，每分钟用错密码连一次库。这类问题不会出现在性能调优手册里，但会在你凌晨三点的 oncall 页面上反复弹出。