Performance issue..LIO is very hig,need to reduce

In this query ,Lio is very high.Please suggest how to low down the LIO
SELECT DISTINCT ool.org_id, ool.header_id, ooh.order_number, ool.line_id,
ool.line_number, ool.shipment_number,
NVL (ool.option_number, -99) option_number, xcl.GROUP_ID,
xcl.attribute3, xcl.attribute4
FROM oe_order_headers ooh,
xxcn_comp_header xch,
xxcn_comp_lines xcl,
fnd_lookup_values_vl fvl,
oe_order_lines ool
WHERE 1 = 1
AND ooh.org_id = 1524
AND xch.src_ref_no = TO_CHAR (ooh.order_number)
AND xch.src_ref_id = ooh.header_id
AND xch.org_id = 1524
AND xcl.header_id = xch.header_id
AND ool.line_id = xcl.oe_line_id
AND ool.flow_status_code IN
('WWD_SHIPPED',
'FULFILLED',
'SHIPPED',
'CLOSED',
'RETURNED'
AND ool.org_id = 1524
AND ool.header_id = ooh.header_id
AND xch.org_id = 1524
AND fvl.lookup_type = 'EMR OIC SOURCE FOR OU'
AND fvl.tag = '1524'
AND fvl.description = xch.SOURCE
AND EXISTS (
SELECT 1
FROM oe_order_lines oe
WHERE oe.header_id = ool.header_id
AND oe.org_id = 1524
AND oe.line_number = ool.line_number
AND oe.ordered_item = ool.ordered_item
AND oe.shipment_number > ool.shipment_number
AND NVL (oe.option_number, -99) =
NVL (ool.option_number,
-99)
AND NOT EXISTS (
SELECT 1
FROM xxcn_comp_lines xcl2
WHERE xcl.GROUP_ID = xcl2.GROUP_ID
AND oe.line_id = oe_line_id))
call count cpu elapsed disk query current rows
Parse 1 0.07 0.12 12 25 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 103.03 852.42 176206 4997766 0 12
total 4 103.10 852.55 176218 4997791 0 12

947729 wrote:
In this query ,Lio is very high.Please suggest how to low down the LIO
SELECT DISTINCT ool.org_id, ool.header_id, ooh.order_number, ool.line_id,
ool.line_number, ool.shipment_number,
NVL (ool.option_number, -99) option_number, xcl.GROUP_ID,
xcl.attribute3, xcl.attribute4
FROM oe_order_headers ooh,
xxcn_comp_header xch,
xxcn_comp_lines xcl,
fnd_lookup_values_vl fvl,
oe_order_lines ool
WHERE 1 = 1
AND ooh.org_id = 1524
AND xch.src_ref_no = TO_CHAR (ooh.order_number)
AND xch.src_ref_id = ooh.header_id
AND xch.org_id = 1524
AND xcl.header_id = xch.header_id
AND ool.line_id = xcl.oe_line_id
AND ool.flow_status_code IN
('WWD_SHIPPED',
'FULFILLED',
'SHIPPED',
'CLOSED',
'RETURNED'
AND ool.org_id = 1524
AND ool.header_id = ooh.header_id
AND xch.org_id = 1524
AND fvl.lookup_type = 'EMR OIC SOURCE FOR OU'
AND fvl.tag = '1524'
AND fvl.description = xch.SOURCE
AND EXISTS (
SELECT 1
FROM oe_order_lines oe
WHERE oe.header_id = ool.header_id
AND oe.org_id = 1524
AND oe.line_number = ool.line_number
AND oe.ordered_item = ool.ordered_item
AND oe.shipment_number > ool.shipment_number
AND NVL (oe.option_number, -99) =
NVL (ool.option_number,
-99)
AND NOT EXISTS (
SELECT 1
FROM xxcn_comp_lines xcl2
WHERE xcl.GROUP_ID = xcl2.GROUP_ID
AND oe.line_id = oe_line_id))
Release 10.2.0.4.0
call     count   cpu    elapsed       disk      query    current        rows
Parse        1      0.07       0.12         12         25          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2    103.03     852.42     176206    4997766          0          12
total        4    103.10     852.55     176218    4997791          0      12
Explain plan of this query is below
Rows     Row Source Operation
12  HASH UNIQUE (cr=4997766 pr=176206 pw=0 time=852428906 us)
17   NESTED LOOPS ANTI (cr=4997766 pr=176206 pw=0 time=1446684781 us)
16526    NESTED LOOPS  (cr=4950508 pr=175369 pw=0 time=550499635 us)
66826     NESTED LOOPS  (cr=859835 pr=30101 pw=0 time=97903856 us)
82858      NESTED LOOPS  (cr=528415 pr=14011 pw=0 time=33166344 us)
20894       NESTED LOOPS  (cr=464522 pr=8691 pw=0 time=23299083 us)
205466        NESTED LOOPS  (cr=32693 pr=7294 pw=0 time=10132722 us)
1         TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=5 pr=3 pw=0 time=44146 us)
25          INDEX RANGE SCAN XXAR_FND_LOOKUP_VALUES_N1 (cr=4 pr=2 pw=0 time=18395 us)(object id 1405422)
205466         TABLE ACCESS BY INDEX ROWID XXCN_COMP_HEADER (cr=32688 pr=7291 pw=0 time=10101528 us)
205466          INDEX RANGE SCAN XXCN_COMP_HEADER_N3 (cr=2388 pr=2382 pw=0 time=3722541 us)(object id 9021932)
20894        TABLE ACCESS BY INDEX ROWID OE_ORDER_HEADERS_ALL (cr=431829 pr=1397 pw=0 time=6679532 us)
20895         INDEX UNIQUE SCAN OE_ORDER_HEADERS_U1 (cr=410934 pr=1072 pw=0 time=2490560 us)(object id 41952)
82858       TABLE ACCESS BY INDEX ROWID XXCN_COMP_LINES (cr=63893 pr=5320 pw=0 time=17896525 us)
82858        INDEX RANGE SCAN XXCN_COMP_LINES_N1 (cr=43320 pr=2178 pw=0 time=3730459 us)(object id 670434)
66826      TABLE ACCESS BY INDEX ROWID OE_ORDER_LINES_ALL (cr=331420 pr=16090 pw=0 time=117930875 us)
82799       INDEX UNIQUE SCAN OE_ORDER_LINES_U1 (cr=165813 pr=4763 pw=0 time=25721344 us)(object id 42102)
16526     TABLE ACCESS BY INDEX ROWID OE_ORDER_LINES_ALL (cr=4090673 pr=145268 pw=0 time=675397399 us)
19359150      INDEX RANGE SCAN OE_ORDER_LINES_N1 (cr=181518 pr=3972 pw=0 time=15991401 us)(object id 42076)
15719    TABLE ACCESS BY INDEX ROWID XXCN_COMP_LINES (cr=47258 pr=837 pw=0 time=5859290 us)
15719     INDEX RANGE SCAN XXCN_COMP_LINES_N3 (cr=31539 pr=423 pw=0 time=2302456 us)(object id 670436)Please suggest how to low down LIO.This is the Row Source Operation output from tkprof, and it looks like a single execution of the query so it's giving us some useful information.
The line that leaps out first is this one:
19359150      INDEX RANGE SCAN OE_ORDER_LINES_N1 (cr=181518 pr=3972 pw=0 time=15991401 us)(object id 42076)This line returns 19, 359,150 rowids from index range scans - but it takes only 15.991401 seconds to do so, with 1.8M buffer gets and 3,972 block reads. However, using these 19M rowids we then visit the table 19M times, returning a total of 16,526 rows (the preceding line in the plan):
   16526     TABLE ACCESS BY INDEX ROWID OE_ORDER_LINES_ALL (cr=4090673 pr=145268 pw=0 time=675397399 us)This takes roughly 4M buffer gets (less the 181,000 from the index range scan), 141,000 disk reads (allowing for the 4,000 from the index range scan) and 659 seconds (allowing for the 16 seconds from the index range scan).
The optimizer is choosing a very bad index to access this table - this may be due to a problem with statistics, the absence of a better index, or some issue with combinations of columns and the optimizer's basic algorithms. To address the problem you may have to hint the appropriate index, although if you're running 11g, creating some "column group" stats may help the optimizer to get the arithmetic right.
(The row stats suggest that there are other inefficiencies in the choice of plan, but this is the most significant one.)
Regards
Jonathan Lewis

Similar Messages

  • Performance issue on query. Help needed.

    This is mainly a performance issue. I hope someone can help me on this.
    Basically I have four tables Master (150000 records), Child1 (100000+ records), Child2 (50 million records !), Child 3 (10000+ records)
    (please pardon the aliases).
    Now every record in master has more than one corresponding record in each of the child tables (one to many).
    Also there may not be any record in any or all of the tables for a particular master record.
    Now, I need to fetch the max of last_updated_date for every master record in each of the 3 child tables and then find the maximum of
    the three last_active_dates obtained from the 3 tables.
    eg: for Master ID 100, I need to query Child1 for all the records of Master ID 100 and get the max last_updated_date.
    Same for the other 2 tables and then get the maximum of these three values.
    (I also need to take care of cases where no record may be found in a child table for a Master ID)
    Writing a procedure that uses cursors that fetches the value from each of the child table hits performance
    badly. And thing is I need to find out the last_updated_date for every Master record (all 150000 of them). It'll probably take days to do this.
    SELECT MAX (C1.LAST_UPDATED_DATE)
    ,MAX (C2.LAST_UPDATED_DATE)
    ,MAX (C3.LAST_UPDATED_DATE)
    FROM CHILD1 C1
    ,CHILD2 C2
    ,CHILD3 C3
    WHERE C1.MASTER_ID = 100
    OR C2.MASTER_ID = 100
    OR C3.MASTER_ID = 100
    I tried the above but I got a temp tablespace error. I don't think the query is good enough at all.
    (The OR clause is to take care of no records in any child table. If there's an AND, then the join and hence select will
    fail even if there is no record in one child table but valid values in the other 2 tables).
    Thanks a lot.
    Edited by: user773489 on Dec 16, 2008 11:49 AM

    Not sure I understand the problem. The max you are getting from the above is already the greatest out of the three - that's why we do the UNION ALL.
    Here's sample code without output, maybe this will clear it up:
    with a as (
    select 10 MASTER_ID, to_date('12/15/2008', 'MM/DD/YYYY') LAST_DTE from dual UNION ALL
    select 20 MASTER_ID, to_date('12/01/2008', 'MM/DD/YYYY') LAST_DTE from dual UNION ALL
    select 30 MASTER_ID, to_date('12/02/2008', 'MM/DD/YYYY') LAST_DTE from dual
    b as (
    select 10 MASTER_ID, to_date('12/14/2008', 'MM/DD/YYYY') LAST_DTE from dual UNION ALL
    select 20 MASTER_ID, to_date('12/02/2008', 'MM/DD/YYYY') LAST_DTE from dual UNION ALL
    select 40 MASTER_ID, to_date('11/15/2008', 'MM/DD/YYYY') LAST_DTE from dual
    c as (
    select 10 MASTER_ID, to_date('12/07/2008', 'MM/DD/YYYY') LAST_DTE from dual UNION ALL
    select 30 MASTER_ID, to_date('11/29/2008', 'MM/DD/YYYY') LAST_DTE from dual UNION ALL
    select 40 MASTER_ID, to_date('12/13/2008', 'MM/DD/YYYY') LAST_DTE from dual
    select MASTER_ID, MAX(LAST_DTE)
    FROM
    (select MASTER_ID, LAST_DTE from a UNION ALL
    select MASTER_ID, LAST_DTE from b UNION ALL
    select MASTER_ID, LAST_DTE from c)
    group by MASTER_ID;
    MASTER_ID              MAX(LAST_DTE)            
    30                     02-DEC-08                
    40                     13-DEC-08                
    20                     02-DEC-08                
    10                     15-DEC-08                
    4 rows selectedEdited by: tk-7381344 on Dec 16, 2008 12:38 PM

  • Performance issue with XI interfaces - Help Needed

    Hi all,
           We are having idoc->xi->file. We have the design of collecting the idocs as the standard example BpmPatternCollectTime.
            We have given the collection time of say 5minutes after the first idoc hits the BPM process. The issue is that the idoc messages are getting missed when we are sending 1000 idocs. Also after applying the note 898131 for the correction of missing idocs we got the problem of the timeout exception not being triggered and workflow instance is waiting for a longtime until all the messages are getting into BPM and is getting struck in the queue.
            We are into XI 3.0 SP13. Can anyone provide some help in optimizing the interfaces/server settings/etc..
    Thanks in advance.
    Jayakrishnan

    Hi Jayakirshnan,
    check if this helps, whether you have optimal number of dialog processes.
    see theselinks as well
    Re: BPM is slow in sending Idocs
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/3.0/sap exchange infrastructure tuning guide xi 3.0.pdf
    http://help.sap.com/saphelp_erp2005/helpdata/en/42/e7bb8f7c9d3ee0e10000000a1553f6/content.htm
    Regards
    Vishnu

  • Performance issue in Portal Reports

    Hi
    We are experiencing a serious performance issue, in a report, and need a urgent fix on this issue.
    The report is a Reports From SQL Query report, I need to find a way to dynamically make/create the where clause otherwise I have to make the statement in a way the exclude the use of indexes.
    Full-table-scan is not a valid option here; the number or records is simply too high (several millions its a datawarehouse solution). In the Developer packaged, we can make the where clause dynamically, this basic yet extremely important feature, is essential to all database application.
    We need to know how to do it, and if this functionality is not natively supported, then this should be one of the priority one functionalities to implement in future releases.
    However, what do I do for now?
    Thank in advance

    I have found a temporary workaround, by editing the where clause in the stored procedure manually. However this fix have to be done every time a change have been committed in the wizard, so it is still not a solution to go for indefinitely, but its ok for now.

  • Performance issue in the table

    Hi All
    i have one table which is based on a VO. This VO has 150 attributes.I am facing performance issue.
    first Q is i need to display only 15 attributes in the table. but other attributes are also required .
    so i have two options .
    1. make other as form value
    or
    2. make them messagetextinput and set rendered false.
    i just wanted to know which will perform better.
    pls help

    these attributes have some default values.
    i need to pass these values to the api on some action
    if i dont keep in my page then
    will row.getAttribute("XYZ") still carry its value
    ??

  • ASO Cube Performance Issue

    We have been working on 2 ASO cubes, performance was great. No modification hasn't been done ever since, but we have been experiencing performance issue now. What could be the possible cause or how I could resolve this. Thank you.

    'Performance issue' isn't very descriptive - performance of what? Query? Data load? Aggregation? Restructure?
    As a start, has the volume of data (input data cells) been increasing significantly?

  • EP6 sp12 Performance Issue, Need help to improve performance

    We have a Portal development environment with EP6.0 sp12.
    What we are experiencing is performance issue, It's not extremely slow, but slow compared to normal ( compared to our prod box). For example, after putting the username and password and clicking the <Log on> Button it's taking more than 10 secs for the first home page to appear. Also currently we have hooked the Portal with 3 xAPPS system and one BW system. The time taken for a BW query to appear ( with selection screen) is also more than 10 secs. However access to one other xAPPS is comparatively faster.
    Do we have a simple to use guide( Not a very elaborate one) with step by step guidance to immediately improve the performance of the Portal.
    Simple guide, easy to implement,  with immediate effect is what we are looking for in the short term
    Thanks
    Arunabha

    Hi Eric,
      I have searched but didn't find the Portal Tuning and Optimization Guide as you have suggested, Can you help to find this.
    Subrato,
      This is good and I would obviously read through this, The issue here is this is only for Network.
      But do you know any other guide, which as very basic ( may be 10 steps) and show step by step the process, it would be very helpful. I already have some information from the thread Portal Performance - page loads slow, client cache reset/cleared too often
    But really looking for answer ( steps to do it quickly and effectively) instead of list of various guides.
    It would be very helpful if you or anybody( who has actually done some performance tuning) can send  a basic list of steps that I can do immediately, instead of reading through these large guides.
    I know I am looking for a shortcut, but this is the need of the hour.
    Thanks
    Arun

  • While creating Billing, system is very slow..performance issue

    Hi,
    While creating Billing, system is very slow. How can I debugg and provide the analysis where is the exact problem.
    This is showing performance issue.
    Waiting for kind response.
    Best Regards,
    Padhy
    Moderator Message : Duplicate post locked.
    Edited by: Vinod Kumar on May 12, 2011 10:59 AM

    hi,
    Chk the links
    http://help.sap.com/saphelp_nw04/helpdata/en/4a/e71f39488fee0ce10000000a114084/content.htm
    Re: How to create Secondary Index?
    How may secondary indices I can create on the ODS?
    Deletion of ODS index
    Ramesh

  • After Effects CS5.5 - Very Serious Performance Issues w/RAM Preview

    My system: Windows 7 Professional, two Intel Xeon X5650's, 12GB RAM, and a NVIDIA Quadro FX 4800.
    Problem: RAM Preview in CS5.5 gives me less than 2 fps (yes---two frames per second). This is even with the most simple of compositions. I created a 1080p 23.976 project with two simple solid layers and keyframed position and scale values for one of them with no other effects on either solid. RAM Preview gives me 1.8 fps.
    I still have AE CS5 installed and it gives me solid, predictable results with RAM Preview. When I create a similar test project inside CS5, it creates the RAM preview almost instantly and displays in proper realtime (23.976 fps).
    My settings for both CS5 and CS5.5 are similar  (and I have tried many variations in my attempt to fix this problem).
    PREVIEWS
    Fast Previews: Adaptive Resolution Limit 1/4
    Enabled OpenGL and both sub-options for OpenGL enabled.
    MEMORY & MULTIPROCESSING
    RAM reserved for other apps: 4GB
    I have tried various settings for Multiprocessing, all of which results in the same less-than-2 fps RAM Previews. Currently I have MP'ing enabled with 1.5GB allocation per background CPU and the actual CPU's used is 4. Again, no matter what I set it to, I get the same performance issue.
    On my screen magnification ratio setting, I am using 25% and my Resolution/Down Sample is set to quarter. On my preview tab, I have tried setting my resolution from the default of "Auto" to "Quarter" with no difference.
    In summary: On the same machine, AE CS5.5 RAM Preview offers terrible performance; CS5 RAM Preview offers great performance.

    Under AJA Preview there are check boxes, one for "Video" and the other for "Preview." I've checked and unchecked them both and I'm still getting poor RAM previews. No matter what I have toggled, I seem to get between 1 and 2 fps for my RAM Previews.
    I am not currently using the AJA card for anything. I will consider uninstalling it if this might possibly solve my problem. It's just a hassle to install and uninstall cards on a per need basis.
    If there are any other thoughts, I'd love to hear them. At this point, I'd do just about anything to have realtime previews back.
    The machine I'm using, by the way, is an HP z800 with Windows 7 Professional, two Intel Xeon X5650's, 12GB RAM, and a NVIDIA Quadro FX 4800. It has the following installed: CS5.5 Production Premium, AVID Media Composer 5.5.2, and AVID DS 10.5.1 (among other programs).

  • Need help with premiere pro cs6 having performance issues please help

    need help with premiere pro cs6 having performance issues please help

    Welcome to the forum.
    First thing that I would do would be to look at this Adobe KB Article to see if it helps.
    Next, I would try the tips in this ARTICLE.
    If that does not help, a Repair Install would definitely be in order.
    Good luck,
    Hunt

  • Performance issue in DB need help with analysing this ADDM report

    Hi,
    My environment:
    Os: RHEL5U3 / 11.1.0.7 64 bit / R12.1.1 64 bit
    Issue:
    Few days are am facing serious of performance problem in our Production instance. Normally the issue will occur 5 to 10 minutes occasionally per day. At the time of issue we not able to access the EBS application its taking time to load. But backend all the oracle, listener and apps services are up and running. No locks at table and session level. Cpu and memory usage is normal.
    We have monitored using "Enterprise Manager" for this issue and we found the wait session present more in Active session tab. At this time EBS application is not able access its loading too time. After some time the in Active session tab the wait session came normal and when we try to access the EBS application its working fine.
    We try to find the cause of the issue by running addm report. But am not able to understand what its says. Kindly suggests me
    ADDM Report for Task 'TASK_42656'
    Analysis Period
    AWR snapshot range from 14754 to 14755.
    Time period starts at 17-APR-12 11.00.22 AM
    Time period ends at 17-APR-12 12.00.33 PM
    Analysis Target
    Database 'PRD' with DB ID 1789440879.
    Database version 11.1.0.7.0.
    ADDM performed an analysis of instance PRD, numbered 1 and hosted at
    advgrpdb.advgroup.ae.
    Activity During the Analysis Period
    Total database time was 18674 seconds.
    The average number of active sessions was 5.17.
    Summary of Findings
    Description Active Sessions Recommendations
    Percent of Activity
    1 Top SQL by DB Time 3.43 | 66.33 5
    2 Buffer Busy 2.52 | 48.81 5
    3 Buffer Busy 1.39 | 26.81 2
    4 Log File Switches .91 | 17.56 1
    5 Buffer Busy .56 | 10.87 2
    6 Undersized SGA .38 | 7.37 1
    7 Commits and Rollbacks .28 | 5.42 1
    8 Undo I/O .18 | 3.53 0
    9 CPU Usage .13 | 2.57 1
    10 Top SQL By I/O .11 | 2.21 1
    Findings and Recommendations
    Finding 1: Top SQL by DB Time
    Impact is 3.43 active sessions, 66.33% of total activity.
    SQL statements consuming significant database time were found.
    Recommendation 1: SQL Tuning
    Estimated benefit is 1.59 active sessions, 30.8% of total activity.
    Action
    Investigate the SQL statement with SQL_ID "a49xsqhv0h31b" for possible
    performance improvements.
    Related Object
    SQL statement with SQL_ID a49xsqhv0h31b.
    SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code,
    P.Application_ID, P.Concurrent_Program_ID, P.Concurrent_Program_Name,
    R.Enable_Trace, R.Restart, DECODE(R.Increment_Dates, 'Y', 'Y', 'N'),
    R.NLS_Compliant, R.OUTPUT_FILE_TYPE, E.Executable_Name,
    E.Execution_File_Name, A2.Basepath, DECODE(R.Stale, 'Y', 'C',
    P.Execution_Method_Code), P.Print_Flag, P.Execution_Options,
    DECODE(P.Srs_Flag, 'Y', 'Y', 'Q', 'Y', 'N'), P.Argument_Method_Code,
    R.Print_Style, R.Argument_Input_Method_Code, R.Queue_Method_Code,
    R.Responsibility_ID, R.Responsibility_Application_ID, R.Requested_By,
    R.Number_Of_Copies, R.Save_Output_Flag, R.Printer, R.Print_Group,
    R.Priority, U.User_Name, O.Oracle_Username,
    O.Encrypted_Oracle_Password, R.Cd_Id, A.Basepath,
    A.Application_Short_Name, TO_CHAR(R.Requested_Start_Date,'YYYY/MM/DD
    HH24:MI:SS'), R.Nls_Language, R.Nls_Territory,
    R.Nls_Numeric_Characters, DECODE(R.Parent_Request_ID, NULL, 0,
    R.Parent_Request_ID), R.Priority_Request_ID, R.Single_Thread_Flag,
    R.Has_Sub_Request, R.Is_Sub_Request, R.Req_Information,
    R.Description, R.Resubmit_Time, TO_CHAR(R.Resubmit_Interval),
    R.Resubmit_Interval_Type_Code, R.Resubmit_Interval_Unit_Code,
    TO_CHAR(R.Resubmit_End_Date,'YYYY/MM/DD HH24:MI:SS'),
    Decode(E.Execution_File_Name, NULL, 'N', Decode(E.Subroutine_Name,
    NULL, Decode(E.Execution_Method_Code, 'I', 'Y', 'J', 'Y', 'N'),
    'Y')), R.Argument1, R.Argument2, R.Argument3, R.Argument4,
    R.Argument5, R.Argument6, R.Argument7, R.Argument8, R.Argument9,
    R.Argument10, R.Argument11, R.Argument12, R.Argument13, R.Argument14,
    R.Argument15, R.Argument16, R.Argument17, R.Argument18, R.Argument19,
    R.Argument20, R.Argument21, R.Argument22, R.Argument23, R.Argument24,
    R.Argument25, X.Argument26, X.Argument27, X.Argument28, X.Argument29,
    X.Argument30, X.Argument31, X.Argument32, X.Argument33, X.Argument34,
    X.Argument35, X.Argument36, X.Argument37, X.Argument38, X.Argument39,
    X.Argument40, X.Argument41, X.Argument42, X.Argument43, X.Argument44,
    X.Argument45, X.Argument46, X.Argument47, X.Argument48, X.Argument49,
    X.Argument50, X.Argument51, X.Argument52, X.Argument53, X.Argument54,
    X.Argument55, X.Argument56, X.Argument57, X.Argument58, X.Argument59,
    X.Argument60, X.Argument61, X.Argument62, X.Argument63, X.Argument64,
    X.Argument65, X.Argument66, X.Argument67, X.Argument68, X.Argument69,
    X.Argument70, X.Argument71, X.Argument72, X.Argument73, X.Argument74,
    X.Argument75, X.Argument76, X.Argument77, X.Argument78, X.Argument79,
    X.Argument80, X.Argument81, X.Argument82, X.Argument83, X.Argument84,
    X.Argument85, X.Argument86, X.Argument87, X.Argument88, X.Argument89,
    X.Argument90, X.Argument91, X.Argument92, X.Argument93, X.Argument94,
    X.Argument95, X.Argument96, X.Argument97, X.Argument98, X.Argument99,
    X.Argument100, R.number_of_arguments, C.CD_Name,
    NVL(R.Security_Group_ID, 0), NVL(R.org_id, 0) FROM
    fnd_concurrent_requests R, fnd_concurrent_programs P, fnd_application
    A, fnd_user U, fnd_oracle_userid O, fnd_conflicts_domain C,
    fnd_concurrent_queues Q, fnd_application A2, fnd_executables E,
    fnd_conc_request_arguments X WHERE R.Status_code = 'I' And
    ((R.OPS_INSTANCE is null) or (R.OPS_INSTANCE = -1) or
    (R.OPS_INSTANCE =
    decode(:dcp_on,1,FND_CONC_GLOBAL.OPS_INST_NUM,R.OPS_INSTANCE))) And
    R.Request_ID = X.Request_ID(+) And R.Program_Application_Id =
    P.Application_Id(+) And R.Concurrent_Program_Id =
    P.Concurrent_Program_Id(+) And R.Program_Application_Id =
    A.Application_Id(+) And P.Executable_Application_Id =
    E.Application_Id(+) And P.Executable_Id =
    E.Executable_Id(+) And P.Executable_Application_Id =
    A2.Application_Id(+) And R.Requested_By = U.User_Id(+) And R.Cd_Id
    = C.Cd_Id(+) And R.Oracle_Id = O.Oracle_Id(+) And Q.Application_Id =
    :q_applid And Q.Concurrent_Queue_Id = :queue_id And (P.Enabled_Flag
    is NULL OR P.Enabled_Flag = 'Y') And R.Hold_Flag = 'N' And
    R.Requested_Start_Date <= Sysdate And ( R.Enforce_Seriality_Flag =
    'N' OR ( C.RunAlone_Flag = P.Run_Alone_Flag And (P.Run_Alone_Flag =
    'N' OR Not Exists (Select Null From Fnd_Concurrent_Requests Sr
    Where Sr.Status_Code In ('R', 'T') And Sr.Enforce_Seriality_Flag =
    'Y' And Sr.CD_id = C.CD_Id)))) And Q.Running_Processes <=
    Q.Max_Processes And R.Rowid = :reqname And
    ((P.Execution_Method_Code != 'S' OR
    (R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) IN
    ((0,98),(0,100),(0,31721),(0,31722),(0,31757))) AND
    ((R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) NOT IN
    ((510,40112),(510,40113),(510,41497),(510,41498),(530,41859),(530,418
    60),(535,41492),(535,41493),(535,41494)))) FOR UPDATE OF
    R.status_code NoWait
    Rationale
    SQL statement with SQL_ID "a49xsqhv0h31b" was executed 4686 times and
    had an average elapsed time of 1.2 seconds.
    Rationale
    Waiting for event "buffer busy waits" in wait class "Concurrency"
    accounted for 85% of the database time spent in processing the SQL
    statement with SQL_ID "a49xsqhv0h31b".
    Rationale
    Waiting for event "log file switch (checkpoint incomplete)" in wait
    class "Configuration" accounted for 9% of the database time spent in
    processing the SQL statement with SQL_ID "a49xsqhv0h31b".
    Recommendation 3: SQL Tuning
    Estimated benefit is .56 active sessions, 10.91% of total activity.
    Action
    Investigate the SQL statement with SQL_ID "5d7957yktf3nn" for possible
    performance improvements.
    Related Object
    SQL statement with SQL_ID 5d7957yktf3nn.
    UPDATE ICX_SESSIONS SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
    Rationale
    SQL statement with SQL_ID "5d7957yktf3nn" was executed 266 times and had
    an average elapsed time of 7.6 seconds.
    Rationale
    Waiting for event "buffer busy waits" in wait class "Concurrency"
    accounted for 86% of the database time spent in processing the SQL
    statement with SQL_ID "5d7957yktf3nn".
    Rationale
    Waiting for event "log file switch (checkpoint incomplete)" in wait
    class "Configuration" accounted for 7% of the database time spent in
    processing the SQL statement with SQL_ID "5d7957yktf3nn".
    Finding 2: Buffer Busy
    Impact is 2.52 active sessions, 48.81% of total activity.
    Read and write contention on database blocks was consuming significant
    database time.
    Recommendation 1: Application Analysis
    Estimated benefit is 1.42 active sessions, 27.44% of total activity.
    Action
    Trace the cause of object contention due to SELECT statements in the
    application using the information provided.
    Related Object
    Database object with ID 34562.
    Rationale
    The SELECT statement with SQL_ID "a49xsqhv0h31b" was significantly
    affected by "buffer busy" waits.
    Related Object
    SQL statement with SQL_ID a49xsqhv0h31b.
    SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code,
    P.Application_ID, P.Concurrent_Program_ID, P.Concurrent_Program_Name,
    R.Enable_Trace, R.Restart, DECODE(R.Increment_Dates, 'Y', 'Y', 'N'),
    R.NLS_Compliant, R.OUTPUT_FILE_TYPE, E.Executable_Name,
    E.Execution_File_Name, A2.Basepath, DECODE(R.Stale, 'Y', 'C',
    P.Execution_Method_Code), P.Print_Flag, P.Execution_Options,
    DECODE(P.Srs_Flag, 'Y', 'Y', 'Q', 'Y', 'N'), P.Argument_Method_Code,
    R.Print_Style, R.Argument_Input_Method_Code, R.Queue_Method_Code,
    R.Responsibility_ID, R.Responsibility_Application_ID, R.Requested_By,
    R.Number_Of_Copies, R.Save_Output_Flag, R.Printer, R.Print_Group,
    R.Priority, U.User_Name, O.Oracle_Username,
    O.Encrypted_Oracle_Password, R.Cd_Id, A.Basepath,
    A.Application_Short_Name, TO_CHAR(R.Requested_Start_Date,'YYYY/MM/DD
    HH24:MI:SS'), R.Nls_Language, R.Nls_Territory,
    R.Nls_Numeric_Characters, DECODE(R.Parent_Request_ID, NULL, 0,
    R.Parent_Request_ID), R.Priority_Request_ID, R.Single_Thread_Flag,
    R.Has_Sub_Request, R.Is_Sub_Request, R.Req_Information,
    R.Description, R.Resubmit_Time, TO_CHAR(R.Resubmit_Interval),
    R.Resubmit_Interval_Type_Code, R.Resubmit_Interval_Unit_Code,
    TO_CHAR(R.Resubmit_End_Date,'YYYY/MM/DD HH24:MI:SS'),
    Decode(E.Execution_File_Name, NULL, 'N', Decode(E.Subroutine_Name,
    NULL, Decode(E.Execution_Method_Code, 'I', 'Y', 'J', 'Y', 'N'),
    'Y')), R.Argument1, R.Argument2, R.Argument3, R.Argument4,
    R.Argument5, R.Argument6, R.Argument7, R.Argument8, R.Argument9,
    R.Argument10, R.Argument11, R.Argument12, R.Argument13, R.Argument14,
    R.Argument15, R.Argument16, R.Argument17, R.Argument18, R.Argument19,
    R.Argument20, R.Argument21, R.Argument22, R.Argument23, R.Argument24,
    R.Argument25, X.Argument26, X.Argument27, X.Argument28, X.Argument29,
    X.Argument30, X.Argument31, X.Argument32, X.Argument33, X.Argument34,
    X.Argument35, X.Argument36, X.Argument37, X.Argument38, X.Argument39,
    X.Argument40, X.Argument41, X.Argument42, X.Argument43, X.Argument44,
    X.Argument45, X.Argument46, X.Argument47, X.Argument48, X.Argument49,
    X.Argument50, X.Argument51, X.Argument52, X.Argument53, X.Argument54,
    X.Argument55, X.Argument56, X.Argument57, X.Argument58, X.Argument59,
    X.Argument60, X.Argument61, X.Argument62, X.Argument63, X.Argument64,
    X.Argument65, X.Argument66, X.Argument67, X.Argument68, X.Argument69,
    X.Argument70, X.Argument71, X.Argument72, X.Argument73, X.Argument74,
    X.Argument75, X.Argument76, X.Argument77, X.Argument78, X.Argument79,
    X.Argument80, X.Argument81, X.Argument82, X.Argument83, X.Argument84,
    X.Argument85, X.Argument86, X.Argument87, X.Argument88, X.Argument89,
    X.Argument90, X.Argument91, X.Argument92, X.Argument93, X.Argument94,
    X.Argument95, X.Argument96, X.Argument97, X.Argument98, X.Argument99,
    X.Argument100, R.number_of_arguments, C.CD_Name,
    NVL(R.Security_Group_ID, 0), NVL(R.org_id, 0) FROM
    fnd_concurrent_requests R, fnd_concurrent_programs P, fnd_application
    A, fnd_user U, fnd_oracle_userid O, fnd_conflicts_domain C,
    fnd_concurrent_queues Q, fnd_application A2, fnd_executables E,
    fnd_conc_request_arguments X WHERE R.Status_code = 'I' And
    ((R.OPS_INSTANCE is null) or (R.OPS_INSTANCE = -1) or
    (R.OPS_INSTANCE =
    decode(:dcp_on,1,FND_CONC_GLOBAL.OPS_INST_NUM,R.OPS_INSTANCE))) And
    R.Request_ID = X.Request_ID(+) And R.Program_Application_Id =
    P.Application_Id(+) And R.Concurrent_Program_Id =
    P.Concurrent_Program_Id(+) And R.Program_Application_Id =
    A.Application_Id(+) And P.Executable_Application_Id =
    E.Application_Id(+) And P.Executable_Id =
    E.Executable_Id(+) And P.Executable_Application_Id =
    A2.Application_Id(+) And R.Requested_By = U.User_Id(+) And R.Cd_Id
    = C.Cd_Id(+) And R.Oracle_Id = O.Oracle_Id(+) And Q.Application_Id =
    :q_applid And Q.Concurrent_Queue_Id = :queue_id And (P.Enabled_Flag
    is NULL OR P.Enabled_Flag = 'Y') And R.Hold_Flag = 'N' And
    R.Requested_Start_Date <= Sysdate And ( R.Enforce_Seriality_Flag =
    'N' OR ( C.RunAlone_Flag = P.Run_Alone_Flag And (P.Run_Alone_Flag =
    'N' OR Not Exists (Select Null From Fnd_Concurrent_Requests Sr
    Where Sr.Status_Code In ('R', 'T') And Sr.Enforce_Seriality_Flag =
    'Y' And Sr.CD_id = C.CD_Id)))) And Q.Running_Processes <=
    Q.Max_Processes And R.Rowid = :reqname And
    ((P.Execution_Method_Code != 'S' OR
    (R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) IN
    ((0,98),(0,100),(0,31721),(0,31722),(0,31757))) AND
    ((R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) NOT IN
    ((510,40112),(510,40113),(510,41497),(510,41498),(530,41859),(530,418
    60),(535,41492),(535,41493),(535,41494)))) FOR UPDATE OF
    R.status_code NoWait
    UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
    Recommendation 1: Schema Changes
    Estimated benefit is .03 active sessions, .62% of total activity.
    Action
    Consider rebuilding the TABLE "APPLSYS.FND_LOGIN_RESP_FORMS" with object
    ID 34651 using a higher value for PCTFREE.
    Related Object
    Database object with ID 34651.
    Rationale
    The UPDATE statement with SQL_ID "cqc5crhxxt36t" was significantly
    affected by "buffer busy" waits.
    Related Object
    SQL statement with SQL_ID cqc5crhxxt36t.
    UPDATE FND_LOGIN_RESP_FORMS FLRF SET END_TIME = SYSDATE WHERE
    FLRF.LOGIN_ID = :B2 AND FLRF.LOGIN_RESP_ID = :B1 AND FLRF.END_TIME IS
    NULL AND (FLRF.FORM_ID, FLRF.FORM_APPL_ID) = (SELECT F.FORM_ID,
    F.APPLICATION_ID FROM FND_FORM F, FND_APPLICATION A WHERE F.FORM_NAME
    = :B4 AND F.APPLICATION_ID = A.APPLICATION_ID AND
    A.APPLICATION_SHORT_NAME = :B3 )
    Symptoms That Led to the Finding:
    Wait class "Concurrency" was consuming significant database time.
    Impact is 2.53 active sessions, 48.87% of total activity.
    Finding 4: Log File Switches
    Impact is .91 active sessions, 17.56% of total activity.
    Log file switch operations were consuming significant database time while
    waiting for checkpoint completion.
    This problem can be caused by use of hot backup mode on tablespaces. DML to
    tablespaces in hot backup mode causes generation of additional redo.
    Recommendation 1: Database Configuration
    Estimated benefit is .91 active sessions, 17.56% of total activity.
    Action
    Verify whether incremental shipping was used for standby databases.
    Symptoms That Led to the Finding:
    Wait class "Configuration" was consuming significant database time.
    Impact is .91 active sessions, 17.63% of total activity.
    Finding 5: Buffer Busy
    Impact is .56 active sessions, 10.87% of total activity.
    A hot data block with concurrent read and write activity was found. The block
    belongs to segment "ICX.ICX_SESSIONS" and is block 243489 in file 36.
    Recommendation 1: Application Analysis
    Estimated benefit is .56 active sessions, 10.87% of total activity.
    Action
    Investigate application logic to find the cause of high concurrent read
    and write activity to the data present in this block.
    Related Object
    Database block with object number 37562, file number 36 and block
    number 243489.
    Rationale
    The SQL statement with SQL_ID "5d7957yktf3nn" spent significant time on
    "buffer busy" waits for the hot block.
    Related Object
    SQL statement with SQL_ID 5d7957yktf3nn.
    UPDATE ICX_SESSIONS SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
    Rationale
    The SQL statement with SQL_ID "326up1aym56dd" spent significant time on
    "buffer busy" waits for the hot block.
    Related Object
    SQL statement with SQL_ID 326up1aym56dd.
    UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
    Recommendation 2: Schema Changes
    Estimated benefit is .56 active sessions, 10.87% of total activity.
    Action
    Consider rebuilding the TABLE "ICX.ICX_SESSIONS" with object ID 37562
    using a higher value for PCTFREE.
    Related Object
    Database object with ID 37562.
    Symptoms That Led to the Finding:
    Wait class "Concurrency" was consuming significant database time.
    Impact is 2.53 active sessions, 48.87% of total activity.
    Finding 6: Undersized SGA
    Impact is .38 active sessions, 7.37% of total activity.
    The SGA was inadequately sized, causing additional I/O or hard parses.
    The value of parameter "sga_target" was "4096 M" during the analysis period.
    Recommendation 1: Database Configuration
    Estimated benefit is .12 active sessions, 2.33% of total activity.
    Action
    Increase the size of the SGA by setting the parameter "sga_target" to
    4608 M.
    Symptoms That Led to the Finding:
    Wait class "User I/O" was consuming significant database time.
    Impact is .7 active sessions, 13.57% of total activity.
    Hard parsing of SQL statements was consuming significant database time.
    Impact is .13 active sessions, 2.51% of total activity.
    Contention for latches related to the shared pool was consuming
    significant database time.
    Impact is 0 active sessions, .03% of total activity.
    Wait class "Concurrency" was consuming significant database time.
    Impact is 2.53 active sessions, 48.87% of total activity.
    Finding 7: Commits and Rollbacks
    Impact is .28 active sessions, 5.42% of total activity.
    Waits on event "log file sync" while performing COMMIT and ROLLBACK operations
    were consuming significant database time.
    Recommendation 1: Host Configuration
    Estimated benefit is .28 active sessions, 5.42% of total activity.
    Action
    Investigate the possibility of improving the performance of I/O to the
    online redo log files.
    Rationale
    The average size of writes to the online redo log files was 163 K and
    the average time per write was 68 milliseconds.
    Symptoms That Led to the Finding:
    Wait class "Commit" was consuming significant database time.
    Impact is .28 active sessions, 5.42% of total activity.
    Finding 8: Undo I/O
    Impact is .18 active sessions, 3.53% of total activity.
    Undo I/O was a significant portion (26%) of the total database I/O.
    No recommendations are available.
    Symptoms That Led to the Finding:
    The throughput of the I/O subsystem was significantly lower than
    expected.
    Impact is .08 active sessions, 1.46% of total activity.
    Wait class "User I/O" was consuming significant database time.
    Impact is .7 active sessions, 13.57% of total activity.
    Finding 9: CPU Usage
    Impact is .13 active sessions, 2.57% of total activity.
    Time spent on the CPU by the instance was responsible for a substantial part
    of database time.
    Recommendation 1: SQL Tuning
    Estimated benefit is .13 active sessions, 2.57% of total activity.
    Finding 10: Top SQL By I/O
    Impact is .11 active sessions, 2.21% of total activity.
    Individual SQL statements responsible for significant user I/O wait were
    found.
    Recommendation 1: SQL Tuning
    Estimated benefit is .11 active sessions, 2.22% of total activity.
    Action
    Run SQL Tuning Advisor on the SQL statement with SQL_ID "b3pnc5yctv2z5".
    Related Object
    SQL statement with SQL_ID b3pnc5yctv2z5.
    INSERT INTO ZX_TRANSACTION_LINES_GT( APPLICATION_ID ,ENTITY_CODE
    ,EVENT_CLASS_CODE ,TRX_ID ,TRX_LEVEL_TYPE ,TRX_LINE_ID ,LINE_CLASS
    ,LINE_LEVEL_ACTION ,TRX_LINE_TYPE ,TRX_LINE_DATE
    ,LINE_AMT_INCLUDES_TAX_FLAG ,LINE_AMT ,TRX_LINE_QUANTITY ,UNIT_PRICE
    ,PRODUCT_ID ,PRODUCT_ORG_ID ,UOM_CODE ,PRODUCT_CODE ,SHIP_TO_PARTY_ID
    ,SHIP_FROM_PARTY_ID ,BILL_TO_PARTY_ID ,BILL_FROM_PARTY_ID
    ,SHIP_FROM_PARTY_SITE_ID ,BILL_FROM_PARTY_SITE_ID
    ,SHIP_TO_LOCATION_ID ,SHIP_FROM_LOCATION_ID ,BILL_TO_LOCATION_ID
    ,SHIP_THIRD_PTY_ACCT_ID ,SHIP_THIRD_PTY_ACCT_SITE_ID ,HISTORICAL_FLAG
    ,TRX_LINE_CURRENCY_CODE ,TRX_LINE_CURRENCY_CONV_DATE
    ,TRX_LINE_CURRENCY_CONV_RATE ,TRX_LINE_CURRENCY_CONV_TYPE
    ,TRX_LINE_MAU ,TRX_LINE_PRECISION ,HISTORICAL_TAX_CODE_ID
    ,TRX_BUSINESS_CATEGORY ,PRODUCT_CATEGORY ,PRODUCT_FISC_CLASSIFICATION
    ,LINE_INTENDED_USE ,PRODUCT_TYPE ,USER_DEFINED_FISC_CLASS
    ,ASSESSABLE_VALUE ,INPUT_TAX_CLASSIFICATION_CODE ,ACCOUNT_CCID
    ,BILL_THIRD_PTY_ACCT_ID ,BILL_THIRD_PTY_ACCT_SITE_ID ,TRX_LINE_NUMBER
    ,TRX_LINE_DESCRIPTION ,PRODUCT_DESCRIPTION ,USER_UPD_DET_FACTORS_FLAG
    ,DEFAULTING_ATTRIBUTE1 ) SELECT :B4 ,:B3 ,:B2
    ,PRL.REQUISITION_HEADER_ID ,:B1 ,PRL.REQUISITION_LINE_ID ,'INVOICE'
    ,NVL(PRL.TAX_ATTRIBUTE_UPDATE_CODE,'UPDATE') ,'ITEM'
    ,NVL(PRL.NEED_BY_DATE, SYSDATE) ,'N' ,NVL(PRL.AMOUNT,
    PRL.UNIT_PRICE*PRL.QUANTITY) ,PRL.QUANTITY ,PRL.UNIT_PRICE
    ,PRL.ITEM_ID ,(SELECT FSP.INVENTORY_ORGANIZATION_ID FROM
    FINANCIALS_SYSTEM_PARAMS_ALL FSP WHERE FSP.ORG_ID=PRL.ORG_ID)
    ,(SELECT MUM.UOM_CODE FROM MTL_UNITS_OF_MEASURE MUM WHERE
    MUM.UNIT_OF_MEASURE=PRL.UNIT_MEAS_LOOKUP_CODE) ,MSIB.SEGMENT1
    ,PRL.DESTINATION_ORGANIZATION_ID ,PV.PARTY_ID ,PRH.ORG_ID
    ,PV.PARTY_ID ,PVS.PARTY_SITE_ID ,PVS.PARTY_SITE_ID
    ,PRL.DELIVER_TO_LOCATION_ID ,(SELECT HZPS.LOCATION_ID FROM
    HZ_PARTY_SITES HZPS WHERE HZPS.PARTY_SITE_ID = PVS.PARTY_SITE_ID)
    ,(SELECT LOCATION_ID FROM HR_ALL_ORGANIZATION_UNITS WHERE
    ORGANIZATION_ID=PRH.ORG_ID) ,PRL.VENDOR_ID ,PRL.VENDOR_SITE_ID ,NULL
    ,NVL(PRL.CURRENCY_CODE, :B9 ) ,NVL2(PRL.CURRENCY_CODE, PRL.RATE_DATE,
    SYSDATE) ,NVL2(PRL.CURRENCY_CODE, PRL.RATE, :B8 )
    ,NVL2(PRL.CURRENCY_CODE, PRL.RATE_TYPE, :B7 )
    ,FC.MINIMUM_ACCOUNTABLE_UNIT ,NVL(FC.PRECISION, 2) ,NULL
    ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
    NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.TRX_BUSINESS_CATEGORY, NULL),
    NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
    NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_CATEGORY, NULL), NULL )
    ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
    NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_FISC_CLASSIFICATION,
    NULL), NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
    NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.LINE_INTENDED_USE, NULL), NULL )
    ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
    NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_TYPE, NULL), NULL )
    ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
    NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.USER_DEFINED_FISC_CLASS, NULL),
    NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
    NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.ASSESSABLE_VALUE, NULL), NULL )
    ,DECODE(:B6 , 'REQIMPORT', PRL.TAX_NAME,
    DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
    NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.INPUT_TAX_CLASSIFICATION_CODE,
    NULL), NULL ) ) ,NVL((SELECT PRD.CODE_COMBINATION_ID FROM
    PO_REQ_DISTRIBUTIONS_ALL PRD WHERE PRD.REQUISITION_LINE_ID =
    PRL.REQUISITION_LINE_ID AND ROWNUM = 1), MSIB.EXPENSE_ACCOUNT )
    ,PV.VENDOR_ID ,PVS.VENDOR_SITE_ID ,PRL.LINE_NUM ,PRL.ITEM_DESCRIPTION
    ,PRL.ITEM_DESCRIPTION ,(SELECT 'Y' FROM DUAL WHERE :B6 = 'REQIMPORT'
    AND PRL.TAX_NAME IS NOT NULL) ,PRL.DESTINATION_ORGANIZATION_ID FROM
    PO_REQUISITION_HEADERS_ALL PRH, PO_REQUISITION_LINES_ALL PRL,
    ZX_LINES_DET_FACTORS ZXLDET, PO_VENDORS PV, PO_VENDOR_SITES_ALL PVS,
    MTL_SYSTEM_ITEMS_B MSIB, FND_CURRENCIES FC WHERE
    PRH.REQUISITION_HEADER_ID = :B5 AND PRH.REQUISITION_HEADER_ID =
    PRL.REQUISITION_HEADER_ID AND ZXLDET.APPLICATION_ID(+) = :B4 AND
    ZXLDET.ENTITY_CODE(+) = :B3 AND ZXLDET.EVENT_CLASS_CODE(+) = :B2 AND
    ZXLDET.TRX_LEVEL_TYPE(+) = :B1 AND ZXLDET.TRX_LINE_ID(+) =
    PRL.PARENT_REQ_LINE_ID AND PV.VENDOR_ID(+) = PRL.VENDOR_ID AND
    PVS.VENDOR_SITE_ID(+) = PRL.VENDOR_SITE_ID AND
    MSIB.INVENTORY_ITEM_ID(+) = PRL.ITEM_ID AND MSIB.ORGANIZATION_ID(+) =
    PRL.ORG_ID AND FC.CURRENCY_CODE(+) = PRL.CURRENCY_CODE AND
    NVL(PRL.MODIFIED_BY_AGENT_FLAG, 'N') = 'N' AND NVL(PRL.CANCEL_FLAG,
    'N') = 'N' AND NVL(PRL.CLOSED_CODE, 'OPEN') <> 'FINALLY CLOSED' AND
    PRL.LINE_LOCATION_ID IS NULL AND PRL.AT_SOURCING_FLAG IS NULL
    Rationale
    SQL statement with SQL_ID "b3pnc5yctv2z5" was executed 3 times and had
    an average elapsed time of 138 seconds.
    Rationale
    Average time spent in User I/O wait events per execution was 137
    seconds.
    Symptoms That Led to the Finding:
    Wait class "User I/O" was consuming significant database time.
    Impact is .7 active sessions, 13.57% of total activity.
    Additional Information
    Miscellaneous Information
    Wait class "Application" was not consuming significant database time.
    Wait class "Network" was not consuming significant database time.
    Session connect and disconnect calls were not consuming significant database
    time.
    The database's maintenance windows were active during 100% of the analysis
    period.
    Regards
    Athish

    Few days are am facing serious of performance problem in our Production instanceFor production issues, please log a SR.
    Was this working before? If yes, any changes been done recently?
    Do you have the statistics collected up to date?
    Please see these docs.
    AutoInvoice Performance Issue When Processing Tax [ID 1059275.1]
    R12 : System Hangs When Attempting To Save Blanket Release After Applying Patch 11817843 [ID 1333336.1]
    Thanks,
    Hussein

  • Socket based application - Performance Issues - Suggestions Needed

    Hi All,
    We have an application which basically has been developed using core java. Here is a high level information about the application:
    a) It opens a serversocket which allows clients to connect to it.
    b) For every new client connection, a separate thread is created and this thread deals with requests from clients, processing the data and replying back to clients.
    c) Each socket is polled continuously and sockettimeout is 2 seconds. If there is a timeout, we handle the situation and socket is again read. So basically sockets is read every 2 seconds. If number of timeouts reaches a configurable value, we close the connection and thread is dropped as well.
    d) In production, three instances of this application are running with the help of a cisco load balancer. It is there for last 5 years.
    However there has always been some minor performance isssues and we have sorted them out using different types of garbage collectors, by introducing hardware load balancers, upgrading the code for new Java versions. It is currently running on 1.4.2.
    However there has always been some performance issues and today while googling over internet I came across following on the bea website which says that core java sockets are not as efficients as native API. BEA has implemented its own APIs for weblogic. My queries are:
    a) Are there any better Java Socket/network API (for solairs, I know Java is plateform independenet but there could be lib which also using native libs) which are much more efficient than Core Java.
    b) We are getting the InputStream/OutputStream and creating objects of DataInputStream/DataOutputStream to read the data 'Byte-By-Byte'. Each byte can have different information thats why it is required. Are there any better way of getting info than what we are currently doing.
    c) As I mentioned, we are continously polling the socket for read operation with a timeout value of 2 seconds. What is the better among the following from performance point of view: (1) Frequent read operation with a lesser timeout value or (2) Less Frequent read operations with larger timeout value. (3) Any better idea??
    Please suggest few things or pointers which I could do to improve the performance of the applcations. Many thanks.
    Thanks,Akhil
    From BEA website:-
    "Although the pure-Java implementation of socket reader threads is a reliable and portable method of peer-to-peer communication, it does not provide the best performance for heavy-duty socket usage in a WebLogic Server cluster. With pure-Java socket readers, threads must actively poll all opened sockets to determine if they contain data to read. In other words, socket reader threads are always "busy" polling sockets, even if the sockets have no data to read. This unnecessary overhead can reduce performance."

    My recommendations:
    - Always use a BufferedInputStream and BufferedOutputStream around the socket streams
    - Increase the socket send and receive buffers to at least 32k if you are on a Windows platform where the default is a ridiculous 8k, which hasn't been enough for about 15 years.
    - Your 2-second timeout is far too short. Increase it to at least 10 seconds.
    - Your strategy of counting up to N short timeouts of S seconds each is completely pointless. Change it to one single timeout of N*S seconds. There is nothing to be gained by the complication you have introduced to this.

  • RE: Case 59063: performance issues w/ C TLIB and Forte3M

    Hi James,
    Could you give me a call, I am at my desk.
    I had meetings all day and couldn't respond to your calls earlier.
    -----Original Message-----
    From: James Min [mailto:jminbrio.forte.com]
    Sent: Thursday, March 30, 2000 2:50 PM
    To: Sharma, Sandeep; Pyatetskiy, Alexander
    Cc: sophiaforte.com; kenlforte.com; Tenerelli, Mike
    Subject: Re: Case 59063: performance issues w/ C TLIB and Forte 3M
    Hello,
    I just want to reiterate that we are very committed to working on
    this issue, and that our goal is to find out the root of the problem. But
    first I'd like to narrow down the avenues by process of elimination.
    Open Cursor is something that is commonly used in today's RDBMS. I
    know that you must test your query in ISQL using some kind of execute
    immediate, but Sybase should be able to handle an open cursor. I was
    wondering if your Sybase expert commented on the fact that the server is
    not responding to commonly used command like 'open cursor'. According to
    our developer, we are merely following the API from Sybase, and open cursor
    is not something that particularly slows down a query for several minutes
    (except maybe the very first time). The logs show that Forte is waiting for
    a status from the DB server. Actually, using prepared statements and open
    cursor ends up being more efficient in the long run.
    Some questions:
    1) Have you tried to do a prepared statement with open cursor in your ISQL
    session? If so, did it have the same slowness?
    2) How big is the table you are querying? How many rows are there? How many
    are returned?
    3) When there is a hang in Forte, is there disk-spinning or CPU usage in
    the database server side? On the Forte side? Absolutely no activity at all?
    We actually have a Sybase set-up here, and if you wish, we could test out
    your database and Forte PEX here. Since your queries seems to be running
    off of only one table, this might be the best option, as we could look at
    everything here, in house. To do this:
    a) BCP out the data into a flat file. (character format to make it portable)
    b) we need a script to create the table and indexes.
    c) the Forte PEX file of the app to test this out.
    d) the SQL staement that you issue in ISQL for comparison.
    If the situation warrants, we can give a concrete example of
    possible errors/bugs to a developer. Dial-in is still an option, but to be
    able to look at the TOOL code, database setup, etc. without the limitations
    of dial-up may be faster and more efficient. Please let me know if you can
    provide this, as well as the answers to the above questions, or if you have
    any questions.
    Regards,
    At 08:05 AM 3/30/00 -0500, Sharma, Sandeep wrote:
    James, Ken:
    FYI, see attached response from our Sybase expert, Dani Sasmita. She has
    already tried what you suggested and results are enclosed.
    ++
    Sandeep
    -----Original Message-----
    From: SASMITA, DANIAR
    Sent: Wednesday, March 29, 2000 6:43 PM
    To: Pyatetskiy, Alexander
    Cc: Sharma, Sandeep; Tenerelli, Mike
    Subject: Re: FW: Case 59063: Select using LIKE has performance
    issues
    w/ CTLIB and Forte 3M
    We did that trick already.
    When it is hanging, I can see what is doing.
    It is doing OPEN CURSOR. But not clear the exact statement of the cursor
    it is trying to open.
    When we run the query directly to Sybase, not using Forte, it is clearly
    not opening any cursor.
    And running it directly to Sybase many times, the response is always
    consistently fast.
    It is just when the query runs from Forte to Sybase, it opens a cursor.
    But again, in the Forte code, Alex is not using any cursor.
    In trying to capture the query,we even tried to audit any statementcoming
    to Sybase. Same thing, just open cursor. No cursor declaration anywhere.==============================================
    James Min
    Technical Support Engineer - Forte Tools
    Sun Microsystems, Inc.
    1800 Harrison St., 17th Fl.
    Oakland, CA 94612
    james.minsun.com
    510.869.2056
    ==============================================
    Support Hotline: 510-451-5400
    CUSTOMERS open a NEW CASE with Technical Support:
    http://www.forte.com/support/case_entry.html
    CUSTOMERS view your cases and enter follow-up transactions:
    http://www.forte.com/support/view_calls.html

    Earthlink wrote:
    Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? Well, we're missing a lot here.
    Like:
    - a database version
    - how did you test
    - what data do you have, how is it distributed, indexed
    and so on.
    If you want to find out what's going on then use a TRACE with wait events.
    All nessecary steps are explained in these threads:
    HOW TO: Post a SQL statement tuning request - template posting
    http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
    Another nice one is RUNSTATS:
    http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701

  • Performance issues with version enable partitioned tables?

    Hi all,
    Are there any known performance issues with version enable partitioned tables?
    I’ve been doing some performance testes with a large version enable partitioned table and it seems that OCB optimiser is choosing very expensive plans during merge operations.
    Tanks in advance,
    Vitor
    Example:
         Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    UPDATE STATEMENT Optimizer Mode=CHOOSE          1          249                    
    UPDATE     SIG.SIG_QUA_IMG_LT                                   
    NESTED LOOPS SEMI          1     266     249                    
    PARTITION RANGE ALL                                   1     9
    TABLE ACCESS FULL     SIG.SIG_QUA_IMG_LT     1     259     2               1     9
    VIEW     SYS.VW_NSO_1     1     7     247                    
    NESTED LOOPS          1     739     247                    
    NESTED LOOPS          1     677     247                    
    NESTED LOOPS          1     412     246                    
    NESTED LOOPS          1     114     244                    
    INDEX RANGE SCAN     WMSYS.MODIFIED_TABLES_PK     1     62     2                    
    INDEX RANGE SCAN     SIG.QIM_PK     1     52     243                    
    TABLE ACCESS BY GLOBAL INDEX ROWID     SIG.SIG_QUA_IMG_LT     1     298     2               ROWID     ROW L
    INDEX RANGE SCAN     SIG.SIG_QUA_IMG_PKI$     1          1                    
    INDEX RANGE SCAN     WMSYS.WM$NEXTVER_TABLE_NV_INDX     1     265     1                    
    INDEX UNIQUE SCAN     WMSYS.MODIFIED_TABLES_PK     1     62                         
    /* Formatted on 2004/04/19 18:57 (Formatter Plus v4.8.0) */                                        
    UPDATE /*+ USE_NL(Z1) ROWID(Z1) */sig.sig_qua_img_lt z1                                        
    SET z1.nextver =                                        
    SYS.ltutil.subsversion                                        
    (z1.nextver,                                        
    SYS.ltutil.getcontainedverinrange (z1.nextver,                                        
    'SIG.SIG_QUA_IMG',                                        
    'NpCyPCX3dkOAHSuBMjGioQ==',                                        
    4574,                                        
    4575                                        
    4574                                        
    WHERE z1.ROWID IN (
    (SELECT /*+ ORDERED USE_NL(T1) USE_NL(T2) USE_NL(J2) USE_NL(J3)
    INDEX(T1 QIM_PK) INDEX(T2 SIG_QUA_IMG_PKI$)
    INDEX(J2 WM$NEXTVER_TABLE_NV_INDX) INDEX(J3 MODIFIED_TABLES_PK) */
    t2.ROWID
    FROM (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
    UNIQUE VERSION
    FROM wmsys.wm$modified_tables
    WHERE table_name = 'SIG.SIG_QUA_IMG'
    AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
    AND VERSION > 4574
    AND VERSION <= 4575) j1,
    sig.sig_qua_img_lt t1,
    sig.sig_qua_img_lt t2,
    wmsys.wm$nextver_table j2,
    (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
    UNIQUE VERSION
    FROM wmsys.wm$modified_tables
    WHERE table_name = 'SIG.SIG_QUA_IMG'
    AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
    AND VERSION > 4574
    AND VERSION <= 4575) j3
    WHERE t1.VERSION = j1.VERSION
    AND t1.ima_id = t2.ima_id
    AND t1.qim_inf_esq_x_tile = t2.qim_inf_esq_x_tile
    AND t1.qim_inf_esq_y_tile = t2.qim_inf_esq_y_tile
    AND t2.nextver != '-1'
    AND t2.nextver = j2.next_vers
    AND j2.VERSION = j3.VERSION))

    Hello Vitor,
    There are currently no known issues with version enabled tables that are partitioned. The merge operation may need to access all of the partitions of a table depending on the data that needs to be moved/copied from the child to the parent. This is the reason for the 'Partition Range All' step in the plan that you provided. The majority of the remaining steps are due to the hints that have been added, since this plan has provided the best performance for us in the past for this particular statement. If this is not the case for you, and you feel that another plan would yield better performance, then please let me know and I will take a look at it.
    One suggestion would be to make sure that the table was been recently analyzed so that the optimizer has the most current data about the table.
    Performance issues are very hard to fix without a reproducible test case, so it may be advisable to file a TAR if you continue to have significant performance issues with the mergeWorkspace operation.
    Thank You,
    Ben

  • Performance issue with brand new intel iMac extreme

    I am at a loss to explain a problem I've been having and I thought I might put it out to you guys.
    In September I purchased a macbook Pro (2.4 ghz, 4 GB RAM) to use in video editing with Final Cut Pro, and for the most part I've been thrilled. I use 1TB LaCie external drives connected via FW800, and perform Multiclip editing with 4-5 video streams at a time and only on occasion have dropped frames during the editing process.
    In December I determined that I needed to have an additional system, and thought a 2.8Ghz Intel iMac extreme would be an excellent choice, since for the same price I could get a little more power in the processor, more hard drive space and a bigger screen to work on. When we picked up the new system in the store (The Grove Apple Store in LA), we had them upgrade the memory to 4GB.
    Since day one we have had performance issues, including problems playing streaming and DVD video, severe delays mounting and unmounting drives (firewire and USB) and application images, and freezing while doing even simple tasks like printing or checking email. These problems occur even while there are no external drives are connected. I have none of these issues with the Macbook Pro, which has virtually an identical set of programs installed, and both running the same version of Leopard.
    I already took the original iMac back to the store, and they exchanged it, but did not have 4GB sets of RAM in stock so they took the RAM from the original machine and put it in the new one. They said if I continued to have problems then it was most likely the RAM and I should come back when they got more in stock. I DID have the same problems with the new machine, and took it back to the Apple Store and they swapped the memory. It seemed to improve the issue, but now I'm seeing the same severe performance issues again.
    All tech support can do is tell me to do a PRAM reset, which seems to improve things very temporarily (but that may be my imagination) or have me restart, which at least has the ability to make the printing of documents capable.
    What I'm wondering is if it is likely that the RAM is the issue and I just got another bad batch, or if the iMac has some weird glitch that isn't present in the macbook Pro...?? Or could I have possibly gotten 2 bad systems in a row? It's extremely frustrating, and I KNOW it shouldn't be this way! It's so bad I get better performance out of my single-core G5 tower! How do I get a good working system that operates like it should? Am I better off getting another Macbook Pro? I'd rather not for several reasons...
    I have xbench on both the MBP and the iMac and can provide test numbers if they'll help, as well as any other info.
    Thank you so much for reading my novella of a post and also for any insight you have!
    Best,
    Travis

    Hi!
    I got the same problem with my MacBook when it still was new in may 2006. It was supposed to be one of the faster Laptops around but it was soooo slow it drove me nuts. I can only advise to have a look if there is something hugging up your RAM and run some tests using these programs on your machine:
    Xbench:
    http://www.macupdate.com/info.php/id/10081
    MenuMeters:
    http://www.macupdate.com/info.php/id/10451
    If they show any unusual results you might have your problem...
    As to my problem with the MacBook: I did a complete re-install (writing the harddisk over with zeroes) and suddenly everything was just fine. (But be sure to back all your files before that, I learned this one the hard way.) I know it is just a standard answer, but it worked out for me this time...
    Hope this helps in some ways.
    Cheers,
    Rene

Maybe you are looking for