尧图网站建设 
在 AWR 里判断“是锁还是 I/O”不要看 SQL 本身要看它背后的等待事件分布。一条 SQL 可能既等锁又等 I/O但比例会告诉你真正的瓶颈在哪。下面给你一套“看 AWR 就能定性”的方法。一、最快定性法看 Top Timed Foreground Events打开 AWR直接看Top 10 Timed Foreground Events 这一节情况结论Top 1~3 全是enq:/latch:/row lock锁问题SQL 在等别人释放Top 1~3 全是db file sequential read/db file scattered read/direct path readI/O 问题SQL 在等磁盘两者都有但enq:占比更高锁为主、I/O 为辅两者都有但 I/O 占比更高I/O 为主、锁为辅百分比看% of DB Time或Wait Class列。二、按等待事件分类一眼认出是锁还是 I/O 锁类等待事件Concurrency 类等待事件含义enq: TX - row lock contention行锁别人没提交或死进程持有enq: TX - allocate ITL slot块级 ITL 槽不够表高并发插同一块enq: TM - contention表级锁DDL 或 FK 无索引enq: INV - quantity treeINV 专用Qty Tree 逻辑锁latch: cache buffers chains热块同一数据块被高并发访问latch: shared pool硬解析风暴特征Wait Class Concurrency单次等待时间可以很长秒级甚至分钟级。 I/O 类等待事件User I/O / System I/O 类等待事件含义db file sequential read单块读索引扫描/通过 rowid 回表db file scattered read多块读全表扫/快速全索引扫direct path read直接路径读大表全扫绕过 buffer cachedirect path read temp临时表空间读排序/Hash Join 溢出log file sync等 LGWR 刷 redocommit 太频繁或 redo 慢log file parallel writeLGWR 写 redo 文件慢存储问题特征Wait Class User I/O或System I/O单次等待短毫秒级但次数多。三、SQL 级别定位从 SQL Statistics 看比例进入SQL Statistics 章节选一个子报告来看 SQL 的等待分布方法 1SQL ordered by Elapsed Time找到慢 SQL点进去看Wait Events 子节AWR 里每个 SQL_ID 展开后有如果 Wait Events 里主要是 enq: TX - row lock contention → 锁 db file sequential read → I/O索引扫描 direct path read → I/O全表扫方法 2SQL ordered by Gets vs ReadsBuffer Gets 高 Reads 低 → 数据在内存CPU/逻辑锁是瓶颈Buffer Gets 高 Reads 高 → 内存装不下物理 I/O 是瓶颈Buffer Gets 低 Reads 高 Elapsed 高 → 单行等锁经典行锁特征方法 3SQL ordered by Concurrency排在这里的 SQL →锁嫌疑最大直接看它的 Wait Events 确认。四、INV 场景实战3 个典型 AWR 画面场景 1INCTCW 过账卡Top Events: enq: TX - row lock contention 65% log file sync 15% db file sequential read 10% SQL ordered by Concurrency: SQL_ID xxxx (UPDATE mtl_transactions_interface SET process_flag...) 结论锁问题。MTI 行被死 Worker 锁住其他 Worker 排队等。场景 2Material Workbench 全组织查询慢Top Events: db file sequential read 55% direct path read 25% CPU time 15% SQL ordered by Gets: SQL_ID yyyy (SELECT ... FROM mtl_material_transactions WHERE ...) Buffer Gets: 5,000,000 Rows: 200 结论I/O 问题。MMT 全表扫 无分区裁剪内存装不下走物理读。场景 3Pick Release 热料发料慢Top Events: enq: INV - quantity tree 40% enq: TX - row lock contention 25% db file sequential read 20% 结论混合型。Qty Tree 逻辑锁为主行锁为辅I/O 是附带消耗。五、一个快速判断口诀等的时间长、次数少 → 锁等的时间短、次数多 → I/OWait Class Concurrency → 锁Wait Class User I/O → I/O六、确认后的下一步动作定性下一步锁查v$lock/v$session找 blocker查 MTI 中LOCK_FLAG2行查 INCTCW 进程是否 defunctI/O查执行计划是否走全表扫查 MMT 统计信息查是否有transaction_date分区裁剪考虑表分区混合先解锁释放死 Worker再看 I/O 是否自然回落 华为MetaERP 在 AWR 里判断“是锁还是 I/O”，不要看 SQL 本身，要看它背后的等待事件分布。一条 SQL 可能既等锁又等 I/O，但比例会告诉你真正的瓶颈在哪。下面给你一套“看 AWR
在 AWR 里判断“是锁还是 I/O”不要看 SQL 本身要看它背后的等待事件分布。一条 SQL 可能既等锁又等 I/O但比例会告诉你真正的瓶颈在哪。下面给你一套“看 AWR 就能定性”的方法。一、最快定性法看 Top Timed Foreground Events打开 AWR直接看Top 10 Timed Foreground Events 这一节情况结论Top 1~3 全是enq:/latch:/row lock锁问题SQL 在等别人释放Top 1~3 全是db file sequential read/db file scattered read/direct path readI/O 问题SQL 在等磁盘两者都有但enq:占比更高锁为主、I/O 为辅两者都有但 I/O 占比更高I/O 为主、锁为辅百分比看% of DB Time或Wait Class列。二、按等待事件分类一眼认出是锁还是 I/O 锁类等待事件Concurrency 类等待事件含义enq: TX - row lock contention行锁别人没提交或死进程持有enq: TX - allocate ITL slot块级 ITL 槽不够表高并发插同一块enq: TM - contention表级锁DDL 或 FK 无索引enq: INV - quantity treeINV 专用Qty Tree 逻辑锁latch: cache buffers chains热块同一数据块被高并发访问latch: shared pool硬解析风暴特征Wait Class Concurrency单次等待时间可以很长秒级甚至分钟级。 I/O 类等待事件User I/O / System I/O 类等待事件含义db file sequential read单块读索引扫描/通过 rowid 回表db file scattered read多块读全表扫/快速全索引扫direct path read直接路径读大表全扫绕过 buffer cachedirect path read temp临时表空间读排序/Hash Join 溢出log file sync等 LGWR 刷 redocommit 太频繁或 redo 慢log file parallel writeLGWR 写 redo 文件慢存储问题特征Wait Class User I/O或System I/O单次等待短毫秒级但次数多。三、SQL 级别定位从 SQL Statistics 看比例进入SQL Statistics 章节选一个子报告来看 SQL 的等待分布方法 1SQL ordered by Elapsed Time找到慢 SQL点进去看Wait Events 子节AWR 里每个 SQL_ID 展开后有如果 Wait Events 里主要是 enq: TX - row lock contention → 锁 db file sequential read → I/O索引扫描 direct path read → I/O全表扫方法 2SQL ordered by Gets vs ReadsBuffer Gets 高 Reads 低 → 数据在内存CPU/逻辑锁是瓶颈Buffer Gets 高 Reads 高 → 内存装不下物理 I/O 是瓶颈Buffer Gets 低 Reads 高 Elapsed 高 → 单行等锁经典行锁特征方法 3SQL ordered by Concurrency排在这里的 SQL →锁嫌疑最大直接看它的 Wait Events 确认。四、INV 场景实战3 个典型 AWR 画面场景 1INCTCW 过账卡Top Events: enq: TX - row lock contention 65% log file sync 15% db file sequential read 10% SQL ordered by Concurrency: SQL_ID xxxx (UPDATE mtl_transactions_interface SET process_flag...) 结论锁问题。MTI 行被死 Worker 锁住其他 Worker 排队等。场景 2Material Workbench 全组织查询慢Top Events: db file sequential read 55% direct path read 25% CPU time 15% SQL ordered by Gets: SQL_ID yyyy (SELECT ... FROM mtl_material_transactions WHERE ...) Buffer Gets: 5,000,000 Rows: 200 结论I/O 问题。MMT 全表扫 无分区裁剪内存装不下走物理读。场景 3Pick Release 热料发料慢Top Events: enq: INV - quantity tree 40% enq: TX - row lock contention 25% db file sequential read 20% 结论混合型。Qty Tree 逻辑锁为主行锁为辅I/O 是附带消耗。五、一个快速判断口诀等的时间长、次数少 → 锁等的时间短、次数多 → I/OWait Class Concurrency → 锁Wait Class User I/O → I/O六、确认后的下一步动作定性下一步锁查v$lock/v$session找 blocker查 MTI 中LOCK_FLAG2行查 INCTCW 进程是否 defunctI/O查执行计划是否走全表扫查 MMT 统计信息查是否有transaction_date分区裁剪考虑表分区混合先解锁释放死 Worker再看 I/O 是否自然回落