EBS的性能调优



  metalink    Tuning performance on eBusiness suite (Doc ID 744143.1)

 

这篇文档描述了如何调查电子商务套件的整体性能下降。特别是，我们强调最普遍的等待时间和如何在AWR/ Statspack 报表中理解它们。在最后，我们提供了在数据库层/应用层性能调优的最佳实践。

1. 确保对eBusiness suite初始化参数的设置是正确的。

 可以用 文档 Note 174605.1中的 bde_chk_cbo.sql脚本来进行检查。然后你可以用下面两个文档中的任何一篇文档来验证结果:

Note 216205.1 Database Initialization Parameters for Oracle Applications 11i

Note 396009.1 Database Initialization Parameters for Oracle Applications Release 12

2.确保Gather Schema Stats定期运行. 这可以被bde_last_analyzed.sql(Note 163208.1)检查, 它按照Schema和索引的验证统计信息.

• 不要过度收集整个Schema或整个数据库的统计数据，如按日或按周收集.
• 不要在系统高峰期间对永久性对象做数据收集.
• 数据收集会将游标无效化。除非您使用 'No Invalidate'选项.
• 收集统计数据需要字典和对象级锁。
• 'GATHER_AUTO选项只有对指定了'修改阈值'（DML与表的行数的数量的比值的百分比）的对象时才使用。
• 如果数据分配没有改变的话计划是不可能改变的.
• 只使用FND_STATS或者 Gather Schema 和Gather Table Statistics 并发程序。
• 不要直接使用分析或者dbms_stats命令。因为这是不支持的并且会导致局部最优计划。
• 为了从SQL*Plus执行FND_STATS相关的存储进程对一个或所有的schemas，或者某个表来收集 CBO stats,请使用如下例子：
  
  # sqlplus apps/<apps_pwd>
  SQL> exec fnd_stats.gather_schema_statistics('MRP'); <- One schema
  SQL> exec fnd_stats.gather_schema_statistics('ALL'); <- All schemas
  SQL> exec fnd_stats.gather_table_stats('MRP','MRP_FORECAST_DATES'); <- One table

3.对与10g数据库的用户，我们推荐启用自动共享内存管理(Automatic shared memory management). 这使得Oracle在SGA范围内控制内存的分配。SGA_TARGET 参数对SGA设定可用的内存的大小。这个参数能够被动态地更改到SGA_MAX_SIZE 参数值的最大值。假定STATISTICS_LEVEL 被设定成 TYPICAL 或者ALL ，并且参数 SGA_TARGET 不被设定成"0"，Oracle会控制内存池，否则会被以下参数所控制：

DB_CACHE_SIZE (默认块大小)
SHARED_POOL_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE


4.如果所有上面的设定都是没问题的，但您还是会有性能慢的问题，那么您必须要检查AWR 或 Statspack报表。

-对于10g数据库用户,  请参考 Note 276103.1  PERFORMANCE TUNING USING 10g ADVISORS AND MANAGEABILITY .
-对于9i 数据库用户, 请参考 Note 94224.1 Title: FAQ- Statspack Complete Reference

如何理解AWR 或 Statspack 报表?

在下面的例子中，我们试图给您一些指引，以帮助您理解AWR或Statspack报告.
当您开始分析时，首先应该查看一下 Top 5 timed  events.
您将会从ARW 或者Statspack 报表看到类似以下内容：

Top 5 Timed Events

Event                              Waits Time(s)     Avg Wait(ms) % Total Call Time  Wait Class
db file sequential read            11,948,893         56,405          535.1      User I/O
db file scattered read             8,992,348          32,431          420.2      User I/O
enq: TX - row lock contention      10,697 31,327      2,929           19.5      Application
CPU time                                              23,634           7.9

在上面的例子中，db file sequential read 是第一个等待事件。db文件顺序读出的可能原因是调整得不好的SQL, 然后您需要到AWR中去进一步的研究 SQL ordered by Reads , 您将会看到如下信息:

Physical Reads Executions Reads per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
9,889,217 1,089 9,081.01 12.42 537.78 1774.66 73gnca4jdqv67 XXPOLCWB SELECT XCD.CHARGE_LINE_ID, XCD...
9,683,142 1,089 8,891.77 12.16 520.62 1761.63 9u72nudw7csmy XXPOLCWB SELECT 1 FROM XXPO_LC_CHARGE...
8,761,131 50 175,222.62 11.00 641.13 10598.91 g0g2sj2by3p75 JDBC Thin Client BEGIN WF_EVENT.LISTEN ( p_ag...

 

检查排在前面的SQL语句。如果其中的SQL语句不属于ORACLE标准应用模块的像上面我们看到的'XXPOLCWB'，那么这就需要由客户的开发团队对其进行调优。
如果其中的SQL语句有属于ORACLE标准应用模块的像 GL, PO , FND 或者 WF，那么应由ORACLE每个对应的产品组进行研究。
当对SQL语句调优后，观察您的性能并且看是否是会让您满意。
当性能是好的时候，我们也会推荐您产生一下ARW 或者Statspack 报表，当您再遇到性能问题是，这会个您一个数字比照基准。
在其他情况您会看到 CPU time 是最高等待事件, 那么您要对SQL ordered by CPU Time 进行进一步的研究。所以您需要按照上面一样的方法来分析。

在下面的表格中，我们收集最常见的等待事件，并给出了一个诊断概览, 它在下面的查看中是有用的.

常见的等待事件

等待事件	描述	范围	检查
db file sequential read	这个会话已经发起了一个I/O请求来从数据文件里读取一个块到缓冲区缓存并且等待到操作完成。这种情况通常发生在索引查找或通过ROWID从表中读取已不在内存中的所需数据块时	I/O SQL 调优	查看AWR/Statspack中按读排序的排在前面的SQL
db file scattered read	这个会话已经发起了一个I/O请求来从一个数据文件里读取一系列的连续块到缓冲区缓存并且等待到操作完成。特别的这会发生在全表扫描或快速全索引扫描过程中。	I/O SQL 调优	查看AWR/Statspack中按获取和读取排序的排在前面的SQL 物理读取的段 检查会话中表空间I/O数据并且确保对那个top表空间的平均读取时间要小于20分钟。
Buffer busy waits	会话要访问一个数据块，要么是: 1.当前不在内存中，但另一个进程已经发起了读取块到内存的I/O请求，或者 2.在内存中但在一个不兼容的模式下（例如，另一个会话已经更新了块但没有提交），所以我们需要从还原段段中重建块 在任何一种情况下，是指至少有两个会话在为同一个块竟争，或者我们所说的有一个‘热块’	缓冲区高速缓存	按缓冲区忙等待查看段统计数据 请参照 Note.163424.1 How To Identify a Hot Block Within The Database Buffer Cache
Library cache	闩锁争用的症状往往是由于一个合法的问题，如非共享的SQL，执行全表或全索引扫描的次优SQL，动态对象的创建/删除等 因此有太多的解析或者没有共享的SQL	共享池/闩锁	查看AWR报表的闩锁数据部分来判断热闩锁。跟踪一些waiter and holder sessions来判断实际的原因和SQL语句。按照Parse Calls排序查看AWR或者Statspack SQL。 使用文档Note 62143.1中'Useful SQL for looking at Shared Pool problems'中的语句来鉴别出有问题的SQL
Enque waits (enq:)	取决于enq 类型: TX Transaction Lock  总体来说是由于应用或者表的设置问题。请参照Note 62354.1 中能引起TX lock waits的案例情况。 TM DML enqueue  总体来说是由于应用问题，特别是如果外键约束没有被索引.以下两篇文章描述了TM locking相关的参照完整性问题 Note 38373.1  Note 33453.1  ST Space management enqueue  通常是由于有太多的空间管理引起的（例如：小的，很多的排序问题..） 更多关于ST enqueue 的信息请查看Note 33567.1	Locks	请看下面的部分: enqueue,  row lock & ITL waits

 

性能调优的最佳实践

数据库层

• 请参照note  244040.1 Recommended Performance Patches for the Oracle E-Business Suite.
• 有几种优化相关的修补程序需要应用在版本10.2.0.(2/3)上.请参照Note <a href="https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=244040.1" a="" <="">
• 将EBusiness Suite转换成OATM表空间模型。请参照Note 404954.1How to run OATM migration utility. 

应用层

• 内部用户部署socket模式：R12: 请参照Note 384241.1. 
• 启用Forms死客户端检测
        数值以分钟来制定: FORMS_TIMEOUT=10
  • 终止死掉的客户端的 fwebmx 进程.
  • 启用Forms异常终止手柄
•  不要设置 FORMS_CATCHTERM

以上两个变量( FORMS_TIMEOUT 和 FORMS_CATCHTERM ) 能从context 文件.XML更改。 
对11i的用户您可以通过s_f60catchterm 和s_f60time两个参数找到。
对R12的用户您可以通过s_forms_catchterm 和s_forms_time两个参数找到。

•  禁止取消查询
  • 取消查询会增加中间层和数据库层的CPU
  • 关于如何启用并且调优取消查询相关的参数，请参照Note 138159.1
  • 禁止取消查询 :  将 预置文件 “FND: Enable Cancel Query” 设置成 ‘No’
•  关于调优JVM/OC4J ，请参照Note 362851.1:Guidelines to setup the JVM in Apps 11i
•  每两个CPUs使用一个JVM
  • 每个CPU不超过一个JVM
  • 每个JVM不超过100个并行用户。

References

NOTE:33453.1 - Locking and Referential Integrity
NOTE:33567.1 - TECH: ORA-1575 Timeout waiting for Space Management Enqueue
NOTE:34566.1 - WAITEVENT: "enqueue" Reference Note
NOTE:38373.1 - TECH: Example TM(Table Locks) During Referential Integrity Enforcement
NOTE:396009.1 - Database Initialization Parameters for Oracle E-Business Suite Release 12
NOTE:404954.1 - How to run OATM migration utility
NOTE:62143.1 - Troubleshooting: Tuning the Shared Pool and Tuning Library Cache Latch Contention
NOTE:228913.1 - Systemwide Tuning using STATSPACK Reports
NOTE:244040.1 - Oracle E-Business Suite Recommended Performance Patches
NOTE:169935.1 - Troubleshooting Oracle Applications Performance Issues
NOTE:174605.1 - bde_chk_cbo.sql - EBS initialization parameters - Healthcheck
NOTE:216205.1 - Database Initialization Parameters for Oracle Applications Release 11i
NOTE:62354.1 - Waits for 'Enq: Tx - Row Lock Contention' - Wait Scenario Examples
NOTE:153507.1 - Oracle Applications and StatsPack
NOTE:384241.1 - Using Forms Socket Mode with Oracle E-Business Suite Release 12
NOTE:362851.1 - JVM: Guidelines to setup the Java Virtual Machine in Apps Ebusiness Suite 11i and R12
NOTE:138159.1 - Canceling Long Running Queries in Oracle Applications 11i
NOTE:276103.1 - Performance Tuning Using Advisors and Manageability Features: AWR, ASH, ADDM and Sql Tuning Advisor
NOTE:94224.1 - FAQ- Statspack Complete Reference
NOTE:163208.1 - bde_last_analyzed.sql - Verifies CBO Statistics
NOTE:163424.1 - How To Identify a Hot Block Within The Database Buffer Cache.
NOTE:1020008.6 - SCRIPT: FULLY DECODED LOCKING
NOTE:1020012.6 - Script to Return Locking Information (Medium Detail)
NOTE:122371.1 - How To Gather Statistics For Oracle Applications Prior to 11.5.10