Professional Documents
Culture Documents
https://support.oracle.com/CSP/main/ar
Tuning performance on eBusiness suite [ID 744143.1] Modified 13-MAY-2009 In this Document Purpose Last Review Date Instructions for the Reader Troubleshooting Details How to interpret AWR or Statspack report ? Commonly Observed Wait Events Best practices for tuning performance References Type TROUBLESHOOTING Status PUBLISHED
Applies to:
Oracle Application Object Library - Version: 11.5.10.2 to 12.0.4 Information in this document applies to any platform.
Purpose
This note describes how to investigate overall slow performace on eBusiness suite. In particular , we highlight the the most common wait events and how to interpret them in AWR/Statspack report. at the end we provide best practices on tuning performance on Database / Applications tier.
Troubleshooting Details
1.Ensure the initialization parameters for eBusiness suite are set correctly. It can be checked by using Note 174605.1 bde_chk_cbo.sq l .Then you verify the result with one of the following two notes : Note 216205.1 Database Initialization Parameters for Oracle Applications 11i Note 396009.1 Database Initialization Parameters for Oracle Applications Release 12 2.Make sure Gather Shema Stats is running on periodical basis. It can be checked with bde_last_analyzed.sql (Note:163208.1) which verifies stats by schema and index. Do not gather statistics excessively on entire schemas or the entire database such as nightly or weekly.
support.oracle.com/CSP/main/article?c 1/6
9/29/2010
https://support.oracle.com/CSP/main/ar
Do not gather statistics on permanent objects during peak intervals. Gathering statistics invalidates cursors .Unless you use the No Invalidate option. Gathering statistics requires dictionary and object level locks. The option 'GATHER_AUTO' can be used, to gather statistics only on objects that have changes above the specified 'Modification Threshold' (percentage of DML compared to the number of rows of the table). Plans are not likely to change if the data distribution has not changed. Use only FND_STATS or the Gather Schema and Gather Table Statistics Concurrent Programs. Do NOT USE the analyze or dbms_stats command directly. It is not supported, and results in sub-optimal plans. To execute the corresponding FND_STATS procedures from SQL*Plus to gather CBO stats for one or all schemas, or for a particular table, use the following examples: # 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.For 10g Database users, we recommend to enable ASMM(Automatic shared memory management). This puts Oracle in control of allocating memory within the SGA. The SGA_TARGET parameter sets the amount of memory available to the SGA. This parameter can be altered dynamically up to a maximum of the SGA_MAX_SIZE parameter value. Provided the STATISTICS_LEVEL is set to TYPICAL or ALL and the SGA_TARGET is set to a value other than "0" Oracle will control the memory pools which would otherwise be controlled by the following parameters: DB_CACHE_SIZE (default block size) SHARED_POOL_SIZE LARGE_POOL_SIZE JAVA_POOL_SIZE
4.If all the above settings are fine, and still you face slow performance, then either AWR or Statspack report is must checking. -For10g Database users, refer to Note 276103.1 PERFORMANCE TUNING USING 10g ADVISORS AND MANAGEABILITY . -For 9i Database users, refer to Note 94224.1 Title: FAQ- Statspack Complete Reference
In the above case db file sequential read is the first wait event .The possible cause of db file sequential read is poorly tuned SQL, then you need to go deeper in AWR and investigate SQL ordered by Reads , you will see something like the following :
support.oracle.com/CSP/main/article?c
2/6
9/29/2010
https://support.oracle.com/CSP/main/ar
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...
Check the top SQL statements. If one of SQL statements doesn't belong to standard oracle apps modules like what we see above 'XXPOLCWB', then this needs to be tuned by customer's development team. If you find one SQL statement belong to one of oracle modules like GL, PO , FND or WF then this needs to be investigated by team owns the product. After you tune SQL statement, monitor your performance and see if this is satisfied to you. We would recommend to have AWR or Statspack report generated when performance is good ,this will give you like a baseline in which you can compare the numbers when you get any performance issue again. In other cases you may see CPU time is the top wait event ,then go deeper and investigate SQL ordered by CPU Time so you need to treat it same way as the above example. In the table below, we collect the most commonly observed wait events and gives an of the overview diagnostics that could be useful to review next.
I/O SQL tuning The ses sion has issued an I/O reques t to read one block from a data file into buffer cache and is waiting for the operation to complete. This typically happens during an index lookup or fetch from a table by ROWID when the required data block is not already in memory. The ses sion has issued an I/O reques t to read a series of contiguous clocks from a data file Into the other buffer cache and is waiting for the operation to complete. This typically happens during full table scan or fast full index scan. I/O SQL tuning
Review AWR/Stats pack Top SQL ordered by gets and by reads . Segments by Physical Reads. Check that s ess ion for the tablespace I/O s tats and make s ure that avg reading is <20m for the top tablespace Buffer cache/DBWR
support.oracle.com/CSP/main/article?c
3/6
9/29/2010
https://support.oracle.com/CSP/main/ar a data block that is either: 1.Currently not in memory, but another process has already iss ued an I/O reques t to read the block into memory, or 2.in memory but in an incompatible mode( (for example another s ess ion have updated the block but not commit ed), so we need to rebuild the block from the undo segments
In any case, means that at leas t 2 sessions are competing for the s ame blocks , or what we call .. there is a 'hot block'
buffer busy waits Refer to Note.163424.1 How To Identify a Hot Block Within The Databas e Buffer Cache
Library cache latch contention is often a symptom due to a legitimate problem such as non-sharable SQL, suboptimal SQL which performs full table or full index scans, dynamic object creation/removal, etc So its too much parsing or not s haring s ql
shared pool/latches Review the latch Statistics section of the AWR report to determine the hot latches Trace s ome waiter and holder ses sions to determine actual caus e & SQL statements Review AWR/Stats pack SQL ordered by Parse Calls Use the s tatements in Note 62143.1:Understanding and Tuning the Shared Pool under 'Us eful SQL for looking at Shared Pool problems ' to identify the problematic s ql
Enque waits (enq:) Depends on enq type: TX Transaction Lock Generally due to application or table s etup issues See Note 62354.1 for example s cenarios which can cause TX lock waits. TM DML enqueue Generally due to application issues, particularly if foreign key constraints have not been indexed. The following two articles describe referential integrity iss ues
Locks
Review the following sections : enqueue, row lock & ITL waits
support.oracle.com/CSP/main/article?c
4/6
9/29/2010
https://support.oracle.com/CSP/main/ar
related to TM locking: Example TM locks During Referential Integrity Enforcement Note 38373.1 TM locks and Foreign Key Cons traints Note 33453.1 ST Space management enqueue Usually caused by too much space management occurring (Eg: small extent sizes , lots of sorting etc..) See Note 33567.1 for more information about the ST enqueue.
support.oracle.com/CSP/main/article?c
5/6
9/29/2010
https://support.oracle.com/CSP/main/ar
References
NOTE:1020008.6 - SCRIPT: FULLY DECODED LOCKING NOTE:1020012.6 - SCRIPT TO RETURN MEDIUM DETAIL LOCKING INFO NOTE:122371.1 - How To Gather Statistics For Oracle Applications Prior to 11.5.10 NOTE:149124.1 - Creating a StatsPack performance report NOTE:153507.1 - Oracle Applications and StatsPack NOTE:169935.1 - Troubleshooting Oracle Applications Performance Issues NOTE:174605.1 - bde_chk_cbo.sql - Reports Database Initialization Parameters related to an Apps 12 or 11i instance NOTE:216205.1 - Database Initialization Parameters for Oracle Applications Release 11i NOTE:228913.1 - Systemwide Tuning using STATSPACK Reports NOTE:276103.1 - PERFORMANCE TUNING USING 10g ADVISORS AND MANAGEABILITY FEATURES NOTE:34566.1 - WAITEVENT: "enqueue" Reference Note NOTE:362851.1 - Guidelines to setup the JVM in Apps Ebusiness Suite 11i and R12 NOTE:396009.1 - Database Initialization Parameters for Oracle Applications Release 12 NOTE:94224.1 - FAQ- Statspack Complete Reference http://blogs.oracle.com/stevenChan/2008/10/tuning_all_layers_of_the_oracle_e-business_suite.html
Related Products Oracle E-Business Suite > Applications Technology > Application Object Library > Oracle Application Object Library Keywords CBO; INITIALIZATION PARAMETERS; SQL TUNING; ORACLE APPS; PERFORMANCE TUNING; WAIT TIME
Back to top
Rate this document
support.oracle.com/CSP/main/article?c
6/6