尧图网站建设 
用 AWR 定位 EBS INV 瓶颈核心思路是先把 AWR 的通用章节映射到 INV 特有逻辑对象INCTCW/MTI/MMT/Qty Tree再反查 SQL 和等待事件是否落在 INV 关键表上。下面给你一套可直接照着翻 AWR 的操作顺序而不是泛泛而谈“看 Top SQL”。0. 前置抓对快照区间最关键一步INV 性能问题分两类快照区间选错全白看过账卡INCTCW 不动 → 选“用户投诉库存没过账”的时间窗通常 15~60 分钟报表/Workbench 慢 → 选用户查 Material Workbench / 跑 INV 报表的时间窗生成?/rdbms/admin/awrrpt.sql选 HTMLRAC 环境别漏选实例跨节点锁争用会掩盖。1. Report Summary先判断“是不是 INV 把 DB 拖垮”看DB TimevsDB CPUDB Time ≫ DB CPU → 时间在等锁/I/OINV 常见是 enqueue 和 db file sequential readDB CPU 占满 → 可能是 Qty Tree / 成本派生 PLSQL 死算批次序列号同时开尤其明显看Instance CPU里 Oracle 占比排除 OS 层面抢资源。2. Top 10 Timed Foreground Events看“等什么”INV 相关典型等待与含义等待事件指向的 INV 逻辑瓶颈enq: TX - row lock contentionMTI/MMTT 中LOCK_FLAG2行被死 Worker 持有或热料发料行锁enq: INV - quantity tree/INV: Quantity Tree TimeoutINV_QUANTITY_TREE_PUB热料串行化高并发 Pick Releasedb file sequential read高MMT / MTL_ONHAND_QUANTITIES 索引单块读放大大表无分区缺日期谓词log file sync高INCTCW 单行 commit 太碎或接口表一次塞几十万行buffer busy waitsMMT 热块同一 itemorg 高并发插入direct path read高MMT 全表扫报表 SQL 走大表直接读如果 Top 5 里出现enq: TXINV qty tree组合基本可锁定“接口过账卡 热料锁”并发。3. SQL Statistics按 INV 表名反查而不是只看 Elapsed Time不要只排SQL ordered by Elapsed TimeINV 场景建议四张表交叉看3.1 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命中即重点看Executions 极少但 Elapsed 极大一次性大事务还是Executions 极高单列平均慢N1 或行级循环3.2 SQL ordered by Gets / by ReadsINV 报表慢往往是Gets 高但 Rows 少 → 索引错了或统计信息过期MMT 最常见MTL_MATERIAL_TRANSACTIONS相关 SQL 若 Buffer Gets 千万级 → 没用transaction_date做分区裁剪3.3 SQL ordered by Concurrency / Cluster高并发发料 SQL 排这里 → 配合 Top Event 的enq: INV锁确认是 Qty Tree 串行3.4 SQL ordered by Parse CallsINCTCW 里拼动态 SQL如弹性域条件导致硬解析风暴 → 看 Module 是否INCTCW实操技巧AWR 里点 SQL_ID 看Module/ActionEBS 会话会带MODULEINCTCW或 Form 名如INVIDITX能直接区分是 Worker 还是前台 Form 慢。4. Segment Statistics看 INV 表/索引谁在烧 I/OSegments by Logical Reads / Physical Reads / Row Lock Waits重点盯MTL_MATERIAL_TRANSACTIONS及其索引N1/N2…MTL_TRANSACTIONS_INTERFACEMTL_ONHAND_QUANTITIESMTL_SERIAL_NUMBERS批次序列号校验时暴增若MTL_MWB_GTMP出现在临时段 Top → Material Workbench 明细查询 N1 典型特征5. 把 AWR 证据链拼回 INV 逻辑对象对照表AWR 现象反推 INV 逻辑对象验证动作MTI 表 SQL 慢 TX row lockINCTCM/INCTCW 死锁或 Worker 掉查fnd_concurrent_requestsINCTCW 状态、MTI 中LOCK_FLAG2, PROCESS_FLAG1堆积INV qty tree等待INV_QUANTITY_TREE_PUB看是否热销料 Pick Release 并发调 profileINV: Quantity Tree TimeoutMMT 全表扫 SQL报表/Workbench 无日期裁剪检查 SQL 是否有transaction_date绑定变量Gather StatsMMTT 单 SQL 长事务移动单 Allocate 后等 TM看 MMTT 行数、是否 transaction_mode3 卡住Serial interface 表高 I/O批次序列号同时过账MSL 接口 15 万行经典坑需分批6. INV 专属“AWR 之外必须交叉看”的点否则会误判AWR 只给 DB 侧证据这三处必须同窗口查并发管理器INCTCW实际活跃进程数 vs targetINCTCM 是否在 pollMTI/MMTT 水位SELECT count(*) FROM mtl_transactions_interface WHERE process_flag1 AND lock_flag2;堆积多少万行Forms 侧Material Workbench 若慢AWR 可能只看到MTL_MWB_GTMP的 INSERT逐行 SELECT需结合 Form 逻辑确认是 DetailedLocator 视图导致7. 一个最小闭环排查顺序生产可用确定时间窗 → 出 AWRHTMLTop Events 判断是否锁/I/O 主导SQL by Elapsed/Gets 搜MTL_前缀拎出 Top 3 SQL_IDSegment Stats 确认是不是 MMT/MTI/ONHAND 烧资源拿 SQL_ID 回查v$active_session_history看 P1/P2/P3 是否落在 INV 表行锁同窗查 INCTCW 并发请求 MTI 堆积数 → 定性“过账卡”还是“查询慢” 华为MetaERP 用 AWR 定位 EBS INV 瓶颈，核心思路是：先把 AWR 的通用章节映射到 INV 特有逻辑对象（INCTCW/MTI/MMT/Qty Tree），再反查 SQL 和等待事
用 AWR 定位 EBS INV 瓶颈核心思路是先把 AWR 的通用章节映射到 INV 特有逻辑对象INCTCW/MTI/MMT/Qty Tree再反查 SQL 和等待事件是否落在 INV 关键表上。下面给你一套可直接照着翻 AWR 的操作顺序而不是泛泛而谈“看 Top SQL”。0. 前置抓对快照区间最关键一步INV 性能问题分两类快照区间选错全白看过账卡INCTCW 不动 → 选“用户投诉库存没过账”的时间窗通常 15~60 分钟报表/Workbench 慢 → 选用户查 Material Workbench / 跑 INV 报表的时间窗生成?/rdbms/admin/awrrpt.sql选 HTMLRAC 环境别漏选实例跨节点锁争用会掩盖。1. Report Summary先判断“是不是 INV 把 DB 拖垮”看DB TimevsDB CPUDB Time ≫ DB CPU → 时间在等锁/I/OINV 常见是 enqueue 和 db file sequential readDB CPU 占满 → 可能是 Qty Tree / 成本派生 PLSQL 死算批次序列号同时开尤其明显看Instance CPU里 Oracle 占比排除 OS 层面抢资源。2. Top 10 Timed Foreground Events看“等什么”INV 相关典型等待与含义等待事件指向的 INV 逻辑瓶颈enq: TX - row lock contentionMTI/MMTT 中LOCK_FLAG2行被死 Worker 持有或热料发料行锁enq: INV - quantity tree/INV: Quantity Tree TimeoutINV_QUANTITY_TREE_PUB热料串行化高并发 Pick Releasedb file sequential read高MMT / MTL_ONHAND_QUANTITIES 索引单块读放大大表无分区缺日期谓词log file sync高INCTCW 单行 commit 太碎或接口表一次塞几十万行buffer busy waitsMMT 热块同一 itemorg 高并发插入direct path read高MMT 全表扫报表 SQL 走大表直接读如果 Top 5 里出现enq: TXINV qty tree组合基本可锁定“接口过账卡 热料锁”并发。3. SQL Statistics按 INV 表名反查而不是只看 Elapsed Time不要只排SQL ordered by Elapsed TimeINV 场景建议四张表交叉看3.1 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命中即重点看Executions 极少但 Elapsed 极大一次性大事务还是Executions 极高单列平均慢N1 或行级循环3.2 SQL ordered by Gets / by ReadsINV 报表慢往往是Gets 高但 Rows 少 → 索引错了或统计信息过期MMT 最常见MTL_MATERIAL_TRANSACTIONS相关 SQL 若 Buffer Gets 千万级 → 没用transaction_date做分区裁剪3.3 SQL ordered by Concurrency / Cluster高并发发料 SQL 排这里 → 配合 Top Event 的enq: INV锁确认是 Qty Tree 串行3.4 SQL ordered by Parse CallsINCTCW 里拼动态 SQL如弹性域条件导致硬解析风暴 → 看 Module 是否INCTCW实操技巧AWR 里点 SQL_ID 看Module/ActionEBS 会话会带MODULEINCTCW或 Form 名如INVIDITX能直接区分是 Worker 还是前台 Form 慢。4. Segment Statistics看 INV 表/索引谁在烧 I/OSegments by Logical Reads / Physical Reads / Row Lock Waits重点盯MTL_MATERIAL_TRANSACTIONS及其索引N1/N2…MTL_TRANSACTIONS_INTERFACEMTL_ONHAND_QUANTITIESMTL_SERIAL_NUMBERS批次序列号校验时暴增若MTL_MWB_GTMP出现在临时段 Top → Material Workbench 明细查询 N1 典型特征5. 把 AWR 证据链拼回 INV 逻辑对象对照表AWR 现象反推 INV 逻辑对象验证动作MTI 表 SQL 慢 TX row lockINCTCM/INCTCW 死锁或 Worker 掉查fnd_concurrent_requestsINCTCW 状态、MTI 中LOCK_FLAG2, PROCESS_FLAG1堆积INV qty tree等待INV_QUANTITY_TREE_PUB看是否热销料 Pick Release 并发调 profileINV: Quantity Tree TimeoutMMT 全表扫 SQL报表/Workbench 无日期裁剪检查 SQL 是否有transaction_date绑定变量Gather StatsMMTT 单 SQL 长事务移动单 Allocate 后等 TM看 MMTT 行数、是否 transaction_mode3 卡住Serial interface 表高 I/O批次序列号同时过账MSL 接口 15 万行经典坑需分批6. INV 专属“AWR 之外必须交叉看”的点否则会误判AWR 只给 DB 侧证据这三处必须同窗口查并发管理器INCTCW实际活跃进程数 vs targetINCTCM 是否在 pollMTI/MMTT 水位SELECT count(*) FROM mtl_transactions_interface WHERE process_flag1 AND lock_flag2;堆积多少万行Forms 侧Material Workbench 若慢AWR 可能只看到MTL_MWB_GTMP的 INSERT逐行 SELECT需结合 Form 逻辑确认是 DetailedLocator 视图导致7. 一个最小闭环排查顺序生产可用确定时间窗 → 出 AWRHTMLTop Events 判断是否锁/I/O 主导SQL by Elapsed/Gets 搜MTL_前缀拎出 Top 3 SQL_IDSegment Stats 确认是不是 MMT/MTI/ONHAND 烧资源拿 SQL_ID 回查v$active_session_history看 P1/P2/P3 是否落在 INV 表行锁同窗查 INCTCW 并发请求 MTI 堆积数 → 定性“过账卡”还是“查询慢”