Вы находитесь на странице: 1из 6



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: to 12.0.4 Information in this document applies to any platform.


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.

Last Review Date

October 20, 2008

Instructions for the Reader

A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist in troubleshooting.

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



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

How to interpret AWR or Statspack report ?

In the below example we are trying to give you some guidelines to help you interpreting AWR or Statspack report. When you start Investigating, first thing you need to look at is the Top 5 timed events. You will see something like the following example in AWR or Statspack report : Top 5 Timed Events
Event Class db file sequential read db file scattered read enq: TX - row lock contention CPU time Waits Time(s) 11,948,893 8,992,348 10,697 31,327 Avg Wait(ms) % Total Call Time 56,405 32,431 2,929 23,634 535.1 420.2 19.5 7.9 Wait

User I/O User I/O Application

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 :





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.

Commonly Observed Wait Events

wait event db file sequential read Description Area Examine Review AWR/Stats pack Top SQL ordered by reads

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

db file scattered read

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

Buffer busy waits the s ess ion wants to acces s

Review s egment statis tics by




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


Review the following sections : enqueue, row lock & ITL waits




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.

Best practices for tuning performance

Database tier Refer to note 244040.1 Recommended Performance Patches for the Oracle E-Business Suite. There are several optimizer related patches that need to be applied on top of 10.2.0.(2/3). Refer to note 244040.1 for an updated list. Convert to the OATM Tablespace Model for the EBusiness Suite. See Note 404954.1 How to run OATM migration utility. Applications tier Deploy with socket mode for internal users: R12: Refer to Note 384241.1. Enable Forms Dead Client Detection Value specified in minutes : FORMS_TIMEOUT=10 Terminates fwebmx processes for dead clients. Enable Forms Abnormal Termination Handle Do not set FORMS_CATCHTERM The above two variables ( FORMS_TIMEOUT and FORMS_CATCHTERM ) can be changed from context file.XML. You will find them as s_f60catchterm and s_f60time parameters for 11i users. s_forms_catchterm and s_forms_time for R12 users. Disable Cancel Query Cancel Query increases middle-tier CPU as well as DB CPU Refer to MetaLink Note 138159.1 on how to enable and tune Cancel query related parameters To Disable Cancel Query : Set the Profile FND: Enable Cancel Query to No For tuning JVM/OC4J Refer to Note 362851.1:Guidelines to setup the JVM in Apps 11i Use one JVM per 2 CPUs No more than one JVM/CPU No more than 100 concurrent users per JVM





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