在 Fusion Applications Control本质是 OEM Fusion Middleware Control 套壳里做性能瓶颈定位日志分析工具不是孤立用的而是和Metrics / Problem Analysis / ECID 串联 / ADF Request 分析 / SOA Flow Trace / JVM Diagnostics 组合发力。下面按“从慢点发现 → 锚定 ECID → 日志与轨迹拆层 → 判瓶颈类型”的顺序给操作动线专门适配 PO LE 这类 ADFSOA 混合场景。1. 先找“慢在哪里”Metrics Problem Analysis不先翻日志不要一上来就开 FINEST 搜日志先用量化面板缩范围导航树Product Family → Procurement → Fusion Cluster App如 PrcPoServer_1→ Performance Summary看Request Processing Time (ms)、Requests/min、JVM Heap、Thread Pool、DB Connection Usage在任意请求类指标图上点Additional Information → Problem Analysis会把关联指标CPU、GC、ESS 负载、SOA 吞吐拉成依赖图一眼看是 App 层慢还是 DB 层慢同菜单点Analyze Logs自动按该指标时间窗 目标范围打开 Log Messages 查询比全量搜快 10 倍PO 场景典型信号Request Processing Time 尖峰 SOA Min/Max Response Time 同步尖峰 → 瓶颈在PrcPoApprovalComposite而不是 PO EO 本身。2. 锚定一次慢请求ECID / RID 是主键性能分析的核心是把一次用户操作或一条 SOA 实例的完整耗时链路拎出来在线页面慢浏览器 Network 或页面“关于本页”拿ECID格式0000Hl9TwKUCslT6uBi8UH18lkWX000002RID 形如0:3:7表示线程代际SOA 慢Instances 里点 Instance ID → Flow Trace 页右上角抄 ECIDESS 导入 PO 慢Scheduled Processes 里 Request ID → View Log 头里带作业 ECID拿到 ECID 后Logs → View Log Messages → Add Field 勾 ECID → 粘贴 → 时间窗 ±10min → Search → 选中一条 → View Related Messages → by ECID。这样把 OHS→WebLogic→ADF BC→SOA→ADF Service 的全部日志按时间排成一条线首错/首慢组件即“first-fault component”。3. ADF 层瓶颈用 Diagnostic Log Analyzer 看 Phase 耗时条PO 页面打开慢 / 保存转圈走 ADF Web Request 分析日志级别临时开oracle.adf→TRACE:1 (FINE) 或 FINER默认 INFO排错完调回否则性能雪崩用Oracle Diagnostic Log AnalyzerFusion 的 ADF 请求分析视图或 JDeveloper 离线分析 diagnostic.log按By ADF Request 搜用户页面如/faces/po/order/CreatePurchaseOrder)完成后每条请求有duration bar graph根节点总耗时子节点JSF 各阶段Restore View / Render Response ADF 事件Execute iterator binding / Execute query黑色条已埋点 ADF 代码耗时灰色条未埋点原生 JSF/业务 Java长黑条直接指出是哪个 VO 查询或 EO 校验慢展开 Render Response → 看Execute query节点下方明细会给出View Object 名 实际 SQLPO 场景常命中PurchaseOrderHeaderPVO/POLinePVO的 SQL 没走索引或 EO fault-in 触发整行重查4. SOA/BPEL 层瓶颈Flow Trace Audit Trail 看时间缝PO 批准事件、PO→OIC 推送慢在 SOA 侧定界SOA → soa-infra → Instances → 点 Instance ID → Flow Trace每个组件BPEL / Mediator / Human Task有起止时间组件间大段空白 等待下游服务ADF Service / 审批服务 / OIC点 BPEL 组件 →Audit Trail 展开每个 activity 的 completion time找最大时间缝若是Invoke卡住拿 ECID 去 Request Monitor / JVM Diagnostics 看该线程在等什么DB 锁 / 远程 HTTP / JMS 队列Delay AnalysisEM Cloud Control 里 BPEL 功能视图红色条最慢 activity 组直接告诉你是ApprovalService.call()慢还是POEventPublish慢5. 线程/SQL/锁JVM Diagnostics ASH 下沉到代码和库日志只能告诉你“哪层慢”根因要下沉Flow Trace 里发现某 ADF Service 调用慢 → 该 ECID 点JVM DiagnosticsThread state transitionsBLOCKED 等锁Top methods热点方法如某个 Groovy 规则 O(n²) 遍历 PO LinesTop SQLADF BC 生成的SELECT ... FROM PO_HEADERS_F是否全表扫ESS 作业慢作业详情页眼镜图标拿DB Session ID → DB 侧跑ASH ReportAverage Active Sessions → Run ASH Report 按时间窗看 top SQL / top wait eventlatch free、enq: PO 行锁、log file sync若慢到出 STUCK thread → 自动生成 IncidentIncident 目录里有JRockit Flight Recorder (JFR) 录屏看 GC 暂停、锁竞争、native 调用耗时6. 日志级别与开关性能分析期的正确姿势日常INFO800/NOTIFICATION绝不长期 FINEST否则日志 I/O 本身成瓶颈排错临时调oracle.apps.po→ FINERoracle.adf→ FINEoracle.soa.services.workflow.task→ FINE/TRACE:32SOA Audit Level 临时调 Minimal/ProductionDev 级 audit 写 audit_trail 表拖慢 BPEL复现完立刻调回 INFO并清 Passivation/PS_TXN 快照如果怀疑 AM 池膨胀7. PO LE 同步慢的速查判定日志里看到什么 → 瓶颈在哪日志/轨迹特征瓶颈层动作ADF Request 条中Execute query PO_HEADER_PVO黑条 8sVO SQL / 缺索引 / EO fault-in拿 SQL 去 ASH 看 planECID 链路中 ADF BC 日志到doDML后长时间无 SOA 事件日志commit 后 EDN 事件未抛 / 事务大查 PO EO 里 composition 级联改太多子行SOA Flow Trace BPELApprovalServiceinvoke 空等 30sBPM 审批人未认领 / 规则 XPath 空结果看 Human Workflow 审计BPEL invoke 到PrcPoEventOutbound后卡 AQJMS/AQ 积压看 SOA Recovery DBdlv_messageJVM Diagnostics 线程 BLOCKED 在EntityCache.get同 AM 并发改同一 PO Header EO乐观锁重试 / 串行化提交ASH 报enq: TX - row lock contention等 PO_HEADER_ID别的事务占行锁反查持有者 ECID8. 标准动线一句话串起来Performance Summary 看指标尖峰 → 点 Analyze Logs/Problem Analysis 缩时间窗 → 拿 ECID页面/SOA Instance/ESS Request→ Log Messages by ECID 排首慢组件 → ADF 层用 Diagnostic Log Analyzer 看 Phase 条SOA 层用 Flow TraceAudit Trail 看时间缝 → JVM Diagnostics 看线程/SQLESS 类配 ASH → 定位到 VO SQL / Groovy / BPEL invoke / 行锁。关键认知Fusion Apps Control 的“日志分析”本身不画火焰图它靠ECID 把各层日志缝成一条时间线 ADF/SOA 自带轨迹视图把时间缝可视化瓶颈是“比”出来的组件间耗时差不是单条 ERROR 报出来的。