Query takes longer to run with indexes.

Here is my situation. I had a query which I use to run in Production (oracle 9.2.0.5) and Reporting database (9.2.0.3). The time taken to run in both databases was almost the same until 2 months ago which was about 2 minutes. Now in production the query does not run at all where as in Reporting it continues to run in about 2 minutes. Some of the things I obsevred in P are 1) the optimizer_index_cost_adj parameter was changed to 20 from 100 in order to improve the performance of a paycalc program about 3 months ago. Even with this parameter being set to 20, the query use to run in 2 minutes until 2 months ago. in the last two months the GL table increased in size from 25 million rows to 27 million rows. With optimizer_index_cost_adj of 20 and Gl table of 25 million rows it runs fine, but with 27 million rows it does not run at all. If I change the value of optimizer_index_cost_adj to 100 then the query runs with 27 million rows in 2 minutes and I found that it uses full table scan. In Reporting database it always used full table sacn as found thru explain plan. CBO determines which scan is best and it uses that. So my question is that by making optimizer_index_cost_adj = 20, does oracle forces it to use index scan when the table size is 27 million rows? Isn't the index scan is not faster than full table scan? In what situation the full table scan is faster than index scan? If I drop all the indexes on the GL table then the query runs faster in production as it uses full table scan. What is the real benefit of changing optimizer_index_cost_adj values? Any input is most welcome.

Isn't the index scan is not faster than full table scan? In what situation the full table scan is faster than index scan? No. It is not about which one is the "+fastest+" as that concept is flawed. How can an index be "faster" than a table for example? Does it have better tires and shinier paint job? ;-)
It is about the amount of I/O that the database needs to perform in order to use that object's contents for resolving/executing that applicable SQL statement.
If the CBO determines that it needs a 100 widgets worth of I/O to scan the index, and then another 100 widgets of I/O to scan the table, it may decide to not use the index at all, as a full table scan will cost only a 180 I/O widgets - 20 less than the combined scanning of index and table.
Also, a full scan can make use of multi-block reads - and this, on most storage/file systems, is faster than single block reads.
So no - a full table scan is NOT a Bad Thing (tm) and not an indicator of a problem. The thing that is of concern is the amount of I/O. The more I/O, the slower the operation. So obviously, we want to make sure that we design SQL that requires the minimal amount of I/O, design a database that support minimal I/O to find the required data (using clusters/partitions/IOTs/indexes/etc), and then check that the CBO also follows suit (which can be the complex bit).
But before questioning the CBO, first question your code and design - and whether or not they provide the optimal (smallest) I/O footprint for the job at hand.

Similar Messages

  • 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 Takes Longer time

    SELECT CAL_EMPCALENDAR.START_DATE as main,
    bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' /' ||
    CAL_EMPCALENDAR.EMPLOYEE_ID as secondary,
    TO_DATE('1-4-2006', 'DD-MM-YYYY') as FROM_DATE,
    TO_DATE('30-4-2006', 'DD-MM-YYYY') as TO_DATE,
    bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' / ' ||
    CAL_EMPCALENDAR.EMPLOYEE_ID as name,
    CAL_EMPCALENDAR.START_DATE as sdate,
    CAL_EMPCALENDAR.OVERTIME_REASON as OTReason,
    CAL_EMPCALENDAR.POSTED_ON as POSTED_ON,
    TO_CHAR(CAL_EMPCALENDAR.START_DATE, 'Dy') as dayname,
    TAM_GET_ADJUSTED_IN(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_in,
    TAM_GET_ADJUSTED_OUT(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_out,
    CAL_EMPCALENDAR.SHIFT_ID AS SHIFT_ABBREV,
    CAL_EMPCALENDAR.LATE_IN,
    CAL_EMPCALENDAR.EARLY_OUT,
    CAL_EMPCALENDAR.UNDER_TIME,
    CAL_EMPCALENDAR.OVERTIME,
    TAM_GET_LEAVE_DESC(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'ALL') Leave,
    CAL_EMPCALENDAR.EMPLOYEE_ID as empid,
    HRM_CURR_CAREER_V.DEPARTMENT_CODE as deptcode,
    BIT_CODEDESC(HRM_CURR_CAREER_V.DEPARTMENT_CODE) as deptname,
    (SELECT shift_id
    FROM CAL_GRPWORKDAY
    WHERE CAL_GRPWORKDAY.calgrp_id =
    (SELECT calgrp_id
    FROM CAL_CALASSIGNMENT
    WHERE employee_id = CAL_EMPCALENDAR.employee_id
    AND CAL_CALASSIGNMENT.START_DATE <=
    CAL_EMPCALENDAR.START_DATE
    AND (CAL_CALASSIGNMENT.END_DATE is null or
    CAL_CALASSIGNMENT.END_DATE >=
    CAL_EMPCALENDAR.START_DATE))
    AND CAL_GRPWORKDAY.start_date = CAL_EMPCALENDAR.start_date) AS shift_id,
    (SELECT max(entry_dt)
    FROM , LV_TXN txn, CAL_EMPDAILYEVENT cale
    WHERE status = 'Approved'
    AND LV_APPSTATUSHIST.application_id = txn.application_id
    AND cale.reference_id = txn.txn_id
    AND cale.empcalendar_id = CAL_EMPCALENDAR.empcalendar_id
    ) AS entry_dt,
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 1
    and BIZUNIT_ID like 'SG')) F1,
    --TAM_GET_ENT_AND_ADJUSTED(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'SG', 1) F1,                            
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 2
    and bizunit_id like 'SG')) F2,
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 3
    and bizunit_id like 'SG')) F3,
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 4
    and bizunit_id like 'SG')) F4,
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 5
    and bizunit_id like 'SG')) F5
    From CAL_EMPCALENDAR, HRM_CURR_CAREER_V, CAL_SHIFT, HRM_EMPLOYEE
    Where CAL_SHIFT.SHIFT_ID(+) = CAL_EMPCALENDAR.ACTUAL_SHIFT_ID
    AND (CAL_EMPCALENDAR.WF_STATUS = 'Approved' Or
    CAL_EMPCALENDAR.WF_STATUS = 'No Action')
    AND CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_EMPLOYEE.EMPLOYEE_ID
    --and CAL_EMPCALENDAR.START_DATE between TO_DATE('1-4-2006','DD-MM-YYYY') AND TO_DATE('31-4-2006','DD-MM-YYYY')
    AND CAL_EMPCALENDAR.START_DATE BETWEEN
    GREATEST(HRM_EMPLOYEE.COMMENCE_DATE,
    TO_DATE('1-4-2006', 'DD-MM-YYYY')) AND
    LEAST(TO_DATE('30-4-2006', 'DD-MM-YYYY'),
    NVL(HRM_EMPLOYEE.CESSATION_DATE,
    TO_DATE('30-4-2006', 'DD-MM-YYYY')))
    And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SG' || '%'
    And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SGTAM001'
    And CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_CURR_CAREER_V.EMPLOYEE_ID
    -- AND HRM_CURR_CAREER_V.DEPARTMENT_CODE like 'DPHR'
    --AND HRM_EMPLOYEE.EMPLOYMENT_TYPE_CODE like '$P!{EmploymentType}'
    --$P!{ExceptionSQL}
    --$P!{iHRFilterClause}
    --order by $P!{OrderBy}
    order by main
    Hi all this query takes a very long time to run.
    On the explain plan the The table in bold letter is using full tablescan rest all go for index scanning.
    Table got Indexe on those CLOMUNS REFERREED
    Oracle version 9.2.0.6
    Message was edited by:
    Maran.E
    Message was edited by:
    Maran.E

    Maran,
    With tags and indentation it should be easiest to analyze at least for you :
    SELECT CAL_EMPCALENDAR.START_DATE as main,
           bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' /' || CAL_EMPCALENDAR.EMPLOYEE_ID as secondary,
           TO_DATE('1-4-2006', 'DD-MM-YYYY') as FROM_DATE,
           TO_DATE('30-4-2006', 'DD-MM-YYYY') as TO_DATE,
           bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' / ' || CAL_EMPCALENDAR.EMPLOYEE_ID as name,
           CAL_EMPCALENDAR.START_DATE as sdate,
           CAL_EMPCALENDAR.OVERTIME_REASON as OTReason,
           CAL_EMPCALENDAR.POSTED_ON as POSTED_ON,
           TO_CHAR(CAL_EMPCALENDAR.START_DATE, 'Dy') as dayname,
           TAM_GET_ADJUSTED_IN(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_in,
           TAM_GET_ADJUSTED_OUT(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_out,
           CAL_EMPCALENDAR.SHIFT_ID AS SHIFT_ABBREV,
           CAL_EMPCALENDAR.LATE_IN,
           CAL_EMPCALENDAR.EARLY_OUT,
           CAL_EMPCALENDAR.UNDER_TIME,
           CAL_EMPCALENDAR.OVERTIME,
           TAM_GET_LEAVE_DESC(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'ALL') Leave,
           CAL_EMPCALENDAR.EMPLOYEE_ID as empid,
           HRM_CURR_CAREER_V.DEPARTMENT_CODE as deptcode,
           BIT_CODEDESC(HRM_CURR_CAREER_V.DEPARTMENT_CODE) as deptname,
           (SELECT shift_id
            FROM   CAL_GRPWORKDAY
            WHERE  CAL_GRPWORKDAY.calgrp_id = (SELECT calgrp_id
                                               FROM   CAL_CALASSIGNMENT
                                               WHERE employee_id = CAL_EMPCALENDAR.employee_id
                                               AND CAL_CALASSIGNMENT.START_DATE <= CAL_EMPCALENDAR.START_DATE
                                               AND (   CAL_CALASSIGNMENT.END_DATE is null
                                                    or CAL_CALASSIGNMENT.END_DATE >= CAL_EMPCALENDAR.START_DATE))
            AND CAL_GRPWORKDAY.start_date = CAL_EMPCALENDAR.start_date) AS shift_id,
           (SELECT max(entry_dt)
            FROM   LV_TXN txn, CAL_EMPDAILYEVENT cale
            WHERE status = 'Approved'
            AND LV_APPSTATUSHIST.application_id = txn.application_id
            AND cale.reference_id = txn.txn_id
            AND cale.empcalendar_id = CAL_EMPCALENDAR.empcalendar_id) AS entry_dt,
           (SELECT ENTITLEMENT + ADJUST
            FROM TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM   TAM_CLAIM_FORMAT
                           WHERE  SEQUENCE = 1
                           and BIZUNIT_ID like 'SG')) F1,
           --TAM_GET_ENT_AND_ADJUSTED(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'SG', 1) F1,
           (SELECT ENTITLEMENT + ADJUST
            FROM TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM   TAM_CLAIM_FORMAT
                           WHERE  SEQUENCE = 2
                           and    bizunit_id like 'SG')) F2,
           (SELECT ENTITLEMENT + ADJUST
            FROM   TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM   TAM_CLAIM_FORMAT
                           WHERE SEQUENCE = 3
                           and   bizunit_id like 'SG')) F3,
           (SELECT ENTITLEMENT + ADJUST
            FROM TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM TAM_CLAIM_FORMAT
                           WHERE SEQUENCE = 4
                           and bizunit_id like 'SG')) F4,
           (SELECT ENTITLEMENT + ADJUST
            FROM TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM TAM_CLAIM_FORMAT
                           WHERE SEQUENCE = 5
                           and bizunit_id like 'SG')) F5
    From CAL_EMPCALENDAR,
         HRM_CURR_CAREER_V,
         CAL_SHIFT,
         HRM_EMPLOYEE
    Where CAL_SHIFT.SHIFT_ID(+) = CAL_EMPCALENDAR.ACTUAL_SHIFT_ID
    AND   (   CAL_EMPCALENDAR.WF_STATUS = 'Approved'
           Or CAL_EMPCALENDAR.WF_STATUS = 'No Action')
    AND   CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_EMPLOYEE.EMPLOYEE_ID
    --and CAL_EMPCALENDAR.START_DATE between TO_DATE('1-4-2006','DD-MM-YYYY') AND TO_DATE('31-4-2006','DD-MM-YYYY')
    AND   CAL_EMPCALENDAR.START_DATE BETWEEN GREATEST(HRM_EMPLOYEE.COMMENCE_DATE, TO_DATE('1-4-2006', 'DD-MM-YYYY'))
                                         AND LEAST(TO_DATE('30-4-2006', 'DD-MM-YYYY'), NVL(HRM_EMPLOYEE.CESSATION_DATE, TO_DATE('30-4-2006', 'DD-MM-YYYY')))
    And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SG' || '%'
    And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SGTAM001'
    And CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_CURR_CAREER_V.EMPLOYEE_ID
    -- AND HRM_CURR_CAREER_V.DEPARTMENT_CODE like 'DPHR'
    --AND HRM_EMPLOYEE.EMPLOYMENT_TYPE_CODE like '$P!{EmploymentType}'
    --$P!{ExceptionSQL}
    --$P!{iHRFilterClause}
    --order by $P!{OrderBy}
    order by mainNicolas.

  • Why NL instead of HJ(query takes long)

    Hi there!
    There are a db(10.2.0.5 RAC), SLES 10 and two schemes.In the first schema query takes very fast:
    SQL> explain plan for
                 select  count(distinct c.unit)
               from quantity_comp_v qc, comps c, noticequant nq, notices_table n,    noticediss nd
                  where
                  c.id = qc.comp
                  and nq.quant = qc.quantity
                  and n.id = nq.note
                  and n.type_id = 2
                       and nq.link = 2
                  and nd.note = n.id
                  and n.trust >=0
                and nd.dis in (select dr.dismbr from disrelflat dr where dr.disgrp = 1080801245);
    Explained.
    Elapsed: 00:00:00.27
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 2567928671
    | Id  | Operation                              | Name                           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                       |                                |     1 |    91 |       |  2099   (4)| 00:00:07 |
    |   1 |  SORT GROUP BY                         |                                |     1 |    91 |       |            |          |
    |*  2 |   HASH JOIN                            |                                | 55203 |  4905K|       |  2099   (4)| 00:00:07 |
    |*  3 |    INDEX RANGE SCAN                    | DISRELFLAT_UI_DISGRP_DISMBR    | 10618 |   155K|       |    54   (2)| 00:00:01 |
    |*  4 |    HASH JOIN                           |                                | 42398 |  3146K|  2984K|  2043   (4)| 00:00:06 |
    |*  5 |     HASH JOIN                          |                                | 42398 |  2484K|       |  1262   (4)| 00:00:04 |
    |*  6 |      HASH JOIN                         |                                | 24173 |  1109K|       |  1022   (4)| 00:00:03 |
    |*  7 |       HASH JOIN                        |                                | 21471 |   650K|       |   951   (3)| 00:00:03 |
    |*  8 |        VIEW                            | index$_join$_004               | 21471 |   314K|       |   783   (3)| 00:00:03 |
    |*  9 |         HASH JOIN                      |                                |       |       |       |            |          |
    |* 10 |          INDEX RANGE SCAN              | NOTICES_TABLE_I_TYPE_ID_TRUST_ | 21471 |   314K|       |   141   (5)| 00:00:01 |
    |  11 |          INDEX FAST FULL SCAN          | NOTICES_TABLE_PK               | 21471 |   314K|       |   832   (2)| 00:00:03 |
    |  12 |        INDEX FAST FULL SCAN            | NOTICEDISS_UI_NOTE_DIS         |   169K|  2647K|       |   162   (4)| 00:00:01 |
    |* 13 |       TABLE ACCESS FULL                | NOTICEQUANT                    | 38141 |   595K|       |    69   (5)| 00:00:01 |
    |  14 |      VIEW                              |                                | 88786 |  1127K|       |   236   (3)| 00:00:01 |
    |  15 |       SORT UNIQUE                      |                                |       |       |       |            |          |
    |  16 |        UNION-ALL                       |                                |       |       |       |            |          |
    |* 17 |         HASH JOIN                      |                                | 23140 |  1355K|       |   130   (8)| 00:00:01 |
    |  18 |          INDEX FAST FULL SCAN          | QUANTITIES_I_ID_OP             | 50822 |   397K|       |    51   (4)| 00:00:01 |
    |* 19 |          HASH JOIN                     |                                | 23057 |  1170K|       |    76   (7)| 00:00:01 |
    |  20 |           INDEX FAST FULL SCAN         | QOPNC_I_ALL                    | 37964 |   481K|       |    55   (2)| 00:00:01 |
    |  21 |           VIEW                         |                                | 23057 |   878K|       |    18   (6)| 00:00:01 |
    |* 22 |            CONNECT BY WITHOUT FILTERING|                                |       |       |       |            |          |
    |  23 |             TABLE ACCESS FULL          | QOPNQ                          | 23057 |   225K|       |    18   (6)| 00:00:01 |
    |* 24 |         HASH JOIN                      |                                | 38100 |   781K|       |   109   (6)| 00:00:01 |
    |  25 |          INDEX FAST FULL SCAN          | QOPNC_I_ALL                    | 37964 |   481K|       |    55   (2)| 00:00:01 |
    |  26 |          INDEX FAST FULL SCAN          | QUANTITIES_I_ID_OP             | 50822 |   397K|       |    51   (4)| 00:00:01 |
    |  27 |     TABLE ACCESS FULL                  | COMPS                          |   218K|  3406K|       |   282   (4)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("ND"."DIS"="DR"."DISMBR")
       3 - access("DR"."DISGRP"=1080801245)
       4 - access("C"."ID"="COMP")
       5 - access("NQ"."QUANT"="ID")
       6 - access("NQ"."NOTE"="N"."ID")
       7 - access("ND"."NOTE"="N"."ID")
       8 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
       9 - access(ROWID=ROWID)
      10 - access("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
      13 - filter("NQ"."LINK"=2)
      17 - access("ID"="RT")
      19 - access("QOP"="QUANTITY")
      22 - access("QUANTITY"=PRIOR "QOP")
      24 - access("ID"="QUANTITY")
    52 rows selected.
    Elapsed: 00:00:00.06
    SQL> In second schema query takes very long:
    PLAN_TABLE_OUTPUT
    Plan hash value: 543063124
    | Id  | Operation                             | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                      |                             |     1 |    92 |   333   (2)| 00:00:01 |
    |   1 |  SORT GROUP BY                        |                             |     1 |    92 |            |          |
    |   2 |   NESTED LOOPS                        |                             |    91 |  8372 |   333   (2)| 00:00:01 |
    |   3 |    NESTED LOOPS                       |                             |    91 |  6916 |   241   (2)| 00:00:01 |
    |   4 |     NESTED LOOPS                      |                             |    52 |  3276 |   189   (2)| 00:00:01 |
    |   5 |      NESTED LOOPS                     |                             |    47 |  2209 |   123   (3)| 00:00:01 |
    |*  6 |       HASH JOIN                       |                             |    81 |  2592 |    42   (8)| 00:00:01 |
    |*  7 |        INDEX RANGE SCAN               | DISRELFLAT_UI_DISGRP_DISMBR |    18 |   288 |     2   (0)| 00:00:01 |
    |   8 |        INDEX FAST FULL SCAN           | NOTICEDISS_UI_NOTE_DIS      | 38127 |   595K|    38   (3)| 00:00:01 |
    |*  9 |       TABLE ACCESS BY INDEX ROWID     | NOTICES_TABLE               |     1 |    15 |     1   (0)| 00:00:01 |
    |* 10 |        INDEX UNIQUE SCAN              | NOTICES_TABLE_PK            |     1 |       |     0   (0)| 00:00:01 |
    |* 11 |      TABLE ACCESS BY INDEX ROWID      | NOTICEQUANT                 |     1 |    16 |     3   (0)| 00:00:01 |
    |* 12 |       INDEX RANGE SCAN                | NOTICEQUANT_UI_NOTE_QUANT   |     1 |       |     1   (0)| 00:00:01 |
    |  13 |     VIEW                              |                             |     2 |    26 |     1   (0)| 00:00:01 |
    |  14 |      SORT UNIQUE                      |                             |       |       |            |          |
    |  15 |       UNION-ALL PARTITION             |                             |       |       |            |          |
    |  16 |        NESTED LOOPS                   |                             |     1 |    60 |    19   (6)| 00:00:01 |
    |  17 |         NESTED LOOPS                  |                             |     1 |    47 |    18   (6)| 00:00:01 |
    |* 18 |          INDEX RANGE SCAN             | QUANTITIES_UI_ID_OP         |     1 |     8 |     2   (0)| 00:00:01 |
    |* 19 |          VIEW                         |                             |     1 |    39 |    16   (7)| 00:00:01 |
    |* 20 |           CONNECT BY WITHOUT FILTERING|                             |       |       |            |          |
    |  21 |            TABLE ACCESS FULL          | QOPNQ                       | 19811 |   193K|    16   (7)| 00:00:01 |
    |* 22 |         INDEX RANGE SCAN              | QOPNC_UI_QUANTITY_NUM_COMP  |     1 |    13 |     1   (0)| 00:00:01 |
    |  23 |        NESTED LOOPS                   |                             |     1 |    21 |     3   (0)| 00:00:01 |
    |* 24 |         INDEX RANGE SCAN              | QUANTITIES_UI_ID_OP         |     1 |     8 |     2   (0)| 00:00:01 |
    |* 25 |         INDEX RANGE SCAN              | QOPNC_UI_QUANTITY_NUM_COMP  |     1 |    13 |     1   (0)| 00:00:01 |
    |  26 |    TABLE ACCESS BY INDEX ROWID        | COMPS                       |     1 |    16 |     1   (0)| 00:00:01 |
    |* 27 |     INDEX UNIQUE SCAN                 | COMPS_UI_ID                 |     1 |       |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       6 - access("ND"."DIS"="DR"."DISMBR")
       7 - access("DR"."DISGRP"=1080801245)
       9 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
      10 - access("ND"."NOTE"="N"."ID")
      11 - filter("NQ"."LINK"=2)
      12 - access("NQ"."NOTE"="N"."ID")
      18 - access("ID"="NQ"."QUANT")
      19 - filter("ID"="RT" AND "RT"="NQ"."QUANT")
      20 - access("QUANTITY"=PRIOR "QOP")
      22 - access("QOP"="QUANTITY")
      24 - access("ID"="NQ"."QUANT")
      25 - access("QUANTITY"="NQ"."QUANT")
           filter("ID"="QUANTITY")
      27 - access("C"."ID"="COMP")As you can see, plans are different. Why? Statistics is up-to-date in both schemas.
    In tkprof trace for the second schema i see strange thing:
    select count(distinct c.unit)
    from quantity_comp_v qc, comps c, noticequant nq, notices_table n,
    noticediss nd
    where
    c.id = qc.comp
    and nq.quant = qc.quantity
    and n.id = nq.note
    and n.type_id = 2
    and nq.link = 2
    and nd.note = n.id
    and n.trust >=0
    and nd.dis in (select dr.dismbr from disrelflat dr where dr.disgrp = 1080801245)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.02       0.02          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        2    558.36     545.39          1     845921          0           1
    total        4    558.38     545.42          1     845921          0           1
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 156
    Rows     Row Source Operation
          1  SORT GROUP BY (cr=845921 pr=1 pw=0 time=545397464 us)
      13865   NESTED LOOPS  (cr=845921 pr=1 pw=0 time=546471010 us)
      13865    NESTED LOOPS  (cr=818189 pr=1 pw=0 time=546290764 us)
      13308     HASH JOIN  (cr=31053 pr=1 pw=0 time=172231 us)
      13308      NESTED LOOPS  (cr=30863 pr=0 pw=0 time=126100 us)
      15326       HASH JOIN  (cr=209 pr=0 pw=0 time=21640 us)
      11522        INDEX RANGE SCAN DISRELFLAT_UI_DISGRP_DISMBR (cr=68 pr=0 pw=0 time=40 us)(object id 634347)
      37432        INDEX FAST FULL SCAN NOTICEDISS_UI_NOTE_DIS (cr=141 pr=0 pw=0 time=50 us)(object id 638914)
      13308       TABLE ACCESS BY INDEX ROWID NOTICES_TABLE (cr=30654 pr=0 pw=0 time=95620 us)
      15326        INDEX UNIQUE SCAN NOTICES_TABLE_PK (cr=15328 pr=0 pw=0 time=41398 us)(object id 638937)
      34391      TABLE ACCESS FULL NOTICEQUANT (cr=190 pr=1 pw=0 time=53 us)
      13865     VIEW  (cr=787136 pr=0 pw=0 time=544908246 us)
      13865      SORT UNIQUE (cr=787136 pr=0 pw=0 time=544893509 us)
      13950       UNION-ALL PARTITION (cr=787136 pr=0 pw=0 time=539509573 us)
       1223        NESTED LOOPS  (cr=733813 pr=0 pw=0 time=539271493 us)
       1233         NESTED LOOPS  (cr=731971 pr=0 pw=0 time=539245389 us)
      13308          INDEX RANGE SCAN QUANTITIES_UI_ID_OP (cr=26647 pr=0 pw=0 time=120240 us)(object id 634738)
       1233          VIEW  (cr=705324 pr=0 pw=0 time=539109785 us)
    275435676           CONNECT BY WITHOUT FILTERING (cr=705324 pr=0 pw=0 time=493869861 us)
    263644788            TABLE ACCESS FULL QOPNQ (cr=705324 pr=0 pw=0 time=163378 us)
       1223         INDEX RANGE SCAN QOPNC_UI_QUANTITY_NUM_COMP (cr=1842 pr=0 pw=0 time=10296 us)(object id 634729)
      12727        NESTED LOOPS  (cr=53323 pr=0 pw=0 time=216730 us)
      13308         INDEX RANGE SCAN QUANTITIES_UI_ID_OP (cr=26647 pr=0 pw=0 time=111770 us)(object id 634738)
      12727         INDEX RANGE SCAN QOPNC_UI_QUANTITY_NUM_COMP (cr=26676 pr=0 pw=0 time=84638 us)(object id 634729)
      13865    TABLE ACCESS BY INDEX ROWID COMPS (cr=27732 pr=0 pw=0 time=235066 us)
      13865     INDEX UNIQUE SCAN COMPS_UI_ID (cr=13867 pr=0 pw=0 time=128663 us)(object id 634315)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      gc current block 3-way                        208        0.00          0.08
      gc current block 2-way                         93        0.00          0.02
      gc cr multi block request                     150        0.00          0.01
      db file sequential read                         1        0.01          0.01
      SQL*Net message from client                     2        0.00          0.00
    ********************************************************************************Cardinality of QOPNQ not real (over 263 millions rows instead of 19 thousands). If i set optimizer_index_cost_adj=400, plan uses HJ and cardinality in tkprof trace is right. Thanks in advance.
    Best regards, Pavel.

    Hi there.
    What I found:
    In schema, where optimizer uses NL:
    SQL> select TABLE_NAME,COLUMN_NAME,NUM_BUCKETS,LAST_ANALYZED from user_tab_col_statistics where table_name in ('DISRELFLAT','NOTICES_TABLE','QOPNQ','COMPS');
    TABLE_NAME           COLUMN_NAME      NUM_BUCKETS LAST_ANALYZED
    COMPS                ID                       254 31-JUL-10
    COMPS                UNIT                     254 31-JUL-10
    COMPS                LOC                       34 31-JUL-10
    COMPS                TIS                      246 31-JUL-10
    COMPS                RTYP                       2 31-JUL-10
    DISRELFLAT           DISGRP                   254 31-JUL-10
    DISRELFLAT           DISMBR                   254 31-JUL-10
    DISRELFLAT           CNT                      174 31-JUL-10
    DISRELFLAT           SPL                       10 31-JUL-10
    DISRELFLAT           DIST                      16 31-JUL-10
    DISRELFLAT           PART                       2 31-JUL-10
    DISRELFLAT           ISA                        2 31-JUL-10
    DISRELFLAT           MIX                        2 31-JUL-10
    DISRELFLAT           CLONAL                     1 31-JUL-10
    NOTICES_TABLE        ID                         1 08-SEP-10
    NOTICES_TABLE        TEXT                       1 08-SEP-10
    NOTICES_TABLE        DESCRIPTION                1 08-SEP-10
    NOTICES_TABLE        TYPE_ID                    4 08-SEP-10
    NOTICES_TABLE        CUSER_ID                   1 08-SEP-10
    NOTICES_TABLE        CDATE                      1 08-SEP-10
    NOTICES_TABLE        TRUST                     10 08-SEP-10
    NOTICES_TABLE        RTYP                       2 08-SEP-10
    NOTICES_TABLE        CHECKEDBY                  1 08-SEP-10
    NOTICES_TABLE        FEATURE_ID                13 08-SEP-10
    QOPNQ                QUANTITY                   1 31-JUL-10
    QOPNQ                NUM                       12 31-JUL-10
    QOPNQ                QOP                        1 31-JUL-10
    27 rows selected.In schema where optimizer uses HJ:
    TABLE_NAME           COLUMN_NAME      NUM_BUCKETS LAST_ANALYZED
    COMPS                ID                       254 28-JUL-10
    COMPS                UNIT                     254 28-JUL-10
    COMPS                LOC                       29 28-JUL-10
    COMPS                TIS                      223 28-JUL-10
    COMPS                RTYP                       2 28-JUL-10
    DISRELFLAT           DISGRP                   254 21-AUG-10
    DISRELFLAT           DISMBR                     1 21-AUG-10
    DISRELFLAT           CNT                      103 21-AUG-10
    DISRELFLAT           SPL                       10 21-AUG-10
    DISRELFLAT           DIST                      11 21-AUG-10
    DISRELFLAT           PART                       2 21-AUG-10
    DISRELFLAT           ISA                        2 21-AUG-10
    DISRELFLAT           MIX                        2 21-AUG-10
    DISRELFLAT           CLONAL                     2 21-AUG-10
    NOTICES_TABLE        ID                         1 09-AUG-10
    NOTICES_TABLE        TEXT                     254 09-AUG-10
    NOTICES_TABLE        DESCRIPTION              254 09-AUG-10
    NOTICES_TABLE        TYPE_ID                    4 09-AUG-10
    NOTICES_TABLE        CUSER_ID                   1 09-AUG-10
    NOTICES_TABLE        CDATE                    254 09-AUG-10
    NOTICES_TABLE        TRUST                      9 09-AUG-10
    NOTICES_TABLE        RTYP                       2 09-AUG-10
    NOTICES_TABLE        CHECKEDBY                  1 09-AUG-10
    NOTICES_TABLE        FEATURE_ID                21 09-AUG-10
    QOPNQ                QUANTITY                   1 28-JUL-10
    QOPNQ                NUM                       10 28-JUL-10
    QOPNQ                QOP                        1 28-JUL-10
    27 rows selected.Then i gathered statistics with estimate_percent=>null,method_opt=>'for all columns size 1'(without histogramms).
    Plan became:
    PLAN_TABLE_OUTPUT
    Plan hash value: 2184582790
    | Id  | Operation                             | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                      |                             |     1 |    91 |   969   (4)| 00:00:03 |
    |   1 |  SORT GROUP BY                        |                             |     1 |    91 |            |          |
    |*  2 |   HASH JOIN                           |                             |   689 | 62699 |   969   (4)| 00:00:03 |
    |*  3 |    HASH JOIN                          |                             |   689 | 51675 |   719   (3)| 00:00:03 |
    |*  4 |     HASH JOIN                         |                             |   392 | 24304 |   549   (2)| 00:00:02 |
    |   5 |      NESTED LOOPS                     |                             |   377 | 17342 |   479   (1)| 00:00:02 |
    |*  6 |       HASH JOIN                       |                             |   435 | 13485 |    43   (7)| 00:00:01 |
    |*  7 |        INDEX RANGE SCAN               | DISRELFLAT_UI_DISGRP_DISMBR |    12 |   180 |     3   (0)| 00:00:01 |
    |   8 |        INDEX FAST FULL SCAN           | NOTICEDISS_UI_NOTE_DIS      | 38127 |   595K|    38   (3)| 00:00:01 |
    |*  9 |       TABLE ACCESS BY INDEX ROWID     | NOTICES_TABLE               |     1 |    15 |     1   (0)| 00:00:01 |
    |* 10 |        INDEX UNIQUE SCAN              | NOTICES_TABLE_PK            |     1 |       |     0   (0)| 00:00:01 |
    |* 11 |      TABLE ACCESS FULL                | NOTICEQUANT                 | 34306 |   536K|    69   (5)| 00:00:01 |
    |  12 |     VIEW                              |                             | 79375 |  1007K|   167   (3)| 00:00:01 |
    |  13 |      SORT UNIQUE                      |                             |       |       |            |          |
    |  14 |       UNION-ALL                       |                             |       |       |            |          |
    |* 15 |        HASH JOIN                      |                             | 19811 |  1160K|    86  (11)| 00:00:01 |
    |  16 |         INDEX FAST FULL SCAN          | QUANTITIES_UI_ID_OP         | 45161 |   352K|    33   (7)| 00:00:01 |
    |* 17 |         HASH JOIN                     |                             | 19811 |  1006K|    51  (10)| 00:00:01 |
    |  18 |          TABLE ACCESS FULL            | QOPNC                       | 34214 |   434K|    33   (7)| 00:00:01 |
    |  19 |          VIEW                         |                             | 19811 |   754K|    16   (7)| 00:00:01 |
    |* 20 |           CONNECT BY WITHOUT FILTERING|                             |       |       |            |          |
    |  21 |            TABLE ACCESS FULL          | QOPNQ                       | 19811 |   193K|    16   (7)| 00:00:01 |
    |* 22 |        HASH JOIN                      |                             | 34214 |   701K|    68   (9)| 00:00:01 |
    |  23 |         TABLE ACCESS FULL             | QOPNC                       | 34214 |   434K|    33   (7)| 00:00:01 |
    |  24 |         INDEX FAST FULL SCAN          | QUANTITIES_UI_ID_OP         | 45161 |   352K|    33   (7)| 00:00:01 |
    |  25 |    TABLE ACCESS FULL                  | COMPS                       |   212K|  3320K|   244   (5)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("C"."ID"="COMP")
       3 - access("NQ"."QUANT"="ID")
       4 - access("NQ"."NOTE"="N"."ID")
       6 - access("ND"."DIS"="DR"."DISMBR")
       7 - access("DR"."DISGRP"=1080801245)
       9 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
      10 - access("ND"."NOTE"="N"."ID")
      11 - filter("NQ"."LINK"=2)
      15 - access("ID"="RT")
      17 - access("QOP"="QUANTITY")
      20 - access("QUANTITY"=PRIOR "QOP")
      22 - access("ID"="QUANTITY")Now,query executes as fast as in first schema.
    Best regards,Pavel.
    Edited by: Pavel E.

  • Query takes long time for first time

    I have a table with 100 million records and another tables with many rows.
    When I ran a query - it's takes about 1 minute to complete, but when I ran it again it takes less than 1 second to complete.
    Why it is happening?
    Thanks,
    Tz.

    Welcome to the forum.
    When you post a question always provide your 4 digit Oracle version. Different versions have different functionality and this can affect your results and the advice you need.
    For performance tuning questions see the FAQ (upper right corner of page) for the information needed for tuning requests.
    >
    When I ran a query
    >
    How did you run it? Did you use sql*plus, sqldeveloper, some other tool?
    What command did you enter?
    Using sql*plus you can get an execution plan for the query by
    SQL> set serveroutput on
    SQL> set autotrace traceonly
    SQL> select * from emp;
    Execution Plan
    Plan hash value: 3956160932
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |    14 |   546 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| EMP  |    14 |   546 |     3   (0)| 00:00:01 |
    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.

  • Query takes 5 min when using Indexes and 1 Second without Indexes !!

    Hi,
    We have been using indexes on all tables until recently when we faced problems with queries like the one below:
    SELECT a.std_id FROM students a, student_degree b, student_course c, course d
    WHERE b.std_id = a.std_id
    AND c.std_id = a.std_id
    AND d.crn = c.crn
    AND b.in_progress = 'Y'
    AND b.major_code = 'ABTC'
    AND a.program_code = 'DP'
    AND a.level_code = 'S2'
    AND a.campus_code = '05'
    AND a.termcode = '200702';
    This query takes more than 5 minutes to return a result, but as soon as we remove indexes on the columns termcode and campus_code,it shows result in 1 second.
    What could be the problem ?, Is there an attribute that need to be set when creating these indexes ?
    Thanks in advance
    Madani

    Thank you Karthik for your reply.Here are the explain plan report (as shown on Oracle 9i Enterprise Manager)
    *1-Explain plan without Indexes:*
    Execution Steps:
    Step # Step Name
    11 SELECT STATEMENT
    10 MERGE JOIN
    7 SORT [JOIN]
    6 NESTED LOOPS
    4 NESTED LOOPS
    1 ERMS.STUDENT_DEGREE TABLE ACCESS [FULL]
    3 ERMS.STUDENTS TABLE ACCESS [BY INDEX ROWID]
    2 ERMS.SYS_C006642 INDEX [UNIQUE SCAN]
    5 ERMS.SYS_C007065 INDEX [RANGE SCAN]
    9 SORT [JOIN]
    8 ERMS.COURSE TABLE ACCESS [FULL]
    Step # Description
    1 This plan step retrieves all rows from table STUDENT_DEGREE.
    2 This plan step retrieves a single ROWID from the B*-tree index SYS_C006642.
    3 This plan step retrieves rows from table STUDENTS through ROWID(s) returned by an index.
    4 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
    5 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SYS_C007065.
    6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
    7 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
    8 This plan step retrieves all rows from table COURSE.
    9 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
    10 This plan step accepts two sets of rows sorted on the join key. By walking both sets of rows in the order of the join key, every distinct pair of rows satisfying the join condition in the WHERE clause is found through a single pass of the row sets.
    11 This plan step designates this statement as a SELECT statement.
    *2-Explain plan with Indexes:* (I added index on column campus_code which is a varchar2 column)
    Execution Steps:
    Step # Step Name
    11 SELECT STATEMENT
    10 MERGE JOIN
    7 SORT [JOIN]
    6 NESTED LOOPS
    4 NESTED LOOPS
    1 ERMS.COURSE TABLE ACCESS [FULL]
    3 ERMS.STUDENTS TABLE ACCESS [BY INDEX ROWID]
    2 ERMS.INDEX_STUDENTS_CAMPUS_CODE INDEX [RANGE SCAN]
    5 ERMS.SYS_C007065 INDEX [RANGE SCAN]
    9 SORT [JOIN]
    8 ERMS.STUDENT_DEGREE TABLE ACCESS [FULL]
    Step # Description
    1 This plan step retrieves all rows from table COURSE.
    2 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index INDEX_STUDENTS_CAMPUS_CODE.
    3 This plan step retrieves rows from table STUDENTS through ROWID(s) returned by an index.
    4 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
    5 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SYS_C007065.
    6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
    7 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
    8 This plan step retrieves all rows from table STUDENT_DEGREE.
    9 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
    10 This plan step accepts two sets of rows sorted on the join key. By walking both sets of rows in the order of the join key, every distinct pair of rows satisfying the join condition in the WHERE clause is found through a single pass of the row sets.
    11 This plan step designates this statement as a SELECT statement.

  • SQL-Command to long to run with SQL*Plus

    Hello to everyone,
    I'm creating a dynamic SQL Script to run with SQL*Plus.
    The Script contains only INSERT Command.
    The point is that the SQL*Plus supports only SQL-Strings (Commands)
    not longer than 2500 Characters.
    I've considered to split the String in Insert- and Update-Command(s),
    but I've would like first to know if there any simpler way to run these
    Commands on SQL*Plus.
    thanx in Advance
    bm

    SQL> create table t(x varchar2(4000));
    Table created.
    SQL> insert into t values (
    '1234567890........0........0........0........0........0........0........0........0......100' ||
    '1234567890........0........0........0........0........0........0........0........0......200' ||
    '1234567890........0........0........0........0........0........0........0........0......300' ||
    '1234567890........0........0........0........0........0........0........0........0......400' ||
    '1234567890........0........0........0........0........0........0........0........0......500' ||
    '1234567890........0........0........0........0........0........0........0........0......600' ||
    '1234567890........0........0........0........0........0........0........0........0......700' ||
    '1234567890........0........0........0........0........0........0........0........0......800' ||
    '1234567890........0........0........0........0........0........0........0........0......900' ||
    '1234567890........0........0........0........0........0........0........0........0.....1000' ||
    '1234567890........0........0........0........0........0........0........0........0.....1100' ||
    '1234567890........0........0........0........0........0........0........0........0.....1200' ||
    '1234567890........0........0........0........0........0........0........0........0.....1300' ||
    '1234567890........0........0........0........0........0........0........0........0.....1400' ||
    '1234567890........0........0........0........0........0........0........0........0.....1500' ||
    '1234567890........0........0........0........0........0........0........0........0.....1600' ||
    '1234567890........0........0........0........0........0........0........0........0.....1700' ||
    '1234567890........0........0........0........0........0........0........0........0.....1800' ||
    '1234567890........0........0........0........0........0........0........0........0.....1900' ||
    '1234567890........0........0........0........0........0........0........0........0.....2000' ||
    '1234567890........0........0........0........0........0........0........0........0.....2100' ||
    '1234567890........0........0........0........0........0........0........0........0.....2200' ||
    '1234567890........0........0........0........0........0........0........0........0.....2300' ||
    '1234567890........0........0........0........0........0........0........0........0.....2400' ||
    '1234567890........0........0........0........0........0........0........0........0.....2500' ||
    '1234567890........0........0........0........0........0........0........0........0.....2600' ||
    '1234567890........0........0........0........0........0........0........0........0.....2700' ||
    '1234567890........0........0........0........0........0........0........0........0.....2800' ||
    '1234567890........0........0........0........0........0........0........0........0.....2900' ||
    '1234567890........0........0........0........0........0........0........0........0.....3000'
    1 row created.try to break your query in multiple lines in order to avoid
    SP2-0027: Input is too long (> 2499 characters) - line ignored

  • Query takes long time to return results.

    I am on Oracle database 10g Enterprise Edition Release 10.2.0.4.0 – 64 bit
    This query takes about 58 seconds to return 180 rows...
             SELECT order_num,
                    order_date,
                    company_num,
                    customer_num,
                    address_type,
                    create_date as address_create_date,
                    contact_name,
                    first_name,
                    middle_init,
                    last_name,
                    company_name,
                    street_address_1,
                    customer_class,
                    city,
                    state,
                    zip_code,
                    country_code,
                    MAX(decode(media_type,
                               'PHH',
                               phone_area_code || '''' || phone_number,
                               NULL)) home_phone,
                    MAX(decode(media_type,
                               'PHW',
                               phone_area_code || '''' || phone_number,
                               NULL)) work_phone,
                    address_seq_num,
                    street_address_2
               FROM (SELECT oh.order_num order_num,
                            oh.order_datetime order_date,
                            oh.company_num company_num,
                            oh.customer_num customer_num,
                            ad.address_type address_type,
                            c.create_date create_date,
                            con.first_name || '''' || con.last_name contact_name,
                            con.first_name first_name,
                            con.middle_init middle_init,
                            con.last_name last_name,
                            ad.company_name company_name,
                            ad.street_address_1 street_address_1,
                            c.customer_class customer_class,
                            ad.city city,
                            ad.state state,
                            ad.zip_code zip_code,
                            ad.country_code,
                            cph.media_type media_type,
                            cph.phone_area_code phone_area_code,
                            cph.phone_number phone_number,
                            ad.address_seq_num address_seq_num,
                            ad.street_address_2 street_address_2
                       FROM reporting_base.gt_gaft_orders gt,
                            doms.us_ordhdr   oh,
                            doms.us_address  ad,
                            doms.us_customer c,
                            doms.us_contact  con,
                            doms.us_contph   cph
                      WHERE oh.customer_num = c.customer_num(+)
                        AND oh.customer_num = ad.customer_num(+)
                        AND (
                               ad.customer_num = c.customer_num
                        AND
                               ad.address_type = 'B'
                         OR   (
                                ad.customer_num = c.customer_num
                        AND
                                ad.address_type = 'S'
                        AND
                            ad.address_seq_num = oh.ship_to_seq_num
                        AND ad.customer_num = con.customer_num(+)
                        AND ad.address_type = con.address_type(+)
                        AND ad.address_seq_num = con.address_seq_num(+)
                        AND con.customer_num = cph.customer_num(+)
                        AND con.contact_id = cph.contact_id(+)
                        AND oh.order_num = gt.order_num
                        AND oh.business_unit_id = gt.business_unit_id)
              GROUP BY order_num,
                       order_date,
                       company_num,
                       customer_num,
                       address_type,
                       create_date,
                       contact_name,
                       first_name,
                       middle_init,
                       last_name,
                       company_name,
                       street_address_1,
                       customer_class,
                       city,
                       state,
                       zip_code,
                       country_code,
                       address_seq_num,
                       street_address_2;This is the explain plan for the query:
    Plan
    SELECT STATEMENT FIRST_ROWS Cost: 21 Bytes: 207 Cardinality: 1
         18 HASH GROUP BY Cost: 21 Bytes: 207 Cardinality: 1
               17 NESTED LOOPS OUTER Cost: 20 Bytes: 207 Cardinality: 1
                     14 NESTED LOOPS OUTER Cost: 16 Bytes: 183 Cardinality: 1
                           11 FILTER
                                 10 NESTED LOOPS OUTER Cost: 12 Bytes: 152 Cardinality: 1
                                       7 NESTED LOOPS OUTER Cost: 8 Bytes: 74 Cardinality: 1
                                             4 NESTED LOOPS OUTER Cost: 5 Bytes: 56 Cardinality: 1
                                                   1 TABLE ACCESS FULL TABLE (TEMP) REPORTING_BASE.GT_GAFT_ORDERS Cost: 2 Bytes: 26 Cardinality: 1
                                                   3 TABLE ACCESS BY INDEX ROWID TABLE DOMS.US_ORDHDR Cost: 3 Bytes: 30 Cardinality: 1
                                                         2 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USORDHDR_IXUPK_ORDNUMBUID Cost: 2 Cardinality: 1
                                             6 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CUSTOMER Cost: 3 Bytes: 18 Cardinality: 1 Partition #: 11
                                                   5 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USCUSTOMER_IXUPK_CUSTNUM Cost: 2 Cardinality: 1
                                       9 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_ADDRESS Cost: 4 Bytes: 156 Cardinality: 2 Partition #: 13
                                             8 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USADDR_IXUPK_CUSTATYPASEQ Cost: 3 Cardinality: 2
                           13 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTACT Cost: 4 Bytes: 31 Cardinality: 1 Partition #: 15
                                 12 INDEX RANGE SCAN INDEX DOMS.USCONT_IX_CNATAS Cost: 3 Cardinality: 1
                     16 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTPH Cost: 4 Bytes: 24 Cardinality: 1 Partition #: 17
                           15 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USCONTPH_IXUPK_CUSTCONTMEDSEQ Cost: 3 Cardinality: 1 Cost is good. All indexes are used. However the time to return the data is very high.
    Any ideas to make the query faster?.
    Thanks

    Hi, here is the tkprof output as requested by Rob..
    TKPROF: Release 10.2.0.4.0 - Production on Mon Jul 13 09:07:09 2009
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    Trace file: axispr1_ora_15293.trc
    Sort options: default
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    SELECT ORDER_NUM, ORDER_DATE, COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE,
      CREATE_DATE AS ADDRESS_CREATE_DATE, CONTACT_NAME, FIRST_NAME, MIDDLE_INIT,
      LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1, CUSTOMER_CLASS, CITY, STATE,
      ZIP_CODE, COUNTRY_CODE, MAX(DECODE(MEDIA_TYPE, 'PHH', PHONE_AREA_CODE ||
      '''' || PHONE_NUMBER, NULL)) HOME_PHONE, MAX(DECODE(MEDIA_TYPE, 'PHW',
      PHONE_AREA_CODE || '''' || PHONE_NUMBER, NULL)) WORK_PHONE, ADDRESS_SEQ_NUM,
       STREET_ADDRESS_2
    FROM
    (SELECT OH.ORDER_NUM ORDER_NUM, OH.ORDER_DATETIME ORDER_DATE, OH.COMPANY_NUM
      COMPANY_NUM, OH.CUSTOMER_NUM CUSTOMER_NUM, AD.ADDRESS_TYPE ADDRESS_TYPE,
      C.CREATE_DATE CREATE_DATE, CON.FIRST_NAME || '''' || CON.LAST_NAME
      CONTACT_NAME, CON.FIRST_NAME FIRST_NAME, CON.MIDDLE_INIT MIDDLE_INIT,
      CON.LAST_NAME LAST_NAME, AD.COMPANY_NAME COMPANY_NAME, AD.STREET_ADDRESS_1
      STREET_ADDRESS_1, C.CUSTOMER_CLASS CUSTOMER_CLASS, AD.CITY CITY, AD.STATE
      STATE, AD.ZIP_CODE ZIP_CODE, AD.COUNTRY_CODE, CPH.MEDIA_TYPE MEDIA_TYPE,
      CPH.PHONE_AREA_CODE PHONE_AREA_CODE, CPH.PHONE_NUMBER PHONE_NUMBER,
      AD.ADDRESS_SEQ_NUM ADDRESS_SEQ_NUM, AD.STREET_ADDRESS_2 STREET_ADDRESS_2
      FROM REPORTING_BASE.GT_GAFT_ORDERS GT, DOMS.US_ORDHDR OH, DOMS.US_ADDRESS
      AD, DOMS.US_CUSTOMER C, DOMS.US_CONTACT CON, DOMS.US_CONTPH CPH WHERE
      OH.ORDER_NUM = GT.ORDER_NUM AND OH.BUSINESS_UNIT_ID = GT.BUSINESS_UNIT_ID
      AND OH.CUSTOMER_NUM = C.CUSTOMER_NUM(+) AND OH.CUSTOMER_NUM =
      AD.CUSTOMER_NUM(+) AND AD.CUSTOMER_NUM = C.CUSTOMER_NUM AND (
      AD.ADDRESS_TYPE = 'B' OR ( AD.ADDRESS_TYPE = 'S' AND AD.ADDRESS_SEQ_NUM =
      OH.SHIP_TO_SEQ_NUM ) ) AND AD.CUSTOMER_NUM = CON.CUSTOMER_NUM(+) AND
      AD.ADDRESS_TYPE = CON.ADDRESS_TYPE(+) AND AD.ADDRESS_SEQ_NUM =
      CON.ADDRESS_SEQ_NUM(+) AND CON.CUSTOMER_NUM = CPH.CUSTOMER_NUM(+) AND
      CON.CONTACT_ID = CPH.CONTACT_ID(+) ) GROUP BY ORDER_NUM, ORDER_DATE,
      COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE, CREATE_DATE, CONTACT_NAME,
      FIRST_NAME, MIDDLE_INIT, LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1,
      CUSTOMER_CLASS, CITY, STATE, ZIP_CODE, COUNTRY_CODE, ADDRESS_SEQ_NUM,
      STREET_ADDRESS_2
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch      257      0.04       0.05         45          0          0        6421
    total      257      0.04       0.05         45          0          0        6421
    Misses in library cache during parse: 0
    Parsing user id: 126
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch      257      0.04       0.05         45          0          0        6421
    total      257      0.04       0.05         45          0          0        6421
    Misses in library cache during parse: 0
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        0      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
        1  user  SQL statements in session.
        0  internal SQL statements in session.
        1  SQL statements in session.
    Trace file: axispr1_ora_15293.trc
    Trace file compatibility: 10.01.00
    Sort options: default
           1  session in tracefile.
           1  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           1  SQL statements in trace file.
           1  unique SQL statements in trace file.
         289  lines in trace file.
          83  elapsed seconds in trace file.Thanks in advance!

  • Query takes long when using UNION

    Hi ,
    I habe a query as follows;
    SELECT
                        '9999' site_id,
                        m.ghi_prov_num provnum,
                           SUBSTR (l.seq_num, 1, 3)provloc,
                        t.dea_number dea,
                            t.license_number statelicensenumber ,
                            n.npi_num npi,
                            m.prefix prefixname,
                            m.lastname lastname,
                            m.firstname firstname,
                            t.middle_name middleinitial,
                            m.suffix suffixname,
                            null clinicname,
                            l.street1 addressline1,
                            l.street2 addressline2,
                            l.city city,
                            l.state state,
                            l.zip5 zip,
                            l.phone phoneprimary,
                            null ext,
                            null fax,
                            null email,
                            null alt_phone,
                            null alt_phone_ext
                     FROM provider m, LOCATION l, npi n,TEMP_VITAL_CACTUS t,test_provider_pin pin
                      WHERE m.ghi_prov_num=l.ghi_prov_num
                          and m.ghi_prov_num=n.ghi_prov_num(+)
                          and m.ghi_prov_num=t.ghi_prov_num(+)
                          and m.tax_id=pin.tax_id
         UNION
          SELECT   
                        '9999', m.ghi_prov_num ,
                            m.location provloc,
                           null  ,
                           null  ,
                            n.npi_num  ,
                            null ,
                            m.lastname ,
                            m.firstname  ,
                            null,
                            null  ,
                            null  ,
                            m.street1  ,
                            m.street2  ,
                            m.city ,
                            m.state  ,
                            m.zip5 ,
                            m.phone  ,
                            null  ,
                            null  ,
                            null  ,
                            null  ,
                            null
                           FROM dental_provider m, npi n,test_provider_pin pin
                       WHERE m.ghi_prov_num=n.tax_id(+)
                           and m.location=n.location(+)
                            and pin.tax_id=m.ghi_prov_num;The query takes for ever;
    But Individual query takes less than a sec to execute.Is there any way can i rewrite the query?
    Please help
    Hena.

    user11253970 wrote:
    But Individual query takes less than a sec to execute.Is there any way can i rewrite the query?Have a feeling you are using Toad/SQL Navigator or similar tool which returns data one screen at a time. If so, then it does not "takes less than a sec to execute" but rather to fetch first screen of rows. When you use UNION Oracle has to return distinct rows from both queries. Therefore it must fetch not just first screen but all rows. To verify, issue first query and in yiour GUI tool click on get last screen. Then you'll know how long whole select takes. Do the same for second query. Also, do you need distinct rows or akll rows? IF all rows, change UNION to UNION ALL.
    SY.

  • Why does it take longer to Save with Layers v. no Layers?

    I've noticed that file save times go way up even with just 1 layer (plus Background) compared to saving with no layers. "Flat" PSDs save very fast, whether to my SSD boot drive, or to my spinny work drive.Is this normal? And can anyone tell me why?
    My scratch disc is on my SSD boot drive. Windows 7 Ultimate fully updated. I have 30GB of RAM and my average file size (open) is around 400MB. I do have the compatibility turned on (otherwise Lightroom doesn't like it), and compression. I understand those will add more time. But why so much more than a "flat" PSD?

    Thanks. I need to rephrase my subject line I guess...
    Obviously, additional layers will take longer to save, because, like you said, each layers is like another image (sorta). HOWEVER, the save time seems to increase EXPONENTIALLY just by adding 1 layer.
    Here's a specific example...
    I'm working on a 7360 x 4912 image which Photoshop says is 206.9M. It takes less than 2 seconds to save the PSD.
    I clicked Ctrl+J to copy the Background layer to a new layer. Now there's the Background layer, plus Layer 1, and now Photoshop tells me it's 206.9M/413.7M. Now it takes 34 seconds to save the PSD!
    So it's not just double, it takes 17x longer!!! Why so much longer?

  • Query takes long time 41 seconds to run how to tune

    my query is simple as follows...i dont know how to tune it..
    cur_memb_count (p_as_of_date IN date)
    is
    select
    count(ip.individual_id) membercount,
    --lpad(re.region_id,2,'0')||lpad('000',3,'0')||lpad( pb.plan_cd,3,'0') group_id,
    substr(pb.plan_cd,1,1)||lpad(re.region_id, 2,'0')||'0000' group_id,
    ipp.legal_entity_id,
    bus.gl_bus_unit_a,
    bus.lob,
    loc.gl_loc_nbr_a,
    prod.gl_product_cd_a,
    prod.gl_fin_argmt_a,pb.plan_type_id ,pb.plan_cd
    from
    plan pb ,region_map re , state_plan_billing spb,
    insured_plan_profile ipp , insured_plan ip ,
    ods.oods_gl_bus_unit bus, ods.oods_gl_loc_nbr loc,
    ods.oods_gl_product_line prod,
    household h,
    employer_household eh
    where
    ipp.residence_st_plan_billing_id = spb.state_plan_billing_id
    and ipp.insured_plan_id = ip.insured_plan_id
    and ip.plan_cd = pb.plan_cd
    and pb.plan_cd=spb.plan_cd
    -- and pb.plan_type_id = loc.lob
    and spb.state_cd = re.state_cd
    and p_as_of_date between ip.insured_plan_effective_date and
    nvl(ip.insured_plan_termination_date,'31-dec-9999')
    and ip.insured_plan_effective_date <>
    nvl(ip.insured_plan_termination_date,'31-dec-9999')
    -- the condition below is necessary. but not enough data to test.when
    uncommented will only give
    -- a few records. try testing it just by uncommenting it.
    --and p_as_of_date between re.region_map_start_date and re.region_map_stop_date
    and loc.lob=prod.lob and loc.lob=bus.lob(+) and loc.company_cd=bus.company_cd(+)
    and p_as_of_date between pb.plan_start_date and pb.plan_stop_date
    and p_as_of_date between ipp.ins_plan_profile_start_date and
    ipp.ins_plan_profile_stop_date
    -- and lpad(re.region_id,2,'0')||lpad('000',3,'0')||lpad(pb.plan_cd,3,'0')
    = loc.group_id
    and substr(pb.plan_cd,1,
    1)||lpad(re.region_id,2,'0')||nvl(employee_id,'0000') =loc.group_id
    and p_household_id_param = h.household_id
    and h.household_id = eh.employer_household_id
    and p_date_param between eh.emp_hhold_start_date and eh.emp_hhold_stop_date
    and insplan.individual_id=housmemb.individual_id(+)
    and eh.delete_ind = 'N'
    group by
    --lpad(re.region_id,2,'0')||lpad('000',3,'0')||lpad(pb.plan_cd,3,'0'),
    substr(pb.plan_cd ,1,1)||lpad(re.region_id,2, '0')||nvl(employee_id,'0000'),

    If many full table scans on big tables consider creating indexes. Or if many index reads consider forcing full table scans :)
    Ah, I just love these tuning questions. "My query is slow. Please make it go fast". Sure, put on these red shoes, click your heels three times and make a wish. Alas, tuning is rather more complicated than that, more of a science than a voodoo rirtual. We would like to help. But we need more data, some concrete figures. Otherwise we're just guessing.
    So, first off, please read the Performance Tuning Guide. Apply some of its techniques. If you still don't understand why your query is running slow, come back to us with table descriptions, volumetrics, indexes, explain plans, stats, timings and tkprof output.
    Good luck, APC

  • Select statement takes very long to run with order by clause.

    Hi all,
    I have a select statement which when I run without the order by clause takes arround 2 minutes to run. But with the order by clause it goes on for ever. I am trying to access the database server through a network which is not too fast.
    The select statement is based on 9 views which are again based on some views. It also has inline views and outer joins. These views and inline views can not be done away with.
    When selected without the order by clause it gives 3215 records.
    Anything like 2 to 3 minutes will be Ok.
    Thanks.
    --Malay                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

    The select statement is as follows :-
    SELECT f.system_name,
    a.signal_type,
    f.sys_signal_name,
    a.bus_desc,
    b.vl_ident,
    b.vl_name,
    b.src_mac,
    b.src_mac_addr,
    b.dest_mac,
    b.dest_mac_addr,
    b.network,
    bb.bufr_size_in_bytes,
    bb.bag_in_ms,
    bb.is_rma_used,
    bb.is_ic_used,
    bb.sub_vl_cnt,
    bb.skew_max_in_ns,
    cc.msg_name,
    c.src_ip,
    c.src_ip_addr,
    c.src_port,
    c.dest_ip,
    c.dest_ip_addr,
    c.dest_port,
    cc.rate_in_ms,
    cc.tx_mode,
    cc.protocol,
    cc.port_type,
    cc.msg_length_in_bytes,
    d.mnemonic,
    d.start_addr32,
    d.lsb,
    d.end_addr32,
    d.msb,
    d.format,
    d.init_value,
    d.fs_mnemonic,
    d.fs_afdx_data_id,
    d.digital_data_id,
    DECODE(
    d.digital_datatype,
    NULL, '',
    'UNUSED', '',
    api$util.concat_column_data(
    'api_'
    || d.digital_datatype,
    'digital_data_id',
    d.digital_data_id,
    bool.FALSE
    ) AS data_details,
    f.connection_id
    || '_'
    || a.digital_bus_id
    || '_'
    || b.afdx_vl_id
    || '_'
    || bb.afdx_output_id
    || '_'
    || c.afdx_frame_id
    || '_'
    || cc.afdx_msg_id
    || '_'
    || d.afdx_data_id AS KEY
    FROM api_afdx a,
    api_afdx_vl b,
    api_afdx_output bb,
    api_afdx_frame c,
    api_afdx_msg cc,
    api_afdx_data d,
    vf_signal e,
    (SELECT DISTINCT aa.signal_id,
    cc.system_name,
    bb.connection_id,
    bb.sys_signal_name
    FROM vf_nodes aa,
    vf_connections bb,
    vf_system cc
    WHERE aa.connection_id = bb.connection_id
    AND bb.system_id = cc.system_id) f
    WHERE e.signal_id = f.signal_id(+)
    AND e.digital_bus_id = a.digital_bus_id
                   AND a.digital_bus_id = bb.digital_bus_id(+)
    AND bb.afdx_output_id = b.afdx_output_id(+)
                   AND b.afdx_vl_id = c.afdx_vl_id(+)
    AND bb.afdx_output_id = cc.afdx_output_id(+)
    AND cc.afdx_msg_id = d.afdx_msg_id(+)
    ORDER BY f.system_name,
    a.signal_type,
    f.sys_signal_name,
    b.vl_name,
    cc.msg_name,
    d.start_addr32,
    d.lsb;
    Where api_afdx ,
    api_afdx_vl ,
    api_afdx_output ,
    api_afdx_frame ,
    api_afdx_msg ,
    api_afdx_data ,
    vf_signal ,
    vf_nodes ,
    vf_connections ,
    vf_system
    are all views.

  • Select query take long time

    Hi All.
    When i execute select query from View it takes about 00:00:45:12 sec to pull the data , but when i execute same query in some other system(different database with same table structure) it takes about 00:00:02:05 sec.
    1)I have tried by dropped and recreated the index then i tried by exec dbms_stats.gather_table_stats procedure still no luck.
    Please help me to understand the reason difference in response time
    Thanks
    sankar

    did you run the EXPLAIN PLAN?

  • Query take long time in fetching when used within a procedure

    The Database is : Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
    Query just takes a second from toad but when used inside a procedure as a cursor it takes takes 3 to 5 minutes.
    Following is the Tkprof information when running from procedure.
    SELECT CHCLP.CLM_PRVDR_TYPE_LKPCD, CHCLP.PRVDR_LCTN_IID, TO_CHAR
    (CHCLP.MODIFIED_DATE, 'MM-dd-yyyy hh24:mi:ss') MODIFIED_DATE,
    CHCLP.PRVDR_LCTN_IDENTIFIER, CHCLP.CLM_HDR_CLM_LN_X_PVDR_LCTN_SID
    FROM
    CLM_HDR_CLM_LN_X_PRVDR_LCTN CHCLP WHERE CHCLP.CLAIM_HEADER_SID = :B1 AND
    CHCLP.CLAIM_LINE_SID IS NULL AND CHCLP.IDNTFR_TYPE_CID = 7
    call count cpu elapsed disk query current rows
    Parse 0 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 110.79 247.79 568931 576111 0 3
    total 2 110.79 247.79 568931 576111 0 3
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 93 (CMSAPP) (recursive depth: 1)
    Rows     Execution Plan
    0 SELECT STATEMENT MODE: ALL_ROWS
    0 PARTITION RANGE (SINGLE) PARTITION:KEYKEY
    0 TABLE ACCESS MODE: ANALYZED (BY LOCAL INDEX ROWID) OF
    'CLM_HDR_CLM_LN_X_PRVDR_LCTN' (TABLE) PARTITION:KEYKEY
    0 INDEX MODE: ANALYZED (RANGE SCAN) OF
    'XAK1CLM_HDR_CLM_LN_X_PRVDR_LCT' (INDEX (UNIQUE))
    PARTITION:KEYKEY
    Execution plan when running just the query from TOAD is: (it comes out in a second)
    Plan
    SELECT STATEMENT ALL_ROWSCost: 6 Bytes: 100 Cardinality: 2                
         3 PARTITION RANGE SINGLE Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 1 Partitions accessed #13          
              2 TABLE ACCESS BY LOCAL INDEX ROWID TABLE CMSAPP.CLM_HDR_CLM_LN_X_PRVDR_LCTN Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 2 Partitions accessed #13     
    Why would fetching take such a long time? Please let me know if you need any other information.
    Thank You.
    Edited by: spur230 on Apr 1, 2009 10:23 AM
    Edited by: spur230 on Apr 1, 2009 10:26 AM
    Edited by: spur230 on Apr 1, 2009 10:28 AM
    Edited by: spur230 on Apr 1, 2009 10:30 AM

    Query just takes a second from toad It's possible that the query starts returning rows in a second, but that's not the time required for the entire query.

Maybe you are looking for

  • Error message when trying to Copy iPhoto Library

    I am trying to backup my iPhoto Library from it's location on a WD external hard drive to another WD external hard drive. The Library is 54GB in size. When I try to copy the library, it copies about 1.1GB then I get this message: "The operation canno

  • WE14 only creat new files

    Hello, we create IDoc-files with the tcode we14. The system which catch the file do this on the next day. The report of the tcode we14 always create a new file. So when I run the report twize a day the second run kll the file of the first run. I don'

  • Where did the time display go and why is the screen stuck on master track? Thanks.

    My time display disappeared and the screen is stuck on master track. Any ideas? Thanks.

  • Making Roll over images from photoshop layout

    Hello Everyone, I am working on a website and I have sliced my parts of my Photoshop file. I have saved as a html with images as well! How would I amek a roll over image out of the buttons I made in photoshop and sliced?

  • Database Authentication Schema Setup

    Hi, Page 13-17 in the User Guide talks about setting up DAD credentials verification. Text is copied below About DAD Credentials Verification DAD database authentication uses the Oracle database native authentication and user mechanisms to authentica