Performance issue with pl/sql code

Hi Oracle Gurus,
I am in need of your recommendations for a performance issue that I am facing in production envrionment. There is a pl/sql procedure which executes with different elapsed time at different executions. Elapsed Times are 30minutes , 40 minutes, 65 minutes , 3 minutes ,3 seconds.
Expected elapsed time is maximum of 3 minutes. ( But some times it took 3 seconds too...! )
Output on all different executions are same that is deletion and insertion of 12K records into a table.
Here is the auto trace details of two different scenarios.
Slow execution - 33.65 minutes
Stat Name                                Statement   Per Execution % Snap
Elapsed Time (ms)                         1,712,343    1,712,342.6    41.4
CPU Time (ms)                             1,679,689    1,679,688.6    44.7
Executions                                        1            N/A     N/A
Buffer Gets                              ##########  167,257,973.0    86.9
Disk Reads                                    1,284        1,284.0     0.4
Parse Calls                                       1            1.0     0.0
User I/O Wait Time (ms)                       4,264            N/A     N/A
Cluster Wait Time (ms)                        3,468            N/A     N/A
Application Wait Time (ms)                        0            N/A     N/A
Concurrency Wait Time (ms)                        6            N/A     N/A
Invalidations                                     0            N/A     N/A
Version Count                                     4            N/A     N/A
Sharable Mem(KB)                                 85            N/A     N/A
          -------------------------------------------------------------Fast Exection : 5 seconds
Stat Name                                Statement   Per Execution % Snap
Elapsed Time (ms)                            41,550       41,550.3     0.7
CPU Time (ms)                                40,776       40,776.3     1.0
Executions                                        1            N/A     N/A
Buffer Gets                               2,995,677    2,995,677.0     4.2
Disk Reads                                       22           22.0     0.0
Parse Calls                                       1            1.0     0.0
User I/O Wait Time (ms)                         162            N/A     N/A
Cluster Wait Time (ms)                          621            N/A     N/A
Application Wait Time (ms)                        0            N/A     N/A
Concurrency Wait Time (ms)                       55            N/A     N/A
Invalidations                                     0            N/A     N/A
Version Count                                     4            N/A     N/A
Sharable Mem(KB)                                 85            N/A     N/A
          -------------------------------------------------------------For security reasons, I cannot share the actual code. Its a report generating code that deletes and load the data into table using insert into select statement.
Delete from table ;
cursor X to get the master data ( 98 records )
For each X loop
insert into tableA select * from tables where a= X.a and b= X.b and c=X.c ..... ;
-- 12 K records inserted on average
insert into tableB select * from tables where a= X.a and b= X.b and c=X.c ..... ;
-- 12 K records inserted on average
end loop ;1. The select query is complex with bind variables ( explain plan varies for each values )
2. I have checked the tablespace of the tables involved, it is 82% used. DBA confirmed that it is not the reason.
3. Disk reads are high during long execution.
4. At long running times, I can see a db sequential read wait event on a index object. This index is on the table where data is inserted.
All I need to find is why this code is taking 3 seconds and 60 minutes on the same day and on the consecutive executions ?
Is there any other approach to find the root cause of this behaviour and to fix it ? Kindly adivse.
Thanks in advance your help.
Regards,
Hari
Edited by: BluShadow on 26-Sep-2012 08:24
edited to add {noformat}{noformat} tags.  You've been a member long enough to know to do this yourself... so please do so in future.  ({message:id=9360002})                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

Hariharan ST wrote:
Hi Oracle Gurus,
I am in need of your recommendations for a performance issue that I am facing in production envrionment. There is a pl/sql procedure which executes with different elapsed time at different executions. Please reedit your post and add some code tags around the trace information. This would improve readability greatly and will help us to help you
example
{<b></b>code}
select * from dual;{<b></b>code}
Based upon your description I can imagine two things.
a) The execution plan for the select query does change frequently.
A typical reason can be not up to date statistics.
b) Some locking / wait conflict. For example upon a UK index.
Are there any other operations going on while it is slow? If anybody inserts a value, then your session will wait, if the same (PK/UK) value also is to be inserted.
Those wait events can be recognized using standard tools like oracle sql developer or enterprise manager while the query is slow.
Also go through the links that are in the FAQ. They tell you how to get better information for makeing a tuning request.
SQL and PL/SQL FAQ
Edited by: Sven W. on Sep 25, 2012 6:41 PM

Similar Messages

  • Performance issue with using MAX function in pl/sql

    Hello All,
    We are having a performance issue with the below logic wherein MAX is being used in order to get the latest instance/record for a given input variable ( p_in_header_id).. the item_key is having the format as :
    p_in_header_id - <number generated from a sequence>
    This query to fetch even 1 record takes around 1 minutes 30 sec..could someone please help if there is a better way to form this logic & to improve performance in this case.
    We want to get the latest record for the item_key ( this we are getting using MAX (begin_date)) for a given p_in_header_id value.
    Query 1 :
    SELECT item_key FROM wf_items WHERE item_type = 'xxxxzzzz'
    AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id
    AND root_activity ='START_REQUESTS'
    AND begin_date =
    (SELECT MAX (begin_date) FROM wf_items WHERE item_type = 'xxxxzzzz'
    AND root_activity ='START_REQUESTS'
    AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id);
    Could someone please help us with this performance issue..we are really stuck because of this
    regards

    First of all Thanks to all gentlemen who replied ..many thanks ...
    Tried the ROW_NUMBER() option but still it is taking time...have given output for the query and tkprof results as well. Even when it doesn't fetch any record ( this is a valid cased because the input header id doesn't have any workflow request submitted & hence no entry in the wf_items table)..then also see the time it has taken.
    Looked at the RANK & DENSE_RANK options which were suggested..but it is still taking time..
    Any further suggestions or ideas as to how this could be resolved..
    SELECT 'Y', 'Y', ITEM_KEY
    FROM
    ( SELECT ITEM_KEY, ROW_NUMBER() OVER(ORDER BY BEGIN_DATE DESC) RN FROM
    WF_ITEMS WHERE ITEM_TYPE = 'xxxxzzzz' AND ROOT_ACTIVITY = 'START_REQUESTS'
    AND SUBSTR(ITEM_KEY,1,INSTR(ITEM_KEY,'-') - 1) = :B1
    ) T WHERE RN <= 1
    call count cpu elapsed disk query current rows
    Parse 0 0.00 0.00 0 0 0 0
    Execute 1 0.00 1.57 0 0 0 0
    Fetch 1 8700.00 544968.73 8180 8185 0 0
    total 2 8700.00 544970.30 8180 8185 0 0
    many thanks

  • Performance issues with pipelined table functions

    I am testing pipelined table functions to be able to re-use the <font face="courier">base_query</font> function. 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? The <font face="courier">processor</font> function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
    Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
    Many thanks in advance.
    CREATE OR REPLACE PACKAGE pipeline_example
    IS
       TYPE resultset_typ IS REF CURSOR;
       TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
       TYPE table_typ IS TABLE OF row_typ;
       FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
          RETURN resultset_typ;
       c_default_limit   CONSTANT PLS_INTEGER := 100;  
       FUNCTION processor (
          p_source_data   IN resultset_typ,
          p_limit_size    IN PLS_INTEGER DEFAULT c_default_limit)
          RETURN table_typ
          PIPELINED
          PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
       PROCEDURE with_pipeline (argA          IN     VARCHAR2,
                                argB          IN     VARCHAR2,
                                o_resultset      OUT resultset_typ);
       PROCEDURE no_pipeline (argA          IN     VARCHAR2,
                              argB          IN     VARCHAR2,
                              o_resultset      OUT resultset_typ);
    END pipeline_example;
    CREATE OR REPLACE PACKAGE BODY pipeline_example
    IS
       FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
          RETURN resultset_typ
       IS
          o_resultset   resultset_typ;
       BEGIN
          OPEN o_resultset FOR
             SELECT colC, colD, colE
               FROM some_table
              WHERE colA = ArgA AND colB = argB;
          RETURN o_resultset;
       END base_query;
       FUNCTION processor (
          p_source_data   IN resultset_typ,
          p_limit_size    IN PLS_INTEGER DEFAULT c_default_limit)
          RETURN table_typ
          PIPELINED
          PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
       IS
          aa_source_data   table_typ;-- := table_typ ();
       BEGIN
          LOOP
             FETCH p_source_data
             BULK COLLECT INTO aa_source_data
             LIMIT p_limit_size;
             EXIT WHEN aa_source_data.COUNT = 0;
             /* Process the batch of (p_limit_size) records... */
             FOR i IN 1 .. aa_source_data.COUNT
             LOOP
                PIPE ROW (aa_source_data (i));
             END LOOP;
          END LOOP;
          CLOSE p_source_data;
          RETURN;
       END processor;
       PROCEDURE with_pipeline (argA          IN     VARCHAR2,
                                argB          IN     VARCHAR2,
                                o_resultset      OUT resultset_typ)
       IS
       BEGIN
          OPEN o_resultset FOR
               SELECT /*+ PARALLEL(t, 5) */ colC,
                      SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
                      SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
                      SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
                      SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
                 FROM TABLE (processor (base_query (argA, argB),100)) t
             GROUP BY colC
             ORDER BY colC
       END with_pipeline;
       PROCEDURE no_pipeline (argA          IN     VARCHAR2,
                              argB          IN     VARCHAR2,
                              o_resultset      OUT resultset_typ)
       IS
       BEGIN
          OPEN o_resultset FOR
               SELECT colC,
                      SUM (CASE WHEN colD > colE AND colE  != '0' THEN colD / ColE END)de,
                      SUM (CASE WHEN colE > colD AND colD  != '0' THEN colE / ColD END)ed,
                      SUM (CASE WHEN colD = colE AND colD  != '0' THEN 1 END) de_one,
                      SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
                 FROM (SELECT colC, colD, colE
                         FROM some_table
                        WHERE colA = ArgA AND colB = argB)
             GROUP BY colC
             ORDER BY colC;
       END no_pipeline;
    END pipeline_example;
    ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
    Edited by: Earthlink on Nov 14, 2010 11:31 AM
    Edited by: Earthlink on Nov 14, 2010 11:32 AM
    Edited by: Earthlink on Nov 20, 2010 12:04 PM
    Edited by: Earthlink on Nov 20, 2010 12:54 PM

    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 Bapi BAPI_MATERIAL_AVAILABILITY...

    Hello,
    I have a Z program to check ATP which is working with Bapi BAPI_MATERIAL_AVAILABILITY....
    As I am in the retail system we have performance issues with this bapi due the huge amount of articles in the system we need to calculate the ATP.
    any  way to  improve  the  performance?
    Thanks and best regards
    L

    The BAPI appears to execute for only one plant/material, etc., at a time, so I would have to concentrate on making data retrieval and post-bapi processing as efficient as possible.  In your trace output, how much of your overall time is consumed by the BAPI?  How much by the other code?  You might find improvements there...

  • Performance issues with Spry

    Hi all,
    I'm facing some performance issues with Spry. I'm using it
    for handling a menubar acting as a rollover menu : its color
    changes under mouse cursor, and a submenu does appear at the same
    time.
    I have no problem when working with Firefox, but in IE6, it
    renders too slowly
    Is there something I've missed in the configuration or code
    (or is there some tips for this kind of problem) ?
    For information, I used UL and LI html tags, and I've
    configured Spry to render these as a menubar (with multiple levels)
    Thanks for your response

    Sorry, there are no public access to this application
    :-(

  • Performance issues with Oracle EE 9.2.0.4 and RedHat 2.1

    Hello,
    I am having some serious performance issues with Oracle Enterprise Edition 9.2.0.4 and RedHat Linux 2.1. The processor goes berserk at 100% for long (some 5 min.) periods of time, and all the ram memory gets used.
    Some environment characteristics:
    Machine: Intel Pentium IV 2.0GHz with 1GB of RAM.
    OS: RedHat Linux 2.1 Enterprise.
    Oracle: Oracle Enterprise Edition 9.2.0.4
    Application: We have a small web-application with 10 users (for now) and very basic queries (all in stored procedures). Also we use the latest version of ODP.NET with default connection settings (some low pooling, etc).
    Does anyone know what could be going on?
    Is anybody else having this similar behavior?
    We change from SQL-Server so we are not the world expert on the matter. But we want a reliable system nonetheless.
    Please help us out, gives some tips, tricks, or guides…
    Thanks to all,
    Frank

    Thank you very much and sorry I couldn’t write sooner. It seems that the administrator doesn’t see the kswap going on so much, so I don’t really know what is going on.
    We are looking at some queries and some indexing but this is nuts, if I had some poor queries, which we don’t really, the server would show pick right?
    But he goes crazy and has two oracle processes taking all the resources. There seems to be little swapping going on.
    Son now what? They are all ready talking about MS-SQL please help me out here, this is crazy!!!
    We have, may be the most powerful combinations here. What is oracle doing?
    We even kill the Working Process of the IIS and have no one do anything with the database and still dose two processes going on.
    Can some one help me?
    Thanks,
    Frank

  • Performance issue with view selection after migration from oracle to MaxDb

    Hello,
    After the migration from oracle to MaxDb we have serious performance issues with a lot of our tableview selections.
    Does anybody know about this problem and how to solve it ??
    Best regards !!!
    Gert-Jan

    Hello Gert-Jan,
    most probably you need additional indexes to get better performance.
    Using the command monitor you can identify the long running SQL statements and check the optimizer access strategy. Then you can decide which indexes might help.
    If this is about an SAP system, you can find additional information about performance analysis in SAP notes 725489 and 819641.
    SAP Hosting provides the so-called service 'MaxDB Migration Support' to help you in such cases. The service description can be found here:
    http://www.saphosting.de/mediacenter/pdfs/solutionbriefs/MaxDB_de.pdf
    http://www.saphosting.com/mediacenter/pdfs/solutionbriefs/maxDB-migration-support_en.pdf.
    Best regards,
    Melanie Handreck

  • Performance issue with the ABAP statements

    Hello,
    Please can some help me with the below statements where I am getting performance problem.
    SELECT * FROM /BIC/ASALHDR0100 into Table CHDATE.
    SORT CHDATE by DOC_NUMBER.
    SORT SOURCE_PACKAGE by DOC_NUMBER.
    LOOP AT CHDATE INTO WA_CHDATE.
       READ TABLE SOURCE_PACKAGE INTO WA_CIDATE WITH KEY DOC_NUMBER =
       WA_CHDATE-DOC_NUMBER BINARY SEARCH.
       MOVE WA_CHDATE-CREATEDON  to WA_CIDATE-CREATEDON.
    APPEND WA_CIDATE to CIDATE.
    ENDLOOP.
    I wrote an above code for the follwing requirement.
    1. I have 2 tables from where i am getting the data
    2.I have common fields in both the table names CREATEDON date. In both the tables I hve the values.
    3. While accessing the 2 table and copying to thrid table i have to modify the field.
    I am getting performance issues with the above statements.
    Than
    Edited by: Rob Burbank on Jul 29, 2010 10:06 AM

    Hello,
    try a select like the following one instead of you code.
    SELECT field field2 ...
    INTO TABLE it_table
    FROM table1 AS T1 INNER JOIN table2 AS T2
    ON t1-doc_number = t2-doc_number

  • Performance issue with a Custom view

    Hi ,
    I am pretty new to performance tuning and facing a performance issue with a custom view.
    Execution time for view query is good but as soon as I append a where caluse to view query ,the execution time increases.
    Below is the view query:
    CREATE OR REPLACE XXX_INFO_VIEW AS
    SELECT csb.system_id license_id,
    cst.name license_number ,
    csb.system_type_code license_type ,
    csb.attribute3 lac , -- license authorization code
    csb.attribute6 lat , -- license admin token
    csb.attribute12 ols_reg, -- OLS Registration allowed flag
    l.attribute4 license_biz_type ,
    NVL (( SELECT 'Y' l_supp_flag
    FROM csi_item_instances cii,
    okc_k_lines_b a,
    okc_k_items c
    WHERE c.cle_id = a.id
    AND a.lse_id = 9
    AND c.jtot_object1_code = 'OKX_CUSTPROD'
    AND c.object1_id1 = cii.instance_id||''
    AND cii.instance_status_id IN (3, 510)
    AND cii.system_id = csb.system_id
    AND a.sts_code IN ('SIGNED', 'ACTIVE')
    AND NVL (a.date_terminated, a.end_date) > SYSDATE
    AND ROWNUM < 2), 'N') active_supp_flag,
    hp.party_name "Customer_Name" , -- Customer Name
    hca.attribute12 FGE_FLAG,
    (SELECT /*+INDEX (oklt OKC_K_LINES_TL_U1) */
    nvl(max((decode(name, 'eSupport','2','Enterprise','1','Standard','1','TERM RTU','0','TERM RTS','0','Notfound'))),0) covName --TERM RTU and TERM RTS added as per Vijaya's suggestion APR302013
    FROM OKC_K_LINES_B oklb1,
    OKC_K_LINES_TL oklt,
    OKC_K_LINES_B oklb2,
    OKC_K_ITEMS oki,
    CSI_item_instances cii
    WHERE
    OKI.JTOT_OBJECT1_CODE = 'OKX_CUSTPROD'
    AND oklb1.id=oklt.id
    AND OKI.OBJECT1_ID1 =cii.instance_id||''
    AND Oklb1.lse_id=2
    AND oklb1.dnz_chr_id=oklb2.dnz_chr_id
    AND oklb2.lse_id=9
    AND oki.CLE_ID=oklb2.id
    AND cii.system_id=csb.system_id
    AND oklt.LANGUAGE=USERENV ('LANG')) COVERAGE_TYPE
    FROM csi_systems_b csb ,
    csi_systems_tl cst ,
    hz_cust_accounts hca,
    hz_parties hp,
    fnd_lookup_values l
    WHERE csb.system_type_code = l.lookup_code (+)
    AND csb.system_id = cst.system_id
    AND hca.cust_account_id =csb.customer_id
    AND hca.party_id= hp.party_id
    AND cst.language = USERENV ('LANG')
    AND l.lookup_type (+) = 'CSI_SYSTEM_TYPE'
    AND l.language (+) = USERENV ('LANG')
    AND NVL (csb.end_date_active, SYSDATE+1) > SYSDATE)
    I have forced an index to avoid Full table scan on OKC_K_LINES_TL and suppressed an index on CSI_item_instances.instance id to make the view query fast.
    So when i do select * from XXX_INFO_VIEWit executes in a decent time,But when I try to do
    select * from XXX_INFO_VIEW where active_supp_flag='Y' and coverage_type='1'
    it takes lot of time.
    Execution plan is same for both queries in terms of cost but with WHERE clause Number of bytes increases.
    Below are the execution plans:
    View query:
    SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 536,237 Cardinality: 3,211                                         
         10 COUNT STOPKEY                                    
              9 NESTED LOOPS                               
                   7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1                          
                        5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299                     
                             2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155                
                                  1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315           
                             4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2                
                                  3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2           
                        6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1                     
                   8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1                          
         12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1                                    
              11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1                               
         28 SORT AGGREGATE Bytes: 169 Cardinality: 1                                    
              27 NESTED LOOPS                               
                   25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768                          
                        23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757                     
                             20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578                
                                  17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606           
                                       14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315      
                                            13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                                       16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2      
                                            15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                                  19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1           
                                       18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1      
                             22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10                
                                  21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9           
                        24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1                     
                   26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1                          
         43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211                                    
              41 NESTED LOOPS                               
                   39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196                          
                        37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196                     
                             32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196                
                                  30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17           
                                       29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17      
                                  31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196           
                             36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887                
                                  35 HASH JOIN           
                                       33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887      
                                       34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887      
                        38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1                     
                   40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1                          
              42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918           
    Execution plan for view query with WHERE clause:
    SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211                                         
         10 COUNT STOPKEY                                    
              9 NESTED LOOPS                               
                   7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1                          
                        5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299                     
                             2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155                
                                  1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315           
                             4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2                
                                  3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2           
                        6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1                     
                   8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1                          
         12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1                                    
              11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1                               
         28 SORT AGGREGATE Bytes: 169 Cardinality: 1                                    
              27 NESTED LOOPS                               
                   25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768                          
                        23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757                     
                             20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578                
                                  17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606           
                                       14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315      
                                            13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                                       16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2      
                                            15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                                  19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1           
                                       18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1      
                             22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10                
                                  21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9           
                        24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1                     
                   26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1                          
         44 VIEW VIEW APPS.WRS_LICENSE_INFO_V Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211                                    
              43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211                               
                   41 NESTED LOOPS                          
                        39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196                     
                             37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196                
                                  32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196           
                                       30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17      
                                            29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
                                       31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196      
                                  36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887           
                                       35 HASH JOIN      
                                            33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
                                            34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
                             38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1                
                        40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1                     
                   42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918

    Hi,
    You should always try using primary index fields, if not possible then secondary index fields.
    Even if you cannot do anything from either of the two then try this,
    Use Less distinct fields on the top.
    In your case , you can use bukrs ,gjahr ,werks on the top in the where condition..then followed by less distinct values..
    Even when you use secondary index if you have 4 fields in your sec index and you are using only two fields from the top then the index is useful only upto that two fields provided they are in sequence.

  • Performance issue with BSEG

    Hi,
              I am having serious performance issue due to BSEG table .I am having a change request in which I have to solve the performance issue with regard to BSEG. The situation was that previously they had used select * on both BKPF and BSEG. I removed the select * and selected only those fields which are required as shown below. I also tried using cursors. But the problem is happening in the TEST server where BSEG is having more than 1 crore entries. I have gone through some threads but still not able to understand how to solve this problem. Please help
    select bukrs belnr gjahr bldat bstat from bkpf into table T_BKPF_p
                                                    WHERE BUKRS IN sd_bukrs AND
                                                    BLDAT < s_bldat-low
                                                    and  BSTAT = ' ' .
    select bukrs belnr gjahr shkzg dmbtr hkont from bseg into table T_BSEG_C
                                            FOR ALL ENTRIES IN t_BKPF_p
                                            WHERE BUKRS = T_bkpf_p-bukrs
                                            AND   BELNR = T_bkpf_p-belnr
                                            AND   GJAHR = T_bkpf_p-gjahr
                                            AND   HKONT = SKB1-SAKNR.

    Hi Kunal,
    Here is my take on your issue.
    In your select statement on BKPF you are selecting every BKPF record for a specified company code and blank document status that was created before a specified date. If your company has implemented SAP 10 years ago, and your user enters todays date and leaves the company code field blank you will effectively be retrieving almost all the records from BKPF (excluding the ones created today or those with non-blank document status). This would effectively be a huge amount of data. After that you are looking for the corresponding BSEG records for all the records that you have selected in BKPF.
    My question to you is why do you need to look at all the records before a given date? Why not ask the user to enter a smaller date range and make the document date and the company code a mandatory entry? You do not have to look at 10 years worth of data especially if you are running this online (as opposed to in the background).
    Your BSEG select looks correct. There is very little that you can do except for adding BUZEI to the field list. If you use for all entries and do not include the entire primary key you could lose data.
    TABLES: bkpf,
            skb1.
    SELECT-OPTIONS: s_bldat  FOR bkpf-bldat OBLIGATORY,
                    sd_bukrs FOR bkpf-bukrs OBLIGATORY.
    TYPES: BEGIN OF ty_bkpf,
            bukrs TYPE bkpf-bukrs,
            belnr TYPE bkpf-belnr,
            gjahr TYPE bkpf-gjahr,
            bldat TYPE bkpf-bldat,
            bstat TYPE bkpf-bstat,
          END OF ty_bkpf,
          BEGIN OF ty_bseg,
            bukrs TYPE bseg-bukrs,
            belnr TYPE bseg-belnr,
            gjahr TYPE bseg-gjahr,
            buzei TYPE bseg-buzei,
            shkzg TYPE bseg-shkzg,
            dmbtr TYPE bseg-dmbtr,
            hkont TYPE bseg-hkont,
          END OF ty_bseg.
    DATA: t_bkpf_p TYPE TABLE OF ty_bkpf,
          t_bseg_c TYPE TABLE OF ty_bseg.
    SELECT bukrs
           belnr
           gjahr
           bldat
           bstat
    FROM bkpf
    INTO TABLE t_bkpf_p
    WHERE bukrs IN sd_bukrs
    AND   bldat IN s_bldat
    AND   bstat EQ space .
    IF NOT t_bkpf_p[] IS INITIAL.
      SELECT bukrs
             belnr
             gjahr
             buzei
             shkzg
             dmbtr
             hkont
        FROM bseg
        INTO TABLE t_bseg_c
        FOR ALL ENTRIES IN t_bkpf_p
        WHERE bukrs EQ t_bkpf_p-bukrs
        AND   belnr EQ t_bkpf_p-belnr
        AND   gjahr EQ t_bkpf_p-gjahr
        AND   hkont EQ skb1-saknr.
    ENDIF.

  • Performance Issue with SXMB_MONI

    Hi All,
    I have a typical performance issue with SXMB_MONI, when I trigger this T.code it is taking around 20-24 hrs to execute.
    Here I have found some tables which actually stores these processed xml messages,
    SXMSPFADDRESS
    SXMSPFRAWH
    RSXMB_REMOTE_SERVICE
    SXMSPFAGG
    SXMSCONFVL
    SXMSPMAST
    SXMSPEMAS, SXMSPERROR, SXMSPMAST & SXMSPVERS.
    SXMSPMAST, SXMSPMAST2, SXMSCLUR, SXMSCLUR2,
    SXMSCLUP, SMXSLUP2, SXMSPFRAWH,
    Here I want to increase the performance of sxmb_moni, firstly I want to know from which tables does the sxmb_moni fetches data and more over is it a single table or multiple table.
    And please suggest any technique which can decrease the latency time in executing sxmb_moni.
    Regards,
    Vijay N

    Hi,
    Periodically you need to archive the XI messages, that allows you to maintain sufficient performance level.
    Create archive jobs in SXMB_ADM to archive data which is 15 days old from XI related growing tables like SXMSCLUR, SXMSPEMAS, SXMSPHIST, SXMSPMAST, SXMSPVERS, SXMSPFRAW ,SWWWIHEAD. This archive job created archive files at the OS Level
    For XI tables refer
    /people/gourav.khare2/blog/2007/12/12/interesting-abap-tables-in-xi-150-part-i
    SXMSPMAST, SXMSCLUP, SXMSPCLUR
    the last two are cluster tables
    and you won't get XML messages directly from them
    have a look inside them
    The classes that reads this information in SXMB_MONI are abap classes,
    (can be seen at SE24) it is quite difficult to use them,
    you might debug SXMB_MONI or use SE30 and see all the classes
    that have been used.
    You can use value mapping if you are not looking at picking up values from application system.It is just like SM30 transcation.You can get the info under SAP XI->Design and Configuration->Configuration->Value Mapping.
    Also see the
    these tables,
    /SAPDMC/LSOMAP Field Mapping
    /SAPTRX/SCAOTMAP
    /SAPTRX/SCCNDMAP /SAPTRX/SCEVTMAP
    /SAPTRX/SCFUNMAP /SAPTRX/SCSOMAP
    /people/udo.martens/blog/2006/02/16/own-logging-of-xi-messages
    message-mappings: stored in which database-table?
    sxmb_moni, table sxmspmast, Messages with ICON_LED_RED, report RSXMB_SELECT
    http://help.sap.com/saphelp_nw04s/helpdata/en/44/a1b46c4c686341e10000000a114a6b/frameset.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/ef/45393c3eb3036be10000000a11402f/frameset.htm
    Thanks
    Swarup

  • Performance issue with transaction MC50

    I am not sure where to post this question. If I need to post it in another forum, please let me know.
    We are having performance issues with transaction MC50. After reviewing SAP Note 457615 we created an index on mseg with the following fields:  MANDT, MJAHR, MATNR, WERKS and SOBKZ.
    When running an explain on the sql statement, the database is using a different index. This index has the following fields MANDT, MATNR, WERKS, LGORT, BWART and SOBKZ.
    The sql statement is ( sql trace from ST05):
    SELECT * from mseg WHERE "MANDT" = '400' AND "MJAHR" BETWEEN 2009 AND 2009 AND "MATNR" = '000000000054001121'  AND "WERKS" = 'SAT' AND "SOBKZ" IN ( 'K' , 'V' , 'W' , 'O' , ' ' )
    Is there any way to force the database to use the newly created index.
    Thanks....Tommy
    Edited by: Tommy Knight on Dec 8, 2009 2:24 PM
    Edited by: Tommy Knight on Dec 8, 2009 3:07 PM
    Edited by: Tommy Knight on Dec 8, 2009 3:08 PM

    Hello Tommy,
    at first your database release and patchset is missing.
    If you are using Oracle 10g, the advice of Peter is useless, because of statistics are automatically collected by a CREATE INDEX.
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_5010.htm#i2075657
    COMPUTE STATISTICS
    In earlier releases, you could use this clause to start or stop the collection of statistics on an index. This clause has been deprecated. Oracle Database now automatically collects statistics during index creation and rebuild. This clause is supported for backward compatibility and will not cause errors.
    The other thing is  - are you really sure that this SQL statements was executed with literals?
    I know that on MSEG (with histograms) it is recommended sometimes, but i just want to be sure.
    If you want us to help you - we need much more information .. please check sapnote #1257075 and upload the information to a webhosting platform, so that we can take a look at it.
    Regards
    Stefan

  • Is there a recommended limit on the number of custom sections and the cells per table so that there are no performance issues with the UI?

    Is there a recommended limit on the number of custom sections and the cells per table so that there are no performance issues with the UI?

    Thanks Kelly,
    The answers would be the following:
    1200 cells per custom section (NEW COUNT), and up to 30 custom sections per spec.
    Assuming all will be populated, and this would apply to all final material specs in the system which could be ~25% of all material specs.
    The cells will be numeric, free text, drop downs, and some calculated numeric.
    Are we reaching the limits for UI performance?
    Thanks

  • Performance issues with Homesharing?

    I have a Time Capsule as the base station for my wireless network, then 2 Airport Express setup to extend the network around the house, an iMac i7 as the main iTunes Library and couple of iPads, and a couple of Apple TVs. Everything has the latest software, but I have several performance issues with Home sharing. I've done several tests making sure nothing is taking additional bandwidth, so here are the list of issues:
    1) With nothing else running, trying playing a movie via home sharing in an iPad 2 which is located on my iMac, it stops and I have to keep pressing the play button over and over again. I typically see that the iPad tries to download part of the movie first and then starts playing so that it deals with the bandwidth, but in many cases it doesn't.
    2) When trying to play any iTunes content (movies, music, photos, etc) from my Apple TV I can see my computer library, but when I go in on any of the menus, it says there's no content. I have to reboot the Apple TV and then problem fixed. I's just annoying that I have to reboot.
    3) When watching a Netflix movie on my iPad and with Airplay I send the sound to some speakers via Airplay through an Airport Express. At time I lose the connection to the speakers.
    I've complained about Wifi's instability, but here I tried to keep everything with Apples products to avoid any compatibility issues and stay within N wireless technology, which I understood it was much more stable.
    Has anyone some suggestions?

    Hi,
    you should analyze the db after you have loaded the tables.
    Do you use sequences to generate PKs? Do you have a lot of indexex and/or triggers on the tables?
    If yes:
    make sure your sequence caches (alter sequence s cache 10000)
    Drop all unneeded indexes while loading and disable trigger if possible.
    How big is your Redo Log Buffer? When loading a large amount of data it may be an option to enlarge this buffer.
    Do you have more then one DBWR Process? Writing parallel can speed up things when a checkpoint is needed.
    Is it possible using a direct load? Or do you already direct load?
    Dim

  • Performance issues with the Vouchers index build in SES

    Hi All,
    We are currently performing an upgrade for: PS FSCM 9.1 to PS FSCM 9.2.
    As a part of the upgrade, Client wants Oracle SES to be deployed for some modules including, Purchasing, Payables (Vouchers)
    We are facing severe performance issues with the Vouchers index build. (Volume of data = approx. 8.5 million rows of data)
    The index creation process runs for over 5 days.
    Can you please share any information or issues that you may have faced on your project and how they were addressed?

    Check the following logs for errors:
    1.  The message log from the process scheduler
    2.  search_server1-diagnostic.log  in /search_server1/logs directory
    If the build is getting stuck while crawling then we typically have to increase the Java Heap size for the Weblogic instance for SES>

Maybe you are looking for

  • TV@nywhere & subtitles/closed captioning

    I wonder if there's any way to get WinDVR or any other software app that works with this card to record the subtitles/captions with the mpeg stream? I noticed when I record a tv show, the CC shuts off while its "recording"... this really sucks becaus

  • Application difference between jdic and jdicplus

    Hi, what is difference between jdic and jdicplus.. In my application i used jdic for integrating flash with java. Now i would like to change jdicplus. Is it correct move..? Pl tel the advantages of jdicplus..

  • How can I edit a pdf that opens in preview  w maverick

    With new PAGES app in Maverick, I need to make changes to a pdf document....can't seem to figure out how?  Thanks

  • Responsibilities of APO-DP consultant

    Hi Friends, i am Rajesh,i am new to this forum. Can anyone post me what would be the exact role and responsibilities of APO - DP consultant who is having 6 months to one year experience in DP. I appreciate your answers. thanks and regards, rajesh.

  • 2960G Switch - connected to 4510R - not routing VLAN 40 to VLAN 11 ?

    One of our 2960G switches failed, which we replaced but did not have a current config. Now a user on VLAN 40 cannot access shared drives on VLAN 11 ? I tried the IP ROUTING command on the 2960G but it is not available. Other VLANs 30 and 50 can acces