尧图网站建设 
把 AWR 当成 INV 的“黑盒听诊器”时关键是先按故障形态选快照窗再沿“等待事件 → 模块标识MODULE/ACTION→ SQL 反查 MTL_ 表 → 段热点”这条链走而不是泛读 Top SQL。下面按 EBS INV 实际踩坑路径给你一套闭环分析法。1. 快照窗选择决定 AWR 有没有用过账卡 / INCTCW 不动选用户投诉“库存没过账”的 15~60 分钟窗别选整点 1 小时会把峰值稀释。Workbench 慢 / 报表慢选用户操作时段最好精确到前后各 5 分钟。接口大批量灌入选 MTI 堆积上升区间。RAC 环境必须指定实例跨节点锁争用会在全局视图里被摊平。2. Report Summary先定性“等还是算”DB Time≫DB CPU→ 时间在等待锁 / I/O / log syncINV 典型。DB CPU占满 单行事务慢 → 可能是INV_QUANTITY_TREE_PUB或批次/序列号校验 PL/SQL 死算。Redo size per transaction突变变大 → 接口批处理 commit 策略变了或串行号行暴增。3. Top Timed Foreground Events看 INV 特有等待INV 场景重点盯这几类直接映射逻辑对象等待事件指向的 INV 逻辑瓶颈enq: TX - row lock contentionMTI/MMTT 中LOCK_FLAG2被死 Worker 持有或热料发料行锁enq: INV - quantity tree或超时报错INV_QUANTITY_TREE_PUB热料高并发 Pick Release 串行化db file sequential read高MMT / MTL_ONHAND_QUANTITIES 索引单块读放大大表无分区裁剪log file sync高INCTCW 单行 commit 太碎或接口一次塞几十万行buffer busy waitsMMT 热块同 itemorg 高并发插direct path read高MMT 全表扫报表 SQL若出现enq: TXINV qty tree同屏 → 基本锁定“接口堆积 热料锁”并发恶化。4. SQL Statistics用 INV 表名反查而非只看 Elapsed不要只排SQL ordered by Elapsed Time按四张子表交叉SQL ordered by Elapsed Time搜MTL_MATERIAL_TRANSACTIONS、MTL_TRANSACTIONS_INTERFACE、MTL_MATERIAL_TRANSACTIONS_TEMP、MTL_ONHAND_QUANTITIES、MTL_SERIAL_NUMBERS_INTERFACE、MTL_ITEM_LOCATIONS、MTL_MWB_GTMP。命中即重点。SQL ordered by GetsINV 报表慢常是Gets 千万级但 Rows 极少 → MMT 统计信息过期或缺transaction_date分区谓词。SQL ordered by Concurrency高并发发料 SQL 排这里 上面enq: INV→ Qty Tree 串行确认。SQL ordered by Parse CallsINCTCW 里拼动态 SQL弹性域条件硬解析风暴MODULEINCTCW。点开 SQL_ID 看Module/ActionINCTCW/INCTCM→ 后台 Worker 消费慢INVIDITX等 Form 名 → 前台事务或 Workbench 慢BI/OTBI 会话 → 报表 SQL5. Segment Statistics确认烧 I/O 的是哪张 INV 表看Segments by Logical Reads / Physical Reads / Row Lock WaitsMTL_MATERIAL_TRANSACTIONS及其索引N1/N2/U1常驻 Top → 流水表全扫或统计信息旧MTL_TRANSACTIONS_INTERFACEMTL_SERIAL_NUMBERS_INTERFACE→ 接口堆积消费不掉MTL_ONHAND_QUANTITIES→ 现有量查询维度爆炸批/货位/状态全开MTL_MWB_GTMP出现在临时段 Top → Material Workbench DetailedLocator 的 N1 特征6. 把 AWR 证据拼回 INV 逻辑对象闭环AWR 现象反推 INV 逻辑层同窗交叉验证必须做MTI SQL 慢 TX row lockINCTCM/INCTCW 死锁或 Worker 掉fnd_concurrent_requests看 INCTCW 实际活跃数SELECT count(*) FROM mtl_transactions_interface WHERE process_flag1 AND lock_flag2堆积数INV qty tree 等待Qty Tree 锁超时是否热销料 Pick Release 并发profileINV: Quantity Tree TimeoutMMT 全表扫 SQL报表无日期裁剪SQL 文本有无transaction_date绑定MMT 统计信息最后收集时间MMTT 长事务移动单 Allocate 后等 TMMMTT 行数、transaction_mode3 卡住行Serial interface 高 I/O批序列号同时过账MSL 接口行数15 万行经典坑7. INV 专属补充AWR 之外必须同屏看的 3 件事AWR 只给 DB 侧漏看会误判并发管理器INCTCW target vs actualINCTCM 是否在 poll接口水位MTI/MMTT 中process_flag1, lock_flag2, transaction_mode3堆积多少万行Form 侧Material Workbench 慢时AWR 可能只显示MTL_MWB_GTMP的 INSERT逐行 SELECT需结合 Form 逻辑确认 DetailedLocator 视图导致 N18. 最小闭环顺序生产直接用定时间窗出 HTML AWRRAC 指定实例Top Events 判锁/I/O 主导SQL by Elapsed/Gets 搜MTL_前缀拎 Top 3 SQL_ID看 ModuleSegment Stats 确认 MMT/MTI/ONHAND/SERIAL 谁烧资源拿 SQL_ID 回v$active_session_history看 P1/P2/P3 是否落在 INV 表行锁同窗查 INCTCW 并发请求 MTI 堆积 → 定性“过账卡”还是“查询慢” 华为MetaERP 把 AWR 当成 INV 的“黑盒听诊器”时，关键是先按故障形态选快照窗，再沿“等待事件 → 模块标识（MODULE/ACTION）→ SQL 反查 MTL_ 表 → 段热点”这条
把 AWR 当成 INV 的“黑盒听诊器”时关键是先按故障形态选快照窗再沿“等待事件 → 模块标识MODULE/ACTION→ SQL 反查 MTL_ 表 → 段热点”这条链走而不是泛读 Top SQL。下面按 EBS INV 实际踩坑路径给你一套闭环分析法。1. 快照窗选择决定 AWR 有没有用过账卡 / INCTCW 不动选用户投诉“库存没过账”的 15~60 分钟窗别选整点 1 小时会把峰值稀释。Workbench 慢 / 报表慢选用户操作时段最好精确到前后各 5 分钟。接口大批量灌入选 MTI 堆积上升区间。RAC 环境必须指定实例跨节点锁争用会在全局视图里被摊平。2. Report Summary先定性“等还是算”DB Time≫DB CPU→ 时间在等待锁 / I/O / log syncINV 典型。DB CPU占满 单行事务慢 → 可能是INV_QUANTITY_TREE_PUB或批次/序列号校验 PL/SQL 死算。Redo size per transaction突变变大 → 接口批处理 commit 策略变了或串行号行暴增。3. Top Timed Foreground Events看 INV 特有等待INV 场景重点盯这几类直接映射逻辑对象等待事件指向的 INV 逻辑瓶颈enq: TX - row lock contentionMTI/MMTT 中LOCK_FLAG2被死 Worker 持有或热料发料行锁enq: INV - quantity tree或超时报错INV_QUANTITY_TREE_PUB热料高并发 Pick Release 串行化db file sequential read高MMT / MTL_ONHAND_QUANTITIES 索引单块读放大大表无分区裁剪log file sync高INCTCW 单行 commit 太碎或接口一次塞几十万行buffer busy waitsMMT 热块同 itemorg 高并发插direct path read高MMT 全表扫报表 SQL若出现enq: TXINV qty tree同屏 → 基本锁定“接口堆积 热料锁”并发恶化。4. SQL Statistics用 INV 表名反查而非只看 Elapsed不要只排SQL ordered by Elapsed Time按四张子表交叉SQL ordered by Elapsed Time搜MTL_MATERIAL_TRANSACTIONS、MTL_TRANSACTIONS_INTERFACE、MTL_MATERIAL_TRANSACTIONS_TEMP、MTL_ONHAND_QUANTITIES、MTL_SERIAL_NUMBERS_INTERFACE、MTL_ITEM_LOCATIONS、MTL_MWB_GTMP。命中即重点。SQL ordered by GetsINV 报表慢常是Gets 千万级但 Rows 极少 → MMT 统计信息过期或缺transaction_date分区谓词。SQL ordered by Concurrency高并发发料 SQL 排这里 上面enq: INV→ Qty Tree 串行确认。SQL ordered by Parse CallsINCTCW 里拼动态 SQL弹性域条件硬解析风暴MODULEINCTCW。点开 SQL_ID 看Module/ActionINCTCW/INCTCM→ 后台 Worker 消费慢INVIDITX等 Form 名 → 前台事务或 Workbench 慢BI/OTBI 会话 → 报表 SQL5. Segment Statistics确认烧 I/O 的是哪张 INV 表看Segments by Logical Reads / Physical Reads / Row Lock WaitsMTL_MATERIAL_TRANSACTIONS及其索引N1/N2/U1常驻 Top → 流水表全扫或统计信息旧MTL_TRANSACTIONS_INTERFACEMTL_SERIAL_NUMBERS_INTERFACE→ 接口堆积消费不掉MTL_ONHAND_QUANTITIES→ 现有量查询维度爆炸批/货位/状态全开MTL_MWB_GTMP出现在临时段 Top → Material Workbench DetailedLocator 的 N1 特征6. 把 AWR 证据拼回 INV 逻辑对象闭环AWR 现象反推 INV 逻辑层同窗交叉验证必须做MTI SQL 慢 TX row lockINCTCM/INCTCW 死锁或 Worker 掉fnd_concurrent_requests看 INCTCW 实际活跃数SELECT count(*) FROM mtl_transactions_interface WHERE process_flag1 AND lock_flag2堆积数INV qty tree 等待Qty Tree 锁超时是否热销料 Pick Release 并发profileINV: Quantity Tree TimeoutMMT 全表扫 SQL报表无日期裁剪SQL 文本有无transaction_date绑定MMT 统计信息最后收集时间MMTT 长事务移动单 Allocate 后等 TMMMTT 行数、transaction_mode3 卡住行Serial interface 高 I/O批序列号同时过账MSL 接口行数15 万行经典坑7. INV 专属补充AWR 之外必须同屏看的 3 件事AWR 只给 DB 侧漏看会误判并发管理器INCTCW target vs actualINCTCM 是否在 poll接口水位MTI/MMTT 中process_flag1, lock_flag2, transaction_mode3堆积多少万行Form 侧Material Workbench 慢时AWR 可能只显示MTL_MWB_GTMP的 INSERT逐行 SELECT需结合 Form 逻辑确认 DetailedLocator 视图导致 N18. 最小闭环顺序生产直接用定时间窗出 HTML AWRRAC 指定实例Top Events 判锁/I/O 主导SQL by Elapsed/Gets 搜MTL_前缀拎 Top 3 SQL_ID看 ModuleSegment Stats 确认 MMT/MTI/ONHAND/SERIAL 谁烧资源拿 SQL_ID 回v$active_session_history看 P1/P2/P3 是否落在 INV 表行锁同窗查 INCTCW 并发请求 MTI 堆积 → 定性“过账卡”还是“查询慢”