SQL Query Executing longer time

Hi , The below SQL query executing longer time . Please help to Improve the query performance. The query continuously running for more than 24 hours and failing with roolback segment error. Not getting the final output. Most of the tables are having milions of records.
Select distinct
IBS.ADSL_ACCESS_INFO,
IBS.LIJ ,
regexp_substr(OBVS.REFERENTIE_A,'[[:digit:]]+') as O_NUMBER,
DBS.CKR_NUMMER_CONTRACTANT,
DBS.DNUMBER
FROM CD.IBS,
CD.OIBL,
CD.IH,
CD.ODL,
CD.OH,
CD.DBS,
CD.OBVS
Where IBS.END_DT = To_Date('31129999', 'ddmmyyyy')
AND OIBL.END_DT = to_date('31129999', 'ddmmyyyy')
AND DBS.END_DT = to_date('31129999', 'ddmmyyyy')
AND OBVS.END_DT = to_date('31129999', 'ddmmyyyy')
AND OBVS.REFERENTIE_A LIKE 'OFM%'
AND OIBL.INFRA_KEY = IH.INFRA_KEY
AND OIBL.ORDERS_KEY = OH.ORDERS_KEY
AND IBS.INFH_ID = IH.INFH_ID
AND ODL.ORDH_ID = OH.ORDH_ID
AND DBS.DEBH_ID = ODL.DEBH_ID
AND OBVS.ORDH_ID = ODL.ORDH_ID
Order By IBS.LIJ
All the columns which are present in the where condition are having either Index/key (Primary/unique) except END_DT column.
Please Advise

Predicate pushing can help when it greatlly restricts the number of rows - you must experiment - might not work with all predicates pushed (as shown here)
select distinct
       ibs.adsl_access_info,
       ibs.lij,
       obvs.o_number,
       dbs.ckr_nummer_contractant,
       dbs.dnumber
  from (select infh_id,adsl_access_info,lij
          from cd.ibs
         where end_dt = to_date('31129999','ddmmyyyy')
       ) ibs,
       (select infra_key,orders_key
          from cd.oibl
         where end_dt = to_date('31129999','ddmmyyyy')
       ) oibl,
       (select ordh_id,regexp_substr(obvs.referentie_a,'[[:digit:]]+') as o_number
          from cd.obvs
         where end_dt = to_date('31129999','ddmmyyyy')
           and referentie_a like 'OFM%'
       ) obvs,
       (select debh_id,ckr_nummer_contractant,dnumber
          from cd.dbs
         where end_dt = to_date('31129999','ddmmyyyy')
       ) dbs,
       cd.ih,
       cd.odl,
       cd.oh
where oibl.infra_key = ih.infra_key
   and oibl.orders_key = oh.orders_key
   and ibs.infh_id = ih.infh_id
   and odl.ordh_id = oh.ordh_id
   and dbs.debh_id = odl.debh_id
   and obvs.ordh_id = odl.ordh_id
order by ibs.lijRegards
Etbin

Similar Messages

  • SQL Query taking longer time as seen from Trace file

    Below Query Execution timings:
    Any help will be benefitial as its affecting business needs.
    SELECT MATERIAL_DETAIL_ID
    FROM
    GME_MATERIAL_DETAILS WHERE BATCH_ID = :B1 FOR UPDATE OF ACTUAL_QTY NOWAIT
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.70 0 0 0 0
    Execute 2256 8100.00 24033.51 627 12298 31739 0
    Fetch 2256 900.00 949.82 0 12187 0 30547
    total 4513 9000.00 24984.03 627 24485 31739 30547
    Thanks and Regards

    Thanks Buddy.
    Data Collected from Trace file:
    SELECT STEP_CLOSE_DATE
    FROM
    GME_BATCH_STEPS WHERE BATCH_ID
    IN (SELECT
    DISTINCT BATCH_ID FROM
    GME_MATERIAL_DETAILS START WITH BATCH_ID = :B2 CONNECT BY PRIOR PHANTOM_ID=BATCH_ID)
    AND NVL(STEP_CLOSE_DATE, :B1) > :B1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.54 0 0 0 0
    Execute 2256 800.00 1120.32 0 0 0 0
    Fetch 2256 9100.00 13551.45 396 77718 0 0
    total 4513 9900.00 14672.31 396 77718 0 0
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 66 (recursive depth: 1)
    Rows Row Source Operation
    0 TABLE ACCESS BY INDEX ROWID GME_BATCH_STEPS
    13160 NESTED LOOPS
    6518 VIEW
    6518 SORT UNIQUE
    53736 CONNECT BY WITH FILTERING
    30547 NESTED LOOPS
    30547 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
    30547 TABLE ACCESS BY USER ROWID GME_MATERIAL_DETAILS
    23189 NESTED LOOPS
    53736 BUFFER SORT
    53736 CONNECT BY PUMP
    23189 TABLE ACCESS BY INDEX ROWID GME_MATERIAL_DETAILS
    23189 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
    4386 INDEX RANGE SCAN GME_BATCH_STEPS_U1 (object id 146144)
    In the Package there are lots of SQL Statements using CONNECT BY CLAUSE.
    Does the use of CONNECT BY Clause degrades performance?
    As you can see the Rows Section is 0 but the Query and elapsed time is taking longer
    Regards

  • Sql query taking long time

    the below query is taking very long time.
    select /*+ PARALLEL(a,8) PARALLEL(b,8) */ a.personid,a.winning_id, b.questionid from
    winning_id_cleanup a , rm_personquestion b
    where a.personid = b.personid and (a.winning_id,b.questionid) not in
    (select /*+ PARALLEL(c,8) */ c.personid,c.questionid from rm_personquestion c where c.personid=a.winning_id);
    where the rm_personquestion table is having 45 million rows and winning_id_cleanup is having 1 million rows.
    please tell me how to tune this query?

    Please post u'r query at PL/SQL
    It's not for SQL and PL/SQL

  • SQL Query taking long time....its very urgent !!!

    Hi All,
    Can any body help me out to tune this query... its cost is 62,900.. and thete is full table scan on ap_invoices_all...
    For one invoice ID its taking 20 sccs...
    SELECT /*+ INDEX  ( i2 AP_INVOICES_N8 )  INDEX  ( i1 AP_INVOICES_N8 )   */ DISTINCT ou.name operating_unit,
    NVL(SUBSTR(UPPER(TRANSLATE(i1.invoice_num,'a!@#\/-_$%^&*.','a')),
    1,:P_MATCH_LENGTH),'NomatchKluDge1') match_string,
    UPPER(v.vendor_name) upper_supplier_name,
    i1.invoice_num invoice_number,
    to_char(i1.invoice_date,'DD-MON-YYYY') invoice_date,
    --i1.invoice_date invoice_date,
    NVL(i1.invoice_amount,0) invoice_amount,
    i1.invoice_currency_code currency_code,
    v.segment1 supplier_number,
    v.vendor_name supplier_name,
    ssa.vendor_site_code supplier_code,
    lc.displayed_field invoice_type,
    poh.segment1 po_number,
    (select min(por.release_num)
    from po_releases_all por
    where poh.po_header_id = por.po_header_id) release_num,
    gcc.segment1 location,
    i1.payment_method_code payment_method_code,
    DECODE(LENGTH(TO_CHAR(aca.check_number)),9,aca.check_number,aca.doc_sequence_value) payment_doc_number
    FROM ap_invoices_all i1,
    ap_invoices_all i2,
    ap_suppliers v ,
    ap_supplier_sites_all ssa,
    ap_lookup_codes lc,
    /* (select distinct pha.SEGMENT1, i.PO_HEADER_ID, i.INVOICE_ID
    from ap_invoice_lines_all i
    ,po_headers_all pha
    where pha.PO_HEADER_ID = i.PO_HEADER_ID) poh, */
    po_headers_all poh,
    ap_invoice_lines_all ail,
    ap_invoice_distributions_all aida,
    gl_code_combinations gcc,
    ap_checks_all aca,
    ap_invoice_payments_all ipa,
    hr_all_organization_units ou
    WHERE i1.invoice_id <> i2.invoice_id
    AND NVL(substr(upper(translate(i1.invoice_num,'a!@#\/-_$%^&*.','a')),
    1,:P_MATCH_LENGTH),'NomatchKluDge1')
    = NVL(substr(upper(translate(i2.invoice_num,'a!@#\/-_$%^&*.','a')),
    1,:P_MATCH_LENGTH),'abcdefghijklm')
    --AND i1.creation_date between :p_creation_date_from  and  :p_creation_date_to
    AND i1.cancelled_date IS NULL
    --AND i2.creation_date between  :p_creation_date_from  and  :p_creation_date_to
    AND i2.cancelled_date IS NULL
    AND i1.invoice_amount = nvl(i2.invoice_amount,-1)
    --AND i1.vendor_id      =  i2.vendor_id
    AND i1.vendor_id+0 = i2.vendor_id+0
    AND nvl(i1.vendor_id,-1) = v.vendor_id
    AND i1.invoice_id = aida.invoice_id
    AND aida.distribution_line_number = 1
    AND gcc.code_combination_id = aida.dist_code_combination_id
    AND     lc.lookup_code (+)      = i1.invoice_type_lookup_code
    AND     lc.lookup_type (+)      = 'INVOICE TYPE'
    AND i1.vendor_site_id = ssa.vendor_site_id(+)
    --AND i1.invoice_id = poh.invoice_id (+)
    AND i1.invoice_id = ail.invoice_id
    --AND ail.line_number = 1                                       
    AND aida.INVOICE_LINE_NUMBER = 1
    --AND ail.po_header_id = poh.po_header_id (+)  
    AND ail.po_header_id = poh.po_header_id
    AND ail.INVOICE_ID = aida.INVOICE_ID
    and ail.LINE_NUMBER = aida.INVOICE_LINE_NUMBER
    AND i1.invoice_id = ipa.invoice_id(+)
    AND ipa.check_id = aca.check_id(+)
    AND i1.org_id = ou.organization_id
    and i1.invoice_id = 123456
    ORDER BY upper(v.vendor_name),
    NVL(substr(upper(translate(i1.invoice_num,'a!@#\/-_$%^&*.','a')),
    1,:P_MATCH_LENGTH),'abcdefghijklm'),
    upper(i1.invoice_num);
    Regards
    --Harry                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

    I tried to rewrite this query to format it into something more readable. Since I can't test, this may have introduced syntax errors:
    SELECT /*+ INDEX  ( i2 AP_INVOICES_N8 )  INDEX  ( i1 AP_INVOICES_N8 )   */
           DISTINCT ou.name                             operating_unit,
           NVL(SUBSTR(UPPER(TRANSLATE(i1.invoice_num,
                            'a!@#\/-_$%^&*.','a')),
               1,:P_MATCH_LENGTH),'NomatchKluDge1')     match_string,
           UPPER(v.vendor_name)                         upper_supplier_name,
           i1.invoice_num                               invoice_number,
           to_char(i1.invoice_date,'DD-MON-YYYY')       invoice_date,
           NVL(i1.invoice_amount,0)                     invoice_amount,
           i1.invoice_currency_code                     currency_code,
           v.segment1                                   supplier_number,
           v.vendor_name                                supplier_name,
           ssa.vendor_site_code                         supplier_code,
           lc.displayed_field                           invoice_type,
           poh.segment1                                 po_number,
           (SELECT MIN(por.release_num)
            FROM   po_releases_all por
            WHERE  poh.po_header_id = por.po_header_id) release_num,
           gcc.segment1                                 location,
           i1.payment_method_code                       payment_method_code,
           DECODE(LENGTH(TO_CHAR(aca.check_number)),9,
              aca.check_number,aca.doc_sequence_value)  payment_doc_number
    FROM   ap_invoices_all i1
           INNER JOIN ap_invoices_all i2
             ON   i1.invoice_id = i2.invoice_id
             AND  i1.invoice_amount = NVL(i2.invoice_amount,-1)
             AND  i1.vendor_id+0 = i2.vendor_id+0
           INNER JOIN ap_suppliers v
             ON    NVL(i1.vendor_id,-1) = v.vendor_id
           INNER JOIN ap_lookup_codes lc,
             ON lc.lookup_code  = i1.invoice_type_lookup_code
           INNER JOIN ap_invoice_distributions_all aida
              ON    i1.invoice_id = aida.invoice_id
           INNER JOIN gl_code_combinations gcc
             ON     gcc.code_combination_id = aida.dist_code_combination_id
           INNER JOIN ap_invoice_lines_all ail
             ON     i1.invoice_id = ail.invoice_id
           INNER JOIN po_headers_all poh
             ON     ail.po_header_id = poh.po_header_id
           INNER JOIN hr_all_organization_units ou
             ON     i1.org_id = ou.organization_id
           LEFT JOIN (ap_invoice_payments_all ipa
                       INNER JOIN ap_checks_all aca
                         ON ipa.check_id = aca.check_id)
             ON     i1.invoice_id = ipa.invoice_id
           LEFT JOIN ap_supplier_sites_all ssa,
             ON i1.vendor_site_id = ssa.vendor_site_id
    WHERE  NVL(substr(upper(translate(i1.invoice_num,'a!@#\/-_%^&*.','a')),
                1,:P_MATCH_LENGTH),'NomatchKluDge1')
               = NVL(substr(upper(translate(i2.invoice_num,'a!@#\/-_$%^&*.','a')),
                1,:P_MATCH_LENGTH),'abcdefghijklm')
    AND    i1.cancelled_date IS NULL
    AND    i2.cancelled_date IS NULL
    AND    aida.distribution_line_number = 1
    AND    aida.INVOICE_LINE_NUMBER = 1
    AND    ail.LINE_NUMBER = 1
    AND    lc.lookup_type  = 'INVOICE TYPE'
    AND    i1.invoice_id = 123456
    ORDER BY upper(v.vendor_name),
             NVL(substr(upper(translate(i1.invoice_num,'a!@#\/-_$%^&*.','a')),
              1,:P_MATCH_LENGTH),'abcdefghijklm'),
             upper(i1.invoice_num);I dislike queries in the SELECT clause like the one you have to get RELEASE_NUM. One thing in particular that I see about this on is that this appears to be the only place that anything from the PO_HEADERS_ALL table is used. PO_HEADERS_ALL is only in the query pulled in by the AP_INVOICE_LINES_ALL table. Since the JOIN column used for that is PO_HEADER_ID and that's the same one used in the SELECT clause query, do you really even need the PO_HEADERS_ALL table? This would remove one join at least.
    Your query had "AND aida.INVOICE_LINE_NUMBER = 1" and "AND ail.LINE_NUMBER = aida.INVOICE_LINE_NUMBER". The second needn't reference AIDA, I changed it to "AND ail.LINE_NUMBER = 1". It likely won't make a performance impact, but the SQL is clearer.

  • Select query running long time

    Hi,
    DB version : 10g
    platform : sunos
    My select sql query running long time (more than 20hrs) .Still running .
    Is there any way to find sql query completion time approximately. (Pending time)
    Also is there any possibilities to increase the speed of sql query (already running) like adding hints.
    Please help me on this .
    Thanks

    Hi Sathish thanks for your reply,
    I have already checked in V$SESSION_LONGOPS .But it's showing TIME_REMAINING -->0
    select TOTALWORK,SOFAR,START_TIME,TIME_REMAINING from V$SESSION_LONGOPS where SID='10'
    TOTALWORK      SOFAR START_TIME      TIME_REMAINING
         1099759    1099759 27-JAN-11                    0Any idea ?
    Thanks.

  • How to know if executing a query cost long time

    Hi,
    I have a question about how to figure out if execution of a query takes long time. I am building a web application in java. The back end database is oracle. If a query is too large, I want to put show the user the error message to let the user make more specific query. but how can I tell if the query execution takes long time? Thanks.

    The following link may be of help.
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch3175.htm#1123208

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

  • Query taking long time for EXTRACTING the data more than 24 hours

    Hi ,
    Query taking long time for EXTRACTING the data more than 24 hours please find the query and explain plan details below even indexes avilable on table's goe's to FULL TABLE SCAN. please suggest me.......
    SQL> explain plan for select a.account_id,round(a.account_balance,2) account_balance,
    2 nvl(ah.invoice_id,ah.adjustment_id) transaction_id,
    to_char(ah.effective_start_date,'DD-MON-YYYY') transaction_date,
    to_char(nvl(i.payment_due_date,
    to_date('30-12-9999','dd-mm-yyyy')),'DD-MON-YYYY')
    due_date, ah.current_balance-ah.previous_balance amount,
    decode(ah.invoice_id,null,'A','I') transaction_type
    3 4 5 6 7 8 from account a,account_history ah,invoice i_+
    where a.account_id=ah.account_id
    and a.account_type_id=1000002
    and round(a.account_balance,2) > 0
    and (ah.invoice_id is not null or ah.adjustment_id is not null)
    and ah.CURRENT_BALANCE > ah.previous_balance
    and ah.invoice_id=i.invoice_id(+)
    AND a.account_balance > 0
    order by a.account_id,ah.effective_start_date desc; 9 10 11 12 13 14 15 16
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 544K| 30M| | 693K (20)|
    | 1 | SORT ORDER BY | | 544K| 30M| 75M| 693K (20)|
    |* 2 | HASH JOIN | | 544K| 30M| | 689K (20)|
    |* 3 | TABLE ACCESS FULL | ACCOUNT | 20080 | 294K| | 6220 (18)|
    |* 4 | HASH JOIN OUTER | | 131M| 5532M| 5155M| 678K (20)|
    |* 5 | TABLE ACCESS FULL| ACCOUNT_HISTORY | 131M| 3646M| | 197K (25)|
    | 6 | TABLE ACCESS FULL| INVOICE | 262M| 3758M| | 306K (18)|
    Predicate Information (identified by operation id):
    2 - access("A"."ACCOUNT_ID"="AH"."ACCOUNT_ID")
    3 - filter("A"."ACCOUNT_TYPE_ID"=1000002 AND "A"."ACCOUNT_BALANCE">0 AND
    ROUND("A"."ACCOUNT_BALANCE",2)>0)
    4 - access("AH"."INVOICE_ID"="I"."INVOICE_ID"(+))
    5 - filter("AH"."CURRENT_BALANCE">"AH"."PREVIOUS_BALANCE" AND ("AH"."INVOICE_ID"
    IS NOT NULL OR "AH"."ADJUSTMENT_ID" IS NOT NULL))
    22 rows selected.
    Index Details:+_
    SQL> select INDEX_OWNER,INDEX_NAME,COLUMN_NAME,TABLE_NAME from dba_ind_columns where
    2 table_name in ('INVOICE','ACCOUNT','ACCOUNT_HISTORY') order by 4;
    INDEX_OWNER INDEX_NAME COLUMN_NAME TABLE_NAME
    OPS$SVM_SRV4 P_ACCOUNT ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME ACCOUNT_NAME ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT CUSTOMER_NODE_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT ACCOUNT_TYPE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_ACCOUNT_TYPE ACCOUNT_TYPE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_INVOICE INVOICE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_PREVIOUS_INVOICE PREVIOUS_INVOICE_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_NAME ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 I_LAST_MODIFIED_ACCOUNT LAST_MODIFIED ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_INVOICE_ACCOUNT INVOICE_ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT ACCOUNT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT SEQNR ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_INVOICE INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA CURRENT_BALANCE ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ACCOUNT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_LMOD LAST_MODIFIED ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_PAYMENT PAYMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADJUSTMENT ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_APPLIED_DT APPLIED_DATE ACCOUNT_HISTORY
    OPS$SVM_SRV4 P_INVOICE INVOICE_ID INVOICE
    OPS$SVM_SRV4 U_INVOICE CUSTOMER_INVOICE_STR INVOICE
    OPS$SVM_SRV4 I_LAST_MODIFIED_INVOICE LAST_MODIFIED INVOICE
    OPS$SVM_SRV4 U_INVOICE_ACCOUNT ACCOUNT_ID INVOICE
    OPS$SVM_SRV4 U_INVOICE_ACCOUNT BILL_RUN_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_BILL_RUN BILL_RUN_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_INVOICE_TYPE INVOICE_TYPE_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_CUSTOMER_NODE CUSTOMER_NODE_ID INVOICE
    32 rows selected.
    Regards,
    Bathula
    Oracle-DBA

    I have some suggestions. But first, you realize that you have some redundant indexes, right? You have an index on account(account_name) and also account(account_name, account_id), and also account_history(invoice_id) and account_history(invoice_id, adjustment_id). No matter, I will suggest some new composite indexes.
    Also, you do not need two lines for these conditions:
    and round(a.account_balance, 2) > 0
    AND a.account_balance > 0
    You can just use: and a.account_balance >= 0.005
    So the formatted query isselect a.account_id,
           round(a.account_balance, 2) account_balance,
           nvl(ah.invoice_id, ah.adjustment_id) transaction_id,
           to_char(ah.effective_start_date, 'DD-MON-YYYY') transaction_date,
           to_char(nvl(i.payment_due_date, to_date('30-12-9999', 'dd-mm-yyyy')),
                   'DD-MON-YYYY') due_date,
           ah.current_balance - ah.previous_balance amount,
           decode(ah.invoice_id, null, 'A', 'I') transaction_type
      from account a, account_history ah, invoice i
    where a.account_id = ah.account_id
       and a.account_type_id = 1000002
       and (ah.invoice_id is not null or ah.adjustment_id is not null)
       and ah.CURRENT_BALANCE > ah.previous_balance
       and ah.invoice_id = i.invoice_id(+)
       AND a.account_balance >= .005
    order by a.account_id, ah.effective_start_date desc;You will probably want to select:
    1. From ACCOUNT first (your smaller table), for which you supply a literal on account_type_id. That should limit the accounts retrieved from ACCOUNT_HISTORY
    2. From ACCOUNT_HISTORY. We want to limit the records as much as possible on this table because of the outer join.
    3. INVOICE we want to access last because it seems to be least restricted, it is the biggest, and it has the outer join condition so it will manufacture rows to match as many rows as come back from account_history.
    Try the query above after creating the following composite indexes. The order of the columns is important:create index account_composite_i on account(account_type_id, account_balance, account_id);
    create index acct_history_comp_i on account_history(account_id, invoice_id, adjustment_id, current_balance, previous_balance, effective_start_date);
    create index invoice_composite_i on invoice(invoice_id, payment_due_date);All the columns used in the where clause will be indexed, in a logical order suited to the needs of the query. Plus each selected column is indexed as well so that we should not need to touch the tables at all to satisfy the query.
    Try the query after creating these indexes.
    A final suggestion is to try larger sort and hash area sizes and a manual workarea policy.alter session set workarea_size_policy = manual;
    alter session set sort_area_size = 2147483647;
    alter session set hash_area_size = 2147483647;

  • Is index range scan the reason for query running long time

    I would like to know whether index range scan is the reason for the query running long time. Below is the explain plan. If so, how to optimise it? Please help
    Operation     Object     COST     CARDINALITY     BYTES
    SELECT STATEMENT ()          413     1000     265000
    COUNT (STOPKEY)                    
    FILTER ()                    
    TABLE ACCESS (BY INDEX ROWID)     ORDERS     413     58720     15560800
    INDEX (RANGE SCAN)     IDX_SERV_PROV_ID     13     411709     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1

    The index range scan means that the optimiser has determined that it is better to read the index rather than perform a full table scan. So in answer to your question - quite possibly but the alternative might take even longer!
    The best thing to do is to review your query and check that you need every table included in the query and that you are accessing the tables via the best route. For example if you can access a table via primary key index that would be better than using a non-unique index. But the best way of reducing the time the query takes to run is to give it less tables (and indexes) to read.
    John Seaman
    http://www.asktheoracle.net

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

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

  • How to learn sql query's execution time?

    Hello All,
    I am trying to find out the execution times of deterministic and non-deterministic function. Hence I have run following script and want to compare their execution times etc. Should I use v$sql? If so, which coloumns? Because I couln't find.
    {code}
    create table my_table
    as
    select mod(level,10)*10 col from dual connect by level <= 100 order by 1;
    create or replace function my_det(giris number)
    return number deterministic
    is
      num number;
    begin
      num :=giris*10;
      return num;
    end;
    create or replace function my_func(giris number)
    return number
    is
      num number;
    begin
      num :=giris*10;
      return num;
    end;
    select my_det(col) from my_table;   --First I want to run this query
    select my_func(col) from my_table;  --Then this query
    {code}
    What should I do in order to compare these two in terms of execution, fetch times, etc.?
    Thanks in advance.

    Hello NightWig
    As you're on 11g, if you have queries that take more than a few seconds I'd definitely recommend looking at the real-time SQL monitor (assuming you're appropriately licensed). As the name suggests, it shows the progress of an SQL statement in real-time, breaking down how long each operation has taken with details of rows fetched so far. It also keeps details of recently executed queries for a short while so can see how your changes affect a statement.
    Oracle SQL Monitoring documentation:http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF94543
    Thank you

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

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

  • Query taking long time

    Hi
    I have a query in which, its a 3 table join but takes a long time to execute. I had checked with plan table.. it shows one of the table is FULL ACCESS.
    I have 2 clarifications.
    1. Will the status checking as NULL - (it shouldn't use index)
    2. Is the case statements are recommended for queries.
    Query
    Select .........
    FROM CLIENT LEFT OUTER JOIN INTERNET_LOGIN ON INTERNET_LOGIN.NUM_CLIENT_ID=CLIENT.NUM_CLIENT_ID,
    POLI_MOT.
    WHERE
    POLI_MOT.NUM_CLIENT_ID=CLIENT.NUM_CLIENT_ID
    AND
    (POLI_MOT.CHR_CANCEL_STATUS='N'
    OR
    POLI_MOT.CHR_CANCEL_STATUS IS NULL)
    AND
    CLIENT.NUM_CONTACT_TYPE_ID IN (1,3)
    AND
    (NVL(POLI_MOT.VCH_NEW_IC_NO,'A') =
    CASE WHEN (NVL(null,NULL) IS NULL) THEN
    NVL(POLI_MOT.VCH_NEW_IC_NO,'A')
    ELSE
    NVL(null,NULL)
    END
    OR
    POLI_MOT.VCH_OLD_IC_NO =
    CASE WHEN nvl(null,null) IS NULL THEN
    POLI_MOT.VCH_OLD_IC_NO
    ELSE
    NVL(null,NULL)
    END )
    AND POLI_MOT.VCH_POLICY_NO =
    CASE WHEN UPPER(nvl(NULL,null)) IS NULL THEN
    POLI_MOT.VCH_POLICY_NO
    ELSE
    NVL(NULL,NULL)
    END
    AND POLI_MOT.VCH_VEHICLE_NO =
    CASE WHEN UPPER(NVL('123',NULL)) IS NULL THEN
    POLI_MOT.VCH_VEHICLE_NO
    ELSE
    NVL('123',NULL)
    END

    Hi,
    There is nothing wrong in having a full table access. When you do the explain plan please check for which table costs you the maximun. try to work on that table.
    To tune the performance of your query you can try either indexing or parallel access.
    the syntax for parallel index is
    /*+ PARALLEL("TBL_NM",100) */(any number)...
    for index please use the index name of the table you want to index..
    regards
    Bharath

Maybe you are looking for