Oracle应用产品性能调整实例分析.ppt

应用产品性能调整实例分析 张春辉资深技术工程师 内容 应用产品性能调整概要介绍性能调整常用方法应用产品性能调整实例分析 应用产品性能调整概要介绍 问题的定义分清三种类型的应用问题四个领域 AREAS 的调整定期调整性能调整阶段 问题的定义 精确地定义是解决问题的关键 WHAT 问题的特性是什么 其相关的组件是什么 WHERE 问题在什么地方发生 WHEN 问题在什么时候发生 EXTENT 问题影响的用户或地点是什么 多少功能受影响 问题是否孤立 PRIORITY 问题的相关重要性有多高 性能目标设立基于用户需求的性能目标基于实际环境所能达到的性能性能问题的相关性不同模块 组件之间存在相互影响的关系 找到产生问题的主要原因 分清三种类型的应用问题 在线事务处理后台批量数据处理应用报表 四个领域 AREAS 的调整 调整数据库调整服务器调整SQL 执行计划 调整 监控网络 调整数据库 收集应用数据库运行的统计数据 utlB Estat V patameter 调整数据库初始化参数分析数据库对象 AnalyzeTheDatabase 利用PackagePinning策略提高缓存命中率 HitRatio 减少资源竞争 ResourceContention 数据块的大小 DBBlockSize 调整服务器 磁盘I O内存Paging和SwappingCPU进程 调整SQL 执行计划 发现耗时 资源的SQL ExpensiveSQL 跟踪 Tracing CBO统计 索引 视图 嵌套 表连接High WaterMark 监控网络 网络流量监控工具pingARPnetstat等客户端PC 定期调整 用户数增加数据量增加上线模块增加第三方软件的加入客户化报表 程序增加使用时间 性能调整阶段 Why 找到性能问题瓶颈 检查问题真正的原因 How 分析原因 找到解决问题的办法 内容 应用产品性能调整概要介绍性能调整常用方法应用产品性能调整实例分析 性能调整常用方法 用OS工具来发现问题 找到最费时的OS进程 并关联到相应的ORACLESessionVmstatIostatPsTop nmon topas sar检查是否有 死 defunct 进程和运行时间异常长并消耗大量系统资源的进程通过运行Utlbstat utlestat报告来调整数据库用OEM工具找出性能瓶颈确定费时的SQL语句 具体有下列几种办法 性能调整常用方法 Cont trace 生成SQL的执行计划 altersystemsettimed statistics true initSID ora sql trace true dbms system set sql trace in session ProfileOption AR EnableSQLtrace INV DebugTrace MRP TraceMode OE DebugTrace PO EnableSqlTrace 定义并发程序 Checktraceon OEMtopsession FND TOP adminSQLscriptsV sqlarea V sqltext 性能调整常用方法 Cont selectsid serial fromv sessionwherepaddr selectaddrfromv processwherespid 性能调整常用方法 Cont 定期进行CBO统计 具体有下列几种办法 Analyzetable indexcomputestatistics execfnd stats gather schema statistics Appl shortname 运行并发 GatherSchema Table Columnstatistics 运行并发 AnalyzeAllIndexColumnStatistics 定期 Purge 过时的工作流数据和并发请求 性能调整常用方法 Cont 及时安装上ORACLE建议的 特别是强制性PATCHMetalink是一个非常有用的工具 遇到性能问题建议先在Metalink上查一查 大部分的问题应该都有了解决方案调整SQL语句 视图等LogiTAR来获得技术支持及时联系硬件供应商以获得帮助性能问题的差异性现象一样 可能形成的原因不一样 解决的方法也不一样用户的实际情况不一样 同一原因 其影响程度也不一样 内容 应用产品性能调整概要介绍性能调整常用方法应用产品性能调整实例分析 应用产品性能调整实例分析 系统反应慢接收事务处理等非常慢ONT升级 R11i SQL问题应用系统整体反应慢订单录入 预定性能问题PlanningManager运行不完 系统反应慢 问题现象 应用系统反应非常慢 就连登录到应用系统就需5分钟 打开一FORM需3分钟问题检查 用vmstat查 有15个 Running 的OS进CPUidle一直为0用nmon topas查 发现有14个运行的RGRARG进程 大部分运行了十几小时 有些运行了几天 它们占了约95 的CPU资源对这些TOPProcess找不到相应的OracleSession 系统反应慢 cont 原因分析 取消FSG报表 OS进程还在运行并消耗资源用户较长时间未运行 GatherSchemaStatistics 引起FSG报表性能差解决办法 Kill这些OS进程再对GLSchema运行 GatherSchemaStatistics 和运行 GL优化程序 系统反应慢 cont 结果 FSG报表运行正常系统释放了被占用的95 的CPU资源 当然系统反应也恢复了正常问题分析 定期作CBO统计非正常的OS进程会消耗很大的系统资源 接收事务处理等非常慢 问题现象 接收事务处理选择子库存一小时无反应 以前一直都很好 选择时间约一秒 应收接口程并发程序非常慢采购汇总报表运行不完问题检查 Vmstat 2CPU空闲一致为0并伴有较大的PageoutRuningQueue平均为20对此PO接收操作生成SQL执行计划 发现对MTL SYSTEM ITEMS和MTL SECONDARY INVENTORIES进行全表扫描 其中MSI表中有80万条记录 接收事务处理等非常慢 Cont 修改了索引 MTL SYSTEM ITEMS U1 organization id inventory item id 检查索引发现对MSI表新建了索引 MTL SYSTEM ITEMS N8 organization id item type segment1 MTL SYSTEM ITEMS N9 organization id 采取的办法 altertableinv mtl material itemsdropprimarykey dropindexinv mtl system items u1 dropindexinv mtl system items n8 接收事务处理等非常慢 Cont dropindexinv mtl system items n9 Createindexinv mtl system items u1 inventory item id organiziotn id 结果 系统恢复正常问题分析 不能修改标准索引对标准基表添加索引要特别小心建议只对客户化表建索引 并加上CUX 前缀和有自己独立的表空间 Tablespace ONT升级SQL问题 问题现象 R11i升级过程中ontup204 sql运行了一天无法完成问题检查 通过生成此SQL的执行计划发现 对MTL DEMAND进行全表扫描 Fulltablescan 此表有1509351条记录检查MTL DEMAND表上有相应的索引原因分析 R11i采用CBO Optimizer choose采取临时办法 修改ontup204 sql 加Hintaltersessionsetoptimizer goal rule ONT升级SQL问题 Cont 其他类似SQL ont00031 sqlontupg43 sql问题分析 R11i采用CBO基于成本的优化方法 以前都是基于规则的优化方法 RuleBase 如不作CBO统计可能会引起执行计划的不合理 可能比RuleBase的还差建议定期作CBO统计 应用系统整体反应慢 问题现象 应用系统整体性能差 特别是月结期间打开Forms 运行报表 并发程序运行都慢问题检查 Sar vmstat结果CPU空闲很少OEM生成TOP50并发请求报告基于内存的快照 运行1444分钟 在制品收发存日报表 客户化 平均运行40分钟 钞票生产报表 客户化 平均运行30分钟 工序外废统计报表 客户化 平均运行27分 应用系统整体反应慢 Cont 用户还反映 查询事务处理汇总 很慢用OEMTOPsession检查 并发管理 程序本身消耗了较高的系统资源生成utlbstat utlestat报告 dbfilescatteredread 等待通过对表进行Fulltablescan发生的I O bufferbusywait 由于undoblockandheadercontention引起的等 AverageWriteQueueLength 为13 9 此统计值过大对TEMP表空间有较大的读写操作 特别是写操作 比一般的表空间要大100多倍 应用系统整体反应慢 Cont 对上述各问题生成SQL执行计划解决方案 调整数据库init参数 增加db file multiblock read count为原来的2倍 尽量减少由于客户化程序而引起的Fulltablesacn 增加回滚段的个数 现在为8个 建议增加到12个并优化每个Segment的存储参数增加db block buffer值 现150M 建议增加到600M增加sort area size值 现为256000 建议增加到1 6M 为减少在TEMP表空间过多的读写 也要观察是那些客户化应用引起的 尽量对这些程序进行调优 应用系统整体反应慢 Cont 标准应用查询事务处理汇总 删除表 MTL SUMMARY TEMP中的记录 此表有3268051 此查询程序有对它进行Fulltablescan并发管理程序 通过OEMTOPSession监控 发现系统并发管理调度程序消耗很大的CPU资源 进一步检查发现它对fnd conc pp actions表进行FullTableScan 检查表 fnd conc pp actions有62255条记录 并且此SQL运行非常频繁 Patch 1585448消除FullTableScan并解决此问题 应用系统整体反应慢 Cont 标准应用 基于内存的快照 当运行MRP的计划参数设定为 NetWIP MRP的 基于内存的快照 将永远也运行不完 并耗用大量的系统资源 通过对此情况进行模拟 发现0837相关组件的任务令存在循环 解决办法是关闭0837相关的任务令再重新运行MRP 计划3分钟正常完成 应用系统整体反应慢 Cont 客户化应用 在制品收发存日报表 客户化 通过调整数据库初始化参数 使此报表性能提高了3 5倍 现为12分钟 在此基础上调整视图 cux wip xa tmp的定义 改变 Where 条件的顺序 以减少 RangScan 的范围 这样 使此报表的运行时间缩短到2 5分钟 并且大大减少了系统IO钞票生产报表 客户化 平均运行30分钟 分析此报表的TOPSQL 对表QA RESULTS读取9256680条记录 应用程序是通过对QA RESULTS V进行读取的 检查发现有相应的Patch 1828261对此视图进行优化 安装此Patch后此TOPSQL的执行只选取91967条记录 报表运行时间缩短到10分钟 应用系统整体反应慢 Cont 工序外废统计报表 客户化 此报表的TOPSQL 对表MTL SYSTEM ITEMS WIP MOVE TRANSACTIONS进行了大量的 RangeScan 经测试发现此SQL单独运行非常快 仅需3秒 检查此SQL是一报表公式 它处于内循环 对同一求和结果运行了多次 修改此报表 使运行时间由原来27分钟缩短到2分钟 应用系统整体反应慢 Cont 结果 系统的整体性能提高了4到5倍 AverageWriteQueueLength 统计值由13 9降低到0 dbfilesequentialread 统计值由267991 298562 1 1降低到2911 3895 1 34 dbfilescatteredread 值由3763 15123 4 02降低到4 9 2 25 bufferbusywait 统计值由104695 94150 9降低到0 TEMP表空间的读写正常标准应用的性能问题解决 客户化应用有了十倍不等的提高 应用系统整体反应慢 Cont 问题分析 应用环境变化后数据库系统需要依据现有情况进行调整用户数模块数数据量客户化管理 临时数据对客户化报表应尽量优化 并先在测试环境下进行性能测试数据问题也会引起性能问题 MRP问题 第三方软件的加入 订单录入 预定性能差 问题现象 输入销售订单 Nextfield line 很慢 需要10 秒 1 分钟 预定订单非常慢 在一个用户使用的情况下都需要5 分钟 订单录入 预定性能差 Cont 问题检查 Vmstat 13 15runqueue CPUstuck0idle 通过OEM发现一TOPSession引起了大量的 logicalread INSERTINTOQP PREQ LINE ATTRS TMP 通过nmon发现相应的TOPProcess占用了90 的CPU通过Metalink发现相应Patch 1318663 订单录入 预定性能差 Cont 进一步检查 Selectcount fromwf itemswhereend dateisnotnull selectcount fromWF ITEMS ACTIVITY STATUSESwhereend dateisnotnull Selectcount fromfnd concurrent requests 解决方案 安装Patch 1318663清除过时的工作流数据运行 GatherSchemaStatistics forthe ALL Schema清除过多的并发请求数据 订单录入 预定性能差 Cont 结果 Vmstat 1 2runqueue average50 idlelast2hrs OEMTOPsession正常输入销售订单 Nextfield line 只需要 秒 2 3秒 预定订单 只需要3 10秒 订单录入 预定性能差 Cont 问题分析 当遇到问题时 建议多上Metali