Performance issue followup transaction Oppty to Quote

hi,
i am facing an issue where whenever a user tries to create a follow-up Quote from an opportunity, it is taking more than 7-8 secs...can someone help me understand its a standard time or ways to reduce the time taken.
we have already implemented SAP's go-live recommendations on basis side of tune up.
thanks
RH

Hi Rh,
If you follow up window opens up with the right document, then your configuation set up is fine. Now kindly check if your internet speed and network is quick enough to support the follow up activity.
Also do u face this problem in any other follow up transaction.
Regards,
Hemanth

Similar Messages

  • 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

  • VA05 Performance issues & search indices

    All,
    We have a performance issue with transaction VA05 (list of sales orders). On searching SAP notes as well as all forums, no information relevant to our case could be found, so posting it here.
    When we run VA05 with selection criteria - customer purchase order number (BSTKD), sales area (VKORG, VTWEG, SPART), the search takes about 5 min or more and times out for some selections. However when I terminate the transaction and rerun it by leaving VTWEG and SPART blank (or VTWEG alone blank), the search is surprisingly quicker - about 5 sec.
    An input from our ABAP expert is that ideally VBKD data (based on BSTKD) should be read first and this data should be further filtered after reading VBAK; however transaction VA05 reads both tables independently, i.e. fetches handful records from VBKD for matching BSTKD and several thousands of records from VBAK (matching VKORG, VTWEG, SPART) and then does an 'intersection'. So it is this VBAK table that seems to cause the performance issue.
    So we updated statistics of both tables, changed the estimate % from 1 to 10 still there is no improvement. What I don't understand is when only BSTKD and VKORG (VKORG is mandatory) are chosen, the search is much quicker though it is the same two tables relevant for search in both cases.  It couldn't have always been this way because this dip in performance is a phenomenon identified only recently.
    Can someone please throw some light on this or advise how performance can be improved with complete sales area in selection? (sales area is required in selection as VA05 is used by different businesses)
    Thanks & Regards,
    KC
    SAP SD Analyst

    >
    Krishna Chandika wrote:
    > All,
    > We have a performance issue with transaction VA05 (list of sales orders). On searching SAP notes as well as all forums, no information relevant to our case could be found, so posting it here.
    What about note 878680?
    If this doesn't help, you should send it to SAP. How can the forum help??
    Rob

  • Performance issue: Adding a new product line to existing Quote calls pricing engine for existing line a well

    Hi All,
    I need some assistance for my below query...
    If there are already existing some product/quote lines on the quote and then we try to add another new product/quote line to this quote , then  it is taking more time to add the product. As per my understanding it is calling the Pricing engine for the existing line as well. How can we avoid the pricing engine call for the existing lines.
    There are some parameters which we are setting as mentioned below :
    l_control_rec.header_pricing_event := 'BATCH' -- What does this mean when we set to batch
    l_control_rec.price_mode := 'ENTIRE_QUOTE'; -- (possible values could be CHANGE_LINES , QUOTE_LINE)
    l_header_rec.pricing_status_indicator := 'C';
    l_control_rec.calculate_freight_charge_flag := 'Y';
    l_control_rec.calculate_tax_flag := 'Y';
    l_header_rec.tax_status_indicator := 'C';
    Question :Could someone please help us with this whether is there any way with these parameters could be altered or changed to some other value ( like for PRICE_MODE we see this parameter could have some other values like : CHANGE_LINES , QUOTE_LINE etc other than ENTIRE_QUOTE).
    means lets say we do the Pricing Engine call only for the Newly Added quote line but not do it for the Entire Quote again and again..
    Now the other question here could be how do we finally synch the line level price values for all the quote lines upto the Quote header level in form of Totals (TOTAL_LIST_PRICE,TOTAL_TAX, TOTAL_SHIPPING_CHARGE, SURCHARGE, TOTAL_QUOTE_PRICE in aso_quote_headers_all table) ??
    Also is there a way that we don't do the Freight Charge calculation and Tax calculation (means we skip this completely) while adding products to the quote but do it at a later point when doing the Submit to Order functionality.
    Could someone please help with these pricing related parameters and modes to be used in order to get around this performance issue
    Thanks
    Mithun

    Dear Expert,
    Activate your Controlling area as usual and Cost Centers and Profit Center , You can assign an internal order for the particular product line for what you are seeing and can collect the costs of that particular product line exclusively.
    Regards,
    Shankar K B

  • Performance issue adding a new product line to existing Quote pricing issue

    Hi All,
    Morning , need some assistance with this as we are currently stuck with this...
    Using the Seeded API call mentioned here : aso_quote_pub.update_quote we are trying to add a new product/item lines to an existing quote in Sales Online Module but it is taking lot of time ( means performance issue is there ).
    Also if there are already existing some product/quote lines on the quote and then we try to add another new product/quote line to this quote , then also it more and more of the time..
    There are some parameters which we are setting as mentioned below :
    l_control_rec.header_pricing_event := 'BATCH' -- What does this mean when we set to batch
    l_control_rec.price_mode := 'ENTIRE_QUOTE'; -- (possible values could be CHANGE_LINES , QUOTE_LINE)
    l_header_rec.pricing_status_indicator := 'C';
    l_control_rec.calculate_freight_charge_flag := 'Y';
    l_control_rec.calculate_tax_flag := 'Y';
    l_header_rec.tax_status_indicator := 'C';
    Question :Could someone please help us with this whether it there any way these parameters could be altered or changed to some other value ( like for PRICE_MODE we see this parameter could have some other values like : CHANGE_LINES , QUOTE_LINE etc other than ENTIRE_QUOTE).
    means lets say we do the Pricing Engine call only for the Newly Added quote line but not do it for the Entire Quote again and again..
    Question : Now the other question here could be how do we finally synch the line level price values for all the quote lines upto the Quote header level in form of Totals (TOTAL_LIST_PRICE,TOTAL_TAX, TOTAL_SHIPPING_CHARGE, SURCHARGE, TOTAL_QUOTE_PRICE in aso_quote_headers_all table) ??
    2.Also is there a way that we don't do the Freight Charge calculation and Tax calculation (means we skip this completely) while adding products to the quote but do it at a later point when doing the Submit to Order functionality.
    Could someone please help with these pricing related parameters and modes to be used in order to get around this performance issue
    Thanks

    Dear Expert,
    Activate your Controlling area as usual and Cost Centers and Profit Center , You can assign an internal order for the particular product line for what you are seeing and can collect the costs of that particular product line exclusively.
    Regards,
    Shankar K B

  • Performance issues while accessing the Confirm/Goods Services' transaction

    Hello
    We are using SRM 4.0 , through Enterprise Portal 7.0.
    Many of our users are crippled by Performance issues when accessing the Confirm/Goods Services tab( Transaction bbpcf02).
    The system simply clocks and would never show the screen.
    This problem occurs for some users all the time, and some users for some time.
    It's not related to the User's machine as others are able to access it fast using the same machine.
    It is also not dependent on the data size (i.e.no . of confirmations created by the user).
    We would like to know why only some users are suffering more pronouncedly, and why is this transaction generally slower than all others.
    Any directions for finding the Probable cause will be highly rewarded.
    Thanks
    Kedar

    Hi Kedar,
    Please go through the following OSS Notes:
    Note 610805 - Performance problems in goods receipt
    Note 885409 - BBPCF02: The search for confirmation and roles is slow
    Note 1258830 - BBPCF02: Display/Process confirmation response time is slow
    Thanks,
    Pradeep

  • Report Performance Issue - Activity

    Hi gurus,
    I'm developing an Activity report using Transactional database (Online real time object).
    the purpose of the report is to list down all contacts related activities and activities NOT related to Contact by activity owner (user id).
    In order to fullfill that requirment I've created 2 report
    1) All Activities related to Contact -- Report A
    pull in Acitivity ID , Activity Type, Status, Contact ID
    2) All Activities not related to Contact UNION All Activities related to Contact (Base report) -- Report B
    to get the list of activities not related to contact i'm using Advanced filter based on result of another request which is I think is the part that slow down the query.
    <Activity ID not equal to any Activity ID in Report B>
    Anyone encountered performance issue due to the advanced filter in analytic before?
    any input is really appriciated
    Thanks in advanced,
    Fina

    Fina,
    Union is always the last option. If you can get all record in one report, do not use union.
    since all records, which you are targeting, are in the activity subject area, it is not nessecery to combine reports. add a column with the following logic
    if contact id is null (or = 'Unspecified') then owner name else contact name
    Hopefully, this is helping.

  • 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 dynamic action (PL/SQL)

    Hi!
    I'm having perfomance issues with a dynamic action that is triggered on a button click.
    I have 5 drop down lists to select columns which the users want to filter, 5 drop down lists to select an operation and 5 boxes to input values.
    After that, there is a filter button that just submits the page based on the selected filters.
    This part works fine, the data is filtered almost instantaneously.
    After this, I have 3 column selectors and 3 boxes where users put values they wish to update the filtered rows to,
    There is an update button that calls the dynamic action (procedure that is written below).
    It should be straight out, the only performance issue could be the decode section, because I need to cover cases when user wants to set a value to null (@) and when he doesn't want update 3 columns, but less (he leaves '').
    Hence P99_X_UC1 || ' = decode('  || P99_X_UV1 ||','''','|| P99_X_UC1  ||',''@'',null,'|| P99_X_UV1  ||')
    However when I finally click the update button, my browser freezes and nothing happens on the table.
    Can anyone help me solve this and improve the speed of the update?
    Regards,
    Ivan
    P.S. The code for the procedure is below:
    create or replace
    PROCEDURE DWP.PROC_UPD
    (P99_X_UC1 in VARCHAR2,
    P99_X_UV1 in VARCHAR2,
    P99_X_UC2 in VARCHAR2,
    P99_X_UV2 in VARCHAR2,
    P99_X_UC3 in VARCHAR2,
    P99_X_UV3 in VARCHAR2,
    P99_X_COL in VARCHAR2,
    P99_X_O in VARCHAR2,
    P99_X_V in VARCHAR2,
    P99_X_COL2 in VARCHAR2,
    P99_X_O2 in VARCHAR2,
    P99_X_V2 in VARCHAR2,
    P99_X_COL3 in VARCHAR2,
    P99_X_O3 in VARCHAR2,
    P99_X_V3 in VARCHAR2,
    P99_X_COL4 in VARCHAR2,
    P99_X_O4 in VARCHAR2,
    P99_X_V4 in VARCHAR2,
    P99_X_COL5 in VARCHAR2,
    P99_X_O5 in VARCHAR2,
    P99_X_V5 in VARCHAR2,
    P99_X_CD in VARCHAR2,
    P99_X_VD in VARCHAR2
    ) IS
    l_sql_stmt varchar2(32600);
    p_table_name varchar2(30) := 'DWP.IZV_SLOG_DET'; 
    BEGIN
    l_sql_stmt := 'update ' || p_table_name || ' set '
    || P99_X_UC1 || ' = decode('  || P99_X_UV1 ||','''','|| P99_X_UC1  ||',''@'',null,'|| P99_X_UV1  ||'),'
    || P99_X_UC2 || ' = decode('  || P99_X_UV2 ||','''','|| P99_X_UC2  ||',''@'',null,'|| P99_X_UV2  ||'),'
    || P99_X_UC3 || ' = decode('  || P99_X_UV3 ||','''','|| P99_X_UC3  ||',''@'',null,'|| P99_X_UV3  ||') where '||
    P99_X_COL  ||' '|| P99_X_O  ||' ' || P99_X_V  || ' and ' ||
    P99_X_COL2 ||' '|| P99_X_O2 ||' ' || P99_X_V2 || ' and ' ||
    P99_X_COL3 ||' '|| P99_X_O3 ||' ' || P99_X_V3 || ' and ' ||
    P99_X_COL4 ||' '|| P99_X_O4 ||' ' || P99_X_V4 || ' and ' ||
    P99_X_COL5 ||' '|| P99_X_O5 ||' ' || P99_X_V5 || ' and ' ||
    P99_X_CD   ||       ' = '         || P99_X_VD ;
    --dbms_output.put_line(l_sql_stmt); 
    EXECUTE IMMEDIATE l_sql_stmt;
    END;

    Hi Ivan,
    I do not think that the decode is performance relevant. Maybe the update hangs because some other transaction has uncommitted changes to one of the affected rows or the where clause is not selective enough and needs to update a huge amount of records.
    Besides that - and I might be wrong, because I only know some part of your app - the code here looks like you have a huge sql injection vulnerability here. Maybe you should consider re-writing your logic in static sql. If that is not possible, you should make sure that the user input only contains allowed values, e.g. by white-listing P99_X_On (i.e. make sure they only contain known values like '=', '<', ...), and by using dbms_assert.enquote_name/enquote_literal on the other P99_X_nnn parameters.
    Regards,
    Christian

  • Performance issues with the Tuxedo MQ Adapter

    We are experimenting some performance issues with the MQ Adapter. For example, we are seeing that the MQ Adapter takes from 10 to 100 ms in reading a single message from the queue and sending to the Tuxedo service. The Tuxedo service takes 80 ms in its execution so there is a considerable waste of time in the MQ adapter that we cannot explain.
    Also, we have looked a lot of rollback transactions on the MQ adapter, for example we got 980 rollback transactions for 15736 transactions sent and only the MQ adapter is involved in the rollback. However, the operations are executed properly. The error we got is
    135027.122.hqtux101!MQI_QMTESX01.7636.1.0: gtrid x0 x4ec1491f x25b59: LIBTUX_CAT:376: ERROR: tpabort: xa_rollback returned XA_RBROLLBACK.
    I am looking for information at Oracle site, but I have not found nothing. Could you or someone from your team help me?

    Hi Todd,
    We have 6 MQI adapters reading from 5 different queues, but in this case we are writing in only one queue.
    Someone from Oracle told us that the XA_RBROLLBACK occurs because we have 6 MQ adapters that are reading from the same queues and when one adapter finds a message and try to get that message, it can occurs that other MQ Adapter gets it before. In this case, the MQ adapter rollbacks the transaction. Even when we got some XA_RBROLLBACK errors, we don´t lose message. Also, I read something about that when XA sends a xa_end call to MQ adapter, it actually does the rollback, so when the MQ adapter receives the xa_rollback call, it answers with XA_RBROLLBACK. Is that true?
    However, I am more worried about the performance. We are putting a request message in a MQ queue and waiting for the reply. In some cases, it takes 150ms and in other cases it takes much more longer (more than 400ms). The average is 300ms. MQ adapter calls a service (txgralms0) which lasts 110ms in average.
    This is our configuration:
    "MQI_QMTESX01" SRVGRP="g03000" SRVID=3000
    CLOPT="-- -C /tuxedo/qt/txqgral00/control/src/MQI_QMTESX01.cfg"
    RQPERM=0600 REPLYQ=N RPPERM=0600 MIN=6 MAX=6 CONV=N
    SYSTEM_ACCESS=FASTPATH
    MAXGEN=1 GRACE=86400 RESTART=N
    MINDISPATCHTHREADS=0 MAXDISPATCHTHREADS=1 THREADSTACKSIZE=0
    SICACHEENTRIESMAX="500"
    /tuxedo/qt/txqgral00/control/src/MQI_QMTESX01.cfg:
    *SERVER
    MINMSGLEVEL=0
    MAXMSGLEVEL=0
    DEFMAXMSGLEN=4096
    TPESVCFAILDATA=Y
    *QUEUE_MANAGER
    LQMID=QMTESX01
    NAME=QMTESX01
    *SERVICE
    NAME=txgralms0
    FORMAT=MQSTR
    TRAN=N
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KGCRQ01
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KGCPQ01
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KPSAQ01
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KPINQ01
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KDECQ01
    Thanks in advance,
    Marling

  • Short dump due to performance issue

    Hi all,
    I am facing performance issue in my sandbox. Below is the content of short dump.
    Short text
        Unable to fulfil request for 805418 bytes of memory space.
    What happened?
        Each transaction requires some main memory space to process
        application data. If the operating system cannot provide any more
        space, the transaction is terminated.
    What can you do?
        Try to find out (e.g. by targetted data selection) whether the
        transaction will run with less main memory.
        If there is a temporary bottleneck, execute the transaction again.
        If the error persists, ask your system administrator to check the
        following profile parameters:
        o  ztta/roll_area            (1.000.000 - 15.000.000)
               Classic roll area per user and internal mode
               usual amount of roll area per user and internal mode
        o  ztta/roll_extension       (10.000.000 - 500.000.000)
               Amount of memory per user in extended memory (EM)
        o  abap/heap_area_total      (100.000.000 - 1.500.000.000)
               Amount of memory (malloc) for all users of an application
               server. If several background processes are running on
               one server, temporary bottlenecks may occur.
    Pls help me to resolve this issue
    Regards,
    Kalyani
    Edited by: kalyani usa on Jan 9, 2008 9:04 PM

    Hi Rob Burbank,
    I am pasting the transaction I found in the dump
    Transaction......... "SESSION_MANAGER "
    Transactions ID..... "4783E5B027A73C1EE10000000A200A17"
    Program............. "SAPMSYST"
    Screen.............. "SAPMSYST 0500"
    Screen line......... 16
    Also i am pasting the screenshot of ST02
    Nametab (NTAB)                                                                                0
      Table definition     99,22     6.799      3.591      62,97    20.000     12.591      62,96       0    8.761
      Field definition     99,06    31.563        345       1,15    20.000     13.305      66,53     244    7.420
      Short NTAB           99,22     3.625      2.590      86,33     5.000      3.586      71,72       0    1.414
      Initial records      52,50     6.625      3.408      56,80     5.000        249       4,98     817    5.568
                                                                                    0
    program                99,58   300.000      1.212       0,42    75.000     67.561      90,08   7.939   46.575
    CUA                    99,08     3.000        211       8,84     1.500      1.375      91,67  23.050      846
    Screen                 99,46     4.297      1.842      45,00     2.000      1.816      90,80      81      963
    Calendar              100,00       488        401      85,14       200        111      55,50       0       89
    OTR                   100,00     4.096      3.281     100,00     2.000      2.000     100,00       0
                                                                                    0
    Tables                                                                                0
      Generic Key          99,69    29.297      2.739       9,87     5.000        177       3,54      57   56.694
      Single record        89,24    10.000         63       0,64       500        468      93,60     241  227.134
                                                                                    0
    Export/import          76,46    50.000     40.980      83,32     2.000                         2.676
    Exp./ Imp. SHM         97,82     4.096      3.094      94,27     2.000      1.999      99,95       0
    SAP Memory      Curr.Use % CurUse[KB] MaxUse[KB] In Mem[KB] OnDisk[KB] SAPCurCach HitRatio %
    Roll area            0,16        432     18.672    131.072    131.072   IDs           98,11
    Page area            0,19        496    187.616     65.536    196.608   Statement     95,00
    Extended memory      9,89    151.552  1.531.904  1.531.904          0                  0,00
    Heap memory                        0          0  1.953.045          0  
      0,00
    Regards,
    Kalyani

  • Many-to-many performance issue

    I realize that many-to-many joins have been discussed before (yes, I looked through many threads), but I'm having a slight variation on the issue. Our data warehouse has been functioning for a couple of years now, but we're now experiencing a dramatic degradation in report performance. I'll tell you everything I know and what I've tried. My hope is that someone will have an idea that hasn't occurred to me yet.
    The troubling data links deal with accounts and account_types. Each transaction will have one account, but each account can have multiple account_types and each account_type is made up of multiple accounts. It ends up looking like this:
    Transaction_cube --< account_dimension >--< account_type_table
    Given the many-to-many relationship between account and account_type, this is the only architecture I could come up with that will maintain data integrity in the transaction cube.
    I know that this is the cause of the performance issues because the reports run normally when this is removed. The volume of data obviously increases over time, but the problem appeared very suddenly -- not a gradual degradation that one would expect from a volume issue. The cube is partitioned by year and we're a little below last year's growth.
    The other fact to throw in is that the account_type table did increase in size by an additional 30% when we first noticed the problem. However, the business was able to go back and remove half of the account_types (unused types) so now the table has fewer rows than it had before we noticed the problem (~15k rows in the account_type table).
    We have tried pinning the table so that it remain in memory, but that did not help. I tried creating a materialized view combining accounts and account_types with a similar lack of improvement. I've tried adding indexes, but there is still a full-table scan. All database objects are analyzed nightly after the data load is completed.
    I'm fresh out of ideas at this point. Any suggestions and/or ideas would be greatly appreciated.

    I've thought about that. What it would mean would be aprox. 20 additional columns for each of the different account_types. Unfortunately, that would also mean that all the reports that use the account_type would have to have a condition:
    WHERE acct_type1='Income Stmt." OR acct_type2='Income Stmt." OR ....
    Since the account_types are not set up in a hierarchy and there must be only one row for account, I'm not sure that this is a feasible solution.
    Thank you for the suggestion.

  • QUERY PERFORMANCE AND DATA LOADING PERFORMANCE ISSUES

    WHAT ARE  QUERY PERFORMANCE ISSUES WE NEED TO TAKE CARE PLEASE EXPLAIN AND LET ME KNOW T CODES...PLZ URGENT
    WHAT ARE DATALOADING PERFORMANCE ISSUES  WE NEED TO TAKE CARE PLEASE EXPLAIN AND LET ME KNOW T CODES PLZ URGENT
    WILL REWARD FULL POINT S
    REGARDS
    GURU

    BW Back end
    Some Tips -
    1)Identify long-running extraction processes on the source system. Extraction processes are performed by several extraction jobs running on the source system. The run-time of these jobs affects the performance. Use transaction code SM37 — Background Processing Job Management — to analyze the run-times of these jobs. If the run-time of data collection jobs lasts for several hours, schedule these jobs to run more frequently. This way, less data is written into update tables for each run and extraction performance increases.
    2)Identify high run-times for ABAP code, especially for user exits. The quality of any custom ABAP programs used in data extraction affects the extraction performance. Use transaction code SE30 — ABAP/4 Run-time Analysis — and then run the analysis for the transaction code RSA3 — Extractor Checker. The system then records the activities of the extraction program so you can review them to identify time-consuming activities. Eliminate those long-running activities or substitute them with alternative program logic.
    3)Identify expensive SQL statements. If database run-time is high for extraction jobs, use transaction code ST05 — Performance Trace. On this screen, select ALEREMOTE user and then select SQL trace to record the SQL statements. Identify the time-consuming sections from the results. If the data-selection times are high on a particular SQL statement, index the DataSource tables to increase the performance of selection (see no. 6 below). While using ST05, make sure that no other extraction job is running with ALEREMOTE user.
    4)Balance loads by distributing processes onto different servers if possible. If your site uses more than one BW application server, distribute the extraction processes to different servers using transaction code SM59 — Maintain RFC Destination. Load balancing is possible only if the extraction program allows the option
    5)Set optimum parameters for data-packet size. Packet size affects the number of data requests to the database. Set the data-packet size to optimum values for an efficient data-extraction mechanism. To find the optimum value, start with a packet size in the range of 50,000 to 100,000 and gradually increase it. At some point, you will reach the threshold at which increasing packet size further does not provide any performance increase. To set the packet size, use transaction code SBIW — BW IMG Menu — on the source system. To set the data load parameters for flat-file uploads, use transaction code RSCUSTV6 in BW.
    6)Build indexes on DataSource tables based on selection criteria. Indexing DataSource tables improves the extraction performance, because it reduces the read times of those tables.
    7)Execute collection jobs in parallel. Like the Business Content extractors, generic extractors have a number of collection jobs to retrieve relevant data from DataSource tables. Scheduling these collection jobs to run in parallel reduces the total extraction time, and they can be scheduled via transaction code SM37 in the source system.
    8). Break up your data selections for InfoPackages and schedule the portions to run in parallel. This parallel upload mechanism sends different portions of the data to BW at the same time, and as a result the total upload time is reduced. You can schedule InfoPackages in the Administrator Workbench.
    You can upload data from a data target (InfoCube and ODS) to another data target within the BW system. While uploading, you can schedule more than one InfoPackage with different selection options in each one. For example, fiscal year or fiscal year period can be used as selection options. Avoid using parallel uploads for high volumes of data if hardware resources are constrained. Each InfoPacket uses one background process (if scheduled to run in the background) or dialog process (if scheduled to run online) of the application server, and too many processes could overwhelm a slow server.
    9). Building secondary indexes on the tables for the selection fields optimizes these tables for reading, reducing extraction time. If your selection fields are not key fields on the table, primary indexes are not much of a help when accessing data. In this case it is better to create secondary indexes with selection fields on the associated table using ABAP Dictionary to improve better selection performance.
    10)Analyze upload times to the PSA and identify long-running uploads. When you extract the data using PSA method, data is written into PSA tables in the BW system. If your data is on the order of tens of millions, consider partitioning these PSA tables for better performance, but pay attention to the partition sizes. Partitioning PSA tables improves data-load performance because it's faster to insert data into smaller database tables. Partitioning also provides increased performance for maintenance of PSA tables — for example, you can delete a portion of data faster. You can set the size of each partition in the PSA parameters screen, in transaction code SPRO or RSCUSTV6, so that BW creates a new partition automatically when a threshold value is reached.
    11)Debug any routines in the transfer and update rules and eliminate single selects from the routines. Using single selects in custom ABAP routines for selecting data from database tables reduces performance considerably. It is better to use buffers and array operations. When you use buffers or array operations, the system reads data from the database tables and stores it in the memory for manipulation, improving performance. If you do not use buffers or array operations, the whole reading process is performed on the database with many table accesses, and performance deteriorates. Also, extensive use of library transformations in the ABAP code reduces performance; since these transformations are not compiled in advance, they are carried out during run-time.
    12)Before uploading a high volume of transaction data into InfoCubes, activate the number-range buffer for dimension IDs. The number-range buffer is a parameter that identifies the number of sequential dimension IDs stored in the memory. If you increase the number range before high-volume data upload, you reduce the number of reads from the dimension tables and hence increase the upload performance. Do not forget to set the number-range values back to their original values after the upload. Use transaction code SNRO to maintain the number range buffer values for InfoCubes.
    13)Drop the indexes before uploading high-volume data into InfoCubes. Regenerate them after the upload. Indexes on InfoCubes are optimized for reading data from the InfoCubes. If the indexes exist during the upload, BW reads the indexes and tries to insert the records according to the indexes, resulting in poor upload performance. You can automate the dropping and regeneration of the indexes through InfoPackage scheduling. You can drop indexes in the Manage InfoCube screen in the Administrator Workbench.
    14)IDoc (intermediate document) archiving improves the extraction and loading performance and can be applied on both BW and R/3 systems. In addition to IDoc archiving, data archiving is available for InfoCubes and ODS objects.
    Hope it Helps
    Chetan
    @CP..

  • Performance issue showing read by other session Event

    Hi All,
    we are having a severe performance issue in my database when we are running batch jobs.
    This was a new database(11.2.0.2) and we are testing the performance by running some batch jobs. These batch jobs included some inserts and updates.
    I am seeing read by other session in top 5 timed events and cache buffers chains in Latch Miss Sources section.
    Please help me to solve this out.
    Inst Num Startup Time    Release     RAC
    1 27-Feb-12 09:03 11.2.0.2.0  NO
    Platform                         CPUs Cores Sockets Memory(GB)
    Linux x86 64-bit                    8     8       8      48.00           
    Snap Id      Snap Time      Sessions Curs/Sess
    Begin Snap:      5605 29-Feb-12 03:00:27        63       4.5
      End Snap:      5614 29-Feb-12 12:00:47        63       4.3
       Elapsed:              540.32 (mins)
       DB Time:            1,774.23 (mins)
    Cache Sizes                       Begin        End
    ~~~~~~~~~~~                  ---------- ----------
                   Buffer Cache:     1,952M     1,952M  Std Block Size:        16K
               Shared Pool Size:     1,024M     1,024M      Log Buffer:    18,868K
    Load Profile              Per Second    Per Transaction   Per Exec   Per Call
    ~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
          DB Time(s):                3.3                0.8       0.02       0.05
           DB CPU(s):                1.1                0.3       0.01       0.02
           Redo size:           55,763.8           13,849.3
       Logical reads:           23,906.6            5,937.4
       Block changes:              325.7               80.9
      Physical reads:              665.6              165.3
    Physical writes:               40.4               10.0
          User calls:               60.7               15.1
              Parses:               10.6                2.6
         Hard parses:                1.1                0.3
    W/A MB processed:                0.6                0.2
              Logons:                0.1                0.0
            Executes:              151.2               37.6
           Rollbacks:                0.0                0.0
        Transactions:                4.0
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:   99.94       Redo NoWait %:  100.00
                Buffer  Hit   %:   97.90    In-memory Sort %:  100.00
                Library Hit   %:   98.06        Soft Parse %:   90.16
             Execute to Parse %:   92.96         Latch Hit %:  100.00
    Parse CPU to Parse Elapsd %:   76.71     % Non-Parse CPU:   98.57
    Shared Pool Statistics        Begin    End
                 Memory Usage %:   89.38   87.96
        % SQL with executions>1:   97.14   95.15
      % Memory for SQL w/exec>1:   96.05   92.46
    Top 5 Timed Foreground Events
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                               Avg
                                                              wait   % DB
    Event                                 Waits     Time(s)   (ms)   time Wait Class
    db file sequential read          14,092,706      65,613      5   61.6 User I/O
    DB CPU                                           34,819          32.7
    read by other session               308,534       1,260      4    1.2 User I/O
    direct path read                     97,454         987     10     .9 User I/O
    db file scattered read               71,870         910     13     .9 User I/O
    Host CPU (CPUs:    8 Cores:    8 Sockets:    8)
    ~~~~~~~~         Load Average
                   Begin       End     %User   %System      %WIO     %Idle
                    0.43      0.36      13.7       0.6       9.7      85.7
    Instance CPU
    ~~~~~~~~~~~~
                  % of total CPU for Instance:      13.5
                  % of busy  CPU for Instance:      94.2
      %DB time waiting for CPU - Resource Mgr:       0.0
    Memory Statistics
    ~~~~~~~~~~~~~~~~~                       Begin          End
                      Host Mem (MB):     49,152.0     49,152.0
                       SGA use (MB):      3,072.0      3,072.0
                       PGA use (MB):        506.5        629.1
        % Host Mem used for SGA+PGA:         7.28         7.53
    Time Model Statistics             
    -> Total time in database user-calls (DB Time): 106453.8s
    -> Statistics including the word "background" measure background process
       time, and so do not contribute to the DB time statistic
    -> Ordered by % or DB time desc, Statistic name
    Statistic Name                                       Time (s) % of DB Time
    sql execute elapsed time                            105,531.1         99.1
    DB CPU                                               34,818.8         32.7
    parse time elapsed                                      714.7           .7
    hard parse elapsed time                                 684.8           .6
    PL/SQL execution elapsed time                           161.9           .2
    PL/SQL compilation elapsed time                          44.2           .0
    connection management call elapsed time                  16.9           .0
    hard parse (sharing criteria) elapsed time               10.2           .0
    hard parse (bind mismatch) elapsed time                   9.4           .0
    sequence load elapsed time                                2.9           .0
    repeated bind elapsed time                                0.5           .0
    failed parse elapsed time                                 0.0           .0
    DB time                                             106,453.8
    background elapsed time                               1,753.9
    background cpu time                                      61.7
    Operating System Statistics        
    -> *TIME statistic values are diffed.
       All others display actual values.  End Value is displayed if different
    -> ordered by statistic type (CPU Use, Virtual Memory, Hardware Config), Name
    Statistic                                  Value        End Value
    BUSY_TIME                              3,704,415
    IDLE_TIME                             22,203,740
    IOWAIT_TIME                            2,517,864
    NICE_TIME                                      3
    SYS_TIME                                 145,696
    USER_TIME                              3,557,758
    LOAD                                           0                0
    RSRC_MGR_CPU_WAIT_TIME                         0
    VM_IN_BYTES                      358,813,045,760
    VM_OUT_BYTES                      29,514,830,848
    PHYSICAL_MEMORY_BYTES             51,539,607,552
    NUM_CPUS                                       8
    NUM_CPU_CORES                                  8
    NUM_CPU_SOCKETS                                8
    GLOBAL_RECEIVE_SIZE_MAX                4,194,304
    GLOBAL_SEND_SIZE_MAX                   1,048,586
    TCP_RECEIVE_SIZE_DEFAULT                  87,380
    TCP_RECEIVE_SIZE_MAX                   4,194,304
    TCP_RECEIVE_SIZE_MIN                       4,096
    TCP_SEND_SIZE_DEFAULT                     16,384
    TCP_SEND_SIZE_MAX                      4,194,304
    TCP_SEND_SIZE_MIN                          4,096
    Operating System Statistics -
    Snap Time           Load    %busy    %user     %sys    %idle  %iowait
    29-Feb 03:00:27      0.4      N/A      N/A      N/A      N/A      N/A
    29-Feb 04:00:35      1.4     11.9     11.2      0.6     88.1     14.3
    29-Feb 05:00:41      1.7     13.8     13.2      0.6     86.2     15.8
    29-Feb 06:00:48      1.5     14.0     13.5      0.6     86.0     12.3
    29-Feb 07:01:00      1.8     16.3     15.8      0.5     83.7     10.4
    29-Feb 08:00:12      2.6     23.2     22.5      0.6     76.8     12.6
    29-Feb 09:00:26      1.3     16.6     16.0      0.5     83.4      5.7
    29-Feb 10:00:33      1.2     13.8     13.3      0.5     86.2      2.0
    29-Feb 11:00:43      1.3     14.5     14.0      0.5     85.5      3.8
    29-Feb 12:00:47      0.4      4.9      4.2      0.7     95.1     10.6
    Foreground Wait Class              
    -> s  - second, ms - millisecond -    1000th of a second
    -> ordered by wait time desc, waits desc
    -> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
    -> Captured Time accounts for         97.9%  of Total DB time     106,453.79 (s)
    -> Total FG Wait Time:            69,415.64 (s)  DB CPU time:      34,818.79 (s)
                                                                      Avg
                                          %Time       Total Wait     wait
    Wait Class                      Waits -outs         Time (s)     (ms)  %DB time
    User I/O                   14,693,843     0           69,222        5      65.0
    DB CPU                                                34,819               32.7
    Commit                         40,629     0              119        3       0.1
    System I/O                     26,504     0               57        2       0.1
    Network                     1,945,010     0               11        0       0.0
    Other                         125,200    99                4        0       0.0
    Application                     2,673     0                2        1       0.0
    Concurrency                     3,059     0                1        0       0.0
    Configuration                      31    19                0       15       0.0
    Foreground Wait Events            
    -> s  - second, ms - millisecond -    1000th of a second
    -> Only events with Total Wait Time (s) >= .001 are shown
    -> ordered by wait time desc, waits desc (idle events last)
    -> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
                                                                 Avg
                                            %Time Total Wait    wait    Waits   % DB
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    db file sequential read      14,092,706     0     65,613       5    108.0   61.6
    read by other session           308,534     0      1,260       4      2.4    1.2
    direct path read                 97,454     0        987      10      0.7     .9
    db file scattered read           71,870     0        910      13      0.6     .9
    db file parallel read            35,001     0        372      11      0.3     .3
    log file sync                    40,629     0        119       3      0.3     .1
    control file sequential re       26,504     0         57       2      0.2     .1
    direct path read temp            14,499     0         49       3      0.1     .0
    direct path write temp            9,186     0         28       3      0.1     .0
    SQL*Net message to client     1,923,973     0          5       0     14.7     .0
    SQL*Net message from dblin        1,056     0          5       5      0.0     .0
    Disk file operations I/O          8,848     0          2       0      0.1     .0
    ASM file metadata operatio           36     0          2      54      0.0     .0
    SQL*Net break/reset to cli        2,636     0          1       1      0.0     .0
    ADR block file read                 472     0          1       1      0.0     .0
    os thread startup                     8     0          1      74      0.0     .0
    SQL*Net more data to clien       17,656     0          1       0      0.1     .0
    asynch descriptor resize        123,852   100          0       0      0.9     .0
    local write wait                    110     0          0       4      0.0     .0
    utl_file I/O                     55,635     0          0       0      0.4     .0
    log file switch (private s            8     0          0      52      0.0     .0
    cursor: pin S wait on X               2     0          0     142      0.0     .0
    enq: KO - fast object chec           13     0          0      20      0.0     .0
    PX Deq: Slave Session Stat          248     0          0       1      0.0     .0
    enq: RO - fast object reus           18     0          0      11      0.0     .0
    latch: cache buffers chain        2,511     0          0       0      0.0     .0
    latch: shared pool                  195     0          0       1      0.0     .0
    CSS initialization                   12     0          0       8      0.0     .0
    PX qref latch                        54   100          0       2      0.0     .0
    SQL*Net more data from cli          995     0          0       0      0.0     .0
    SQL*Net more data from dbl          300     0          0       0      0.0     .0
    kksfbc child completion               1   100          0      56      0.0     .0
    library cache: mutex X              244     0          0       0      0.0     .0
    PX Deq: Signal ACK RSG              124     0          0       0      0.0     .0
    undo segment extension                6   100          0       7      0.0     .0
    PX Deq: Signal ACK EXT              124     0          0       0      0.0     .0
    library cache load lock               3     0          0       9      0.0     .0
    ADR block file write                 45     0          0       1      0.0     .0
    CSS operation: action                12     0          0       2      0.0     .0
    reliable message                     28     0          0       1      0.0     .0
    CSS operation: query                 72     0          0       0      0.0     .0
    latch: row cache objects             14     0          0       1      0.0     .0
    enq: SQ - contention                 17     0          0       0      0.0     .0
    latch free                           32     0          0       0      0.0     .0
    buffer busy waits                    52     0          0       0      0.0     .0
    enq: PS - contention                 16     0          0       0      0.0     .0
    enq: TX - row lock content            6     0          0       1      0.0     .0
    SQL*Net message to dblink         1,018     0          0       0      0.0     .0
    cursor: pin S                        23     0          0       0      0.0     .0
    latch: cache buffers lru c            8     0          0       0      0.0     .0
    SQL*Net message from clien    1,923,970     0    944,508     491     14.7
    jobq slave wait                  66,732   100     33,334     500      0.5
    Streams AQ: waiting for me        6,481   100     32,412    5001      0.0
    wait for unread message on       32,858    98     32,411     986      0.3
    PX Deq: Execution Msg             1,448     0        190     131      0.0
    PX Deq: Execute Reply             1,196     0         74      62      0.0
    HS message to agent                 228     0          4      19      0.0
    single-task message                  42     0          4      97      0.0
    PX Deq Credit: send blkd            904     0          2       3      0.0
    PX Deq Credit: need buffer          205     0          1       3      0.0
    Foreground Wait Events            
    -> s  - second, ms - millisecond -    1000th of a second
    -> Only events with Total Wait Time (s) >= .001 are shown
    -> ordered by wait time desc, waits desc (idle events last)
    -> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
                                                                 Avg
                                            %Time Total Wait    wait    Waits   % DB
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    PX Deq: Table Q Normal            4,291     0          1       0      0.0
    PX Deq: Join ACK                    124     0          0       1      0.0
    PX Deq: Parse Reply                 124     0          0       0      0.0
    KSV master wait                     256     0          0       0      0.0
    Latch Miss Sources                
    -> only latches with sleeps are shown
    -> ordered by name, sleeps desc
                                                         NoWait              Waiter
    Latch Name               Where                       Misses     Sleeps   Sleeps
    ASM map operation freeli kffmTranslate2                   0          2        0
    DML lock allocation      ktadmc                           0          2        0
    FOB s.o list latch       ksfd_allfob                      0          2        2
    In memory undo latch     ktiFlushMe                       0          5        0
    In memory undo latch     ktichg: child                    0          3        0
    PC and Classifier lists  No latch                         0          6        0
    Real-time plan statistic keswxAddNewPlanEntry             0         20       20
    SQL memory manager worka qesmmIRegisterWorkArea:1         0          1        1
    active service list      kswslogon: session logout        0         23       12
    active service list      kswssetsvc: PX session swi       0          6        1
    active service list      kswsite: service iterator        0          1        0
    archive process latch    kcrrgpll                         0          3        3
    cache buffers chains     kcbgtcr_2                        0      1,746      573
    cache buffers chains     kcbgtcr: fast path (cr pin       0      1,024    2,126
    cache buffers chains     kcbgcur_2                        0         60        8
    cache buffers chains     kcbchg1: kslbegin: bufs no       0         16        3
    cache buffers chains     kcbgtcr: fast path               0         14       20
    cache buffers chains     kcbzibmlt: multi-block rea       0         10        0
    cache buffers chains     kcbrls_2                         0          9       53
    cache buffers chains     kcbgtcr: kslbegin shared         0          8        1
    cache buffers chains     kcbrls_1                         0          7       84
    cache buffers chains     kcbgtcr: kslbegin excl           0          6       14
    cache buffers chains     kcbnew: new latch again          0          6        0
    cache buffers chains     kcbzgb: scan from tail. no       0          6        0
    cache buffers chains     kcbzwb                           0          5        8
    cache buffers chains     kcbgcur: fast path (shr)         0          3        0
    cache buffers chains     kcbget: pin buffer               0          3        0
    cache buffers chains     kcbzhngcbk2_1                    0          1        0
    cache buffers lru chain  kcbzgws                          0         19        0
    cache buffers lru chain  kcbo_link_q                      0          3        0
    call allocation          ksuxds                           0         14       10
    call allocation          ksudlp: top call                 0          2        3
    enqueue hash chains      ksqgtl3                          0          2        1
    enqueue hash chains      ksqrcl                           0          1        2
    enqueues                 ksqgel: create enqueue           0          1        0
    object queue header oper kcbo_unlink_q                    0          5        2
    object queue header oper kcbo_sw_buf                      0          2        0
    object queue header oper kcbo_link_q                      0          1        2
    object queue header oper kcbo_switch_cq                   0          1        2
    object queue header oper kcbo_switch_mq_bg                0          1        4
    parallel query alloc buf kxfpbalo                         0          1        1
    process allocation       ksucrp:1                         0          2        0
    process queue reference  kxfpqrsnd                        0          1        0
    qmn task queue latch     kwqmnmvtsks: delay to read       0          1        0
    redo allocation          kcrfw_redo_gen: redo alloc       0         17        0
    row cache objects        kqreqd: reget                    0          6        0
    row cache objects        kqrpre: find obj                 0          6       13
    row cache objects        kqrso                            0          2        0
    row cache objects        kqreqd                           0          1        2
    row cache objects        kqrpre: init complete            0          1        1
    shared pool              kghalo                           0        199      106
    shared pool              kghupr1                          0         39      109
    shared pool              kghfre                           0         18       19
    shared pool              kghalp                           0          7       29
    space background task la ktsj_grab_task                   0         21       27
    Mutex Sleep Summary                
    -> ordered by number of sleeps desc
                                                                             Wait
    Mutex Type            Location                               Sleeps    Time (ms)
    Library Cache         kglhdgn2 106                              338           12
    Library Cache         kgllkc1   57                              259           10
    Library Cache         kgllkdl1  85                              123           21
    Cursor Pin            kkslce [KKSCHLPIN2]                        70          286
    Library Cache         kglget2   2                                31            1
    Library Cache         kglhdgn1  62                               31            2
    Library Cache         kglpin1   4                                26            1
    Library Cache         kglpnal1  90                               18            0
    Library Cache         kglpndl1  95                               15            2
    Library Cache         kgllldl2 112                                6            0
    Library Cache         kglini1   32                                1            0
              -------------------------------------------------------------Thanks in advance.

    Hi,
    Thanks for reply.
    I provided one hour report.
    Inst Num Startup Time    Release     RAC
    1 27-Feb-12 09:03 11.2.0.2.0  NO
      Platform                         CPUs Cores Sockets Memory(GB)
    Linux x86 64-bit                    8     8       8      48.00
                  Snap Id      Snap Time      Sessions Curs/Sess
    Begin Snap:      5606 29-Feb-12 04:00:35        63       3.7
      End Snap:      5607 29-Feb-12 05:00:41        63       3.6
       Elapsed:               60.11 (mins)
       DB Time:              382.67 (mins)
    Cache Sizes                       Begin        End
    ~~~~~~~~~~~                  ---------- ----------
                   Buffer Cache:     1,952M     1,952M  Std Block Size:        16K
               Shared Pool Size:     1,024M     1,024M      Log Buffer:    18,868K
    Load Profile              Per Second    Per Transaction   Per Exec   Per Call
    ~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
          DB Time(s):                6.4                0.8       0.03       0.03
           DB CPU(s):                1.0                0.1       0.00       0.00
           Redo size:           84,539.3           10,425.6
       Logical reads:           23,345.6            2,879.1
       Block changes:              386.5               47.7
      Physical reads:            1,605.0              197.9
    Physical writes:                7.1                0.9
          User calls:              233.9               28.9
              Parses:                4.0                0.5
         Hard parses:                0.1                0.0
    W/A MB processed:                0.1                0.0
              Logons:                0.1                0.0
            Executes:              210.9               26.0
           Rollbacks:                0.0                0.0
        Transactions:                8.1
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:   99.62       Redo NoWait %:  100.00
                Buffer  Hit   %:   95.57    In-memory Sort %:  100.00
                Library Hit   %:   99.90        Soft Parse %:   98.68
             Execute to Parse %:   98.10         Latch Hit %:   99.99
    Parse CPU to Parse Elapsd %:   32.08     % Non-Parse CPU:   99.90
    Shared Pool Statistics        Begin    End
                 Memory Usage %:   89.25   89.45
        % SQL with executions>1:   96.79   97.52
      % Memory for SQL w/exec>1:   95.67   96.56
    Top 5 Timed Foreground Events
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                               Avg
                                                              wait   % DB
    Event                                 Waits     Time(s)   (ms)   time Wait Class
    db file sequential read           3,054,464      17,002      6   74.0 User I/O
    DB CPU                                            3,748          16.3
    read by other session               199,603         796      4    3.5 User I/O
    direct path read                     46,301         439      9    1.9 User I/O
    db file scattered read               21,113         269     13    1.2 User I/O
    Host CPU (CPUs:    8 Cores:    8 Sockets:    8)
    ~~~~~~~~         Load Average
                   Begin       End     %User   %System      %WIO     %Idle
                    1.45      1.67      13.2       0.6      15.8      86.2
    Instance CPU
    ~~~~~~~~~~~~
                  % of total CPU for Instance:      13.0
                  % of busy  CPU for Instance:      94.7
      %DB time waiting for CPU - Resource Mgr:       0.0
    Memory Statistics
    ~~~~~~~~~~~~~~~~~                       Begin          End
                      Host Mem (MB):     49,152.0     49,152.0
                       SGA use (MB):      3,072.0      3,072.0
                       PGA use (MB):        513.5        467.7
        % Host Mem used for SGA+PGA:         7.29         7.20
    Time Model Statistics            
    -> Total time in database user-calls (DB Time): 22960.5s
    -> Statistics including the word "background" measure background process
       time, and so do not contribute to the DB time statistic
    -> Ordered by % or DB time desc, Statistic name
    Statistic Name                                       Time (s) % of DB Time
    sql execute elapsed time                             22,835.9         99.5
    DB CPU                                                3,748.4         16.3
    parse time elapsed                                       15.4           .1
    hard parse elapsed time                                  14.3           .1
    PL/SQL execution elapsed time                             7.5           .0
    PL/SQL compilation elapsed time                           6.0           .0
    connection management call elapsed time                   1.6           .0
    sequence load elapsed time                                0.4           .0
    hard parse (sharing criteria) elapsed time                0.0           .0
    repeated bind elapsed time                                0.0           .0
    failed parse elapsed time                                 0.0           .0
    DB time                                              22,960.5
    background elapsed time                                 238.1
    background cpu time                                       4.9
    Operating System Statistics        
    -> *TIME statistic values are diffed.
       All others display actual values.  End Value is displayed if different
    -> ordered by statistic type (CPU Use, Virtual Memory, Hardware Config), Name
    Statistic                                  Value        End Value
    BUSY_TIME                                396,506
    IDLE_TIME                              2,483,725
    IOWAIT_TIME                              455,495
    NICE_TIME                                      0
    SYS_TIME                                  16,163
    USER_TIME                                380,052
    LOAD                                           1                2
    RSRC_MGR_CPU_WAIT_TIME                         0
    VM_IN_BYTES                       95,646,943,232
    VM_OUT_BYTES                       1,686,059,008
    PHYSICAL_MEMORY_BYTES             51,539,607,552
    NUM_CPUS                                       8
    NUM_CPU_CORES                                  8
    NUM_CPU_SOCKETS                                8
    GLOBAL_RECEIVE_SIZE_MAX                4,194,304
    GLOBAL_SEND_SIZE_MAX                   1,048,586
    TCP_RECEIVE_SIZE_DEFAULT                  87,380
    TCP_RECEIVE_SIZE_MAX                   4,194,304
    TCP_RECEIVE_SIZE_MIN                       4,096
    TCP_SEND_SIZE_DEFAULT                     16,384
    TCP_SEND_SIZE_MAX                      4,194,304
    TCP_SEND_SIZE_MIN                          4,096
    Operating System Statistics -
    Snap Time           Load    %busy    %user     %sys    %idle  %iowait
    29-Feb 04:00:35      1.4      N/A      N/A      N/A      N/A      N/A
    29-Feb 05:00:41      1.7     13.8     13.2      0.6     86.2     15.8
    Foreground Wait Class              
    -> s  - second, ms - millisecond -    1000th of a second
    -> ordered by wait time desc, waits desc
    -> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
    -> Captured Time accounts for         97.6%  of Total DB time      22,960.46 (s)
    -> Total FG Wait Time:            18,651.75 (s)  DB CPU time:       3,748.35 (s)
                                                                      Avg
                                          %Time       Total Wait     wait
    Wait Class                      Waits -outs         Time (s)     (ms)  %DB time
    User I/O                    3,327,253     0           18,576        6      80.9
    DB CPU                                                 3,748               16.3
    Commit                         23,882     0               69        3       0.3
    System I/O                      1,035     0                3        3       0.0
    Network                       842,393     0                2        0       0.0
    Other                          10,120    99                0        0       0.0
    Configuration                       3     0                0       58       0.0
    Application                       264     0                0        1       0.0
    Concurrency                     1,482     0                0        0       0.0
    Foreground Wait Events            
    -> s  - second, ms - millisecond -    1000th of a second
    -> Only events with Total Wait Time (s) >= .001 are shown
    -> ordered by wait time desc, waits desc (idle events last)
    -> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
                                                                 Avg
                                            %Time Total Wait    wait    Waits   % DB
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    db file sequential read       3,054,464     0     17,002       6    104.5   74.0
    read by other session           199,603     0        796       4      6.8    3.5
    direct path read                 46,301     0        439       9      1.6    1.9
    db file scattered read           21,113     0        269      13      0.7    1.2
    log file sync                    23,882     0         69       3      0.8     .3
    db file parallel read             4,727     0         68      14      0.2     .3
    control file sequential re        1,035     0          3       3      0.0     .0
    SQL*Net message to client       840,792     0          2       0     28.8     .0
    direct path read temp                95     0          2      18      0.0     .0
    local write wait                     79     0          0       4      0.0     .0
    Disk file operations I/O            870     0          0       0      0.0     .0
    ASM file metadata operatio            4     0          0      50      0.0     .0
    log file switch (private s            3     0          0      58      0.0     .0
    ADR block file read                  36     0          0       3      0.0     .0
    enq: RO - fast object reus            5     0          0      16      0.0     .0
    latch: cache buffers chain        1,465     0          0       0      0.1     .0
    SQL*Net break/reset to cli          256     0          0       0      0.0     .0
    asynch descriptor resize         10,059   100          0       0      0.3     .0
    SQL*Net more data to clien        1,510     0          0       0      0.1     .0
    enq: KO - fast object chec            3     0          0       8      0.0     .0
    SQL*Net more data from cli           91     0          0       0      0.0     .0
    latch: shared pool                   14     0          0       0      0.0     .0
    ADR block file write                  5     0          0       1      0.0     .0
    reliable message                      8     0          0       0      0.0     .0
    direct path write temp                1     0          0       2      0.0     .0
    SQL*Net message from clien      840,794     0     68,885      82     28.8
    jobq slave wait                   7,365   100      3,679     499      0.3
    Streams AQ: waiting for me          721   100      3,605    5000      0.0
    wait for unread message on        3,648    98      3,603     988      0.1
    KSV master wait                      20     0          0       0      0.0
    Background Wait Events            
    -> ordered by wait time desc, waits desc (idle events last)
    -> Only events with Total Wait Time (s) >= .001 are shown
    -> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
                                                                 Avg
                                            %Time Total Wait    wait    Waits   % bg
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    log file parallel write          29,353     0         83       3      1.0   34.8
    db file parallel write            5,753     0         17       3      0.2    6.9
    db file sequential read           1,638     0         15       9      0.1    6.1
    control file sequential re        5,142     0         13       2      0.2    5.4
    os thread startup                   140     0          8      58      0.0    3.4
    control file parallel writ        1,440     0          8       6      0.0    3.4
    log file sequential read            304     0          8      26      0.0    3.3
    db file scattered read              214     0          2       9      0.0     .8
    ASM file metadata operatio        1,199     0          1       1      0.0     .3
    direct path write                    35     0          0       6      0.0     .1
    direct path read                     41     0          0       5      0.0     .1
    kfk: async disk IO                    6     0          0       9      0.0     .0
    Disk file operations I/O          1,266     0          0       0      0.0     .0
    ADR block file read                  16     0          0       2      0.0     .0
    read by other session                 3     0          0       8      0.0     .0
    Log archive I/O                       2     0          0      10      0.0     .0
    log file sync                         3     0          0       5      0.0     .0
    asynch descriptor resize            341   100          0       0      0.0     .0
    CSS initialization                    1     0          0       6      0.0     .0
    log file single write                 4     0          0       1      0.0     .0
    latch: redo allocation                3     0          0       1      0.0     .0
    ADR block file write                  5     0          0       1      0.0     .0
    LGWR wait for redo copy              45     0          0       0      0.0     .0
    CSS operation: query                  6     0          0       0      0.0     .0
    CSS operation: action                 1     0          0       1      0.0     .0
    SQL*Net message to client           420     0          0       0      0.0     .0
    rdbms ipc message                47,816    39     61,046    1277      1.6
    DIAG idle wait                    7,200   100      7,200    1000      0.2
    Space Manager: slave idle         1,146    98      5,674    4951      0.0
    class slave wait                    284     0      3,983   14026      0.0
    dispatcher timer                     61   100      3,660   60006      0.0
    Streams AQ: qmn coordinato          258    50      3,613   14003      0.0
    Streams AQ: qmn slave idle          130     0      3,613   27789      0.0
    Streams AQ: waiting for ti            7    71      3,608  515430      0.0
    wait for unread message on        3,605   100      3,606    1000      0.1
    pmon timer                        1,201   100      3,604    3001      0.0
    smon timer                           15    73      3,603  240207      0.0
    ASM background timer                754     0      3,602    4777      0.0
    shared server idle wait             120   100      3,601   30006      0.0
    SQL*Net message from clien          554     0          4       7      0.0
    KSV master wait                     101     0          0       2      0.0
    Wait Event Histogram              
    -> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
    -> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
    -> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
    -> Ordered by Event (idle events last)
                                                        % of Waits
                               Total
    Event                      Waits  <1ms  <2ms  <4ms  <8ms <16ms <32ms  <=1s   >1s
    ADR block file read           52  73.1   1.9   9.6  13.5               1.9
    ADR block file write          10 100.0
    ADR file lock                 12 100.0
    ARCH wait for archivelog l     3 100.0
    ASM file metadata operatio  1203  97.3    .5    .7    .3    .2          .9
    CSS initialization             1                   100.0
    CSS operation: action          1       100.0
    CSS operation: query           6  83.3  16.7
    Disk file operations I/O    2118  95.4   4.5    .1
    LGWR wait for redo copy       45 100.0
    Log archive I/O                2                         100.0
    SQL*Net break/reset to cli   256  99.6    .4
    SQL*Net message to client  839.9 100.0    .0
    SQL*Net more data from cli    91 100.0
    SQL*Net more data to clien  1503 100.0
    asynch descriptor resize   10.4K 100.0
    buffer busy waits              2 100.0
    control file parallel writ  1440   5.7  35.1  24.0  16.3  12.0   5.5   1.5
    control file sequential re  6177  69.4   7.5   5.9   8.1   7.1   1.7    .3
    db file parallel read       4727   1.7   3.2   3.2  10.1  46.6  33.3   1.8
    db file parallel write      5755  42.3  21.3  18.6  11.2   4.6   1.4    .5
    db file scattered read     21.5K   8.4   4.3  11.9  18.9  26.3  25.3   4.9
    db file sequential read    3053.  28.7  15.1  11.1  17.9  21.5   5.4    .3    .0
    direct path read           46.3K   9.9   8.8  18.5  21.7  22.8  15.7   2.7
    direct path read temp         95               9.5   9.5  23.2  49.5   8.4
    direct path write             35  11.4  31.4  17.1  22.9  11.4   2.9   2.9
    direct path write temp         1       100.0
    enq: KO - fast object chec     3                    66.7  33.3
    enq: RO - fast object reus     5  20.0              20.0  20.0  20.0  20.0
    kfk: async disk IO             6  50.0  16.7              16.7        16.7
    latch free                     3 100.0
    latch: cache buffers chain  1465 100.0
    latch: cache buffers lru c     1 100.0
    latch: object queue header     2 100.0
    latch: redo allocation         3  33.3  33.3  33.3
    latch: row cache objects       2 100.0
    latch: shared pool            15  93.3   6.7
    local write wait              79        35.4  34.2  21.5   8.9
    log file parallel write    29.4K  47.8  21.7  11.9   9.9   6.8   1.6    .3
    log file sequential read     304   6.3   3.0   3.6  10.2  23.4  24.3  29.3
    log file single write          4  25.0  75.0
    log file switch (private s     3                                     100.0
    log file sync              23.9K  40.9  28.0  12.9   9.7   6.7   1.5    .3
    os thread startup            140                                     100.0
    read by other session      199.6  37.1  19.9  12.9  13.1  13.8   3.1    .2
    reliable message               8 100.0
    ASM background timer         755   2.9    .4    .1    .1    .3    .1    .3  95.8
    DIAG idle wait              7196                                     100.0
    KSV master wait              121  88.4   2.5   3.3   2.5    .8    .8   1.7
    SQL*Net message from clien 840.1  97.1   1.8    .5    .2    .2    .1    .0    .1
    Space Manager: slave idle   1147    .1                                  .5  99.4
    Streams AQ: qmn coordinato   258  49.6                .4                    50.0
    Streams AQ: qmn slave idle   130    .8                                      99.2
    Streams AQ: waiting for me   721                                           100.0
    Streams AQ: waiting for ti     7  28.6                                42.9  28.6
    class slave wait             283  39.9   2.5   2.5   3.5   4.9   9.2  15.2  22.3
    dispatcher timer              60                                           100.0
    jobq slave wait             7360    .0    .0    .0                    99.9
    pmon timer                  1201                                           100.0
    rdbms ipc message          47.8K   2.7  31.6  17.4   1.1   1.1    .9  20.9  24.3
    Wait Event Histogram               DB/Inst: I2KPROD/I2KPROD  Snaps: 5606-5607
    -> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
    -> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
    -> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
    -> Ordered by Event (idle events last)
                                                        % of Waits
                               Total
    Event                      Waits  <1ms  <2ms  <4ms  <8ms <16ms <32ms  <=1s   >1s
    shared server idle wait      120                                           100.0
    smon timer                    16                                       6.3  93.8
    wait for unread message on  7250                                  .1  99.9
    Latch Miss Sources                
    -> only latches with sleeps are shown
    -> ordered by name, sleeps desc
                                                         NoWait              Waiter
    Latch Name               Where                       Misses     Sleeps   Sleeps
    In memory undo latch     ktichg: child                    0          1        0
    active service list      kswslogon: session logout        0          2        0
    cache buffers chains     kcbgtcr_2                        0      1,123      483
    cache buffers chains     kcbgtcr: fast path (cr pin       0        496    1,131
    cache buffers chains     kcbrls_2                         0          5        6
    cache buffers chains     kcbgcur_2                        0          4        0
    cache buffers chains     kcbgtcr: fast path               0          3        1
    cache buffers chains     kcbzwb                           0          2        4
    cache buffers chains     kcbchg1: kslbegin: bufs no       0          1        0
    cache buffers chains     kcbnew: new latch again          0          1        0
    cache buffers chains     kcbrls_1                         0          1        6
    cache buffers chains     kcbzgb: scan from tail. no       0          1        0
    cache buffers lru chain  kcbzgws                          0          1        0
    object queue header oper kcbo_switch_cq                   0          1        0
    object queue header oper kcbo_switch_mq_bg                0          1        2
    redo allocation          kcrfw_redo_gen: redo alloc       0          3        0
    row cache objects        kqrpre: find obj                 0          1        1
    row cache objects        kqrso                            0          1        0
    shared pool              kghalo                           0         13        3
    shared pool              kghupr1                          0          4       15
    shared pool              kghalp                           0          1        0
    space background task la ktsj_grab_task                   0          2        2
              -------------------------------------------------------------

  • Performance Issue Executing a BEx Query in Crystal Report E 4.0

    Dear Forum
    I'm working for a customer with big performance issue Executing a BEx Query in Crystal via transient universe.
    When query is executed directly against BW via RSRT query returns results in under 2 seconds.
    When executed in crystal, without the use of subreports multiple executions (calls to BICS_GET_RESULTS) are seen. Runtimes are as long as 60 seconds.
    The Bex query is based on a multiprovider without ODS.
    The RFC trace shows BICS connection problems, CS as BICS_PROV_GET_INITIAL_STATE takes a lot of time.
    I checked the note 1399816 - Task name - prefix - RSDRP_EXECUTE_AT_QUERY_DISP, and itu2019s not applicable because the customer has the BI 7.01 SP 8 and it has already
                domain RSDR0_TASKNAME_LONG in package RSDRC with the
                description: 'BW Data Manager: Task name - 32 characters', data
                type: CHAR; No. Characters: 32, decimal digits: 0
                data element RSDR0_TASKNAME_LONG in package RSDRC with the
                description 'BW Data Manager: Task name - 32 characters' and the
                previously created domain.
    as described on the message
    Could you suggest me something to check, please?
    Thanks en advance
    Regards
    Rosa

    Hi,
    It would be great if you would quote the ADAPT and tell the audience when it is targetted for a fix.
    Generally speaking, CR for Enteprise  isn't as performant as WebI,  because uptake was rather slow .. so i'm of the opinion that there is improvements to be gained.   So please work with Support via OSS.
    My onlt recommendations can be :
    - Patch up to P2.12 in bi 4.0
    -  Define more default values on the Bex query variables.
    - Implement this note in the BW 1593802    Performance optimization when loading query views 
    Regards,
    H

Maybe you are looking for