*More time to Execute*

Hi,
The following code is taking more time to execute...
Kindly assist..
check wagetype selection
  REFRESH it_p8wage.
  CLEAR:  it_p8wage, wa_p8wage, p8wage_flag.
  LOOP AT p0008.
    DO 20 TIMES
    VARYING wa_p8wage-lgart FROM p0008-lga01 NEXT p0008-lga02
    VARYING wa_p8wage-betrg FROM p0008-bet01 NEXT p0008-bet02.
      IF wa_p8wage-lgart IN lgartahm
        AND NOT wa_p8wage IS INITIAL.
        MOVE: 'X' TO p8wage_flag,
              p0008-waers TO wa_p8wage-waers.
        INSERT wa_p8wage INTO TABLE it_p8wage.
        CLEAR wa_p8wage.
      ENDIF.
    ENDDO.
  ENDLOOP.
no wagetype mathing found
  IF p8wage_flag IS INITIAL.
    READ TABLE lgartahm.
    IF sy-subrc EQ 0.
      REJECT.
    ENDIF.
  ENDIF.

Hi,
For each end every employye there may not be data for all the 20 wage types from lga01 bet01..................lga20 and bet20.
in your code it is better to exit the do loop IF wa_p8wage-lgart IS INITIAL rather than looping 20 times even there is no data.
Because wage types will be assigned to an employee in the same sequence form 1,2......20
if the lga03 is initial there there will not be data for lga04 to lga 20.
This may not be the excat reason for slow response time of ur report but may be usefull.
look at the below code for the chane i suggested
LOOP AT p0008.
DO 20 TIMES
VARYING wa_p8wage-lgart FROM p0008-lga01 NEXT p0008-lga02
VARYING wa_p8wage-betrg FROM p0008-bet01 NEXT p0008-bet02.
IF wa_p8wage-lgart IS INITIAL.
  exit.                  " this will exit the do loop
ENDIF.
IF wa_p8wage-lgart IN lgartahm
AND NOT wa_p8wage IS INITIAL.
MOVE: 'X' TO p8wage_flag,
p0008-waers TO wa_p8wage-waers.
INSERT wa_p8wage INTO TABLE it_p8wage.
CLEAR wa_p8wage.
ENDIF.
ENDDO.
ENDLOOP.

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

  • Count (*)  for select stmt take more time than  execute a that sql stmt

    HI
    count (*) for select stmt take more time than execute a that sql stmt
    executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql  command for faster execute .
    but if i tried to find out total number of rows in that query it takes more time ..
    almost 2.30 hrs still running to find count(col)
    please help me to get count of row faster.
    thanks in advance...

    797525 wrote:
    HI
    count (*) for select stmt take more time than execute a that sql stmt
    executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql  command for faster execute .
    but if i tried to find out total number of rows in that query it takes more time ..
    almost 2.30 hrs still running to find count(col)
    please help me to get count of row faster.
    thanks in advance...That may be because your client is displaying only the first few records when you are running the "SELECT *". But when you run "COUNT(*)", the whole records has to be counted.
    As already mentined please read teh FAQ to post tuning questions.

  • Query take more time to execute

    Hi
    I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performance
    thank's

    [email protected] wrote:
    I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performanceI have a query that is using even more time to execute. Do I win?

  • 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

  • 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

  • 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

  • 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

  • "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

  • 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.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • 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

  • What is the reason for query take more time to execute

    Hi,
    What is the reason for the query take more time inside procedure.
    but if i execute that query alone then it excute within a minutes.
    query includes update and insert.

    I have a insert and update query when I execute
    without Procedure then that query execute faster but
    If I execute inside procedure then It takes 2 hours
    to execute.Put you watch 2 hours back and the problem will disappear.
    do you understand what I want to say?I understood what you wanted to say and I understood you didn't understood what I said.
    What does the procedure, what does the query, how can you say the query does the same as the procedure that takes longer. You didn't say anything useful to have an idea of what you're talking about.
    Everyone knows what means that something is slower than something else, but it means nothing if you don't say what you're talking about.
    To begin with something take a look at this
    When your query takes too long ...
    especially the part regarding the trace.
    Bye Alessandro

  • 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

  • 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

  • Threaded program takes more time than executing serially!

    Hello All
    Ive converted my program into a threaded application so as to improve speed. However i found that after converting the execution time is more than it was when the program was non threaded. Im not having any synchronised methods. Any idea what could be the reason ?
    Thanx in advance.

    Putting aside fstreams amusing comment, I suspect your
    theads are never yielding (they are sitting in a tight
    loop, thus taking all available procesor power). Try
    adding Thread.sleep(0) at som point in the loop.No. If you just want to encourage one thread to give another thread a turn, use yield, not sleep.
    Note, though, that this may not help your situation. As was pointed out, on a single CPU machine, the only way a multithreaded program will run faster (by which I mean total wall-clock time start to finish) than its single-threaded equivalent is if the 1-thread version spends a lot of time waiting for IO when it could be doing something else. (If it's waiting for IO, but that IO is needed for the big number crunching, then putting the crunching in another thread won't make things any faster.)
    On the other hand, if by "faster" you're referring to a more responsive GUI, then, yes, in general you might expect better GUI response be putting non-GUI stuff in a different thread, but there's no guarantee. Depending on what the other thread does, how much work your GUI has to do, how your VM's scheduler works, how you've split up the work, etc., it may not be any better.
    I know that's not very specific, but neither was your question.

Maybe you are looking for