存在严重行锁冲突需满足：Top 5 Timed Foreground Events 中 enq: TX - row lock contention 排前三、Avg Wait > 10ms、Waits 每小时上万次；需交叉验证 Segments by Row Lock Waits 与 SQL ordered by Gets，关注未走索引、函数导致索引失效、高执行低处理等SQL；结合 Load Profile 判断事务合理性；RAC 环境须分实例分析，避免合并报告掩盖节点级热点。
看 Top 5 Timed Foreground Events 里有没有 enq: TX - row lock contention
如果这个事件出现在 Top 5 且排前三，同时满足两个条件：Avg Wait > 10ms、Waits 每小时上万次，基本可断定存在严重行锁冲突。别只盯“占比”——它可能只有 6%，但总等待时间占 DB Time 的 72%，说明其他事件全是陪跑。
交叉验证 Segments by Row Lock Waits 和 SQL ordered by Gets
在 AWR 报告末尾的 Segments by Row Lock Waits 区域，找出 Row Lock Waits 高的表和索引；再回到 SQL ordered by Gets 表格，搜索这些对象名，定位对应 sql_id。重点关注：
-
Buffer Gets Per Exec> 50000 但Physical Reads Per Exec很低 → 典型没走索引，全表扫描放大锁范围 -
WHERE条件含to_char(create_time, 'yyyymmdd') = '20260409'这类函数 → 索引失效，UPDATE 实际扫全表 -
Executions高但Rows Processed极低 → 单条 UPDATE 锁住大量无关行
检查事务节奏是否合理：用 Load Profile 反推
翻到 AWR 的 Load Profile 区域，计算三个比值：
-
Executes per Transaction> 50 → 单个事务干太多事，锁持有时间被拉长 -
Logons per Transaction≈ 1 → 应用用短连接 + 长事务，连接一建就开事务不提交，资源长期被占 -
Transactions per Second突增但Commit per Second滞后 → 提交节奏被打乱，锁堆积成山
RAC 环境下必须分实例查，否则直接漏掉热点节点
单实例报告里 enq: TX - row lock contention 占比可能不到 2%，但 RAC 中某节点 AAS 达到 8.3，另一节点仅 0.1 —— 这种负载倾斜在合并报告里会被平均掉。必须用 @?/rdbms/admin/awrrpti.sql 单独生成各实例报告，再逐个比对 Top 5 Events 和 Segments by Row Lock Waits。
