Explain Plan doesn't show predicates.

Not sure what I'm not doing correctly but I don't see predicates in my explain plan. I'm using 1.1.2.25 and 9.2.0.5 Ent Ed with optimizer = choose. my compatible param is at 8.1.0 though, could that be the problem?

I can't say that I've ever seen the predicates in sql plus.

Similar Messages

Explain Plan not showing correct results.

Hi Gurus,
Please help me to understand below issue.
Whenever I am doing explain plan on any of the sql statements it says as explained but when retriving the explain plan output it shows same results again and again.
DB - 11gR2 Stand alone
ASM - Configured.
OS - RHEL 6.2.
SQL> select count(*) from t2114;
COUNT(*)
639292
SQL> explain plan for select count(*) from t2114;
Explained.
SQL> @?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 1497650422
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 6634 | 524K| 2993 (19)| 00:00:01 |
| 1 | SORT ORDER BY | | 6634 | 524K| 2993 (19)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| T2210 | 6634 | 524K| 2947 (17)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | T2210_T | 6842 | | 108 (22)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("T2210"."C490008000"=:SYS_B_0 AND "T2210"."C490009100"=:SYS_B_2
AND "T2210"."C301363300"=TO_NUMBER(:SYS_B_1))
16 rows selected.
SQL> explain plan for
2 SELECT T2114.C1 FROM T2114 WHERE ((T2114.C1000000001 = :"SYS_B_0") AND (T2114.C536871442 = :"SYS_B_1") AND (T2114.C536871477 = :"SYS_B_2") AND ((:"SYS_B_3" - T2114.C3) >= :"SYS_B_4") AND ((:"SYS_B_5" - T2114.C3) <= :"SYS_B_6") AND (T2114.C1000000217 LIKE :"SYS_B_7") AND (T2114.C536871478 < :"SYS_B_8")) ORDER BY C1000000161 DESC, :"SYS_B_9" ASC;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1497650422
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 6634 | 524K| 2993 (19)| 00:00:01 |
| 1 | SORT ORDER BY | | 6634 | 524K| 2993 (19)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| T2210 | 6634 | 524K| 2947 (17)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | T2210_T | 6842 | | 108 (22)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("T2210"."C490008000"=:SYS_B_0 AND "T2210"."C490009100"=:SYS_B_2
AND "T2210"."C301363300"=TO_NUMBER(:SYS_B_1))
16 rows selected.

Hi Dom,
Thanks for your immediate response.
I am getting two values for PLAN_TABLE. Please let me know if we need to drop any of them??
SQL> SELECT *
FROM all_objects
WHERE object_name = 'PLAN_TABLE'; 2 3
OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE CREATED LAST_DDL_TIME TIMESTAMP STATUS T G S NAMESPACE EDITION_NAME
PUBLIC PLAN_TABLE 5127 SYNONYM 17-SEP-11 17-SEP-11 2011-09-17:09:47:47 VALID N N N 1
ARADMIN PLAN_TABLE 219426 219426 TABLE 07-APR-13 07-APR-13 2013-04-07:23:01:12 VALID N N N 1

Understand the output of explain plan

I am trying to understand the output of explain plan. I have 2 plans below and don't understand it completely.
In below SQL I would expect optimizer to fetch "ROWNUM < 500" first and then do the outer join. But below explain plan doesn't list it as No. 1. So I don't really understand how to intepret the sequence from the explain plan:
select TASK0_.TASK_ID from
( select TASK0_.TASK_ID from
( select task0_.task_id from task task0_) TASK0_ where ROWNUM < 500 ) TASK0_
left outer join f_message_task task0_1_ on task0_.task_id=task0_1_.task_id
left outer join b_a_task task0_2_ on task0_.task_id=task0_2_.task_id
left outer join i_task task0_3_ on task0_.task_id=task0_3_.task_id
left outer join o_task task0_4_ on task0_.task_id=task0_4_.task_id
left outer join r_transmission_task task0_5_ on task0_.task_id=task0_5_.task_id
left outer join s_error_task task0_6_ on task0_.task_id=task0_6_.task_id
PLAN_TABLE_OUTPUT
Plan hash value: 707970537
| Id | Operation                    | Name                     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                          |   499 | 19461 | 1042   (6)| 00:00:13 |
|* 1 | HASH JOIN OUTER             |                          |   499 | 19461 | 1042   (6)| 00:00:13 |
|* 2 |   HASH JOIN OUTER            |                          |   499 | 16966 |   757   (6)| 00:00:10 |
|   3 |    NESTED LOOPS OUTER        |                          |   499 | 14471 |   589   (4)| 00:00:08 |
|   4 |     NESTED LOOPS OUTER       |                          |   499 | 12475 |   588   (4)| 00:00:08 |
|   5 |      NESTED LOOPS OUTER      |                          |   499 | 10479 |   588   (4)| 00:00:08 |
|   6 |       NESTED LOOPS OUTER     |                          |   499 | 8982 |   588   (4)| 00:00:08 |
|   7 |        VIEW                  |                          |   499 | 2495 |   588   (4)| 00:00:08 |
|* 8 |         COUNT STOPKEY        |                          |       |       |            |          |
|   9 |          INDEX FAST FULL SCAN| PK_TASK                  |   697K| 3403K|   588   (4)| 00:00:08 |
|* 10 |        INDEX UNIQUE SCAN     | PK_r_TRANSMISSION |     1 |    13 |     0   (0)| 00:00:01 |
|* 11 |       INDEX UNIQUE SCAN      | PK_b_a_TASK          |     1 |     3 |     0   (0)| 00:00:01 |
|* 12 |      INDEX UNIQUE SCAN       | PK_s_ERROR_TASK     |     1 |     4 |     0   (0)| 00:00:01 |
|* 13 |     INDEX UNIQUE SCAN        | PK_i_TASK    |     1 |     4 |     0   (0)| 00:00:01 |
| 14 |    INDEX FAST FULL SCAN      | PK_o_TASK           |   347K| 1695K|   161   (6)| 00:00:02 |
| 15 |   INDEX FAST FULL SCAN       | PK_f_MESSAGE        |   392K| 1917K|   276   (4)| 00:00:04 |
Predicate Information (identified by operation id):
   1 - access("TASK0_"."TASK_ID"="TASK0_1_"."TASK_ID"(+))
   2 - access("TASK0_"."TASK_ID"="TASK0_4_"."TASK_ID"(+))
   8 - filter(ROWNUM<500)
10 - access("TASK0_"."TASK_ID"="TASK0_5_"."TASK_ID"(+))
11 - access("TASK0_"."TASK_ID"="TASK0_2_"."TASK_ID"(+))
12 - access("TASK0_"."TASK_ID"="TASK0_6_"."TASK_ID"(+))
13 - access("TASK0_"."TASK_ID"="TASK0_3_"."TASK_ID"(+))
In below SQL I expect rownum to be applied at the end but it gets applied first:
select * from ( select TASK0_.TASK_ID from ( select task0_.task_id from task task0_
left outer join f_message_task task0_1_ on task0_.task_id=task0_1_.task_id
left outer join b_a_task task0_2_ on task0_.task_id=task0_2_.task_id
left outer join i_task task0_3_ on task0_.task_id=task0_3_.task_id
left outer join o_task task0_4_ on task0_.task_id=task0_4_.task_id
left outer join r_t_task task0_5_ on task0_.task_id=task0_5_.task_id
left outer join s_error_task task0_6_ on task0_.task_id=task0_6_.task_id
) TASK0_ where ROWNUM < 500 ) TASK0_;
PLAN_TABLE_OUTPUT
Plan hash value: 673345378
| Id | Operation                    | Name                     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                          |   499 | 6487 |   507   (1)| 00:00:07 |
|   1 | VIEW                        |                          |   499 | 6487 |   507   (1)| 00:00:07 |
|* 2 |   COUNT STOPKEY              |                          |       |       |            |          |
|   3 |    NESTED LOOPS OUTER        |                          |   501 | 19539 |   507   (1)| 00:00:07 |
|   4 |     NESTED LOOPS OUTER       |                          |   501 | 17034 |     5 (20)| 00:00:01 |
|   5 |      NESTED LOOPS OUTER      |                          |   501 | 15030 |     5 (20)| 00:00:01 |
|   6 |       NESTED LOOPS OUTER     |                          |   501 | 13026 |     5 (20)| 00:00:01 |
|   7 |        NESTED LOOPS OUTER    |                          |   501 | 11523 |     5 (20)| 00:00:01 |
|   8 |         NESTED LOOPS OUTER   |                          |   501 | 5010 |     5 (20)| 00:00:01 |
|   9 |          INDEX FAST FULL SCAN| PK_TASK                  |   499 | 2495 |     2   (0)| 00:00:01 |
|* 10 |          INDEX UNIQUE SCAN   | PK_o_TASK           |     1 |     5 |     1   (0)| 00:00:01 |
|* 11 |         INDEX UNIQUE SCAN    | PK_r_T |     1 |    13 |     0   (0)| 00:00:01 |
|* 12 |        INDEX UNIQUE SCAN     | PK_b_a_TASK          |     1 |     3 |     0   (0)| 00:00:01 |
|* 13 |       INDEX UNIQUE SCAN      | PK_s_ERROR_TASK     |     1 |     4 |     0   (0)| 00:00:01 |
|* 14 |      INDEX UNIQUE SCAN       | PK_i_TASK    |     1 |     4 |     0   (0)| 00:00:01 |
|* 15 |     INDEX UNIQUE SCAN        | PK_f_MESSAGE        |     1 |     5 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(ROWNUM<500)
10 - access("TASK0_"."TASK_ID"="TASK0_4_"."TASK_ID"(+))
11 - access("TASK0_"."TASK_ID"="TASK0_5_"."TASK_ID"(+))
12 - access("TASK0_"."TASK_ID"="TASK0_2_"."TASK_ID"(+))
13 - access("TASK0_"."TASK_ID"="TASK0_6_"."TASK_ID"(+))
14 - access("TASK0_"."TASK_ID"="TASK0_3_"."TASK_ID"(+))
15 - access("TASK0_"."TASK_ID"="TASK0_1_"."TASK_ID"(+))Edited by: user628400 on Feb 20, 2009 12:14 PM
Edited by: user628400 on Feb 20, 2009 12:15 PM

Please read the FAQ: http://forums.oracle.com/forums/help.jspa
And learn how to post code and explain plans using the tags.

Blank Explain plan !

I am running the explain plan but this is showing no data
and no error as well.
SQL> EXPLAIN PLAN FOR
2 select * from user_temp where SUBSTR <---> ORDER BY name;
Explained.
SQL> @%ORACLE_HOME%\rdbms\admin\utlxpls.sql
Plan Table
| Operation | Name | Rows | Bytes| Cost | Pstart| Pstop |
| SELECT STATEMENT | | | | | | |
| SORT ORDER BY | | | | | | |
| TABLE ACCESS FULL |USER_TEMP | | | | | |
--------------------------------------------------------------------------------

I am running the explain plan but this is showing no data and no error as well.Explain plan doesn't select data from db. It only shows you the way Oracle will search for records when you run your query.

Explain plan for update

Hi
I am new to the sql tuning.
When I wrote this below query and generate the explain plan ,It is showing following 3 steps .
1.very row in table employees is read .
2.Rows were updated.
3.Rows were updated.
Why the oracle is doing the update operation 2 times?Why it is showing 3 stesp where as I ma expecting only 2 steps something like below .
1.very row in table employees is read .
2.Rows were updated.
update employees
set salary = 2300
thanks
sri

Hi ,pleaase find below the explain plan generated .
update feed set feed_name = 2300
Plan
1 Every row in the table FI_OPERATIONS.FEED is read.
2 Rows were updated.
3 Rows were updated.

Facing Merge Join Cartersian in the explain plan after adding gl periods

Hi All
I have added gl periods table to the below query , checked the explain plan and it shows merge join cartesian. This query is taking long time to fetch the results.
Need help ASAP , Please let me know where i am going wrong . Any suggestions will be appreciated.
SELECT gljh.period_name, gljh.ledger_id, gljh.je_source,
glcc.segment2,
SUM ( NVL (gljl.accounted_dr, 0)
- NVL (gljl.accounted_cr, 0)
) total_amt,
gljh.currency_code
FROM gl_je_headers gljh,
gl_je_lines gljl,
gl_code_combinations glcc,
gl_periods gps
WHERE 1=1
AND gljh.period_name = gps.period_name
AND gljl.period_name = gps.period_name
AND gps.period_set_name = 'MCD_MONTH_'
AND gps.start_date >= :p_from_date
AND gps.start_date <= :p_to_date
AND gljh.ledger_id = :p_ledger_id
AND gljh.je_header_id = gljl.je_header_id
AND gljl.code_combination_id = glcc.code_combination_id
AND glcc.segment2 = '10007'--get_segment2_rec.flex_value
AND gljh.currency_code <> 'STAT'
GROUP BY gljh.je_source,
gljh.period_name,
glcc.segment2,
gljh.ledger_id,
gljh.currency_code
HAVING SUM ( NVL (gljl.accounted_dr, 0)
- NVL (gljl.accounted_cr, 0)
) <> 0;
Plan
SELECT STATEMENT ALL_ROWSCost: 73,146 Bytes: 2,266 Cardinality: 22
     15 FILTER
          14 HASH GROUP BY Cost: 73,146 Bytes: 2,266 Cardinality: 22
               13 FILTER
                    12 NESTED LOOPS Cost: 73,145 Bytes: 61,079 Cardinality: 593
                         9 NESTED LOOPS Cost: 31,603 Bytes: 1,452,780 Cardinality: 20,754
                              6 MERGE JOIN CARTESIAN Cost: 2,108 Bytes: 394,181 Cardinality: 9,167
                                   2 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_PERIODS Cost: 4 Bytes: 31 Cardinality: 1
                                        1 INDEX RANGE SCAN INDEX (UNIQUE) GL.GL_PERIODS_U2 Cost: 1 Cardinality: 64
                                   5 BUFFER SORT Cost: 2,104 Bytes: 683,988 Cardinality: 56,999
                                        4 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 2,104 Bytes: 683,988 Cardinality: 56,999
                                             3 INDEX RANGE SCAN INDEX GL.GL_CODE_COMBINATIONS_N2 Cost: 155 Cardinality: 56,999
                              8 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_JE_LINES Cost: 18 Bytes: 54 Cardinality: 2
                                   7 INDEX RANGE SCAN INDEX GL.GL_JE_LINES_N1 Cost: 3 Cardinality: 37
                         11 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_JE_HEADERS Cost: 2 Bytes: 33 Cardinality: 1
                              10 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_JE_HEADERS_U1 Cost: 1 Cardinality: 1
Thanks
Chandra

Lots of things come into play when you're tuning a query.
An (unformatted) execution plan isn't enough.
Tuning takes time and understanding how (a lot of) things work, there is no ASAP in the world of tuning.
Please post other important details, like your database version, optimizer settings, how/when are table statistics gathered etc.
So, read the following informative threads (and please take your time, this really is important stuff), and adust your thread as needed.
That way you'll have a bigger chance of getting help that makes sense...
Your DBA should/ought to be able to help you in this as well.
Re: HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html

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

Hi when i run this in toad for explain plan its showing an error ORA_22905

hi when i run this query in toad for explain plan its showing an error ORA_22905 cannot accesss rows from an non nested table item can anyone help me out
SELECT
DISTINCT SERVICE_TBL.SERVICE_ID , SERVICE_TBL.CON_TYPE, SERVICE_TBL.S_DESC || '(' || SERVICE_TBL.CON_TYPE || ')' AS SERVICE_DESC ,SERVICE_TBL.CON_STAT
FROM
TABLE(:B1 )SERVICE_TBL
WHERE
CON_NUM = :B2
thanks

Note the name of this forum is SQL Developer *(Not for general SQL/PLSQL questions)* (so for issues with the SQL Developer tool). Please post these questions under the dedicated SQL And PL/SQL forum.
Regards,
K.

Oem explain plan produced doesn't correspond to explain plan with tkprof

Hello all,
I am running OEM on a 10.2.0.3 database and I have a very slow query with cognos 8 BI on my data warehouse.
I went to the dbconsole through OEM and connected to target database I went to look at the query execution and then got an explain plan.
Then I did a trace file and ran it throught tkprof.
When I look at both produced explain plan, I can see the tree looks the same exept the corresponding values. In OEM, it says I am going throug 18000 rows and in the tkprof result it says more like millions of records.
As anybody had these kind of results?
Shall I have more confidence in TKprof then OEM?
It is very important to me since I am being chalanged by an external DBA.

I would recommend you to get Christian Antogini´s book "Troublshooting Oracle Performance", (http://www.antognini.ch/top/) which explains everything you need to know when analyzing Oracle SQL Performance and Explain Plans.
If you properly trace your SQL Statement, you will get "STAT" lines in the trace file. These stat lines show you the actual number of rows processed per row source operation. Explain plan per default does only show you the "estimated" row counts for the row source operations no matter whether you use "explain=" in the tkprof call or OEM to get the explain plan. Tkprof reads the STAT lines from the trace and outputs a section which is similar to an execution plan but contains the "real" number of rows.
However, if you want to troubleshoot Oracle Performance, I would recommend you to run the statement with the hint /*+ GATHER_PLAN_STATISTICS */ or set statistics_level=ALL in your session (not database-wide!).
If you do, you can get an excellent execution plan with DBMS_XPLAN.DISPLAY_CURSOR containing both estimated rows as well as actual rows combined with the "number of starts" for e.g. nested loop joins.
Get the book, read it, and you will be able to discuss this issue with your external dba in a professional way. ;-)
Regards,
Martin
www.ora-solutions.net

EXPLAIN PLAN not showing no of records

Rows column in the TKPROF output shows zero columns. The same works fine at sqlplus level, when autotrace set to ON.
Explain plan looks like below:
Rows Execution Plan
0 SELECT STATEMENT GOAL: ALL_ROWS
0 WINDOW (SORT)
0 HASH (GROUP BY)
0 MAT_VIEW ACCESS (BY INDEX ROWID) OF 'FII_AR_NET_REC_BASE_MV'
(MAT_VIEW)
0 NESTED LOOPS
0 MERGE JOIN (CARTESIAN)
0 TABLE ACCESS (FULL) OF 'FII_AR_SUMMARY_GT' (TABLE
(TEMP))
0 BUFFER (SORT)
0 INLIST ITERATOR
0 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
'FII_TIME_STRUCTURES' (TABLE)
Can someone help me here ?
Thanks.

Hi,
it's becuz of when u execute query twice its no I/O .data are already in buffer pool.
Thanks
Reena

Why the content of the Explain Plan not show out?

Why the content of the Explain Plan not show out?
I am using Oracle 11g.
I already ran the utlxplan.sql sctipt and I also set serveroutput on.
SQL> set autotrace on
SQL> EXPLAIN PLAN FOR SELECT*FROM DEMO_TABLE WHERE OWNER='HR';
Explained.
Elapsed: 00:00:00.67

When you say:
My release 10.2 database display the Explain Plan automatically.
How to make 11.1.0.6 Oracle database to display the Explain Plan automatically.What do you mean? Specifically, what commands are you executing in the 10.2 database, that displays the execution plan "automatically"?
Are you saying that if you execute the same command in 11.1.0.6, you don't get a similar result? What happens? Do you get an error?
For both the 10.2 case and the 11.1.0.6 case, post the full output of the commands you're executing, and the result you are seeing.
Then, maybe someone can help you.
When you post the output, please encapsulate it in a pair "code" tags, which is the word "code" without the quotes, surrounded by a pair of curly braces {}.
When you do this correctly, the output looks like:
This is output from my execution plan run.and is much easier to read.
Don't be afraid to use the preview tab to see if your message will be posted with the correct formatting.
-Mark

LTP MRP results doesn't show not firmed receipt elements like PRs, Plan Ord

Hi,
I have ran the LTP MRP using a particular planning scenario, but the results doesn't show any Purchase requisitions, Planned Orders, etc in the long-term window. It shows only firm receipt elements like Purchase Orders, Production Orders only. Any reasons behind this? Thanks
Raj

Dear,
Check: Re: Long Term Planning
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PPMPLTP/PPMPLTP.pdf
LTP -MRP Problem
Regards,
Syed Hussain.

Explain plan - support latest Predicate columns

Will raptor support the predicate columns in explain plan? They are available in oracle 9.2.

I just added them.
-kris

Production Order doesn't show planned costs

Please, help me!
When I save the order production, despite in configuration is set "Calculate planned costs when order is saved" & when is saving the order apears "Calculating costs" at the bottom of the window the order doesn't show costs analysis when I review the order in CO02 or CO03.
I am using SAP ECC 6.0
Thank you!

Donald,
I think for your Order type / Plant combination automatic calculation of Planned cost is not defined, you can check this in transaction OPL8, these defination would be in Controlling tab.
Check for Planned cost calc field:
The following options exist:
0: No planned costs are calculated when saving
1: Planned costs are calculated when saving, if the order has been released and having REL status.
2: Planned costs are calculated when saving.
I think in your case the option or 2 is being used, so you need to perform the Cost function manually for the planned cost for the order to get calculated.
Regards,
Prasobh

:Z in predicate section of explain plan

Hi Friends,
What is the meaning of :Z in the predicate section of execution plan of a query ? I didnt understand it .
Also how do i get the execution plan to format properly?? Earlier using code it would get formatted properly.
create table table_x nologging as
select /*+ parallel(a,4) full(a,4) */
ban, subscriber_no , soc PP, effective_date , expiration_date
from table_a a
where service_type = 'P'
and soc = 'SDDVRP'
and effective_date <= sysdate
and (expiration_date > sysdate or expiration_date is null)
PLANS FROM CURSOR
SQL_ID fp0591aupqpwd, child number 0
Plan hash value: 679415194
| Id | Operation              | Name              | Rows | Bytes | Cost | Pstart| Pstop |    TQ |IN-OUT| PQ Distrib |
|   0 | CREATE TABLE STATEMENT |                   |       |       |   291K|       |       |        |      |            |
|   1 | LOAD AS SELECT        |                   |       |       |       |       |       |        |      |            |
|   2 |   PX COORDINATOR       |                   |       |       |       |       |       |        |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000          |     7 |   315 |   291K|       |       | Q1,00 | P->S | QC (RAND) |
|   4 |     PX BLOCK ITERATOR |                   |     7 |   315 |   291K|     1 |    97 | Q1,00 | PCWC |            |
|* 5 |      TABLE ACCESS FULL | table_a           |     7 |   315 |   291K|     1 |    97 | Q1,00 | PCWP |            |
Predicate Information (identified by operation id):
   5 - access(:Z>=:Z AND :Z<=:Z)
       filter(("SERVICE_TYPE"='P' AND "SOC"='SDDVRP' AND "EFFECTIVE_DATE"<=SYSDATE@! AND
              ("EXPIRATION_DATE">SYSDATE@! OR "EXPIRATION_DATE" IS NULL)))

Hi Jonathan,
Thanks for explaining that, i understood it now .
Below is the format for explain plan using your suggestion. Seems it didnt work or i misunderstood your suggestions.
Also for some reason i dont see any preview option to see the output
<pre>
Plan hash value: 679415194
| Id | Operation              | Name              | Rows | Bytes | Cost | Pstart| Pstop |    TQ |IN-OUT| PQ Distrib |
|   0 | CREATE TABLE STATEMENT |                   |       |       |   291K|       |       |        |      |            |
|   1 | LOAD AS SELECT        |                   |       |       |       |       |       |        |      |            |
|   2 |   PX COORDINATOR       |                   |       |       |       |       |       |        |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000          |     7 |   315 |   291K|       |       | Q1,00 | P->S | QC (RAND) |
|   4 |     PX BLOCK ITERATOR |                   |     7 |   315 |   291K|     1 |    97 | Q1,00 | PCWC |            |
|* 5 |      TABLE ACCESS FULL | table_a           |     7 |   315 |   291K|     1 |    97 | Q1,00 | PCWP |            |
</pre>

Explain Plan doesn't show predicates.

Similar Messages

Maybe you are looking for