"3.x Analyzer Server" EVENT taking more Time when Executing Query

Hi All,
When I am Executing the Query Through RSRT   taking more time. When I have checked the statistics
and observed that "3.x Analyzer Server" EVENT taking more Time .
What I have to do , How I will reduce this 3.x Analyzer Server EVENT time.
Please Suggest me.
Thanks,
Kiran Manyam

Hello,
Chk this on query performance:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ce7fb368-0601-0010-64ba-fadc985a1f94
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/4c0ab590-0201-0010-bd9a-8332d8b4f09c
Query Performance
Reg,
Dhanya

Similar Messages

  • Query is taking more time to execute

    Hi,
    Query is taking more time to execute.
    But when i execute same query in other server then it is giving immediate output.
    What is the reason of it.
    thanks in advance.

    'My car doesn't start, please help me to start my car'
    Do you think we are clairvoyant?
    Or is your salary subtracted for every letter you type here?
    Please be aware this is not a chatroom, and we can not see your webcam.
    Sybrand Bakker
    Senior Oracle DBA

  • Query is taking more time to execute in PROD

    Hi All,
    Can anyone tell me why this query is taking more time when I am using for single trx_number record it is working fine but when I am trying to use all the records it is not fatching any records and it is keep on running.
    SELECT DISTINCT OOH.HEADER_ID
    ,OOH.ORG_ID
    ,ct.CUSTOMER_TRX_ID
    ,ool.ship_from_org_id
    ,ct.trx_number IDP_SHIPMENT_ID
    ,ctt.type STATUS_CODE
    ,SYSDATE STATUS_DATE
    ,ooh.attribute16 IDP_ORDER_NBR --Change based on testing on 21-JUL-2010 in UAT
    ,lpad(rac_bill.account_number,6,0) IDP_BILL_TO_CUSTOMER_NBR
    ,rac_bill.orig_system_reference
    ,rac_ship_party.party_name SHIP_TO_NAME
    ,raa_ship_loc.address1 SHIP_TO_ADDR1
    ,raa_ship_loc.address2 SHIP_TO_ADDR2
    ,raa_ship_loc.address3 SHIP_TO_ADDR3
    ,raa_ship_loc.address4 SHIP_TO_ADDR4
    ,raa_ship_loc.city SHIP_TO_CITY
    ,NVL(raa_ship_loc.state,raa_ship_loc.province) SHIP_TO_STATE
    ,raa_ship_loc.country SHIP_TO_COUNTRY_NAME
    ,raa_ship_loc.postal_code SHIP_TO_ZIP
    ,ooh.CUST_PO_NUMBER CUSTOMER_ORDER_NBR
    ,ooh.creation_date CUSTOMER_ORDER_DATE
    ,ool.actual_shipment_date DATE_SHIPPED
    ,DECODE(mp.organization_code,'CHP', 'CHESAPEAKE'
    ,'CSB', 'CHESAPEAKE'
    ,'DEP', 'CHESAPEAKE'
    ,'CHESAPEAKE') SHIPPED_FROM_LOCATION --'MEMPHIS' --'HOUSTON'
    ,ooh.freight_carrier_code FREIGHT_CARRIER
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)
    + NVL(XX_FSG_NA_FASTRAQ_IFACE.get_line_fr_amt ('FREIGHT',ct.customer_trx_id,ct.org_id),0)FREIGHT_CHARGE
    ,ooh.freight_terms_code FREIGHT_TERMS
    ,'' IDP_BILL_OF_LADING
    ,(SELECT WAYBILL
    FROM WSH_DELIVERY_DETAILS_OE_V
    WHERE -1=-1
    AND SOURCE_HEADER_ID = ooh.header_id
    AND SOURCE_LINE_ID = ool.line_id
    AND ROWNUM =1) WAYBILL_CARRIER
    ,'' CONTAINERS
    ,ct.trx_number INVOICE_NBR
    ,ct.trx_date INVOICE_DATE
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('LINE',ct.customer_trx_id,ct.org_id),0) +
    NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) +
    NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)INVOICE_AMOUNT
    ,NULL IDP_TAX_IDENTIFICATION_NBR
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) TAX_AMOUNT_1
    ,NULL TAX_DESC_1
    ,NULL TAX_AMOUNT_2
    ,NULL TAX_DESC_2
    ,rt.name PAYMENT_TERMS
    ,NULL RELATED_INVOICE_NBR
    ,'Y' INVOICE_PRINT_FLAG
    FROM ra_customer_trx_all ct
    ,ra_cust_trx_types_all ctt
    ,hz_cust_accounts rac_ship
    ,hz_cust_accounts rac_bill
    ,hz_parties rac_ship_party
    ,hz_locations raa_ship_loc
    ,hz_party_sites raa_ship_ps
    ,hz_cust_acct_sites_all raa_ship
    ,hz_cust_site_uses_all su_ship
    ,ra_customer_trx_lines_all rctl
    ,oe_order_lines_all ool
    ,oe_order_headers_all ooh
    ,mtl_parameters mp
    ,ra_terms rt
    ,OE_ORDER_SOURCES oos
    ,XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V
    WHERE ct.cust_trx_type_id = ctt.cust_trx_type_id
    AND ctt.TYPE <> 'BR'
    AND ct.org_id = ctt.org_id
    AND ct.ship_to_customer_id = rac_ship.cust_account_id
    AND ct.bill_to_customer_id = rac_bill.cust_account_id
    AND rac_ship.party_id = rac_ship_party.party_id
    AND su_ship.cust_acct_site_id = raa_ship.cust_acct_site_id
    AND raa_ship.party_site_id = raa_ship_ps.party_site_id
    AND raa_ship_loc.location_id = raa_ship_ps.location_id
    AND ct.ship_to_site_use_id = su_ship.site_use_id
    AND su_ship.org_id = ct.org_id
    AND raa_ship.org_id = ct.org_id
    AND ct.customer_trx_id = rctl.customer_trx_id
    AND ct.org_id = rctl.org_id
    AND rctl.interface_line_attribute6 = to_char(ool.line_id)
    AND rctl.org_id = ool.org_id
    AND ool.header_id = ooh.header_id
    AND ool.org_id = ooh.org_id
    AND mp.organization_id = ool.ship_from_org_id
    AND ooh.payment_term_id = rt.term_id
    AND xla_ael_sl_v.last_update_date >= NVL(p_last_update_date,xla_ael_sl_v.last_update_date)
    AND ooh.order_source_id = oos.order_source_id --Change based on testing on 19-May-2010
    AND oos.name = 'FASTRAQ' --Change based on testing on 19-May-2010
    AND ooh.org_id = g_org_id --Change based on testing on 19-May-2010
    AND ool.flow_status_code = 'CLOSED'
    AND xla_ael_sl_v.trx_hdr_id = ct.customer_trx_id
    AND trx_hdr_table = 'CT'
    AND xla_ael_sl_v.gl_transfer_status = 'Y'
    AND xla_ael_sl_v.accounted_dr IS NOT NULL
    AND xla_ael_sl_v.org_id = ct.org_id;
    -- AND ct.trx_number = '2000080';
    }

    Hello Friend,
    You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
    1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
    and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
    First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
    Please check the possbility of finding it through other AR tables.
    2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
    For example : For ra_cust_trx_types_all use ra_cust_trx_types.
    This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
    3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
    You can also check the same using
    SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
    If the tables are not analyzed , the CBO will not be able to tune your query.
    4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
    5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
    report.
    Thanks,
    Neeraj Shrivastava
    [email protected]
    Edited by: user9352949 on Oct 1, 2010 8:02 PM
    Edited by: user9352949 on Oct 1, 2010 8:03 PM

  • Stopping a Query taking more time to execute in runtime in Oracle Forms.

    Hi,
    In the present application one of the oracle form screen is taking long time to execute a query, user wanted an option to stop the query in between and browse the result (whatever has been fetched before stopping the query).
    We have tried three approach.
    1. set max fetch record in form and block level.
    2. set max fetch time in form and block level.
    in above two method does not provide the appropiate solution for us.
    3. the third approach we applied is setting the interaction mode to "NON BLOCKING" at the form level.
    It seems to be worked, while the query took long time to execute, oracle app server prompts an message to press Esc to cancel the query and it a displaying the results fetched upto that point.
    But the drawback is one pressing esc, its killing the session itself. which is causing the entire application to collapse.
    Please suggest if there is any alternative approach for this or how to overcome this perticular scenario.
    This kind of facility is alreday present in TOAD and PL/SQL developer where we can stop an executing query and browse the results fetched upto that point, is the similar facility is avialable in oracle forms ,please suggest.
    Thanks and Regards,
    Suraj
    Edited by: user10673131 on Jun 25, 2009 4:55 AM

    Hello Friend,
    You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
    1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
    and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
    First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
    Please check the possbility of finding it through other AR tables.
    2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
    For example : For ra_cust_trx_types_all use ra_cust_trx_types.
    This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
    3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
    You can also check the same using
    SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
    If the tables are not analyzed , the CBO will not be able to tune your query.
    4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
    5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
    report.
    Thanks,
    Neeraj Shrivastava
    [email protected]
    Edited by: user9352949 on Oct 1, 2010 8:02 PM
    Edited by: user9352949 on Oct 1, 2010 8:03 PM

  • Quesry taking more time to execute

    Dear All,
    User complained that his query is taking more time than yesterday and DB performance is also very slow, so what would be your strategy to check and fix the problem.
    What could be the right approach to check and fix this.
    Regards,
    DevD!
    Edited by: user12138514 on Nov 8, 2009 9:35 PM

    And here is the cause list for slow performance:
    Slow Network connection.
    Bad Connection management.
    Bad Use of Cursors and the Shared Pool
    Bad SQL or Query is not perfectly tune or not using bind variables.
    Use of nonstandard initialization parameters.
    Getting Database I/O Wrong
    Redo Log Setup Problems
    Serialization of data blocks in the buffer cache due to lack of free lists, free list groups, transaction slots (INITRANS), or shortage of rollback segments.
    Long Full Table Scans.
    High Amounts of Recursive (SYS) SQL
    Deployment and Migration Errors
    Table require analyzed.
    Table require indexed.
    Overparsing.
    You have old discs.
    Not enough memory.
    SGA is too small or too big.
    Same for cache buffer.
    Your OS need tuning.
    Your disc is full.
    Running so many instances on a single server.
    You applications are badly written.
    Your applications were ported from Sybase or Microsoft SQL Server.
    Your applications were ported from DB2.
    Your applications dynamically create temp tables.
    Someone wrote referential integrity using triggers, java, vb ...
    Someone wrote replication using triggers, java, vb ...
    Someone wrote a sequence using max + 1.
    Table datatypes are not as per DBMS concepts; like Dates and numbers are stored as strings.
    The statistics are not up to date.
    There are no statistics.
    What are statistics?
    We are using RBO.
    That's a few of the possible causes I could think of, there are lots of others.
    -To analyze your application, you can install Statspack. It will give you some indications.
    Hth
    Girish Sharma

  • BSAD table is taking more time in select query.

    Hi ,
    The below SELECT query is taking more time , there is no any secondary index is there .
    Can anybody suggest how to improve it .
    SELECT bukrs
             kunnr
             augdt
             augbl
             gjahr
             belnr
             budat
             bldat
             waers
             xblnr
             BLART
             monat
             shkzg
             gsber
             DMBTR
             WRBTR
             prctr
             FROM  BSAD INTO TABLE gt_bsad
             WHERE  bukrs  = p_bukrs
             AND    kunnr  IN so_kunnr
             AND    budat  IN so_budat
             AND    xblnr  IN so_xblnr
             AND  ( blart  EQ 'DA' OR
                    blart  EQ 'DZ' OR
                    blart  EQ 'ZP' OR               "D03K904574
                    blart  EQ 'KZ' OR               "D03K904574
                    blart  EQ 'DP' )
             AND   PRCTR IN R_PC.
    Thanks in advance
    Regards
    chetan

    Hi Chetan ,
    I will suggest you two things :
    1. Try to add Secondary ( Non-unique) index on table BSAD with fields : mandt,bukrs,kunnr,budat,xblnr,blart,prctr.
        but before adding this index test the selectivity of this index by going to Tcode DB05
    2. In the select query you have used OR condition for blart. Instead of this try to create a ranges table for blart and append the  values 'DA','DZ','ZP','KZ','DP' and use this in the select query. This will improve the performance for sure.
    Hope this will help to ypu.
    Regards,
    Nikhil

  • Performance tunned report taking more time to execute - URGENT

    Dear Experts,
    In One Report Program is Taking long time to execute at background session, I am Taking That Report To Tune The Performance But This is taking 12 hours more to excute .........
    The Code is given below.
    Before Tune.
    DATA  :  BEGIN OF ITAB OCCURS 0,
            LGOBE    LIKE T001L-LGOBE,
            105DT    LIKE MKPF-BUDAT,
            XBLNR    LIKE MKPF-XBLNR,
            BEDAT    LIKE EKKO-BEDAT,
            LIFNR    LIKE EKKO-LIFNR,
            NAME1    LIKE LFA1-NAME1,
            EKKO     LIKE EKKO-BEDAT,
            BISMT    LIKE MARA-BISMT,
            MAKTX    LIKE MAKT-MAKTX,
            NETPR    LIKE EKPO-NETPR,
            PEINH    LIKE EKPO-PEINH,
            VALUE    TYPE P DECIMALS 2,
            DISPO    LIKE MARC-DISPO,
            DSNAM    LIKE T024D-DSNAM,
            AGE      TYPE P DECIMALS 0,
            PARLIFNR LIKE EKKO-LIFNR,
            PARNAME1 LIKE LFA1-NAME1,
             MBLNR    LIKE MSEG-MBLNR,
             MJAHR    LIKE MSEG-MJAHR,
             ZEILE    LIKE MSEG-ZEILE,
             BWART    LIKE MSEG-BWART,
             MATNR    LIKE MSEG-MATNR,
             WERKS    LIKE MSEG-WERKS,
             LIFNR    LIKE MSEG-LIFNR,
             MENGE    LIKE MSEG-MENGE,
             MEINS    LIKE MSEG-MEINS,
             EBELN    LIKE MSEG-EBELN,
             EBELP    LIKE MSEG-EBELP,
             LGORT    LIKE MSEG-LGORT,
             SMBLN    LIKE MSEG-SMBLN,
             BUKRS    LIKE MSEG-BUKRS,
             GSBER    LIKE MSEG-GSBER,
             INSMK    LIKE MSEG-INSMK,
             XAUTO    LIKE MSEG-XAUTO,
             END OF ITAB.
    SELECT MBLNR MJAHR ZEILE BWART MATNR WERKS LIFNR MENGE MEINS
             EBELN EBELP LGORT SMBLN BUKRS GSBER INSMK XAUTO
             FROM MSEG
             INTO CORRESPONDING FIELDS OF TABLE ITAB
             WHERE WERKS  EQ P_WERKS AND
                   MBLNR  IN S_MBLNR AND
                   BWART  EQ '105'   and
                   mblnr ne '5002361303' and
                   mblnr ne '5003501080' and
                   mblnr ne '5002996300' and
                   mblnr ne '5002996407' AND
                    mblnr ne '5003587026' AND
                    mblnr ne '5003587026' AND
                    mblnr ne '5003493186' AND
                    mblnr ne '5002720583' AND
                    mblnr ne '5002928122' AND
                    mblnr ne '5002628263'.
    After tune.
    TYPES :  BEGIN OF ST_ITAB ,
             MBLNR    LIKE MSEG-MBLNR,
             MJAHR    LIKE MSEG-MJAHR,
             ZEILE    LIKE MSEG-ZEILE,
             BWART    LIKE MSEG-BWART,
             MATNR    LIKE MSEG-MATNR,
             WERKS    LIKE MSEG-WERKS,
             LIFNR    LIKE MSEG-LIFNR,
             MENGE    LIKE MSEG-MENGE,
             MEINS    LIKE MSEG-MEINS,
             EBELN    LIKE MSEG-EBELN,
             EBELP    LIKE MSEG-EBELP,
             LGORT    LIKE MSEG-LGORT,
             SMBLN    LIKE MSEG-SMBLN,
             BUKRS    LIKE MSEG-BUKRS,
             GSBER    LIKE MSEG-GSBER,
             INSMK    LIKE MSEG-INSMK,
             XAUTO    LIKE MSEG-XAUTO,
            END OF ST_ITAB.
    DATA : ITAB TYPE STANDARD TABLE OF ST_ITAB WITH HEADER LINE.
    SELECT MBLNR MJAHR ZEILE BWART MATNR WERKS LIFNR MENGE MEINS
             EBELN EBELP LGORT SMBLN BUKRS GSBER INSMK XAUTO
             FROM MSEG
             INTO TABLE ITAB
             WHERE WERKS  EQ P_WERKS AND
                   MBLNR  IN S_MBLNR AND
                   BWART  EQ '105'   AND
                   MBLNR NE '5002361303' AND
                   MBLNR NE '5003501080' AND
                   MBLNR NE '5002996300' AND
                   MBLNR NE '5002996407' AND
                    MBLNR NE '5003587026' AND
                    MBLNR NE '5003587026' AND
                    MBLNR NE '5003493186' AND
                    MBLNR NE '5002720583' AND
                    MBLNR NE '5002928122' AND
                    MBLNR NE '5002628263'.
    PLEASE GIVE ME THE SOULUTION......
    Reward avail for useful answer
    thanks in adv,
    jai.m

    Hi.
    The Select statment accessing MSEG Table is Slow Many a times.
    To Improve the performance of  MSEG.
    1.Check for the proper notes in the Service Market Place if you are working for CIN version.
    2.Index the MSEG table
    2.Check and limit the Columns in the Select statment .
    Possible Way.
    SELECT MBLNR MJAHR ZEILE BWART MATNR WERKS LIFNR MENGE MEINS
    EBELN EBELP LGORT SMBLN BUKRS GSBER INSMK XAUTO
    FROM MSEG
    INTO CORRESPONDING FIELDS OF TABLE ITAB
    WHERE WERKS EQ P_WERKS AND
    MBLNR IN S_MBLNR AND
    BWART EQ '105' .
    Delete itab where itab EQ '5002361303'
    Delete itab where itab EQ  '5003501080' 
    Delete itab where itab EQ  '5002996300'
    Delete itab where itab EQ '5002996407'
    Delete itab where itab EQ '5003587026'
    Delete itab where itab EQ  '5003587026'
    Delete itab where itab EQ  '5003493186'
    Delete itab where itab EQ  '5002720583'
    Delete itab where itab EQ '5002928122'
    Delete itab where itab EQ '5002628263'.
    Select
    Regards
    Bala.M
    Edited by: Bala Malvatu on Feb 7, 2008 9:18 PM

  • Trunc taking more time to execute..........

    Hiii
    I running a query that is including TRUNC in where condition. But it is taking more time time to execute. Query is ::::::::::
    SELECT POD.REQ_DISTRIBUTION_ID, X.*
    FROM
    SELECT MSI.SEGMENT1||'.'||MSI.SEGMENT2||'.'||MSI.SEGMENT3||'.'||MSI.SEGMENT4 ITEM, RT.TRANSACTION_TYPE,
         MSI.DESCRIPTION, rt.TRANSACTION_ID,RT.PARENT_TRANSACTION_ID,
         RSH.RECEIPT_NUM,
         RSH.SHIP_TO_ORG_ID,
         TRUNC(RT.TRANSACTION_DATE) RCP_DATE,
         RSL.QUANTITY_RECEIVED RCV_QTY,
         PLLA.SHIPMENT_NUM,
         PLA.LINE_NUM PO_LINE,
         PHA.SEGMENT1 PO_NUM,
         PHA.CREATION_DATE,
         PHA.APPROVED_DATE,
         PLA.QUANTITY PO_QTY,
         RSH.SHIPMENT_HEADER_ID,
         RSL.SHIPMENT_LINE_ID,
         PLLA.LINE_LOCATION_ID
    FROM PO_HEADERS_ALL PHA,
         PO_LINES_ALL PLA,
         MTL_SYSTEM_ITEMS MSI,
         RCV_SHIPMENT_HEADERS RSH,
         RCV_SHIPMENT_LINES RSL,
         RCV_TRANSACTIONS RT,
         PO_LINE_LOCATIONS_ALL PLLA
    WHERE PHA.PO_HEADER_ID = PLA.PO_HEADER_ID
    AND     PHA.PO_HEADER_ID = RSL.PO_HEADER_ID
    AND     PHA.PO_HEADER_ID = PLLA.PO_HEADER_ID
    AND     PHA.ORG_ID = PLLA.ORG_ID
    AND     PLA.ITEM_ID = MSI.INVENTORY_ITEM_ID
    AND     PLA.PO_LINE_ID = RSL.PO_LINE_ID
    AND     MSI.INVENTORY_ITEM_ID = RSL.ITEM_ID
    AND     MSI.ORGANIZATION_ID = RSH.SHIP_TO_ORG_ID
    AND     RSH.SHIPMENT_HEADER_ID = RSL.SHIPMENT_HEADER_ID
    AND     RSH.SHIPMENT_HEADER_ID = RT.SHIPMENT_HEADER_ID
    AND     RSL.SHIPMENT_LINE_ID = RT.SHIPMENT_LINE_ID
    AND     RSL.PO_LINE_ID = PLLA.PO_LINE_ID
    AND     RT.TRANSACTION_TYPE = 'RECEIVE'
    AND     NVL(MSI.ENABLED_FLAG,'N') = 'Y'
    AND     NVL(RSL.QUANTITY_RECEIVED,0) > 0
    AND     PHA.ORG_ID = :P_ORG_ID
    AND        TRUNC(RT.TRANSACTION_DATE) BETWEEN :P_FROM_DATE AND :P_TO_DATE ) X, PO_DISTRIBUTIONS_ALL POD
    WHERE POD.LINE_LOCATION_ID = X.LINE_LOCATION_ID
    How can i execute it fast. Any alternate for TRUNC..?
    PS

    You could use a function based index,
    create index idx_trunc_trans_date on RCV_TRANSACTIONS(TRUNC(TRANSACTION_DATE));I guess the trunc you are using will not be of any use unless you are having any time format in your p_from_date and p_to_date or you enter same date for to and from dates.
    Trunc just truncates the time in the date and resets it begining of the day. I dont think you need trunc at all.
    Just do
    IF P_FROM_DATE AND P_TO_DATE
    then
    l_to_date := (p_to_date+1)-(1/(24*3600))
    -- use local variables
    then useAND RT.TRANSACTION_DATE BETWEEN :P_FROM_DATE AND L_TO_DATE
    I believe you should get the same reults unless you have time in your from and to date parameters.
    If you are getting, same results, just remove the trunc.
    G.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Collection function taking more time to execute

    Hi all,
    I am using a collection function in my sql_report it is taking plenty of time to return rows, is there any way to get the resulted rows(using collection) without consuming more time.
    SELECT tab_to_string(CAST(COLLECT(wot_vw."Name") AS t_varchar2_tab)) FROM  REPORT_VW wot_vw
    WHERE(wot_vw."Task ID" = wot."task_id") GROUP BY wot_rept_vw."Task ID") as "WO"
    from   TASK_TBL wot
    INNER JOIN
    (SELECT "name", MAX("task_version") AS MaxVersion from TASK_TBL
             GROUP BY "name") q
    ON (wot."name" = q."name" AND wot."task_version" = q.MaxVersion)
    order by NLSSORT(wot."name",'NLS_SORT=generic_m')
    Here this order by is causing problem
    Apex version is 4.0
    Thanks.
    Edited by: apex on Feb 21, 2012 7:24 PM

    'My car doesn't start, please help me to start my car'
    Do you think we are clairvoyant?
    Or is your salary subtracted for every letter you type here?
    Please be aware this is not a chatroom, and we can not see your webcam.
    Sybrand Bakker
    Senior Oracle DBA

  • Report taking more time to execute

    Hi,
       I Have created a report on " 0FIGL_O02 " General Ledger: Line Items(DSO)
      This report is creates for document details . so using this report i want to creat
       jump report. But When i am running the report it is taking more tme.
      variable sellections i uesed for this report.
    1. company code
    2.G/L Account
    3.Posting date
    there are no caliculations for this report.  But it is taaking more time and not getting
    executed.
    plz sugest.
    Regards,
    prasad.

    Hi,
    Please rebuild the statistics of the ODS.
    Also check the various options available below:
    ODS Performance
    -Vikram

  • Automatic DOP take more time to execute query

    We upgraded database to oracle 11gR2. While testing Automatic DOP feature with our existing query it takes more time than with parallel.
    Note: No constrains or Index created on table to gain performance while loading data (5000records / sec)
    Os : Sun Solaris 64bit
    CPU = 8
    RAM = 7456M
    Default parameter settings:
    parallel_degree_policy               string      MANUAL
    parallel_degree_limit                string      CPU
    parallel_threads_per_cpu             integer     2
    arallel_degree_limit                 string      CPU
    cpu_count                            integer     8
    parallel_threads_per_cpu             integer     2
    resource_manager_cpu_allocation      integer     8
    Query:
    SELECT COUNT(*)
    from (
    SELECT
    /*+ FIRST_ROWS(50), PARALLEL */
    Query gets executed in 22minutes : execution plan
      COUNT(*)
          9600
    Elapsed: 00:22:10.71
    Execution Plan
    Plan hash value: 3765539975
    | Id  | Operation           | Name             | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |                  |     1 |    21 |  2164K  (1)| 07:12:52 |       |   |
    |   1 |  SORT AGGREGATE     |                  |     1 |    21 |            |          |       |   |
    |   2 |   PARTITION RANGE OR|                  | 89030 |  1825K|  2164K  (1)| 07:12:52 |KEY(OR)|KEY(OR)|
    |*  3 |    TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 |  1825K|  2164K  (1)| 07:12:52 |KEY(OR)|KEY(OR)|Automatic DOP Query: parameters set
    alter session set PARALLEL_DEGREE_POLICY = limited;
    alter session force parallel query ;Query:
    SELECT COUNT(*)
    from (
    SELECT /*+ FIRST_ROWS(50), PARALLEL*/
    This query takes more than 2hrs to execute
    COUNT(*)
          9600
    Elapsed: 02:07:48.81
    Execution Plan
    Plan hash value: 127536830
    | Id  | Operation              | Name             | Rows  | Bytes | Cost (%CPU)| Time     | Pstart|Pstop |    TQ   |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT       |                  |     1 |    21 |   150K  (1)| 00:30:01 |       |      |         |      |            |
    |   1 |  SORT AGGREGATE        |                  |     1 |    21 |            |          |       |      |         |      |            |
    |   2 |   PX COORDINATOR       |                  |       |       |            |          |       |      |         |      |            |
    |   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |    21 |            |          |       |      |  Q1,00  | P->S | QC (RAND)  |
    |   4 |     SORT AGGREGATE     |                  |     1 |    21 |            |          |       |      |  Q1,00  | PCWP |            |
    |   5 |      PX BLOCK ITERATOR |                  | 89030 |  1825K|   150K  (1)| 00:30:01 |KEY(OR)|KEY(OR)|  Q1,00 | PCWC |            |
    |*  6 |       TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 |  1825K|   150K  (1)| 00:30:01 |KEY(OR)|KEY(OR)|  Q1,00 | PCWP |            |
    Note
    - automatic DOP: Computed Degree of Parallelism is 16 because of degree limitcan some one help us to find out where we did wrong or any pointer will really helpful to resolve an issue.
    Edited by: Sachin B on May 11, 2010 4:05 AM

    Generated AWR report for ADOP
    Foreground Wait Events                       DB/Inst: HDB/hdb  Snaps: 158-161
    -> 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
    direct path read                522,173     0    125,051     239    628.4   99.3
    db file sequential read             663     0        156     235      0.8     .1
    log file sync                       165     0        117     712      0.2     .1
    Disk file operations I/O            267     0         63     236      0.3     .1
    db file scattered read              251     0         36     145      0.3     .0
    control file sequential re          217     0         32     149      0.3     .0
    library cache load lock               2     0         10    4797      0.0     .0
    cursor: pin S wait on X               3     0          9    3149      0.0     .0
    read by other session                 5     0          2     429      0.0     .0
    kfk: async disk IO              613,170     0          2       0    737.9     .0
    sort segment request                  1   100          1    1007      0.0     .0
    os thread startup                    16     0          1      43      0.0     .0
    direct path write temp                1     0          1     527      0.0     .0
    latch free                           51     0          0       2      0.1     .0
    kksfbc child completion               1   100          0      59      0.0     .0
    latch: cache buffers chain           19     0          0       2      0.0     .0
    latch: shared pool                   36     0          0       1      0.0     .0
    PX Deq: Slave Session Stat           21     0          0       1      0.0     .0
    library cache: mutex X               45     0          0       1      0.1     .0
    CSS initialization                    2     0          0       6      0.0     .0
    enq: KO - fast object chec            1     0          0      11      0.0     .0
    buffer busy waits                     3     0          0       1      0.0     .0
    cursor: pin S                         9     0          0       0      0.0     .0
    CSS operation: action                 2     0          0       1      0.0     .0
    direct path write                     1     0          0       2      0.0     .0
    jobq slave wait                  17,554   100      8,942     509     21.1
    PX Deq: Execute Reply             4,060    95      7,870    1938      4.9
    SQL*Net message from clien           96     0      5,756   59962      0.1
    PX Deq: Execution Msg               618    56        712    1152      0.7
    KSV master wait                      11     0          0       2      0.0
    PX Deq: Join ACK                     16     0          0       1      0.0
    PX Deq: Parse Reply                  14     0          0       1      0.0
    Background Wait Events                       DB/Inst: HDB/hdb  Snaps: 158-161
    -> 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
    control file sequential re        6,249     0      2,375     380      7.5   55.6
    control file parallel writ        2,003     0        744     371      2.4   17.4
    db file parallel write            1,604     0        503     313      1.9   11.8
    log file parallel write             861     0        320     371      1.0    7.5
    db file sequential read             363     0        151     415      0.4    3.5
    db file scattered read              152     0         64     421      0.2    1.5
    Disk file operations I/O            276     0         21      77      0.3     .5
    os thread startup                   316     0         15      48      0.4     .4
    ADR block file read                  24     0         11     450      0.0     .3
    rdbms ipc reply                      17    12          7     403      0.0     .2
    Data file init write                  6     0          6    1016      0.0     .1
    direct path write                    21     0          6     287      0.0     .1
    log file sync                         7     0          6     796      0.0     .1
    ADR block file write                 10     0          4     414      0.0     .1
    enq: JS - queue lock                  1     0          3    2535      0.0     .1
    ASM file metadata operatio        1,801     0          2       1      2.2     .0
    db file parallel read                30     0          1      40      0.0     .0
    kfk: async disk IO                  955     0          1       1      1.1     .0
    db file single write                  1     0          0     415      0.0     .0
    reliable message                     10     0          0      23      0.0     .0
    latch: shared pool                   75     0          0       2      0.1     .0
    latch: call allocation               26     0          0       2      0.0     .0
    CSS initialization                    7     0          0       6      0.0     .0
    asynch descriptor resize            352   100          0       0      0.4     .0
    undo segment extension                2   100          0       5      0.0     .0
    CSS operation: action                 9     0          0       1      0.0     .0
    CSS operation: query                 42     0          0       0      0.1     .0
    latch: parallel query allo            4     0          0       0      0.0     .0
    rdbms ipc message                37,948    97    104,599    2756     45.7
    DIAG idle wait                   16,762   100     16,927    1010     20.2
    ASM background timer              1,724     0      8,467    4912      2.1
    shared server idle wait             282   100      8,465   30019      0.3
    pmon timer                        3,123    90      8,465    2711      3.8
    wait for unread message on        8,381   100      8,465    1010     10.1
    dispatcher timer                    141   100      8,463   60019      0.2
    Streams AQ: qmn coordinato          604    50      8,462   14010      0.7
    Streams AQ: qmn slave idle          304     0      8,462   27836      0.4
    smon timer                           35    71      8,382  239496      0.0
    Space Manager: slave idle         1,621    99      8,083    4986      2.0
    PX Idle Wait                      2,392    99      4,739    1981      2.9
    class slave wait                     46     0        623   13546      0.1
    KSV master wait                       2     0          0      27      0.0
    SQL*Net message from clien            7     0          0       1      0.0
    Wait Event Histogram                         DB/Inst: HDB/hdb  Snaps: 158-161
    -> 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           24                                     100.0
    ADR block file write          10                                     100.0
    ADR file lock                 12 100.0
    ASM file metadata operatio  1812  99.0    .3    .4                      .2    .1
    CSS initialization             9                   100.0
    CSS operation: action         11  90.9   9.1
    CSS operation: query          54 100.0
    Data file init write           6        16.7  16.7                    16.7  50.0
    Disk file operations I/O     533  88.7   2.6    .6               1.5    .2   6.4
    PX Deq: Signal ACK EXT         4 100.0
    PX Deq: Signal ACK RSG         2 100.0
    PX Deq: Slave Session Stat    21  42.9  28.6  28.6
    SQL*Net break/reset to cli     6 100.0
    SQL*Net message to client    102 100.0
    SQL*Net more data to clien     4 100.0
    asynch descriptor resize     527 100.0
    buffer busy waits              4  75.0        25.0
    control file parallel writ  2003   9.3    .5          .0    .1        90.0
    control file sequential re  6466  10.6    .0    .0    .0    .1    .2  89.0
    cursor: pin S                  9 100.0
    cursor: pin S wait on X        3                          33.3  33.3        33.3
    db file parallel read         30                           6.7  30.0  63.3
    db file parallel write      1604   7.4    .1                .6  16.5  75.5
    db file scattered read       403   3.7    .2   2.5  13.6  14.9   3.5  61.5
    db file sequential read     1017  12.3    .8   2.3   7.3   6.6   2.0  68.8
    db file single write           1                                     100.0
    direct path read           522.2   2.2   2.1    .1    .0   1.8  17.9  75.9
    direct path write             22         4.5                     4.5  90.9
    direct path write temp         1                                     100.0
    enq: JS - queue lock           1                                           100.0
    enq: KO - fast object chec     1                         100.0
    enq: PS - contention           1 100.0
    kfk: async disk IO         614.1 100.0                                  .0
    kksfbc child completion        1                                     100.0
    latch free                    58  46.6  27.6  15.5  10.3
    latch: cache buffers chain    19  36.8  10.5  52.6
    latch: call allocation        26  76.9  11.5         7.7         3.8
    latch: parallel query allo     4 100.0
    latch: shared pool           111  44.1  28.8  27.0
    library cache load lock        2                                           100.0
    library cache: mutex X        45  84.4   8.9   4.4   2.2
    log file parallel write      861  10.0          .1    .1              89.5    .2
    log file sync                172   6.4                                90.1   3.5
    os thread startup            332                                     100.0
    rdbms ipc reply               18  72.2                                11.1  16.7
    read by other session          5                                     100.0
    reliable message              11  81.8   9.1                           9.1
    sort segment request           1                                     100.0
    undo segment extension         2  50.0                    50.0
    ASM background timer        1724    .8    .6    .1                      .6  97.9
    DIAG idle wait             16.8K                                     100.0
    KSV master wait               13   7.7  23.1  61.5                     7.7
    PX Deq: Execute Reply       4060    .4          .0    .0          .1   3.4  96.0
    PX Deq: Execution Msg        617  34.7   1.5   2.4   1.5   1.5    .2    .8  57.5
    PX Deq: Join ACK              16  93.8                     6.3
    PX Deq: Parse Reply           14  71.4   7.1  14.3   7.1
    PX Idle Wait                2384    .0                                  .6  99.3
    SQL*Net message from clien   103  82.5         1.0   1.9               1.0  13.6
    Space Manager: slave idle   1621                                        .2  99.8
    Streams AQ: qmn coordinato   604  50.0                                      50.0
    Wait Event Histogram                         DB/Inst: HDB/hdb  Snaps: 158-161
    -> 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)Edited by: Sachin B on May 11, 2010 4:52 AM

  • CO41 taking more time to execute

    Hi,
    I am running CO41 (PRD System), but the time it is taking to execute is extensively high. Ultimately i have to kill the sesison to stop the process.
    What can be the probable reason for the same.
    My Inputs to CO41 are,
    Planning Plant
    MRP Controller
    Production Plant
    Kindly guide.
    Thanks in advance,
    Harris

    Dear,
    This is runtime problems occur during the conversion of planned orders it may be due to ATP check or may be due to  buffering of certain tables.
    In the check control (Transaction OPPJ), you can define the stocks, inward movements and outward movements that are considered.
    Below, you will find a list of database tables that are accessed, depending on the setting.
    Stocks:
    Storage locations:    MARD
    Sales order stocks:   MSSA
    Project stocks:       MSSQ
    Subcontracting:       MSSL
    Batches:              MCHB
    Customer consignment: MSSK
    Inward/outward movements:
    Purchase orders:             MDBS (view for EKPO and EKET)
    Production orders:           MDFA (view for AFPO)
    Purchase requisitions:       EBAN
    Dependent req., order res.:  MDRS (view for RESB)
    Manual reservations:         MDRS (view for RESB)
    Stock transfer reservations: MDUR (view for REUL and RESB)
    Sales requirements:          VBBE (individual records)
                                VBBS (totals records)
    Please use releavant setting for the ATP check.
    Also raise to OSS for same.
    Hope it will help you.
    Regards,
    R.Brahmankar

  • Sub VI to enter database data taking more time when calling from main VI

    Hi All,
    I created a sub vi to enter data to a new database, after reading from another database. when i executed that sub vi alone, it took only 2 minutes to enter 20000 records. But when i called that sub VI from my main VI, its taking 35 minutes to enter 20000 records. 
    my maiin vi has another while loop running parallelly which will perform some other operations. How to handle memory in this case? i mean when i call my sub vi from main vi, i need to give complete processor memory for that sub vi. is it possible?
    please help. thanks in advance.
    Sooraj

    Hi Oliver,
    in your example the numeric data is passed from sub-vi to main only when sub-vi terminates, this is what it's supposed to be when you fetch the data from the connector output of a sub-vi.
    You can use queues function to exchange data between sub-vi and main.vi; take a look at the example Message Logging with Named Queue.vi.
    An alternative method is passing to sub-vi a reference of an indicator (or control) and update its value on the fly.
    See example.
    Alberto
    Attachments:
    passing_data_from_sub-vi.llb ‏35 KB

  • Suddenly ODI scheduled executions taking more time than usual.

    Hi,
    I have set ODI packages scheduled for execution.
    From some days those are taking more time to execute themselves.
    Before they used to take 1 hr 30 mins approx.
    Now they are taking 3 - 3 hr 15 mins approx.
    And there no any major change in data in terms of Quantity.
    My ODI version s
    Standalone Edition Version 11.1.1
    Build ODI_11.1.1.3.0_GENERIC_100623.1635
    ODI packages are mainly using Oracle as SOURCE and TARGET DB.
    What things should i check to get to know reasons of sudden increase in time of execution.
    Any pointers regarding this would be appreciated.
    Thanks,
    Mahesh

    Mahesh,
    Use some repository queries to retrieve the session task timings and compare your slow execution to a previous acceptable execution, then look for the biggest changes - this will highlight where you are slowing down, then its off to tune the item accordingly.
    See here for some example reports , you might need to tweak for your current repos version but I dont think the table structures have changed that much :
    http://rnm1978.wordpress.com/2010/11/03/analysing-odi-batch-performance/

  • Issue with background job--taking more time

    Hi,
    We have a custom program which runs as the background job. It runs every 2 hours.
    Itu2019s taking more time than expected on ECC6 SR2 & SR3 on Oracle 10.2.0.4. We found that it taking more time while executing native SQL on DBA_EXTENTS. When we tried to fetch less number of records from DBA_EXTENTS, it works fine.
    But we need the program to fetch all the records.
    But it works fine on ECC5 on 10.2.0.2 & 10.2.0.4.
    Here is the SQL statement:
    EXEC SQL PERFORMING SAP_GET_EXT_PERF.
      SELECT OWNER, SEGMENT_NAME, PARTITION_NAME,
             SEGMENT_TYPE, TABLESPACE_NAME,
             EXTENT_ID, FILE_ID, BLOCK_ID, BYTES
       FROM SYS.DBA_EXTENTS
       WHERE OWNER LIKE 'SAP%'
       INTO
       : EXTENTS_TBL-OWNER, :EXTENTS_TBL-SEGMENT_NAME,
       :EXTENTS_TBL-PARTITION_NAME,
       :EXTENTS_TBL-SEGMENT_TYPE , :EXTENTS_TBL-TABLESPACE_NAME,
       :EXTENTS_TBL-EXTENT_ID, :EXTENTS_TBL-FILE_ID,
       :EXTENTS_TBL-BLOCK_ID, :EXTENTS_TBL-BYTES
    ENDEXEC.
    Can somebody suggest what has to be done?
    Has something changed in SAP7 (wrt background job etc) or do we need to fine tune the SQL statement?
    Regards,
    Vivdha

    Hi,
    there was an issue with LMT's but that was fixed  in 10.2.0.4
    besides missing system statistics:
    But WHY do you collect every 2 hours this information? The dba_extents view is based on really heavy used system tables.
    Normally , you would start queries of this type against dba_extents ie. to identify corrupt blocks and such:
    SELECT  owner , segment_name , segment_type
            FROM  dba_extents
           WHERE  file_id = &AFN
             AND  &BLOCKNO BETWEEN block_id AND block_id + blocks -1
    Not sure what you want to achieve with it.
    There are monitoring tools (OEM ?) around that may cover your needs.
    Bye
    yk

Maybe you are looking for