*** Interpreting this explain plan ***

Hi,
Please find the explain plan for following: I dont understand why rows = 1 in step 4 and 5 of explain plan?? There are 6 rows corresponding to the condition in join that is satisfied in service def table. Still it shows 1??
explain plan for SELECT costpools.cost_pool_id, servicedef.service_name,
costpools.special_calc
FROM cost_pools costpools, service_definitions servicedef
WHERE costpools.service_def_id = servicedef.service_def_id
AND costpools.special_calc = 'Y'
ORDER BY servicedef.service_name;
PLAN_TABLE_OUTPUT
Plan hash value: 3404549211
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 6 | 270 | 15 (7)| 00:00:01 |
| 1 | SORT ORDER BY | | 6 | 270 | 15 (7)| 00:00:01 |
| 2 | NESTED LOOPS | | 6 | 270 | 14 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL | COST_POOLS | 6 | 60 | 8 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| SERVICE_DEFINITIONS | 1 | 35 | 1 (0)| 00:00:0
|* 5 | INDEX UNIQUE SCAN | SERVICE_DEFINITIONS_PK | 1 | | 0 (0)| 00:00:01
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - filter("COSTPOOLS"."SPECIAL_CALC"='Y')
5 - access("COSTPOOLS"."SERVICE_DEF_ID"="SERVICEDEF"."SERVICE_DEF_ID")
18 rows selected.
regds,
s

I mean how is it executed.....there are 6 rows in the
service_def table that satisfies the join condition
right.....so the cardinlity shud be 6 instead of 1
..isnt it??That's not the way it works in an explain plan. It works as SomeoneElse said: an index unique scan as the second step inside a nested loop will retrieve 1 row (index unique scan) but 6 times (nested loop). In the plan you'll see a "1". However, if you look at the row source operation in tkprof, it will tell you how many rows were flowing through this step in total, so here it reports 6.
SQL> create table cost_pools
  2  as
  3   select level cost_pool_id
  4        , 'Y' special_calc
  5        , level service_def_id
  6     from dual
  7  connect by level <= 6
  8  /
Tabel is aangemaakt.
SQL> create table service_definitions
  2  as
  3   select 'A' service_name
  4        , level service_def_id
  5     from dual
  6  connect by level <= 10000
  7  /
Tabel is aangemaakt.
SQL> alter table service_definitions add constraint service_definitions_pk primary key (service_def_id)
  2  /
Tabel is gewijzigd.
SQL> exec dbms_stats.gather_table_stats(user,'cost_pools')
PL/SQL-procedure is geslaagd.
SQL> exec dbms_stats.gather_table_stats(user,'service_definitions',cascade=>true)
PL/SQL-procedure is geslaagd.
SQL> explain plan
  2  for
  3  SELECT costpools.cost_pool_id, servicedef.service_name,
  4  costpools.special_calc
  5  FROM cost_pools costpools, service_definitions servicedef
  6  WHERE costpools.service_def_id = servicedef.service_def_id
  7  AND costpools.special_calc = 'Y'
  8  ORDER BY servicedef.service_name
  9  /
Uitleg is gegeven.
SQL> select * from table(dbms_xplan.display)
  2  /
PLAN_TABLE_OUTPUT
| Id  | Operation                     |  Name                   | Rows  | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT              |                         |     6 |    78 |     5  (20)|
|   1 |  SORT ORDER BY                |                         |     6 |    78 |     5  (20)|
|   2 |   NESTED LOOPS                |                         |     6 |    78 |     4   (0)|
|*  3 |    TABLE ACCESS FULL          | COST_POOLS              |     6 |    48 |     3  (34)|
|   4 |    TABLE ACCESS BY INDEX ROWID| SERVICE_DEFINITIONS     |     1 |     5 |     2  (50)|
|*  5 |     INDEX UNIQUE SCAN         | SERVICE_DEFINITIONS_PK  |     1 |       |            |
Predicate Information (identified by operation id):
   3 - filter("COSTPOOLS"."SPECIAL_CALC"='Y')
   5 - access("COSTPOOLS"."SERVICE_DEF_ID"="SERVICEDEF"."SERVICE_DEF_ID")
17 rijen zijn geselecteerd.
SQL> alter session set sql_trace true
  2  /
Sessie is gewijzigd.
SQL> SELECT costpools.cost_pool_id, servicedef.service_name,
  2  costpools.special_calc
  3  FROM cost_pools costpools, service_definitions servicedef
  4  WHERE costpools.service_def_id = servicedef.service_def_id
  5  AND costpools.special_calc = 'Y'
  6  ORDER BY servicedef.service_name
  7  /
                          COST_POOL_ID S S
                                     1 A Y
                                     2 A Y
                                     3 A Y
                                     4 A Y
                                     5 A Y
                                     6 A Y
6 rijen zijn geselecteerd.
SQL> disconnectAnd now tkprof shows you:
SELECT costpools.cost_pool_id, servicedef.service_name,
costpools.special_calc
FROM cost_pools costpools, service_definitions servicedef
WHERE costpools.service_def_id = servicedef.service_def_id
AND costpools.special_calc = 'Y'
ORDER BY servicedef.service_name
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        4      0.00       0.00          1         17          0           6
total        6      0.00       0.00          1         17          0           6
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 9833
Rows     Row Source Operation
      6  SORT ORDER BY
      6   NESTED LOOPS
      6    TABLE ACCESS FULL OBJ#(2702816)
      6    TABLE ACCESS BY INDEX ROWID OBJ#(2702817)
      6     INDEX UNIQUE SCAN OBJ#(2702818) (object id 2702818)
********************************************************************************Regards,
Rob.

Similar Messages

  • 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

  • Interpretation of Explain Plan

    Hi All,
    I am trying to optimize my query. Can anybody tell me where can I get documentation for How to interpret the output Generated by Explain Plan.
    TIA
    Dharmesh Patel

    Hi,
    You can find some useful documents on metalink, for example try Note:32951.1. Try searching on key words such as "Explain Plan" and "Optimiser".
    HTH,
    Gerard Kelly

  • Interpreting the Explain plan

    DB version : 10.2.0.4
    After looking for Full Table Scan (in Large tables) , what is the next thing i should be looking for in an Explain Plan?

    Take the explain plan as an idea a tourist has to collect a bunch of stuff in your hometown. You ( as a local guy) will see quite quickly if the idea of collecting everything on the main routes in big shops by car (hash join) or doing a walk in one or two streets with small shops (nested loop) will perform better. Stangers will not.
    ORACLE already knows more about the data than a tourist about your hometome, so if it uses a method which is "suboptimal" it needs someone with good knowlage about the data to do better. So make sure you know your datamodel, contents, indexes, data and then you can help ORACLE with additional indexes, hints etc. without knowlege every plan of ORACLE can not be juged.

  • How can i reduce the cost of this explain plan

    Plan
    SELECT STATEMENT  ALL_ROWSCost: 180,804  Bytes: 984,239,144  Cardinality:
    Edited by: user565033 on Dec 11, 2008 8:05 AM
    Edited by: user565033 on Dec 11, 2008 8:06 AM
    Edited by: user565033 on Dec 12, 2008 1:22 PM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

    user565033 wrote:
    2. i am trying to use this query to create a materialized view. My problem is this query returns in under 5mins. But when i try to create the view ( or even a regular table), it goes in a long-op ( sort ouput) whoes time itself is over 4-5 hrs.If it takes 5 min. to return the first rows, but hours to process the complete result set, this suggests that the problem is very likely caused by the function calls, since the sort of the result set must have already been performed to return the first rows and the function calls will probably be performed using the final result set. Try to perform the same without any function calls and check if you can build then a table more quickly.
    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/

  • Help with interpreting explain plan (dbms_xplan) output

    Hi all,
    I'm trying to get to grips with reading and interpreting the explain plan or dbms_xplan output, and so I hope someone can help with the output below.
    So, with the explain shown below, does it mean that...
    a) it starts with step 8 and sends all rows to the nested loop in step 5
    b) it only sends (or thinks it sends) 1 row to step 5 from step 8
    c) For each row supplied from step 5, there will be an index lookup at step 8 to access the table at step 6
    d) Step 8 only gets (or think it gets) 1 row
    If it does mean that only 1 row is expected by the optimizer, and yet the full table scan should return 150,000 records, and the table has up to date statistiucs, what else would cause the cardinality to be so far off?
    If it doesn't mean it will return 1 row then what does it mean ?
    | Id  | Operation                           | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                    |                                |       |       |   945 (100)|          |
    |   1 |  SORT GROUP BY                      |                                |     1 |   283 |   945   (3)| 00:00:05 |
    |*  2 |   FILTER                            |                                |       |       |            |          |
    |   3 |    NESTED LOOPS                     |                                |       |       |            |          |
    |   4 |     NESTED LOOPS                    |                                |     1 |   283 |   944   (3)| 00:00:05 |
    |   5 |      NESTED LOOPS                   |                                |     1 |   108 |   929   (3)| 00:00:05 |
    |*  6 |       MAT_VIEW ACCESS FULL          | DEMOGRAPHICS_MV                |     1 |    97 |   927   (3)| 00:00:05 |
    |*  7 |       MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV                       |     1 |    11 |     2   (0)| 00:00:01 |
    |*  8 |        INDEX RANGE SCAN             | ORG_MV_IDX1                    |     1 |       |     1   (0)| 00:00:01 |
    |*  9 |      INDEX RANGE SCAN               | PAY_IDX8                       |   252 |       |     4   (0)| 00:00:01 |
    |* 10 |     TABLE ACCESS BY INDEX ROWID     | PAY_ALL                        |     1 |   175 |    15   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
          8 - access("ORG_MV"."ORG_ID"="DEMO_MV"."ORG_ID")Many thanks for your help.

    Thank you Hemant and rp0428,
    I read through that white paper which was really useful.
    I ran query using GATHER_PLAN_STATISTICS and go tthe Estimate and Actual rows - wow - it is a long way out!!
    | Id  | Operation                           | Name                           | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    |   0 | SELECT STATEMENT                    |                                |      1 |        |       |   945 (100)|          |      0 |00:18:11.39 |    2552K|    361K|       |       |          |
    |   1 |  SORT GROUP BY                      |                                |      1 |      1 |   283 |   945   (3)| 00:00:05 |      0 |00:18:11.39 |    2552K|    361K|  1024 |  1024 |          |
    |*  2 |   FILTER                            |                                |      1 |        |       |            |          |      0 |00:18:11.39 |    2552K|    361K|       |       |          |
    |   3 |    NESTED LOOPS                     |                                |      1 |        |       |            |          |      0 |00:18:11.39 |    2552K|    361K|       |       |          |
    |   4 |     NESTED LOOPS                    |                                |      1 |      1 |   283 |   944   (3)| 00:00:05 |     44M|00:04:59.03 |     598K|  63442 |       |       |          |
    |   5 |      NESTED LOOPS                   |                                |      1 |      1 |   108 |   929   (3)| 00:00:05 |    109K|00:00:01.73 |    7807 |      7 |       |       |          |
    |*  6 |       MAT_VIEW ACCESS FULL          | DEMOGRAPHICS_MV                |      1 |      1 |    97 |   927   (3)| 00:00:05 |    126K|00:00:00.26 |    5417 |      1 |       |       |          |
    |*  7 |       MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV                       |    126K|      1 |    11 |     2   (0)| 00:00:01 |    109K|00:00:01.27 |    2390 |      6 |       |       |          |
    |*  8 |        INDEX RANGE SCAN             | ORG_MV_IDX1                    |    126K|      1 |       |     1   (0)| 00:00:01 |    126K|00:00:00.69 |    2023 |      6 |       |       |          |
    |*  9 |      INDEX RANGE SCAN               | PAY_IDX8                       |    109K|    252 |       |     4   (0)| 00:00:01 |     44M|00:04:03.07 |     590K|  63435 |       |       |          |
    |* 10 |     TABLE ACCESS BY INDEX ROWID     | PAY_ALL                        |     44M|      1 |   175 |    15   (0)| 00:00:01 |      0 |00:13:09.85 |    1954K|    297K|       |       |          |
    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------When I unravel the WHERE clause and remove the decode(nvl statements (which only evaluate the passed in parameters and provide default values where they are NULL) I get a much better plan and values
    | Id  | Operation                        | Name                           | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    |   0 | SELECT STATEMENT                 |                                |      1 |        |       |   157K(100)|          |      0 |00:00:43.10 |     343K|  45190 |       |       |          |
    |   1 |  SORT GROUP BY                   |                                |      1 |      1 |   283 |   157K  (1)| 00:13:47 |      0 |00:00:43.10 |     343K|  45190 |  1024 |  1024 |          |
    |   2 |   NESTED LOOPS                   |                                |      1 |        |       |            |          |      0 |00:00:43.10 |     343K|  45190 |       |       |          |
    |   3 |    NESTED LOOPS                  |                                |      1 |      1 |   283 |   157K  (1)| 00:13:47 |      0 |00:00:43.10 |     343K|  45190 |       |       |          |
    |*  4 |     HASH JOIN                    |                                |      1 |      1 |   272 |   157K  (1)| 00:13:47 |      0 |00:00:43.10 |     343K|  45190 |   720K|   720K|  171K (0)|
    |*  5 |      TABLE ACCESS BY INDEX ROWID | PAY_ALL                        |      1 |      2 |   350 |   156K  (1)| 00:13:43 |      0 |00:00:43.10 |     343K|  45190 |       |       |          |
    |*  6 |       INDEX RANGE SCAN           | PAY_IDX7                       |      1 |   3596K|       | 15565   (1)| 00:01:22 |   7251K|00:00:50.88 |   45190 |  45190 |       |       |          |
    |*  7 |      MAT_VIEW ACCESS FULL        | DEMOGRAPHICS_MV                |      0 |    126K|    11M|   919   (2)| 00:00:05 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |*  8 |     INDEX RANGE SCAN             | ORG_MV_IDX1                    |      0 |      1 |       |     1   (0)| 00:00:01 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    |*  9 |    MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV                       |      0 |      1 |    11 |     2   (0)| 00:00:01 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Even though the result set is zero, the time to establish this came down from 35 minutes to 30 seconds and the plan has changed and is using a different index now!
    Thanks for your help!

  • Understand an explain plan

    Hi,
    following is the explain plan for my query :
    Plan Table
    | Operation                 |  Name              |  Rows | Bytes|  Cost  | Pstart| Pstop |
    | SELECT STATEMENT          |                    |     1 |  139 |    464 |       |       |
    |  SORT GROUP BY            |                    |     1 |  139 |    464 |       |       |
    |   NESTED LOOPS            |                    |     1 |  139 |    453 |       |       |
    |    HASH JOIN              |                    |   352 |   35K|    277 |       |       |
    |     NESTED LOOPS          |                    |   105 |    7K|     54 |       |       |
    |      TABLE ACCESS BY INDEX|PS_CE_ITEMVAR_TMP   |   101 |    5K|     53 |       |       |
    |       INDEX RANGE SCAN    |PS_C_ITEMVAR_TMP    |   101 |      |      5 |       |       |
    |      INDEX UNIQUE SCAN    |PS_ITEMS_INV        |    14K|  244K|        |       |       |
    |     TABLE ACCESS FULL     |PS_OUTPUT_LIST      |    47K|    1M|    222 |       |       |
    Plan Table
    |    TABLE ACCESS BY INDEX R|PS_SF_PRDNID_HEADR  |    31K|    1M|      1 |       |       |
    |     INDEX UNIQUE SCAN     |PS_SF_PRDNID_HEADR  |    31K|      |        |       |       |
    ------------------------------------------------------------------------------------------How to understand it ? How to interpret it ?
    Does this explain plan suggest you any tuning or any idea ?
    Many thanks.

    Can you check if you can avoid full table scan of this table - PS_OUTPUT_LIST
    How to understand it ? How to interpret it ?Here is the rule.
    1) First goto the inner most line. That will be the first one to get executed/accessed
    Note : If two are two lines that are the same innermost level, then the one that is above it will get accessed first.
    Here is the order for your case in sequence
    1) INDEX RANGE SCAN |PS_C_ITEMVAR_TMP
    2) TABLE ACCESS BY INDEX|PS_CE_ITEMVAR_TMP (a)
    3) INDEX UNIQUE SCAN - PS_ITEMS_INV (b)
    4) a and b will be joined to form a rowset - (c)
    5) TABLE ACCESS FULL |PS_OUTPUT_LIST - (d)
    6) c and d will have NESTED LOOPS ..
    So on...
    Please read the 9i or 10g Performance Tuning guide - that has the same explanation in the initial chapters
    Message was edited by:
    Srinivas.R

  • About explain plan

    Hello ALL,
    I have the following explain plan, can any body explain the meaning of this explain plan
    SELECT * FROM
    2 TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE','111'));
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
    | 0 | SELECT STATEMENT | | 401 | 25263 | | 751K|
    | 1 | MERGE JOIN SEMI | | 401 | 25263 | | 751K|
    | 2 | SORT JOIN | | 17M| 820M| 2108M| 75297 |
    | 3 | TABLE ACCESS FULL | TABLE1 | 17M| 820M| | 3520 |
    |* 4 | SORT UNIQUE | | 275M| 3412M| 10G| 676K|
    | 5 | VIEW | VW_NSO_1 | 275M| 3412M| | 3538 |
    |* 6 | HASH JOIN | | 275M| 7874M| | 3538 |
    |* 7 | TABLE ACCESS FULL| TABLE2 | 16 | 128 | | 2 |
    |* 8 | TABLE ACCESS FULL| TABLE1 | 17M| 360M| | 3520 |
    Predicate Information (identified by operation id):
    4 - access("TABLE1"."POSITION"="VW_NSO_1"."$nso_col_1")
    filter("TABLE1"."POSITION"="VW_NSO_1"."$nso_col_1")
    6 - access("TABLE2"."VERSION_NO"="TABLE1"."VERSION_NO")
    7 - filter("TABLE2"."STATIC_UPD_FLAG"='N')
    8 - filter("TABLE1"."DATETIME_INSERTED">TO_DATE('0004-01-01 00:00:00',
    'yyyy-mm-dd hh24:mi:ss'))
    Note: cpu costing is off
    26 rows selected.
    SQL>

    There is a section in the manual on interpreting the output of explain plan http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/ex_plan.htm#16972 Tom Kyte also discusses interpreting the plan http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:231814117467#7344298017927 (page down about halfway where he starts his book excerpt).
    Rows, bytes, and temp space are the cost-based optimizer's guess about the number of rows, bytes, and temp space that will be touched (or consumed) by the operation. The cost is an internal number that has no significance to you when you're reading an explain plan-- it does have some significance when you are examining an event 10046 trace.
    Justin
    Distributed Database Consulting, Inc.
    http://www.ddbcinc.com/askDDBC

  • TUNNING A SQL QUERY AND UNSERSTAND EXPLAIN PLAN

    I was trying my handing in tunning sql queries -
    Though I have manged to reduce the cost lil ..creating some index, but have genarated a g8 interesting in tunning - Can some experts ( I know there are lots available :-) ) help me on the approch on "HOW TO TUNE A QUERY"
    moreover I also would like to understand - how to debug a explain plan, - please help ...
    Regards..

    Hi,
    Welcome to this forum...
    I would suggest your to read first the official documentations :
    - The concepts of an Oracle DBMS (this is important to know, because Oracle structures, processes, objects (etc) are the building blocks of your database)
    - SQL reference guide
    - PL/SQL reference guide
    and then at a later stage the Performance and tuning guide:
    You can start there:
    http://download.oracle.com/docs/cd/B14117_01/nav/portal_1.htm
    Once it's done maybe read the Performance and tuning guide:
    http://download.oracle.com/docs/cd/B14117_01/server.101/b10752/toc.htm
    (Chapter 19 explain ... how to interpret the explain plan ..)
    I wish you good chance and be patient: I'm working with Oracle for more that 10 years and I'm still learning! ...
    Rem: The Oracle website is full of interesting articles, and examples, just "search" your special points of interests ..

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

  • Explain plan shows 300T of TempSpc and 999 hours - tuning request

    Hi,
    I have a query which obtains summary statistics. There is an items table which contains the dictionary of items which can be recorded. There is an events table which contains the item ID, timestamp and a value. The query summarizes the data for each item. e.g. Mean, stddev, sample values, length. I have trimmed the query down as simply as possible and am having a problem with large temp space and runtime estimates in the explain plan. Here is the query:
    WITH ChartItems AS (
        SELECT
          ci.itemid,
          ci.label,
          ci.category,
          ci.description,
          COUNT(*),
          COUNT(distinct subject_id)
        FROM mimic2v26.d_chartitems ci
        JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
        --WHERE ci.itemid = 51
        GROUP BY ci.itemid,
                 ci.label,
                 ci.category,
                 ci.description
    --select * from ChartItems;
    , RawData AS (
        SELECT DISTINCT
          ci.itemid,
          ci.label,
          ci.category,
          ci.description,
          last_value(ce.value1) ignore nulls over (partition BY ci.itemid order by
          ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS
          value1_last
        FROM ChartItems ci
        JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
    select * from RawData;Which gives this explain plan:
    Plan hash value: 642453121
    | Id  | Operation                    | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |                |  4811G|  1238T|       |  3686M (13)|999:59:59 |
    |   1 |  VIEW                        |                |  4811G|  1238T|       |  3686M (13)|999:59:59 |
    |   2 |   HASH UNIQUE                |                |  4811G|   258T|       |  3686M (13)|999:59:59 |
    |   3 |    WINDOW BUFFER             |                |  4811G|   258T|       |  3686M (13)|999:59:59 |
    |   4 |     SORT GROUP BY            |                |  4811G|   258T|   317T|  3686M (13)|999:59:59 |
    |*  5 |      HASH JOIN               |                |  4811G|   258T|  4943M|    25M (90)| 85:14:28 |
    |   6 |       VIEW                   | VW_DAG_0       |   152M|  3199M|       |  1366K  (1)| 04:33:18 |
    |   7 |        HASH GROUP BY         |                |   152M|  4216M|  5839M|  1366K  (1)| 04:33:18 |
    |*  8 |         HASH JOIN            |                |   152M|  4216M|       |   147K  (2)| 00:29:36 |
    |   9 |          TABLE ACCESS FULL   | D_CHARTITEMS   |  4832 | 96640 |       |     7   (0)| 00:00:01 |
    |  10 |          INDEX FAST FULL SCAN| CHARTEVENTS_O2 |   196M|  1683M|       |   147K  (1)| 00:29:25 |
    |  11 |       TABLE ACCESS FULL      | CHARTEVENTS    |   196M|  6922M|       |   616K  (1)| 02:03:19 |
    Predicate Information (identified by operation id):
       5 - access("CE"."ITEMID"="ITEM_2")300T of temp space! Ouch.
    TKPROF output (I let the query run for a short while. I let it run for ages earlier, but wasn't tracing the session. Should I let it run for longer?):
    TKPROF: Release 11.2.0.3.0 - Development on Tue Jul 10 16:54:27 2012
    Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
    Trace file: /oracle/11gr2/app/oracle/diag/rdbms/mimic2/mimic2/trace/mimic2_ora_6507.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
    WITH ChartItems AS (
        SELECT
          ci.itemid,
          ci.label,
          ci.category,
          ci.description,
          COUNT(*),
          COUNT(distinct subject_id)
        FROM mimic2v26.d_chartitems ci
        JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
        GROUP BY ci.itemid,
                 ci.label,
                 ci.category,
                 ci.description
    , RawData AS (
        SELECT DISTINCT
          ci.itemid,                                                                                                                                                                                           
          ci.label,                                                                                                                                                                                            
          ci.category,                                                                                                                                                                                         
          ci.description,                                                                                                                                                                                      
          last_value(ce.value1) ignore nulls over (partition BY ci.itemid order by                                                                                                                             
          ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS                                                                                                                            
          value1_last                                                                                                                                                                                          
        FROM ChartItems ci                                                                                                                                                                                     
        JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid                                                                                                                                                 
    select * from RawData                                                                                                                                                                                      
    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        1    582.40     712.23     705238     737351          0           0                                                                                                                           
    total        3    582.43     712.25     705238     737351          0           0                                                                                                                           
    Misses in library cache during parse: 1                                                                                                                                                                    
    Optimizer mode: ALL_ROWS                                                                                                                                                                                   
    Parsing user id: 85 
    Number of plan statistics captured: 1
    Rows (1st) Rows (avg) Rows (max)  Row Source Operation
             0          0          0  VIEW  (cr=0 pr=0 pw=0 time=184 us cost=3686387254 size=1361581801333882 card=4811243114254)
             0          0          0   HASH UNIQUE (cr=0 pr=0 pw=0 time=180 us cost=3686387254 size=283863343740986 card=4811243114254)
             0          0          0    WINDOW BUFFER (cr=0 pr=0 pw=0 time=74 us cost=3686387254 size=283863343740986 card=4811243114254)
             0          0          0     SORT GROUP BY (cr=0 pr=0 pw=0 time=59 us cost=3686387254 size=283863343740986 card=4811243114254)
    178073889  178073889  178073889      HASH JOIN  (cr=737351 pr=705238 pw=124635 time=476372451 us cost=25572251 size=283863343740986 card=4811243114254)
       6211631    6211631    6211631       VIEW  VW_DAG_0 (cr=613768 pr=581413 pw=35805 time=286546567 us cost=1366486 size=3354399576 card=152472708)
       6211631    6211631    6211631        HASH GROUP BY (cr=613768 pr=581413 pw=35805 time=281271878 us cost=1366486 size=4421708532 card=152472708)
    196182740  196182740  196182740         HASH JOIN  (cr=613768 pr=545608 pw=0 time=557485047 us cost=147987 size=4421708532 card=152472708)
          4832       4832       4832          TABLE ACCESS FULL D_CHARTITEMS (cr=18 pr=16 pw=0 time=13666 us cost=7 size=96640 card=4832)
    196182740  196182740  196182740          INDEX FAST FULL SCAN CHARTEVENTS_O2 (cr=613750 pr=545592 pw=0 time=148428499 us cost=147046 size=1765644660 card=196182740)(object id 96501)
      10683044   10683044   10683044       TABLE ACCESS FULL CHARTEVENTS (cr=123583 pr=123825 pw=0 time=25175510 us cost=616507 size=7258761380 card=196182740)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      db file sequential read                         2        0.01          0.01
      db file scattered read                          3        0.02          0.03
      direct path read                             5265        0.75         77.13
      asynch descriptor resize                        1        0.00          0.00
      direct path write temp                      15077        0.71         45.54
      direct path read temp                        2387        0.29         13.54
      SQL*Net break/reset to client                   1        0.66          0.66
      SQL*Net message from client                     1        0.00          0.00
    SQL ID: 7jby2dxrpkkm9 Plan Hash: 1388734953
    select SYS_CONTEXT('USERENV','SESSIONID')
    from
    dual
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.01          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      0.00       0.00          0          0          0           1
    total        3      0.00       0.01          0          0          0           1
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 85 
    Number of plan statistics captured: 1
    Rows (1st) Rows (avg) Rows (max)  Row Source Operation
             1          1          1  FAST DUAL  (cr=0 pr=0 pw=0 time=4 us cost=2 size=0 card=1)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        2      0.02       0.04          0          0          0           0
    Execute      2      0.00       0.00          0          0          0           0
    Fetch        2    582.40     712.23     705238     737351          0           1
    total        6    582.43     712.27     705238     737351          0           1
    Misses in library cache during parse: 2
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       4        0.00          0.00
      db file sequential read                         2        0.01          0.01
      db file scattered read                          3        0.02          0.03
      direct path read                             5265        0.75         77.13
      asynch descriptor resize                        1        0.00          0.00
      direct path write temp                      15077        0.71         45.54
      direct path read temp                        2387        0.29         13.54
      SQL*Net break/reset to client                   1        0.66          0.66
      SQL*Net message from client                     3       14.99         15.01
    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
        2  user  SQL statements in session.
        0  internal SQL statements in session.
        2  SQL statements in session.
    Trace file: /oracle/11gr2/app/oracle/diag/rdbms/mimic2/mimic2/trace/mimic2_ora_6507.trc
    Trace file compatibility: 11.1.0.7
    Sort options: default
           1  session in tracefile.
           2  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           2  SQL statements in trace file.
           2  unique SQL statements in trace file.
       24245  lines in trace file.
         728  elapsed seconds in trace file.Optimizer parameters:
    NAME                                               TYPE        VALUE                                                                                               
    optimizer_capture_sql_plan_baselines               boolean     FALSE                                                                                               
    optimizer_dynamic_sampling                         integer     2                                                                                                   
    optimizer_features_enable                          string      11.2.0.3                                                                                            
    optimizer_index_caching                            integer     0                                                                                                   
    optimizer_index_cost_adj                           integer     100                                                                                                 
    optimizer_mode                                     string      ALL_ROWS                                                                                            
    optimizer_secure_view_merging                      boolean     TRUE                                                                                                
    optimizer_use_invisible_indexes                    boolean     FALSE                                                                                               
    optimizer_use_pending_statistics                   boolean     FALSE                                                                                               
    optimizer_use_sql_plan_baselines                   boolean     TRUE                                                                                                 Can anyone help me figure out what's wrong?
    This is a data warehouse, with up to date statistics. The DB is version 11.2.0.3.0
    Thanks,
    Dan

    rp0428 wrote:
    >
    I trimmed the query down to the simplest that I could which still exhibited the problem
    >
    The DISTINCT isn't the issue. The issue is that the query you posted isn't necessary and doesn't appear to be represented in the plan that you posted.
    That makes it hard to tell where the cardinality misestimates are coming from. How many records does the actual first query (the one with the group by) return? You have a SELECT * commented out - how many rows?No, it's not necessary, but then it isn't the full query. The estimates are still wrong when I pass the count columns through to the second query. The full query contains many more analytic functions in the second query, and some additions to the first. It could probably be cleaned up a little, but the current structure makes logical sense. Should I change the aggregates to analytics and move them into the second query? In any case, there definitely seems to be something wrong with the plan.
    I don't know what you mean when you say "doesn't appear to be represented in the plan that you posted".
    I just checked the first query and while the temp space has dropped to a reasonable amount, the number of rows in the hash join is still way off (I didn't notice before because I was looking at the temp space). The rows for d_chartitems and the index on chartevents are correct:
    Plan hash value: 1249235674
    | Id  | Operation               | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT        |                |   152M|    35G|       |  1366K  (1)| 04:33:18 |
    |   1 |  VIEW                   |                |   152M|    35G|       |  1366K  (1)| 04:33:18 |
    |   2 |   WINDOW SORT           |                |   152M|  4216M|  5839M|  1366K  (1)| 04:33:18 |
    |*  3 |    HASH JOIN            |                |   152M|  4216M|       |   147K  (2)| 00:29:36 |
    |   4 |     TABLE ACCESS FULL   | D_CHARTITEMS   |  4832 | 96640 |       |     7   (0)| 00:00:01 |
    |   5 |     INDEX FAST FULL SCAN| CHARTEVENTS_O2 |   196M|  1683M|       |   147K  (1)| 00:29:25 |
    Predicate Information (identified by operation id):
       3 - access("CE"."ITEMID"="CI"."ITEMID")Edited by: danscott on Jul 10, 2012 5:43 PM
    Edited by: danscott on Jul 11, 2012 6:28 AM

  • Understanding explain plan

    Oracle Gurus,
    I am trying to understand the below explain plan which I generated using DBMS_XPLAN. This explain plan shows 380M cost, what do "M" and "K" mean here? If anyone has any good documentation to understand explain plan, please pass on.
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
    | 0 | INSERT STATEMENT | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
    | 1 | HASH UNIQUE | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
    |* 2 | FILTER | | | | | | | | | | |
    | 3 | PX COORDINATOR | | | | | | | | | | |
    | 4 | PX SEND QC (RANDOM) | :TQ10002 | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | P->S | QC (RAND) |
    |* 5 | HASH JOIN BUFFERED | | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | PCWP | |
    | 6 | PX RECEIVE | | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,02 | PCWP | |
    | 7 | PX SEND HASH | :TQ10000 | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,00 | P->P | HASH |
    | 8 | PX BLOCK ITERATOR | | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWC | |
    |* 9 | TABLE ACCESS FULL | TOP10_UL_SECTOR_LUCENT | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWP | |
    | 10 | PX RECEIVE | | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,02 | PCWP | |
    | 11 | PX SEND HASH | :TQ10001 | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,01 | P->P | HASH |
    | 12 | PX BLOCK ITERATOR | | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWC | |
    |* 13 | TABLE ACCESS FULL | BH_UL_SECTOR_LUCENT | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWP | |
    | 14 | SORT AGGREGATE | | 1 | 14 | | | | | | | |
    | 15 | PARTITION RANGE ITERATOR| | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
    |* 16 | INDEX SKIP SCAN | IDX2_BH_UL_SECTOR_LUCENT | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
    -----------------------------------------------------------------------------------------------------------------------------------------------------

    Hello,
    Once again K is number of (1000) rows fetched and M is for bytes repsentation. Check this oracle doc for reading xplan
    Cost of the operation as estimated by the optimizer's query approach. Cost is not determined for table access operations. The value of this column does not have any particular unit of measurement; it is merely a weighted value used to compare costs of execution plans. The value of this column is a function of the CPU_COST and IO_COST columns
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i16971
    Regards

  • Explain Plan of a query.

    I want to know the concept of this 'Explain Plan' of a query & why it is used. Could u also give the syntax of how a explain plan for a query can be done. Please help in solving the doubt as it is urgent.

    Hi,
    set autotrace traceonly explain or
    -- create your plan table in your schema (only once)
    @ ?/rdbms/admin/utlxplan
    -- populate the plan table for your select
    explain plan for select ...;
    -- display output out of the PLAN_TABLE
    @ ?/rdbms/admin/ultxplsRegards
    Laurent

  • Explain plan not available in dba studio

    Hi, guys,
    Why the explain plan not available in my dba studio with a message like this "explain plan not available for this sql statement. ora-02195: attempt to create permanent object in a temporary tablespace"
    Another question: I can use "set autotrace on" to trace sql statement in sql*plus window. But the final execution plan come up without those thing like cost, cardinality but only the steps
    Thanks for your help
    jim

    Was this a trace started on an already running task? Was the trace stopped before the task completed? Did the trace file reach its set size limit before the task compled?
    In all three cases above you would have cursors that were not closed and stats information not written to the trace file resulting in incomplete data for some SQL.
    HTH -- Mark D Powell --

  • Explaining the explain plan

    Hi all,
    10.2.0.1
    I have this explain plan:
    PLAN_TABLE_OUTPUT
    Plan hash value: 1154125190
    | Id  | Operation                      | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT               |            |     7 |   959 |  1353   (1)| 00:00:17 |
    |*  1 |  HASH JOIN RIGHT SEMI          |            |     7 |   959 |  1353   (1)| 00:00:17 |
    |   2 |   VIEW                         | VW_NSO_1   |   275 |  3025 |    20   (0)| 00:00:01 |
    |*  3 |    FILTER                      |            |       |       | |           |
    |   4 |     HASH GROUP BY              |            |   275 | 13750 |    20   (0)| 00:00:01 |
    |   5 |      NESTED LOOPS              |            |  5499 |   268K|    20   (0)| 00:00:01 |
    |*  6 |       INDEX FULL SCAN          | INDX_GPFEM |   253K|  6673K|    19   (0)| 00:00:01 |
    |*  7 |       INDEX RANGE SCAN         | PK_MONACT  |     1 |    23 |     1   (0)| 00:00:01 |
    |   8 |   TABLE ACCESS BY INDEX ROWID  | EMP_MAST   |     1 |    76 |     1   (0)| 00:00:01 |
    |   9 |    NESTED LOOPS                |            |  6115 |   752K|  1333   (1)| 00:00:16 |
    |  10 |     TABLE ACCESS BY INDEX ROWID| MON_ACT    |   127K|  6222K|    57   (0)| 00:00:01 |
    |* 11 |      INDEX RANGE SCAN          | FUNC_MA    |   127K|       |     3   (0)| 00:00:01 |
    |* 12 |     INDEX RANGE SCAN           | EMPCODE_EM |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access("$nso_col_1"=NVL("GPF_NO",'a'))
       3 - filter(COUNT(*)>1)
       6 - filter("GPF_NO" IS NOT NULL)
       7 - access("A"."TREA_CODE"="B"."TREA_CODE" AND "A"."EMP_CODE"="B"."EMP_CODE")       filter(TO_CHAR(INTERNAL_FUNCTION("UPTO_DATE"),'YYYYMM')='201003')
      11 - access(TO_CHAR(INTERNAL_FUNCTION("UPTO_DATE"),'YYYYMM')='201003')
      12 - access("A"."TREA_CODE"="B"."TREA_CODE" AND "A"."EMP_CODE"="B"."EMP_CODE")As per my understanding this is what is happening:
    1)Oracle accesses the index indx_gpfem at 6 and applies the predicate at 6 returning 253K rows to its parent 5.
    2)For each row in 253K,oracle does a nested loop join retuning 1 row at a time of which only 5499 rows are matching.That means the inner query got executed 253K times but only 5499 rows were matching.
    3)It then does a group by and returns 275 rows.
    4)It then applies the filter and returns 275 rows to the view.
    This is one part of explain plan.IN the second part of explain plan
    1)Oracle does a index full scan of index func_ma and applies the predicate 11 returing 127K rows.
    2)It then passes 127K rowids to access table mon_act returning 127K rows.
    3)For each 127K rows,oracle does a nested loop join of index empcode_em returning only 6115 matching rows.
    Now I don't understand how nested loop is a child of table access by index rowid operation.
    What is happening at 8,9?Also verify whta i have written.
    Thanks
    Edited by: Hashmi on Sep 15, 2010 11:18 PM

    Hashmi wrote:
    Now I don't understand how nested loop is a child of table access by index rowid operation.
    What is happening at 8,9?Also verify whta i have written.You need to issue
    set linesize 131and then generate plan output so that it becomes readable.
    What you see there is a change introduced in 9i to the way optimizer processes NESTED LOOP join.
    Basically, till 8i, oracle would have processed the NESTED LOOP as
    |   9 |    NESTED LOOPS                |            |  6115 |   752K|  1333   (1)| 00:00:16 |
    |  10 |     TABLE ACCESS BY INDEX ROWID| MON_ACT    |   127K|  6222K|    57   (0)| 00:00:01 |
    |* 11 |      INDEX RANGE SCAN          | FUNC_MA    |   127K|       |     3   (0)| 00:00:01 |
    |   8 |     TABLE ACCESS BY INDEX ROWID| EMP_MAST   |     1 |    76 |     1   (0)| 00:00:01 |
    |* 12 |      INDEX RANGE SCAN           | EMPCODE_EM |     1 |       |     1   (0)| 00:00:01 |But starting from 9i, it can optimize the processing by deferring the access of the outer table (EMP_MAST in this case).

Maybe you are looking for

  • Acrobat print window crashed when try to a print the PDF opened through browser

    Hi, I have Acobat pro and reader installed on my machine. I have set the properties - Open pdf in browser. So, all the PDFs are opening in browser uses Acrobat not the reader. And this is way I want. It was woking fine on Windows XP. After Windows 7

  • Strings pls help

    Hi I have the following piece of code... Case 1 : I use an <a href> in HTML and pass a string (with space) .. string is INTRANET NEWS_20020819.txt on running this testpage and on moving the mouse to this hyperlink [hyperlink testing1] i can see the e

  • Won't recognize new memory

    I have a satellite 2805 s201, I purchased 256 MB of memory PC100 SDRAM then update my BIOS from 1.1 to 2.0 but the system will not recognize the new RAM. What are my alternatives? TOSHIBA SATELLITE 2805 S201 MODEL PS2804-865L0H SER# Y0226526PU-1 32 B

  • Oracle Client Installer - INS-32012 problem

    Hi, I created a folder called app as root in / directory. In this app folder I created a folder called oracle. I want install Oracle client into /app/oracle I assigned as root these permission: chmod 775 /app chmod 775 /app/oracle but when I run as u

  • SQL statement taking a long time

    Hi friends, The below query is taking a very long time to execute. Please give some advise to optimise it. INSERT INTO AFMS_ATT_DETL     ATT_NUM,     ATT_REF_CD,     ATT_REF_TYP_CD,     ATT_DOC_CD,     ATT_FILE_NAM,     ATT_FILE_VER_NUM_TXT,     ATT_