DELETE query takes long time more than 30 min

Hi
I have delete query as below.It takes 1300 sec to execute .Please let me know how to reduce the time of execution.I have indexes on both the columns jdoid,jdoversion of deletion.
DELETE FROM SIT7016.DEVICEINTERFACE WHERE JDOID = :1 AND JDOVERSION = :2
Regards
Pandu

udnapp wrote:
I have delete query as below.It takes 1300 sec to execute .Please let me know how to reduce the time of execution.I have indexes on both the columns jdoid,jdoversion of deletion.
DELETE FROM SIT7016.DEVICEINTERFACE WHERE JDOID = :1 AND JDOVERSION = :2Pretty meaningless information without an the execution plan.

Similar Messages

  • SAINT/SPAM UPDATE takes longer time more than 12hours

    Hi everyone,
      I am doing SAINT/SPAM UPDATE version 33 on NW70 systems running on windows 2003 x64 servers with oracle 10g database. The update is running for more than 12 hours and has not finished yet.
    Normally SAINT/SPAM update wud take 15 to 20mins. But this is very unusual.
    Has anyone faced similar problems before ?
    Please suggest solutions if any
    thanks
    Moses

    Check the import monitor and the tp system log to check the status of the patch... please post here any errors found.
    Loging using DDIC
    ensure 000 client you login
    ensure your active login session on CI instance (in case multiple instances)
    ensure to shutdown/stop all other instances (Dialog Distances) running on other hosts
    This information is inacurate and missleading... You don't need to logon with DDIC you can use any user with the right authorizations,  also you don't need to shutdown any instances.
    Regards
    Juan

  • Urgent run the job --SBIE0001 takes  long time more than two hours

    hi expert,
    we run the job which cocntian the program SBIE0001 it takes so along time,
    we use the job to eatra the date from our system to another satellite system, by checking the
    job this is one step takes the mainly time as below.
    88 LUWs confirmed and 88 LUWs to be deleted with function module RSC2_QOUT_CONFIRM_DATA
    any update will be appreciated. thanks in advance.

    If you have transaction ME30 active in yous system, run the program into in.
    It will give more information about how the time is lost.

  • Why update query takes  long time ?

    Hello everyone;
    My update query takes long time.  In  emp  ( self testing) just  having 2 records.
    when i issue update query , it takes long time;
    SQL> select  *  from  emp;
      EID  ENAME     EQUAL     ESALARY     ECITY    EPERK       ECONTACT_NO
          2   rose              mca                  22000   calacutta                   9999999999
          1   sona             msc                  17280    pune                          9999999999
    Elapsed: 00:00:00.05
    SQL> update emp set esalary=12000 where eid='1';
    update emp set esalary=12000 where eid='1'
    * ERROR at line 1:
    ORA-01013: user requested cancel of current operation
    Elapsed: 00:01:11.72
    SQL> update emp set esalary=15000;
    update emp set esalary=15000
      * ERROR at line 1:
    ORA-01013: user requested cancel of current operation
    Elapsed: 00:02:22.27

    Hi  BCV;
    Thanks for your reply but it doesn't provide output,  please  see   this.
    SQL> update emp set esalary=15000;
    ........... Lock already occured.
    >> trying to trace  >>
    SQL> select HOLDING_SESSION from dba_blockers;
    HOLDING_SESSION
                144
    SQL> select sid , username, event from v$session where username='HR';
    SID USERNAME     EVENT
       144   HR    SQL*Net message from client
       151   HR    enq: TX - row lock contention
       159   HR    SQL*Net message from client
    >> It  does n 't  provide  clear output about  transaction lock >>
    SQL> SELECT username, v$lock.SID, TRUNC (id1 / POWER (2, 16)) rbs,
      2  BITAND (id1, TO_NUMBER ('ffff', 'xxxx')) + 0 slot, id2 seq, lmode,
      3  request
      4  FROM v$lock, v$session
      5  WHERE v$lock.TYPE = 'TX'
      6  AND v$lock.SID = v$session.SID
      7  AND v$session.username = USER;
      no rows selected
    SQL> select MACHINE from v$session where sid = :sid;
    SP2-0552: Bind variable "SID" not declared.

  • Why it takes long time (about 10 Min) to map the network drivers in windows 8.1?

    Why it takes long time (about 10 Min) to map the network drivers in windows 8.1? I don’t have this problem with any other operating systems (Ex: Windows 7 or XP)

    Can you perform a refresh ?
    Arnav Sharma | http://arnavsharma.net/ Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading
    the thread.

  • Query take long time

    I m running a query taking more time more than 20 minutes. But if I am changing the values in the
    where clause, its doing fast. I am not changing the query , only i change the numeric value used in the
    where condtion. I thing its a factor of LOCK. How to resolve it. how to make the query return resut even
    row is being locked. thanks

    QUERY 1:
    PROD> select count(*) from patient_ad a,patient_master_data p , patient_contracts c
    2 where a.patient_id=p.patient_id and c.patient_id = a.patient_id and
    3 to_date(a.admit_date,'dd/mm/yyyy') >= '29/12/2008' and
    4 to_date(a.admit_date,'dd/mm/yyyy') <= '17/12/2009' and
    5 p.nationality_code <> 16 and c.CONTRACT_NO= 2207;
    Execution Plan
    Plan hash value: 801996662
    | Id | Operation | Name |
    | 0 | SELECT STATEMENT | |
    | 1 | SORT AGGREGATE | |
    | 2 | NESTED LOOPS | |
    | 3 | NESTED LOOPS | |
    |* 4 | INDEX RANGE SCAN | PATIENT_CONTRACTS_NDX2 |
    |* 5 | TABLE ACCESS BY INDEX ROWID| PATIENT_AD |
    |* 6 | INDEX RANGE SCAN | PATIENT_AD_NDX1 |
    |* 7 | TABLE ACCESS BY INDEX ROWID | PATIENT_MASTER_DATA |
    |* 8 | INDEX UNIQUE SCAN | PK_PATIENT_MASTER_DATA |
    Predicate Information (identified by operation id):
    4 - access("C"."CONTRACT_NO"=2207)
    5 - filter(TO_DATE(INTERNAL_FUNCTION("A"."ADMIT_DATE"),'dd/mm/yyyy')<
    ='17/12/2009' AND TO_DATE(INTERNAL_FUNCTION("A"."ADMIT_DATE"),'dd/mm/yyy
    y')>='29/12/2008')
    6 - access("C"."PATIENT_ID"="A"."PATIENT_ID")
    7 - filter("P"."NATIONALITY_CODE"<>16)
    8 - access("A"."PATIENT_ID"="P"."PATIENT_ID")
    Note
    - rule based optimizer used (consider using cbo)
    THIS QUERY TAKING A LONG TIME EVEN AFTER 24 HOURS NOT YIELDING ANY RESULT.
    QUERY2:
    PROD> select count(*) from patient_ad a,patient_master_data p , patient_contracts c
    2 where a.patient_id=p.patient_id and c.patient_id = a.patient_id and
    3 to_date(a.admit_date,'dd/mm/yyyy') >= '29/12/2008' and
    4 to_date(a.admit_date,'dd/mm/yyyy') <= '17/12/2009' and
    5 p.nationality_code <> 16 and c.CONTRACT_NO= 2207;
    Execution Plan
    Plan hash value: 801996662
    | Id | Operation | Name |
    | 0 | SELECT STATEMENT | |
    | 1 | SORT AGGREGATE | |
    | 2 | NESTED LOOPS | |
    | 3 | NESTED LOOPS | |
    |* 4 | INDEX RANGE SCAN | PATIENT_CONTRACTS_NDX2 |
    |* 5 | TABLE ACCESS BY INDEX ROWID| PATIENT_AD |
    |* 6 | INDEX RANGE SCAN | PATIENT_AD_NDX1 |
    |* 7 | TABLE ACCESS BY INDEX ROWID | PATIENT_MASTER_DATA |
    |* 8 | INDEX UNIQUE SCAN | PK_PATIENT_MASTER_DATA |
    Predicate Information (identified by operation id):
    4 - access("C"."CONTRACT_NO"=2207)
    5 - filter(TO_DATE(INTERNAL_FUNCTION("A"."ADMIT_DATE"),'dd/mm/yyyy')<
    ='17/12/2009' AND TO_DATE(INTERNAL_FUNCTION("A"."ADMIT_DATE"),'dd/mm/yyy
    y')>='29/12/2008')
    6 - access("C"."PATIENT_ID"="A"."PATIENT_ID")
    7 - filter("P"."NATIONALITY_CODE"<>16)
    8 - access("A"."PATIENT_ID"="P"."PATIENT_ID")
    Note
    - rule based optimizer used (consider using cbo)
    THIS QUERY RETURNS THE RESULT WITHIN 1 MINUTES.

  • My query take long time..

    The output of tkprof of my trace file is :
    SELECT ENEXT.NUM_PRSN_EMPLY ,ENEXT.COD_BUSUN ,ENEXT.DAT_CALDE ,ENEXT.COD_SHFT
    FROM
    AAC_EMPLOYEE_ENTRY_EXITS5_VIW ENEXT ,PDS.PDS_EMPLOYEES EMPL ,
    PDS.PDS_EMPLOYMENT_TYPES EMPTYP ,PDS.PDS_PAY_CONDITIONS PAYCON WHERE
    ENEXT.DAT_CALDE BETWEEN :B6 AND :B5 AND ENEXT.NUM_PRSN_EMPLY IN (SELECT
    ATT21 FROM APPS.GLOBAL_TEMPS WHERE ATT1 = 'PRSN') AND ENEXT.NUM_PRSN_EMPLY =
    EMPL.NUM_PRSN_EMPLY AND EMPL.EMTYP_COD_EMTYP = EMPTYP.COD_EMTYP AND
    EMPTYP.LKP_COD_STA_PAY_EMTYP <> 3 AND
    NVL(EMPL.LKP_MNTLY_WITHOUT_ENEXT_EMPLY,2) <> 1 AND EMPL.PCOND_COD_STA_PCOND
    = PAYCON.COD_STA_PCOND AND NVL(EMPL.LKP_MNTLY_WITHOUT_ENEXT_EMPLY,2) <> 1
    AND PAYCON.LKP_FLG_STA_PAY_PCOND = 1 AND ENEXT.DAT_CALDE >=
    EMPL.DAT_EMPLT_EMPLY AND ENEXT.DAT_CALDE <= NVL(EMPL.DAT_DSMSL_EMPLY,
    TO_DATE('15001229','YYYYMMDD')) AND 1 = (CASE WHEN
    ENEXT.LKP_STA_HOLIDAY_CALNR = 2 AND ENEXT.LKP_CAT_SHFT_SHTAB = 1 AND
    ENEXT.TYP_DAY BETWEEN 4 AND 6 THEN 0 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 2
    AND ENEXT.LKP_CAT_SHFT_SHTAB = 1 AND ENEXT.TYP_DAY NOT BETWEEN 4 AND 6 THEN
    1 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 2 AND ENEXT.LKP_CAT_SHFT_SHTAB = 2
    THEN 0 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 1 AND ENEXT.LKP_CAT_SHFT_SHTAB =
    1 THEN 1 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 1 AND ENEXT.LKP_CAT_SHFT_SHTAB =
    2 THEN 0 END) AND ENEXT.LKP_COD_DPUT_BUSUN = NVL(:B4 ,
    ENEXT.LKP_COD_DPUT_BUSUN) AND ENEXT.LKP_COD_MANAG_BUSUN = NVL(:B3 ,
    ENEXT.LKP_COD_MANAG_BUSUN) AND ENEXT.COD_BUSUN = NVL(:B2 , ENEXT.COD_BUSUN)
    AND ENEXT.COD_CAL = NVL(COD_CAL, ENEXT.COD_CAL) AND ENEXT.NUM_PRSN_EMPLY =
    NVL(:B1 , ENEXT.NUM_PRSN_EMPLY) AND ENEXT.COD_SHFT IN (SELECT
    SHFTBL.COD_SHTAB FROM AAC_SHIFT_TABLES SHFTBL WHERE
    SHFTBL.LKP_CAT_SHFT_SHTAB = 1) AND ENEXT.DAT_CALDE NOT IN (SELECT ABN.DAT
    FROM APPS.AAC_EMPL_EN_EX_ABNORMAL_VIW ABN WHERE ABN.PRSN =
    ENEXT.NUM_PRSN_EMPLY AND ABN.DAT BETWEEN :B6 AND :B5 ) AND ENEXT.DAT_CALDE
    IN (SELECT EMPENEXT.DAT_STR_SHFT_ENEXT FROM AAC.AAC_EMPLOYEE_ENTRY_EXITS
    EMPENEXT WHERE EMPENEXT.EMPLY_NUM_PRSN_EMPLY = EMPL.NUM_PRSN_EMPLY AND
    EMPENEXT.DAT_STR_SHFT_ENEXT BETWEEN :B6 AND :B5 AND
    EMPENEXT.LKP_FLG_STA_ENEXT <> 3) ORDER BY ENEXT.NUM_PRSN_EMPLY,
    ENEXT.DAT_CALDE
    call count cpu elapsed disk query current rows
    Parse 2 0.00 0.00 0 0 0 0
    Execute 2 0.00 0.00 0 0 0 0
    Fetch 2 40.45 40.30 306 17107740 0 24
    total 6 40.45 40.30 306 17107740 0 24
    what is wrong in my query?
    why it take long time?

    user13344656 wrote:
    what is wrong in my query?
    why it take long time?See PL/SQL forum FAQ
    https://forums.oracle.com/forums/ann.jspa?annID=1535
    *3. How to improve the performance of my query? / My query is running slow.*
    SQL and PL/SQL FAQ
    For instructions on what information to post an how to format it.

  • Oracle SQL Select query takes long time than expected.

    Hi,
    I am facing a problem in SQL select query statement. There is a long time taken in select query from the Database.
    The query is as follows.
    select /*+rule */ f1.id,f1.fdn,p1.attr_name,p1.attr_value from fdnmappingtable f1,parametertable p1 where p1.id = f1.id and ((f1.object_type ='ne_sub_type.780' )) and ( (f1.id in(select id from fdnmappingtable where fdn like '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#%')))order by f1.id asc
    This query is taking more than 4 seconds to get the results in a system where the DB is running for more than 1 month.
    The same query is taking very few milliseconds (50-100ms) in a system where the DB is freshly installed and the data in the tables are same in both the systems.
    Kindly advice what is going wrong??
    Regards,
    Purushotham

    SQL> @/alcatel/omc1/data/query.sql
    2 ;
    9 rows selected.
    Execution Plan
    Plan hash value: 3745571015
    | Id | Operation | Name |
    | 0 | SELECT STATEMENT | |
    | 1 | SORT ORDER BY | |
    | 2 | NESTED LOOPS | |
    | 3 | NESTED LOOPS | |
    | 4 | TABLE ACCESS FULL | PARAMETERTABLE |
    |* 5 | TABLE ACCESS BY INDEX ROWID| FDNMAPPINGTABLE |
    |* 6 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
    |* 7 | TABLE ACCESS BY INDEX ROWID | FDNMAPPINGTABLE |
    |* 8 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
    Predicate Information (identified by operation id):
    5 - filter("F1"."OBJECT_TYPE"='ne_sub_type.780')
    6 - access("P1"."ID"="F1"."ID")
    7 - filter("FDN" LIKE '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#
    8 - access("F1"."ID"="ID")
    Note
    - rule based optimizer used (consider using cbo)
    Statistics
    0 recursive calls
    0 db block gets
    0 consistent gets
    0 physical reads
    0 redo size
    0 bytes sent via SQL*Net to client
    0 bytes received via SQL*Net from client
    0 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    9 rows processed
    SQL>

  • Select query taking long time (more then 6 min)

    Dear experts,
    DATA:IT_CHEQ2 TYPE TABLE OF TY_BSAS,
         WA_CHEQ2 LIKE LINE OF IT_CHEQ2.
    DATA : IT_CHEQ3 TYPE STANDARD TABLE OF TY_BSAS WITH HEADER LINE.
    TYPES:BEGIN OF TY_BSAS,
           BUKRS TYPE BSAS-BUKRS,
           HKONT TYPE BSAS-HKONT,
           AUGDT TYPE BSAS-AUGDT,
           AUGBL TYPE BSAK-AUGBL,
           ZUONR TYPE BSAK-ZUONR,
           GJAHR TYPE BSAK-GJAHR,
           BELNR TYPE BSAK-BELNR,
           BUZEI TYPE BSAK-BUZEI,
           BUDAT TYPE BSAK-BUDAT,
           XBLNR TYPE BSAK-XBLNR,
           BLART TYPE BSAK-BLART,
           SHKZG TYPE BSAK-SHKZG,
           DMBTR TYPE BSAK-DMBTR,
           WMWST TYPE BSAK-WMWST,
          AUGGJ TYPE BSAK-AUGGJ, " CLEARING FYSICAL YEAR
           OT_TAX TYPE BSAK-DMBTR,
           TDS   TYPE BSAK-DMBTR,
           VAT    TYPE BSAK-DMBTR, "Vat amount
           WCT   TYPE BSAK-DMBTR,
           ADV    TYPE BSAK-DMBTR,  "Advance
           CHAMT TYPE BSAK-DMBTR,
           CHNO  TYPE PAYR-CHECT,
           CHDATE TYPE PAYR-ZALDT,
           DBIT_NOTE TYPE BSAK-DMBTR,
           PAY_ADJ   TYPE BSAK-DMBTR,
           PEND_SES TYPE BSAK-DMBTR, "PENDING SES
           CR_PARTY(50)  TYPE C,
          END OF TY_BSAS.
    SELECT BUKRS HKONT AUGDT AUGBL ZUONR GJAHR BELNR BUZEI BUDAT XBLNR BLART SHKZG
                      DMBTR WMWST
                      FROM BSAS INTO " APPENDING
               CORRESPONDING FIELDS OF TABLE IT_CHEQ3
                      FOR ALL ENTRIES IN IT_CHEQ2
                      WHERE AUGBL = IT_CHEQ2-AUGBL and
                        BUKRS = IT_CHEQ2-BUKRS   AND
    *                  AUGBL = IT_CHEQ2-AUGBL
                          GJAHR = IT_CHEQ2-GJAHR
                      AND  XBLNR = IT_CHEQ2-XBLNR.
    line company code  hkont       augdt               augbl               zuonr              gjahr        belnr                 buzei  budat
    1     1018     0012100030     20110831     2100009710     20110831     2011     2100009710     005     20110831
    xblnr       blart        shkzg
    RA03     KZ         H            37067.00         0.00     2011     0.00     0.00
    2     1018     0012100030     20110831     2100009710     20110831     2011     2100009710     006     20110831
         RA03     KZ     H     393850.00     0.00     2011     0.00     0.00
    3     1018     0012100030     20110831     2100009710     20110831     2011     2100009710     004     20110831     RA03     KZ     S     723589.13     0.00     2011     0.00     0.00
    4     1018     0012100030     20110831     2100009710     20110823     2011     3900001250     001     20110823     RA03     RS     H     712921.13     0.00     2011     0.00     0.00
    5     1018     0023200000     20110831     2100009710     20110831     2011     2100009710     008     20110831     RA03     KZ     H     21788.00     0.00     2011     0.00     0.00
    6     1018     0023200000     20110831     2100009710     20110831     2011     2100009710     007     20110831     RA03     KZ     H     1162821.00     0.00     2011     0.00     0.00
    if i put same entry in se11 for bsas it takes 7 second
    and in query takes  more then 6 min ,kindly tell why
    help me gurus
    regards
    victor

    Tested point 2.
    There is no difference.
    REPORT  Z_YZ_SELECT_ORDER.
    types: begin of t_orderadm,
             description type CRMT_PROCESS_DESCRIPTION,
             created_at type COMT_CREATED_AT_USR,
             LOGICAL_SYSTEM type CRMT_LOGSYS,
             TEMPLATE_TYPE type CRMT_TEMPLATE_TYPE_DB,
             VERIFY_DATE type CRMT_VERIFY_DATE,
             GUID type CRMT_OBJECT_GUID,
           end of t_orderadm.
    types: begin of t_orderadm_1,
             GUID type CRMT_OBJECT_GUID,
             description type CRMT_PROCESS_DESCRIPTION,
             LOGICAL_SYSTEM type CRMT_LOGSYS,
             TEMPLATE_TYPE type CRMT_TEMPLATE_TYPE_DB,
             created_at type COMT_CREATED_AT_USR,
             VERIFY_DATE type CRMT_VERIFY_DATE,
           end of t_orderadm_1.
    data: lt_orders type table of t_orderadm,
          lt_orders_1 type table of t_orderadm_1.
    select description created_at logical_system template_type verify_date guid
      into table lt_orders
      from crmd_orderadm_h.
    select guid description logical_system template_type created_at verify_date
      into table lt_orders_1
      from crmd_orderadm_h.
    write 'done'.
    First select - mixed order of fields. Response time: 82.155 microseconds for 39380 records selected.
    Second select - fields in the order of the table. Response time: 81.061 microseconds for the same 39380 records selected.
    Then I changed the order of SELECT statements. I have put first the select with ordered fields, and second - select with mixed order of fields. The runtimes were the following:
    Ordered fields - 82.649 microseconds
    Mixed order of fields - 80.270 microseconds.
    So I'm going to change the Wiki page in order to avoid  in future advices that make no sense.

  • Query takes long time on multiprovider

    Hi,
    When i execute a query on the multiprovider, it takes very long time. it doesnt show up the results also. It just keep processing. I have executed the report only for one day but still it doesnt show any result. But when i execute on the cube, it executes quickly and shows the result.
    Actually i added one more cube to the multiprovider and ten transported that multiprovider to QA and PRD. Transportation went on successfully. After this i am unalbe to execute the reports on that multiprovider. What might be the cause? your help is appreciated.
    Thanks
    Annie

    Hi Annie.......
    Checklist for the performance of a Query........from a DOc........
    1. If exclusions exist, make sure they exist in the global filter area. Try to remove exclusions by subtracting out inclusions.
    2. Use Constant Selection to ignore filters in order to move more filters to the global filter area. (Use ABAPer to test and validate that this ensures better code)
    3. Within structures, make sure the filter order exists with the highest level filter first.
    4. Check code for all exit variables used in a report.
    5. Move Time restrictions to a global filter whenever possible.
    6. Within structures, use user exit variables to calculate things like QTD, YTD. This should generate better code than using overlapping restrictions to achieve the same thing. (Use ABAPer to test and validate that this ensures better code).
    7. When queries are written on multiproviders, restrict to InfoProvider in global filter whenever possible. MultiProvider (MultiCube) queries require additional database table joins to read data compared to those queries against standard InfoCubes (InfoProviders), and you should therefore hardcode the infoprovider in the global filter whenever possible to eliminate this problem.
    8. Move all global calculated and restricted key figures to local as to analyze any filters that can be removed and moved to the global definition in a query. Then you can change the calculated key figure and go back to utilizing the global calculated key figure if desired
    9. If Alternative UOM solution is used, turn off query cache.
    10. Set read mode of query based on static or dynamic. Reading data during navigation minimizes the impact on the R/3 database and application server resources because only data that the user requires will be retrieved. For queries involving large hierarchies with many nodes, it would be wise to select Read data during navigation and when expanding the hierarchy option to avoid reading data for the hierarchy nodes that are not expanded. Reserve the Read all data mode for special queriesu2014for instance, when a majority of the users need a given query to slice and dice against all dimensions, or when the data is needed for data mining. This mode places heavy demand on database and memory resources and might impact other SAP BW processes and tasks.
    11. Turn off formatting and results rows to minimize Frontend time whenever possible.
    12. Check for nested hierarchies. Always a bad idea.
    13. If u201CDisplay as hierarchyu201D is being used, look for other options to remove it to increase performance.
    14. Use Constant Selection instead of SUMCT and SUMGT within formulas.
    15. Do review of order of restrictions in formulas. Do as many restrictions as you can before calculations. Try to avoid calculations before restrictions.
    16. Check Sequential vs Parallel read on Multiproviders.
    17. Turn off warning messages on queries.
    18. Check to see if performance improves by removing text display (Use ABAPer to test and validate that this ensures better code).
    19. Check to see where currency conversions are happening if they are used.
    20. Check aggregation and exception aggregation on calculated key figures. Before aggregation is generally slower and should not be used unless explicitly needed.
    21. Avoid Cell Editor use if at all possible.
    22. Make sure queries are regenerated in production using RSRT after changes to statistics, consistency changes, or aggregates.
    23. Within the free characteristics, filter on the least granular objects first and make sure those come first in the order.
    24. Leverage characteristics or navigational attributes rather than hierarchies. Using a hierarchy requires reading temporary hierarchy tables and creates additional overhead compared to characteristics and navigational attributes. Therefore, characteristics or navigational attributes result in significantly better query performance than hierarchies, especially as the size of the hierarchy (e.g., the number of nodes and levels) and the complexity of the selection criteria increase.
    25. If hierarchies are used, minimize the number of nodes to include in the query results. Including all nodes in the query results (even the ones that are not needed or blank) slows down the query processing. The u201Cnot assignedu201D nodes in the hierarchy should be filtered out, and you should use a variable to reduce the number of hierarchy nodes selected.
    Also check this.........Recommendations for Modeling MultiProviders
    http://help.sap.com/saphelp_nw70/helpdata/EN/43/5617d903f03e2be10000000a1553f6/frameset.htm
    Hope this helps......
    Regards,
    Debjani......

  • DELETE Statement takes long time running

    Hi,
    DELETE statements take a very long time to complete.
    Can you advice me how can I diagnostic the slow performance
    Thanks

    Deleting rows can be an expensive operation.
    Oracle stores entire row as the 'before image' of deleted information (table and index data) in
    rollback segments, generates redo (keeps archiver busy), updates free lists for blocks that are
    falling below PCTUSED setting etc..
    Select count(*) runs longer because oracle scans all blocks (upto the High Water Mark) whether
    there are or are not any rows in the blocks.
    These operations will take more and more time, if the tables are loaded with APPEND hint or
    SQL*Loader using direct mode.
    A long time ago, I ran into a similar situation. Data was "deleted" selectively, SQL*Loader was
    used (in DIRECT mode) to add new rows to the table. I had a few tables using more number of blocks
    than the number of rows in the table!
    Needless to say, the process was changed to truncate tables after exporting/extracting required
    data first, and then loading the data back. Worked much better.

  • Saving a query takes long time

    Hi
    i have developed a query on the AR cube. This query has a 36 month structure and about 5 key figures. Since the key figures are inter dependant, I am using the cell formulas in the structure.
    Till Friday i had no problem in saving the query after changes to cell formula. But today i am unable to save the query in time. It takes more than 20 minutes and still does not save. What could be the problem in the system causing this? Could this be due to temp space problem? Any suggestions?
    Ram

    Hi,
    I think, Siggi is right.
    In such situations I usually do the following:
    - Hide all windows (Show desktop icon)
    - CTRLALTDEL - Task Manager
    - Close Task Manager
    The popup window from BEx should be on the screen.
    Best regards,
    Eugene

  • Query takes long time - Please help!

    I've a query like below (not actual query)
    update (select eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) set edv_title = eds_title;
    In the above query I've more than 70 columns to select, compare and update (I've shown only one above). The explain plan for the query is below, which does not show any significant time, but the query never returns when executed after a long long time. Any ideas?
    Plan hash value: 2242214163
    | Id | OpMIAtion | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
    | 0 | UPDATE STATEMENT | | 1627K| 1405M| | 18E (1)| |
    | 1 | UPDATE | MIA_DOC_VERSIONS | | | | | |
    |* 2 | HASH JOIN | | 1627K| 1405M| 720M| 18E (1)| |
    | 3 | TABLE ACCESS BY INDEX ROWID | MIA_DOC_VERSIONS | 1627K| 701M| | 18E (1)| |
    | 4 | BITMAP CONVERSION TO ROWIDS| | | | | | |
    | 5 | BITMAP INDEX FULL SCAN | IDX_30 | | | | | |
    PLAN_TABLE_OUTPUT
    | 6 | TABLE ACCESS FULL | MIA_DATA_STAGING | 1628K| 705M| | 7184 (3)| 00:02:29 |
    Predicate Information (identified by operation id):
    ---------------------------------------------------

    user652494 wrote:
    I've a query like below (not actual query)
    |   3 |    TABLE ACCESS BY INDEX ROWID | MIA_DOC_VERSIONS |  1627K|   701M|       |    18E  (1)|          |
    |   4 |     BITMAP CONVERSION TO ROWIDS|                  |       |       |       |            |          |
    |   5 |      BITMAP INDEX FULL SCAN    | IDX_30           |       |       |       |            |          |This part of your execution plan looks very suspicious: It's performing a bitmap index full scan to do then a single row access by rowid apparently for all rows of the table, which seems to be a very inefficient operation. It also shows an unreasonable cost for that operation. The question is why it is not using a "full table scan" to access the MIA_DOC_VERSIONS table?
    You might want to try simply the FULL hint to request a full table scan on the MIA_DOC_VERSIONS table in order to find out how the execution plan then is going to look like:
    update (select /*+ FULL(EDV) */ eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) set edv_title = eds_title;or
    update /*+ FULL(a.EDV) */ (select eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) a set edv_title = eds_title;Looking at the execution plan of the hinted statement one might get a clue why the optimizer favors an index access path instead.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Delete query taking long time

    Hi,
    I have a table containing around 0.25 million records. It has a time stamp column and its indexed. Now I am deleting records from this table older than one year.
    But this is taking more than 10 minutes. Since I am doing this thorough application (has time out setting for 10 min), I am wondering why it is taking so much time.
    Delete qury is similar to this
    delete from table_name where time_column < (sysdate - 366)
    Is that because it is trying to update index at the same time ?
    Thanks in advance.

    Rahul Ner wrote:
    I have a table containing around 0.25 million records. It has a time stamp column and its indexed. Now I am deleting records from this table older than one year.
    But this is taking more than 10 minutes. Since I am doing this thorough application (has time out setting for 10 min), I am wondering why it is taking so much time.
    Delete qury is similar to this
    delete from table_name where time_column < (sysdate - 366)
    Is that because it is trying to update index at the same time ?Could you please post a complete DBMS_XPLAN.DISPLAY output including the "Predicate Information" section below the plan. Please use the \ tag before and after as I did here to format it in fixed font. Use the "Quote" button in the message editor to find out how I used it here.
    Make sure that you use appropriate PAGESIZE and LINESIZE settings in SQL*Plus, suggested values are PAGESIZE 999 LINESIZE 130
    How many indexes are on that table?
    Are there any constraints defined on the table resp. any foreign keys pointing to that table that need to checked while deleting?
    Are any triggers defined on the table?
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Query takes long time

    Hi, could anybody help to tune this query,
    select /*+ choose*/ r.com , r.tvalue,
    t_result.info(r.rt_id,r.rt_ver) rp
              from n_result r,
                 (select /*+ choose*/  rt_id, max(rt_ver) max_ver
                               from n_result
                               group by rt_id) re
         where  
         r.s_id = :p_eone
         and    
         r.stat != 'E'
         and
         r.con not in ('R','M')
            and    
         r.rt_id = re.rt_id
         and    
         r.rt_ver = re.max_veExplain Plan
    OPERATION                      OPTIONS                              COST CARDINALITY      BYTES OPTIMIZER      
    SELECT STATEMENT                                                   15417           9        837 HINT: CHOOSE
    HASH JOIN                                                          15417           9        837
    TABLE ACCESS                   BY INDEX ROWID                          5           9        603 ANALYZED       
    INDEX                          RANGE SCAN                              3           9            ANALYZED       
    VIEW                                                               15401     4829027  125554702
    SORT                           GROUP BY                            15401     4829027   48290270
    INDEX                          FULL SCAN                           15401     4916886   49168860 ANALYZED      

    some more information which i can give you,
    oracle version -8.1.7.4.0
    time taken - 4 minutes (same type of queries are more in the package so all together going more than 1 hr)
    and tkprof is
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.02       0.00          0          0          0           0
    Execute      1      0.00       0.01          0          0          0           0
    Fetch        2     61.55     198.77      38475      15406          2           5
    total        4     61.57     198.78      38475      15406          2           5
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 43 
    Rows     Row Source Operation
          5  HASH JOIN
          5   TABLE ACCESS BY INDEX ROWID N_RESULT
          6    INDEX RANGE SCAN (object id 24943)
    4829162   VIEW
    4829162    SORT GROUP BY
    4917021     INDEX FULL SCAN (object id 24892)Thanks

Maybe you are looking for