Reading explain plan

Hi
I need some help with explain plan...tried some documents but didnt get the clarity...here is the query...
explain plan for
select ename,dname,grade
from emp,dept,salgrade
where emp.deptno=dept.deptno
and emp.sal between salgrade.losal and salgrade.hisal;
and here is the explain plan for this query..
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | | | |
| 1 | NESTED LOOPS | | | | |
| 2 | NESTED LOOPS | | | | |
| 3 | TABLE ACCESS FULL | SALGRADE | | | |
|* 4 | TABLE ACCESS FULL | EMP | | | |
| 5 | TABLE ACCESS BY INDEX ROWID| DEPT | | | |
|* 6 | INDEX UNIQUE SCAN | PK_DEPT | | | |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
4 - filter("EMP"."SAL"<="SALGRADE"."HISAL" AND "EMP"."SAL">="SALGRADE"
."LOSAL")
6 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
Note: rule based optimization
21 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 COLLECTION ITERATOR (PICKLER FETCH) OF 'DISPLAY'
[i suppose it will remove all the spaces....so sorry .... :-( ]
now i have some questions regarding this like...
1. wat does these * mean with 4 and 6
2. how we come to know that which part got executed first and others after that.....as we draw a tree to represent all the steps....
3. wat is this Predicate Information
4. wat info is given at the last titled "Execution Plan"
please help
thanks
Sidhu

Sidhu,
1. wat does these * mean with 4 and 6It means that predicates are applied during this step. You'll see that there is a 4 and a 6 in the predicate informatiion, to specify the actual predicates being applied. The star is to indicate the presence of a predicate.
2. how we come to know that which part got executed
first and others after that.....as we draw a tree to
represent all the steps....This example is taken from an AskTom thread. In this thread he described in great detail how such a tree should be read. I cannot do it better.
3. wat is this Predicate InformationThe filters that are applied to restrict the result set.
4. wat info is given at the last titled "Execution
Plan"You were probably autotracing the 'select * from table(dbms_xplan.display)' itself. So this section is not relevant.
Regards,
Rob.

Similar Messages

Performace and how to read the plan

Hi all, i am having some problem with a query. i cannot really read the explain plan. here it is
VIEW of "LOT" #4 (Cost=559,177 Card=35,277,895 bytes=30,868,158,125)
UNION-ALL
     HASH JOIN (Cost=558,852 Card=34,981,759 bytes=9,794,892,520)
        TABLE ACCESS (FULL) of "ENT" #27 Optimizer=ANALYZED (Cost=13 Card=6,214 bytes=267,202)
        HASH JOIN (Cost=541,331 Card=34,981,759 bytes=8,290,676,883)
           TABLE ACCESS (FULL) of "SMASTER" #28 Optimizer=ANALYZED (Cost=573 Card=282,970 bytes=17,261,170)
           HASH JOIN (Cost=459,945 Card=34,981,759 bytes=6,156,789,584)
           INLIST ITERATOR
               TABLE ACCESS (BY INDEX ROWID) of "INTERFACES" #29 Optimizer=ANALYZED (Cost=2 Card=5 bytes=100)
                   INDEX (RANGE SCAN) of "INTERFACES_INDX1" UNIQUE Optimizer=ANALYZED (Cost=1 Card=1 bytes=)
           HASH JOIN (Cost=457,468 Card=153,919,741 bytes=24,011,479,596)
           TABLE ACCESS (FULL) of "POS" #25 Optimizer=ANALYZED (Cost=1,819 Card=5,756,878 bytes=132,408,194)
           TABLE ACCESS (FULL) of "L_POS" #26 Optimizer=ANALYZED (Cost=179,932 Card=153,840,627 bytes=20,460,803,391)
TABLE ACCESS (FULL) of "HOLD" #31 Optimizer=ANALYZED (Cost=325 Card=296,136 bytes=40,866,768)can somebody tell me what is happening. what steps gets executed first then next and next, etc? it looks like the cost is a lot and this is hurting the performance.
i know tuning involved a lot such as stats, index use, # of rows, etc.
what i am looking for here is how to read the plan, any idea what this is doing? please explain. also any recommendation to improve the plan base on the plan above. thanks

A quick search in google for oracle reading explain plan
Top hits are very nice writeups...
http://www.akadia.com/services/ora_interpreting_explain_plan.html
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm
vr,
Sudhakar B.

Exactly how bad is this explain plan?

Hi,
I'm on Oracle 9i - 9.2.0.6.0.
First, please excuse my question, I'm not that good at reading explain plans.
I have this explain plan:
| Id | Operation                                 | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)|
|   0 | SELECT STATEMENT                          |                            | 70057 |    20M|       |   114K (12)|
|* 1 | FILTER                                   |                            |       |       |       |            |
|   2 |   TABLE ACCESS FULL                       | DUAL                       |    82 |       |       |     3 (34)|
|* 3 |   INDEX RANGE SCAN                        | CHANGELOG_1                |     1 |    44 |       | 2217   (3)|
|   4 | NESTED LOOPS OUTER                       |                            | 70057 |    20M|       |   114K (12)|
|   5 |   NESTED LOOPS OUTER                      |                            | 67062 |    18M|       |   113K (11)|
|   6 |    NESTED LOOPS OUTER                     |                            | 64194 |    16M|       |   111K (10)|
|   7 |     NESTED LOOPS OUTER                    |                            | 61450 |    14M|       |   110K (9)|
|   8 |      NESTED LOOPS OUTER                   |                            | 58823 |    13M|       |   109K (8)|
|   9 |       NESTED LOOPS OUTER                  |                            | 56308 |    12M|       |   107K (6)|
| 10 |        NESTED LOOPS OUTER                 |                            | 53900 |    11M|       |   106K (5)|
| 11 |         NESTED LOOPS OUTER                |                            | 51596 |    10M|       |   105K (4)|
| 12 |          NESTED LOOPS OUTER               |                            | 49390 | 9212K|       |   104K (3)|
| 13 |           NESTED LOOPS OUTER              |                            | 47278 | 8310K|       |   102K (2)|
|* 14 |            HASH JOIN                      |                            | 31639 | 5067K| 4576K| 7331 (13)|
|* 15 |             HASH JOIN                     |                            | 31639 | 4202K| 1936K| 1372   (9)|
| 16 |              TABLE ACCESS FULL            | COMPANY                    | 76111 | 1040K|       |   335 (15)|
|* 17 |              HASH JOIN                    |                            | 31649 | 3770K|       |   933   (7)|
| 18 |               TABLE ACCESS FULL           | AGREEMENT                  |   149 | 3129 |       |     3 (34)|
|* 19 |               HASH JOIN                   |                            | 31649 | 3121K|       |   928   (6)|
| 20 |                TABLE ACCESS FULL          | CONCRETEAGREEMENT          | 34172 |   333K|       |    55 (24)|
|* 21 |                TABLE ACCESS BY INDEX ROWID| SPECIFICATION              | 31649 | 2812K|       |   866   (4)|
|* 22 |                 INDEX RANGE SCAN          | SPECIFICATION_DATE         | 37437 |       |       |   143   (5)|
| 23 |             TABLE ACCESS FULL             | PERSON                     | 1786K|    47M|       | 4584 (11)|
|* 24 |            TABLE ACCESS BY INDEX ROWID    | INFORMATION                |     1 |    16 |       |     4 (25)|
|* 25 |             INDEX RANGE SCAN              | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 26 |           TABLE ACCESS BY INDEX ROWID     | INFORMATION                |     1 |    11 |       |            |
|* 27 |            INDEX RANGE SCAN               | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 28 |          TABLE ACCESS BY INDEX ROWID      | INFORMATION                |     1 |    14 |       |            |
|* 29 |           INDEX RANGE SCAN                | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 30 |         TABLE ACCESS BY INDEX ROWID       | INFORMATION                |     1 |    14 |       |            |
|* 31 |          INDEX RANGE SCAN                 | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 32 |        TABLE ACCESS BY INDEX ROWID        | INFORMATION                |     1 |    11 |       |            |
|* 33 |         INDEX RANGE SCAN                  | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 34 |       TABLE ACCESS BY INDEX ROWID         | INFORMATION                |     1 |    13 |       |            |
|* 35 |        INDEX RANGE SCAN                   | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 36 |      TABLE ACCESS BY INDEX ROWID          | INFORMATION                |     1 |    12 |       |            |
|* 37 |       INDEX RANGE SCAN                    | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 38 |     TABLE ACCESS BY INDEX ROWID           | INFORMATION                |     1 |    15 |       |            |
|* 39 |      INDEX RANGE SCAN                     | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 40 |    TABLE ACCESS BY INDEX ROWID            | INFORMATION                |     1 |    17 |       |            |
|* 41 |     INDEX RANGE SCAN                      | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 42 |   TABLE ACCESS BY INDEX ROWID             | INFORMATION                |     1 |    17 |       |            |
|* 43 |    INDEX RANGE SCAN                       | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
---------------------------------------------------------------------------------------------------------------------                     I can see that there are some FULL TABLE SCAN, but this may be OK. What worries me is the combination with numerous NESTED LOOPS.
A CTAS for approx 500.000 records out of 14.000.000 runs in about 180 mins. This is too much. My guess is that it should/could be brought down to something like 20 min.
For completeness, the query in question:
SELECT *
FROM stik_spec_inf_v
WHERE spdate >= to_date('15-03-2008', 'dd-mm-yyyy')
   AND spdate < to_date('15-04-2008', 'dd-mm-yyyy');Wher eview is created as
CREATE OR REPLACE FORCE VIEW stik_spec_inf_v
AS
   SELECT CAST(1 AS NUMBER(3)) dataversion
         ,sp.ID AS spid
         ,sp."DATE" AS spdate
         ,sp.valuedate
         ,sp.amount
         ,sp.amountcode
         ,sp.periodstart
         ,sp.periodend
         ,sp.ambcode
         ,sp.state AS spstate
         ,sp."TYPE" AS sptype
         ,sp.respitedate
         ,sp.stopcode
         ,sp.validcode
         ,sp.person
         ,sp.company
         ,sp.concreteagreement
         ,sp.reconciliation
         ,sp.partialscheme
         ,(SELECT 1
             FROM dual
            WHERE EXISTS(
                     SELECT 1
                       FROM changelog
                      WHERE targetclass = 'com.csc.jpay.voucher.Specification'
                        AND targetid = sp.ID)) spchanged
         ,i1.startdate AS daekgagedato
         ,i1.amount AS daekgage
         ,i2.startdate AS prmgagedato
         ,i2.amount AS prmgage
         ,i3.employerpercent
         ,i3.employeepercent
         ,i3.voluntarypercent
         ,i5.salaryperiod
         ,i6.groupcontractcode
         ,i7.workinghourspercent
         ,i9.startdate AS hiringdate
         ,i10.startdate AS resignationdate
         ,i21.policenumber
         ,ix."TYPE" AS leavecode
         ,ix.startdate AS leavestartdate
         ,ix.enddate AS leaveenddate
         ,pe.cpr
         ,pe.ksdid
         ,co.opkr_number
         ,a.NAME AS agreement_name
     FROM SPECIFICATION sp
         ,information i1
         ,information i2
         ,information i3
         ,information i5
         ,information i6
         ,information i7
         ,information i9
         ,information i10
         ,information i21
         ,information ix
         ,person pe
         ,company co
         ,concreteagreement ca
         ,agreement a
    WHERE 1 = 1
      AND i1.SPECIFICATION(+) = sp.ID
      AND i1."TYPE"(+) = 1
      AND i2.SPECIFICATION(+) = sp.ID
      AND i2."TYPE"(+) = 2
      AND i3.SPECIFICATION(+) = sp.ID
      AND i3."TYPE"(+) = 3
      AND i5.SPECIFICATION(+) = sp.ID
      AND i5."TYPE"(+) = 5
      AND i6.SPECIFICATION(+) = sp.ID
      AND i6."TYPE"(+) = 6
      AND i7.SPECIFICATION(+) = sp.ID
      AND i7."TYPE"(+) = 7
      AND i9.SPECIFICATION(+) = sp.ID
      AND i9."TYPE"(+) = 9
      AND i10.SPECIFICATION(+) = sp.ID
      AND i10."TYPE"(+) = 10
      AND i21.SPECIFICATION(+) = sp.ID
      AND i21."TYPE"(+) = 21
      AND ix.SPECIFICATION(+) = sp.ID
      AND ix."TYPE"(+) > 10
      AND ix."TYPE"(+) < 21
      AND pe.ID = sp.person
      AND co.ID = sp.company
      AND ca.ID = sp.concreteagreement
      AND a.ID = ca.agreement;Please excuse my lengthy post. I still hope for some valuable input.
Thanks
Peter

Hi,
I have tried with an in-line view as John suggested. This give a FULL TABLE SCAN on information.
SELECT /*+ RULE */ * FROM (
    SELECT sp.id spid, sp."DATE" spdate
     FROM (SELECT   SPECIFICATION
                   ,max(decode("TYPE", 1, startdate)) daekgagedato
                   ,max(decode("TYPE", 1, amount)) daekgage
                   ,max(decode("TYPE", 2, startdate)) prmgagedato
                   ,max(decode("TYPE", 2, amount)) prmgage
                   ,max(decode("TYPE", 3, employerpercent)) employerpercent
                   ,max(decode("TYPE", 3, employeepercent)) employeepercent
                   ,max(decode("TYPE", 3, voluntarypercent)) voluntarypercent
                   ,max(decode("TYPE", 5, salaryperiod)) salaryperiod
                   ,max(decode("TYPE", 6, groupcontractcode)) groupcontractcode
                   ,max(decode("TYPE", 7, workinghourspercent)) workinghourspercent
                   ,max(decode("TYPE", 9, startdate)) hiringdate
                   ,max(decode("TYPE", 10, startdate)) resignationdate
                   ,max(decode("TYPE", 21, policenumber)) policenumber
                   ,max(decode(sign("TYPE" - 10),1, decode(sign("TYPE" - 21), -1, "TYPE"))) leavecode
                   ,max(decode(sign("TYPE" - 10),1, decode(sign("TYPE" - 21), -1, startdate))) leavestartdate
                   ,max(decode(sign("TYPE" - 10),1, decode(sign("TYPE" - 21), -1, enddate))) leaveenddate
               FROM information
              WHERE TYPE BETWEEN 1 AND 21
           GROUP BY SPECIFICATION) i
         ,SPECIFICATION sp
    WHERE 1 = 1
      AND sp.ID = i.SPECIFICATION)
WHERE spid = 1Any ideas on how to get around that?
Regards
Peter

Query Performance and reading an Explain Plan

Hi,
Below I have posted a query that is running slowly for me - upwards of 10 minutes which I would not expect. I have also supplied the explain plan. I'm fairly new to explain plans and not sure what the danger signs are that I should be looking out for.
I have added indexes to these tables, a lot of which are used in the JOIN and so I expected this to be quicker.
Any help or pointers in the right direction would be very much appreciated -
SELECT a.lot_id, a.route, a.route_rev
FROM wlos_owner.tbl_current_lot_status_dim a, wlos_owner.tbl_last_seq_num b, wlos_owner.tbl_hist_metrics_at_op_lkp c
WHERE a.fw_ver = '2'
AND a.route = b.route
AND a.route_rev = b.route_rev
AND a.fw_ver = b.fw_ver
AND a.route = c.route
AND a.route_rev = c.route_rev
AND a.fw_ver = c.fw_ver
AND a.prod = c.prod
AND a.lot_type = c.lot_type
AND c.step_seq_num >= a.step_seq_num
PLAN_TABLE_OUTPUT
Plan hash value: 2447083104
| Id | Operation           | Name                       | Rows | Bytes | Cost
(%CPU)| Time     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT    |                            |   333 | 33633 | 1347
   (8)| 00:00:17 |
|* 1 | HASH JOIN          |                            |   333 | 33633 | 1347
   (8)| 00:00:17 |
|* 2 |   HASH JOIN         |                            |   561 | 46002 | 1333
   (7)| 00:00:17 |
|* 3 |    TABLE ACCESS FULL| TBL_CURRENT_LOT_STATUS_DIM | 11782 |   517K|   203
   (5)| 00:00:03 |
PLAN_TABLE_OUTPUT
|* 4 |    TABLE ACCESS FULL| TBL_HIST_METRICS_AT_OP_LKP |   178K| 6455K| 1120
   (7)| 00:00:14 |
|* 5 |   TABLE ACCESS FULL | TBL_LAST_SEQ_NUM           | 8301 |   154K|    13
(16)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   1 - access("A"."ROUTE"="B"."ROUTE" AND "A"."ROUTE_REV"="B"."ROUTE_REV" AND
              "A"."FW_VER"=TO_NUMBER("B"."FW_VER"))
   2 - access("A"."ROUTE"="C"."ROUTE" AND "A"."ROUTE_REV"="C"."ROUTE_REV" AND
              "A"."FW_VER"="C"."FW_VER" AND "A"."PROD"="C"."PROD" AND "A"."LOT_T
YPE"="C"."LOT_TYPE")
       filter("C"."STEP_SEQ_NUM">="A"."STEP_SEQ_NUM")
   3 - filter("A"."FW_VER"=2)
PLAN_TABLE_OUTPUT
   4 - filter("C"."FW_VER"=2)
   5 - filter(TO_NUMBER("B"."FW_VER")=2)
24 rows selected.

Guys thank you for your help.
I changed the type of the offending column and the plan looks a lot better and results seem a lot quicker.
However I have added to my SELECT, quite substantially, and have a new explain plan.
There are two sections in particular that have a high cost and I was wondering if you seen anything inherently wrong or can explain more fully what the PLAN_TABLE_OUTPUT descriptions are telling me - in particular
INDEX FULL SCAN
PLAN_TABLE_OUTPUT
Plan hash value: 3665357134
| Id | Operation                        | Name                           | Rows
| Bytes | Cost (%CPU)| Time     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT                 |                                |
4 |   316 |    52   (2)| 00:00:01 |
|* 1 | VIEW                            |                                |
4 |   316 |    52   (2)| 00:00:01 |
|   2 |   WINDOW SORT                    |                                |
4 |   600 |    52   (2)| 00:00:01 |
|* 3 |    TABLE ACCESS BY INDEX ROWID   | TBL_HIST_METRICS_AT_OP_LKP     |
1 |    71 |     1   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|   4 |     NESTED LOOPS                 |                                |
4 |   600 |    51   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                |                                |    7
5 | 5925 |    32   (0)| 00:00:01 |
|* 6 |       INDEX FULL SCAN            | UNIQUE_LAST_SEQ                |    8
9 | 2492 |    10   (0)| 00:00:01 |
|   7 |       TABLE ACCESS BY INDEX ROWID| TBL_CURRENT_LOT_STATUS_DIM     |
PLAN_TABLE_OUTPUT
1 |    51 |     1   (0)| 00:00:01 |
|* 8 |        INDEX RANGE SCAN          | TBL_CUR_LOT_STATUS_DIM_IDX1    |
1 |       |     1   (0)| 00:00:01 |
|* 9 |      INDEX RANGE SCAN            | TBL_HIST_METRIC_AT_OP_LKP_IDX1 |    2
9 |       |     1   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   1 - filter("SEQ"=1)
   3 - filter("C"."FW_VER"=2 AND "A"."PROD"="C"."PROD" AND "A"."LOT_TYPE"="C"."L
OT_TYPE" AND
              "C"."STEP_SEQ_NUM">="A"."STEP_SEQ_NUM")
   6 - access("B"."FW_VER"=2)
       filter("B"."FW_VER"=2)
PLAN_TABLE_OUTPUT
   8 - access("A"."ROUTE"="B"."ROUTE" AND "A"."ROUTE_REV"="B"."ROUTE_REV" AND "A
"."FW_VER"=2)
   9 - access("A"."ROUTE"="C"."ROUTE" AND "A"."ROUTE_REV"="C"."ROUTE_REV")

Generating EXPLAIN PLAN on a database which is opened in READ-ONLY mode

Hi,
I am using Oracle 10.2.0.3 version.
If my database is opened in READ-ONLY mode, means no insert/update/delete operations are permitted here.
While generating EXPLAIN PLAN for any SQL, it does entries in PLAN_TABLE. But my database is opened in READ-ONLY mode, means no inserts can happen.
So how can I generate EXPLAIN PLAN for my SQL in this condition?
Thanks in advance.
Best Regards,
oratest

oratest wrote:
I am using Oracle 10.2.0.3 version.
If my database is opened in READ-ONLY mode, means no insert/update/delete operations are permitted here.
While generating EXPLAIN PLAN for any SQL, it does entries in PLAN_TABLE. But my database is opened in READ-ONLY mode, means no inserts can happen.
So how can I generate EXPLAIN PLAN for my SQL in this condition?
You can always do: "explain plan into some_table@remote_database" to avoid inserting into the local database. Unfortunately 10g added a sequence fetch to the "explain plan" code, and this is where the call would fail if you tried this remote approach on your version.
Here's an idea I haven't tested. If you set up a database link from your production database to the read-only database, you could then do an "explain plan" in the production database for the SQL statement by changing every object reference in the SQL statement to "object@readonlydatabase". In most cases this will allow the optimizer to recognise the statement as "fully remote" and get the optimizer on the readonly database to create the execution plan - which would then be written to the production database.
Regards
Jonathan Lewis

Efficient way to read through big explain plan and genterate html explain plan for sql id's executed in past

Hi,
I have a sql which is recently having a performance problems in Production. I have generated a explain plan for it trying to find out what it is doing but plan itself is close to 1000 lines. I want to check if there is any efficient way to go through big plan like this one and quickly find the damaging areas..
2) I also wanted to know if there is way to generate explain plans in HTML format which executed in past and have entry in dba_hist_sqltext.
3) I also have two sql_monitor reports which I want to compare. is there any efficient way to do it as well?
Please share your thoughts!
Thanks in advance!
Regards,
Suman-

Hi,
I suggest you can try running sql advisor on the query maybe something fruitful comes up
http://www.oracle-base.com/articles/11g/sql-access-advisor-11gr1.php
I am not sure about the explain plan being printed in html format but
You may also want to try the sqlhistory.sql query from below page
http://evdbt.com/scripts/
I have used it many times to check on executions and explain plans which may have changed over the period
I have faced it many times , the query picks up a bad explain plan and performs poorly

Help reading an explain plan

Here is an except from an explain plan.
what does index$_join_002 mean?
| Id | Operation                         | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                  |                             |     1 |    74 |   133K (1)| 00:31:04 |
|* 1 | FILTER                           |                             |       |       |            |          |
|* 2 |   HASH JOIN RIGHT SEMI            |                             | 26855 | 1940K| 10561   (1)| 00:02:28 |
|* 3 |    VIEW                           | index$_join$_002            | 66364 |   907K|   851   (2)| 00:00:12

I am having trouble forcing a good plan. I have 2 databases with comparable data sets and the indexes are the same. One has a good plan and one a bad plan. When I analyze the tables in the database with the good plan, it changes to the bad plan.
Definiton of good plan: returns in 3 seconds
definition of bad plan: returns in 6 minutes.
Note that as soon as i analyzed the tables, I started getting the bad plan. I am at a loss on how to force the plan to change.
BAD PLAN
| Id | Operation                         | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                  |                             |     1 |    70 | 62008   (1)| 00:14:29 |
|* 1 | FILTER                           |                             |       |       |            |          |
|* 2 |   HASH JOIN SEMI                  |                             | 29528 | 2018K| 1501   (1)| 00:00:22 |
|* 3 |    TABLE ACCESS BY INDEX ROWID    | EXT_T                       | 29528 | 1614K| 1344   (0)| 00:00:19 |
|   4 |     DOMAIN INDEX                  | EXT_TEXT_IND                      |       |       | 13441   (0)| 00:03:09 |
|   5 |    MAT_VIEW ACCESS BY INDEX ROWID | KM_MV                    |   107K| 1464K|   155   (0)| 00:00:03 |
|* 6 |     INDEX RANGE SCAN              | KAP_IND                            |   107K|         |   136   (1)| 00:00:02 |good plan. I dont get this when I analyze my tables.
| Id | Operation                         | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                  |                             |     1 |    74 |   133K (1)| 00:31:04 |
|* 1 | FILTER                           |                             |       |       |            |          |
|* 2 |   HASH JOIN RIGHT SEMI            |                             | 26855 | 1940K| 10561   (1)| 00:02:28 |
|* 3 |    VIEW                           | index$_join$_002            | 66364 |   907K|   851   (2)| 00:00:12 |
|* 4 |     HASH JOIN                     |                             |       |       |            |          |
|* 5 |      INDEX RANGE SCAN             | KAP_IND | 66364 |   907K|   105   (1)| 00:00:02 |
|   6 |      INDEX FAST FULL SCAN         | KAP_PK                      | 66364 |   907K|   742   (1)| 00:00:11 |
|* 7 |    TABLE ACCESS BY INDEX ROWID    | EXT_T      | 26855 | 1573K| 9709   (0)| 00:02:16 |
|   8 |     DOMAIN INDEX                  | EXT_TEXT_IND     |       |       | 9709   (0)| 00:02:16 |Edited by: Guess2 on Jul 1, 2009 9:06 AM
Edited by: Guess2 on Jul 1, 2009 9:07 AM
Edited by: Guess2 on Jul 1, 2009 9:07 AM
Edited by: Guess2 on Jul 1, 2009 9:08 AM

Query tunning in Oracle using Explain Plan

Adding to my below question: I have now modified the query and the path shownby 'Explain plan' has reduced. The 'Time' column of plan_table is also showing much lesser value. However, some people are suggesting me to consider the time required by the query to execute on Toad. Will it be practical? Please help!!
Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...
Edited by: 885901 on Sep 20, 2011 2:10 AM

885901 wrote:
Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...how fast is fast enough?

Problems with explain plan and statement

Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AM

tobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
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/

Cpu time is not getting displayed in explain plan

Hi All,
I am trying to analyze one query using explain plan .like below
1) explain plan for
SELECT /*+ parallel(tsp,8) use_hash( tsp tp) */ count(1)
FROM router tp,
receiver tsp
WHERE tp.rs = tsp.rp
AND creater_date >=to_date('04032009000000','ddmmyyyyhh24miss')
and tsp.XVF is not null
and tp.XVF is not null
and tp.role_name='BR';
2)@$ORACLE_HOME/rdbms/admin/utlxpls.sql
But i am getting only following columns in result .
| Id | Operation | Name | Rows | Bytes | Cost |
No Cpu time preset .
How can i extimate CPU time ?
Pls help
Thanks

am_73798 wrote:
I am trying to analyze one query using explain plan .like below
But i am getting only following columns in result .
| Id | Operation | Name | Rows | Bytes | Cost |
No Cpu time preset .
How can i extimate CPU time ?You need to mention your database version (4-digits, e.g. 9.2.0.8).
In Oracle 9i CPU costing is disabled by default, you need to gather WORKLOAD system statistics to enable the CPU costing.
In 10g CPU costing is enabled by default and uses default NOWORKLOAD system statistics if no WORKLOAD system statistics have been gathered. It can only be disabled by setting an undocumented parameter or by changing the OPTIMIZER_FEATURES_ENABLE parameter back to 9i compatibility.
You can check the status of your system statistics by running the following query in SQL*Plus:
column sname format a20
column pname format a20
column pval2 format a20
select
sname
, pname
, pval1
, pval2
from
sys.aux_stats$;Can you show us the actual (complete) output you get from "utlxpls.sql"? Use the \ tag to preserve formatting here:
\output
\will show asoutput
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/

Filter(NULL IS NOT NULL) in Explain Plan ??

Hi All,
Can someone please explain what this explain plan statement means? I see a filter(NULL IS NOT NULL) as the first statement - could not figure out why it came up so from googling.
My Query Used:
EXPLAIN PLAN FOR
MERGE INTO summary_bysrccd
USING
(SELECT LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))) AS SUMMARY_DATE,
os.acctnum,
ol.sourcecode AS sourcecode,
ol.sourcename AS sourcename,
count(1) cnt_articleview
FROM article_views os , master_sourcecode ol
where os.sourcecode = ol.sourcecode
AND os.acctnum IS NOT NULL
AND ol.sourcecode IS NOT NULL
AND os.requestdatetime IS NOT NULL
AND UPPER(os.success_ind) = 'S'
     AND (
          ('INCR' = 'FULL'
          AND (get_date_timestamp(os.requestdatetime) BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS')
          AND   os.entry_CreatedDate BETWEEN TO_DATE('22-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('28-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
          OR ('INCR' = 'FULL'
          AND os.entry_createddate BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS') )
group by LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))),
os.acctnum,ol.sourcecode,ol.sourcename) mrg_query
ON (ods_av_summary_bysrccd.acctnum = mrg_query.acctnum AND
ods_av_summary_bysrccd.summary_date=mrg_query.summary_date AND
ods_av_summary_bysrccd.sourcecode=mrg_query.sourcecode)
WHEN NOT MATCHED THEN
INSERT (SUMMARY_date,ACCTNUM,SOURCECODE,SOURCENAME,CNT_ARTICLEVIEW,ENTRY_LASTUPDATEDDATE)
VALUES(mrg_query.summary_date,mrg_query.acctnum,mrg_query.sourcecode,mrg_query.sourcename,
mrg_query.cnt_articleview,sysdate)
WHEN MATCHED THEN
UPDATE SET ods_av_summary_bysrccd.cnt_articleview=
CASE WHEN NVL('INCR','INCR') = 'FULL' THEN mrg_query.cnt_articleview
ELSE ods_av_summary_bysrccd.cnt_articleview+mrg_query.cnt_articleview
END,
ods_av_summary_bysrccd.entry_lastupdateddate=sysdate;My Explain Plan:
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 268591246
| Id | Operation                                 | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | MERGE STATEMENT                           |                           |     1 |   456 |       |     3   (0)| 00:00:01 |       |       |
|   1 | MERGE                                    | ODS_AV_SUMMARY_BYSRCCD    |       |       |       |            |          |       |       |
|   2 |   VIEW                                    |                           |       |       |       |            |          |       |       |
|   3 |    NESTED LOOPS OUTER                     |                           |     1 |   417 |       |     3   (0)| 00:00:01 |       |       |
|   4 |     VIEW                                  |                           |     1 |   360 |       |     5 (100)| 00:00:01 |       |       |
|   5 |      SORT GROUP BY                        |                           |     1 |    73 |   595M|            |          |       |       |
PLAN_TABLE_OUTPUT
|* 6 |       FILTER                              |                           |       |       |       |            |          |       |       |
|* 7 |        HASH JOIN                          |                           | 6975K|   485M| 3944K| 17594   (1)| 00:03:32 |       |       |
|   8 |         TABLE ACCESS FULL                 | ODS_MASTER_SOURCECODE     | 84021 | 2953K|       |   273   (1)| 00:00:04 |       |       |
|* 9 |         TABLE ACCESS BY GLOBAL INDEX ROWID| ODS_ARTICLE_VIEWS         | 7007K|   247M|       |   826   (0)| 00:00:10 |    33 |    33 |
|* 10 |          INDEX FULL SCAN                  | IDX_AV_ACCTNUM            |    25M|       |       |    26   (0)| 00:00:01 |       |       |
| 11 |     TABLE ACCESS BY GLOBAL INDEX ROWID    | ODS_AV_SUMMARY_BYSRCCD    |     1 |    57 |       |     3   (0)| 00:00:01 | ROWID | ROWID |
|* 12 |      INDEX UNIQUE SCAN                    | ODS_AV_SUMMARY_BYSRCCD_PK |     1 |       |       |     2   (0)| 00:00:01 |       |       |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   6 - filter(NULL IS NOT NULL)
   7 - access("OS"."SOURCECODE"="OL"."SOURCECODE")
   9 - filter("OS"."REQUESTDATETIME" IS NOT NULL AND "OS"."ENTRY_CREATEDDATE">=TO_DATE(' 2011-08-23 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss') AND "OS"."ENTRY_CREATEDDATE"<=TO_DATE(' 2011-08-27 23:59:59', 'syyyy-mm-dd hh24:mi:ss') AND UPPER("OS"."SUCCESS_IND")='S')
10 - filter("OS"."ACCTNUM" IS NOT NULL)
12 - access("ODS_AV_SUMMARY_BYSRCCD"."SUMMARY_DATE"(+)=INTERNAL_FUNCTION("MRG_QUERY"."SUMMARY_DATE") AND
              "ODS_AV_SUMMARY_BYSRCCD"."ACCTNUM"(+)="MRG_QUERY"."ACCTNUM" AND "ODS_AV_SUMMARY_BYSRCCD"."SOURCECODE"(+)="MRG_QUERY"."SOURCECODE")
Note
PLAN_TABLE_OUTPUT
   - dynamic sampling used for this statement

Hi Toon,
Thanks for the quick resolution. I went back and verified the table's colunm details and it has a NOT NULL constraint.
Regards,
Chaitanya
P.S: Is it ok if I ask you for some help regarding a production issue I have been encountering since 15 days but haev no clear resolution yet about what/why is the reason (the said issue is neither uniform nor regular - its affecting some modules and happening on some days - i shall give the full details if you are willing to have a look) - i shall start a new post or email you directly - yur convenience.

How to improve the query performance or tune query from Explain Plan

Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
     8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
          5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
               2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
                    1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
                    3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
          7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
               6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
     10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
          12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
               11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
          14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
               13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
     21 FILTER
          16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
          20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
               18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
                    17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
     23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
          42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
               38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
                    34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
                         30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
                              26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                   25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                        24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
                              29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                   28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                        27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
                         33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                              32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                                   31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
                    37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
                         36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
                              35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
               41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
                    40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
                         39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
          44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
               43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1

damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
          1 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        243 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
       SID
       310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
     VALUE
       163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID        CHILD_NUMBER
04mpgrzhsv72w            0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like   (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
      Please verify value of SQL_ID and CHILD_NUMBER;
      It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
PM:     PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD:   Current where clause predicates in SEL$1 (#0) :
          REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
            : call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

How to change the explain plan for currently running query?

Hi All,
I am using Oracle enterprise 9i edition. I have a query which frames dynamically and running in the database. I noticed a table with 31147758 rows
in the query which has no indexes and taking more time to process. I tried to create an INdex on that table. I know the query is already running with a FULL table scan. Is it possible to change the explain plan for the current running query to consider the INDEX?
[code]
SELECT /*+ USE_HASH (c,e,b,a) */
d.att_fcc extrt_prod_dim_id,
d.att_fcc compr_prod_dim_id,
a.glbl_uniq_id glbl_uniq_id,
to_date(c.dit_code,'RRRRMMDD')STRT_DT,
(to_date(c.dit_code,'RRRRMMDD')+150)END_DT,
a.pat_nbr pat_id,
a.rxer_id       rxer_id,
e.rxer_geog_id rxer_geog_id,
a.pharmy_id pharmy_id,
a.pscr_pack_id pscr_pack_id,
a.dspnsd_pack_id dspnsd_pack_id,
DENSE_RANK () OVER (PARTITION BY a.pat_nbr ORDER BY c.dit_code) daterank,
COUNT( DISTINCT d.att_fcc ) OVER (PARTITION BY a.pat_nbr, c.dit_code) event_cnt
DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
d.att_fcc
ORDER BY c.dit_code) prodrank,
DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
d.att_fcc
ORDER BY c.dit_code DESC) stoprank
FROM
pd_dimitems c,
   pd_pack_attribs   d ,
    lrx_tmp_rxer_geog e,
    lrx_tmp_pat_daterank p,
    lrx_tmp_valid_fact_link     a
    WHERE c.dit_id = a.tm_id
    AND   e.rxer_id = a.rxer_id
    AND   a.glbl_uniq_id = p.glbl_uniq_id
    AND   p.daterank > 1
AND   a.pscr_pack_id = d.att_dit_id
[/code]
The table lrx_tmp_pat_daterank is having that 31147758 rows. So I am wondering how to make the query to use the newly created index on the table?

Why do you think using Indexes will improve the performance of the query? How many rows this query is returning? Optimizer might chose a Full table scan when it finds out that Index plan might not be useful. Why are you using /*+ USE_HASH (c,e,b,a) */ hint? This Hint will force oracle to use Full table scan instead of using the index. Try removing it and see if the plan changes.
Regards,

Explain plan before and after ??

is there a way to find out what sql plan was before and what sqlp plan is right now ?
i know we can look at dba_hist_sql_plan but not sure how to put it all togeather...
i am on 10.2.0.3
i have a sql that running slow right now, i have the sql_id for it now...looks like its runing
slow and last week it was fine...need to know what the explain plan was last week ??

If you are lincenced to use AWR and history tables, you can do this
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('&SQL_ID')); ---to get the SQL execution plan as it was run from history
For the current one, you know how to get it
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('&SQL_ID'));
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('&SQL_ID'));
You can also query dba_hist_sql_plan and format the results.

What are the permissions needed to run explain plans via sql develeper?

Are the permissions the same in Sql Developer to run explain plans like they are when you run them via sql*plus?

Yes same permission because the explain plan does not tie to the tools.

Reading explain plan

Similar Messages

Maybe you are looking for