Explain Plan Understanding

Hi,
Is this both plan are same. Table names are change. Both execution wise would choose same plan of execution
No Hint
| Id | Operation              | Name        | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | INSERT STATEMENT       |             | 1285M|   326G|       |    45M (1)|178:06:59 |       |       |
|   1 | LOAD AS SELECT        | E           |       |       |       |            |          |       |       |
|* 2 |   HASH JOIN            |             | 1285M|   326G| 5153M|    45M (1)|178:06:59 |       |       |
|   3 |    TABLE ACCESS FULL   | D           |   135M| 3607M|       |   254K (2)| 00:59:17 |       |       |
|* 4 |    HASH JOIN           |             | 1261M|   287G| 2857M|    32M (1)|124:52:03 |       |       |
|   5 |     TABLE ACCESS FULL | C           |    76M| 1978M|       |   143K (2)| 00:33:33 |       |       |
|* 6 |     HASH JOIN          |             | 1241M|   252G| 1727M|    20M (1)| 78:33:50 |       |       |
|   7 |      TABLE ACCESS FULL | B           |    54M| 1099M|       | 23217   (4)| 00:05:26 |       |       |
|   8 |      PARTITION HASH ALL|             | 1241M|   227G|       | 3452K (4)| 13:25:29 |     1 |    64 |
|   9 |       TABLE ACCESS FULL| A           | 1241M|   227G|       | 3452K (4)| 13:25:29 |     1 |    64 |
Fix card for table A with 10M
| Id | Operation              | Name        | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | INSERT STATEMENT       |             |    10M| 2696M|       | 4578K (1)| 17:48:26 |       |       |
|   1 | LOAD AS SELECT        | E           |       |       |       |            |          |       |       |
|* 2 |   HASH JOIN            |             |    10M| 2696M| 2491M| 4578K (1)| 17:48:26 |       |       |
|* 3 |    HASH JOIN           |             |    10M| 2374M| 2193M| 3996K (1)| 15:32:36 |       |       |
|* 4 |     HASH JOIN          |             |    10M| 2079M| 1727M| 3636K (1)| 14:08:30 |       |       |
|   5 |      TABLE ACCESS FULL | B           |    54M| 1099M|       | 23217   (4)| 00:05:26 |       |       |
|   6 |      PARTITION HASH ALL|             |    10M| 1878M|       | 3362K (1)| 13:04:42 |     1 |    64 |
|   7 |       TABLE ACCESS FULL| A           |    10M| 1878M|       | 3362K (1)| 13:04:42 |     1 |    64 |
|   8 |     TABLE ACCESS FULL | C           |    76M| 1978M|       |   143K (2)| 00:33:33 |       |       |
|   9 |    TABLE ACCESS FULL   | D           |   135M| 3607M|       |   254K (2)| 00:59:17 |       |       |
Also, both have same predicates
Predicate Information (identified by operation id):
   2 - access(A."ID"="D"."ID")
   3 - access("A"."E_ID"="C"."E_ID")
   4 - access("A"."M_ID"="B"."M_ID")                                                                                                                                   If my understanding is right then
1. A Is hashed and then Join with B with hash join. While accessing B will apply predicate 4
2. Then result will be joined to C while with hash join while accessing C will apply using 3 access predicate
3. Then result will be applied to D
4. Then will load with direct path to E
Is not the case please explain both in details and also, please let me know which is best with some guidance and explanation

Taral Desai wrote:
Hi,
Is this both plan are same. Table names are change. Both execution wise would choose same plan of execution
No Hint
| Id | Operation              | Name        | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | INSERT STATEMENT       |             | 1285M|   326G|       |    45M (1)|178:06:59 |       |       |
|   1 | LOAD AS SELECT        | E           |       |       |       |            |          |       |       |
|* 2 |   HASH JOIN            |             | 1285M|   326G| 5153M|    45M (1)|178:06:59 |       |       |
|   3 |    TABLE ACCESS FULL   | D           |   135M| 3607M|       |   254K (2)| 00:59:17 |       |       |
|* 4 |    HASH JOIN           |             | 1261M|   287G| 2857M|    32M (1)|124:52:03 |       |       |
|   5 |     TABLE ACCESS FULL | C           |    76M| 1978M|       |   143K (2)| 00:33:33 |       |       |
|* 6 |     HASH JOIN          |             | 1241M|   252G| 1727M|    20M (1)| 78:33:50 |       |       |
|   7 |      TABLE ACCESS FULL | B           |    54M| 1099M|       | 23217   (4)| 00:05:26 |       |       |
|   8 |      PARTITION HASH ALL|             | 1241M|   227G|       | 3452K (4)| 13:25:29 |     1 |    64 |
|   9 |       TABLE ACCESS FULL| A           | 1241M|   227G|       | 3452K (4)| 13:25:29 |     1 |    64 |
Fix card for table A with 10M
| Id | Operation              | Name        | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | INSERT STATEMENT       |             |    10M| 2696M|       | 4578K (1)| 17:48:26 |       |       |
|   1 | LOAD AS SELECT        | E           |       |       |       |            |          |       |       |
|* 2 |   HASH JOIN            |             |    10M| 2696M| 2491M| 4578K (1)| 17:48:26 |       |       |
|* 3 |    HASH JOIN           |             |    10M| 2374M| 2193M| 3996K (1)| 15:32:36 |       |       |
|* 4 |     HASH JOIN          |             |    10M| 2079M| 1727M| 3636K (1)| 14:08:30 |       |       |
|   5 |      TABLE ACCESS FULL | B           |    54M| 1099M|       | 23217   (4)| 00:05:26 |       |       |
|   6 |      PARTITION HASH ALL|             |    10M| 1878M|       | 3362K (1)| 13:04:42 |     1 |    64 |
|   7 |       TABLE ACCESS FULL| A           |    10M| 1878M|       | 3362K (1)| 13:04:42 |     1 |    64 |
|   8 |     TABLE ACCESS FULL | C           |    76M| 1978M|       |   143K (2)| 00:33:33 |       |       |
|   9 |    TABLE ACCESS FULL   | D           |   135M| 3607M|       |   254K (2)| 00:59:17 |       |       |
Also, both have same predicates
Predicate Information (identified by operation id):
2 - access(A."ID"="D"."ID")
3 - access("A"."E_ID"="C"."E_ID")
4 - access("A"."M_ID"="B"."M_ID")                                                                                                                                   If my understanding is right then
1. A Is hashed and then Join with B with hash join. While accessing B will apply predicate 4
2. Then result will be joined to C while with hash join while accessing C will apply using 3 access predicate
3. Then result will be applied to D
4. Then will load with direct path to E
Is not the case please explain both in details and also, please let me know which is best with some guidance and explanationBoth the explain plan are good when you compare the number of rows in each table.
Here I see for same table optimizer is taking different number of rows in both the xplain plan.
Are they both generated on same database or different different database?
It is always better to do a hash on small table and join to the bigger table which it is doing in both the plan
Regards
Anurag

Similar Messages

Explain Plan understand technique & Query optimizing check list

Hello gurus,
Can some body help me with doc available or your experience to tell on how to understand Explain Plan & Query optimizing check list.
Thanks..

That's correct,
But unfortunately the institute is pretty far from home.. and travelling time will be high..
I am a working man..
Please suggest if some good book or link.
Thanks.

Not Understanding the filter in Explain Plan - filter(NULL IS NOT NULL)

Hi All,
Request your help in understanding the below scenario. (I am not aware of teh application and table details. Just trying to help my friend)
SQL> conn
Enter user-name: [email protected]
Enter password:
Connected.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
--Checking the count in PO_LINES
SQL> select count(*) from po_lines;
COUNT(*)
         0
--PO_LINES is a synonym
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES';
OBJECT_TYPE         OWNER
SYNONYM             APPS
--The synonym is pointing to PO.PO_LINES_ALL
SQL> select * from user_synonyms where synonym_name = 'PO_LINES';
SYNONYM_NAME                   TABLE_OWNER                    TABLE_NAME                     DB_LINK
PO_LINES                       PO                             PO_LINES_ALL
--But when counting PO.PO_LINES_ALL I am getting different result
SQL> select count(*) c from po.po_lines_all;
         C
      8828
--Explain plan of teh original query is
SQL> explain plan for
2 select
3 * from po_lines;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation          | Name         | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT   |              |     1 |   252 |     0   (0)|
|* 1 | FILTER            |              |       |       |            |
|   2 |   TABLE ACCESS FULL| PO_LINES_ALL | 8796 | 2164K|   106   (4)|
Predicate Information (identified by operation id):
   1 - filter(NULL IS NOT NULL)
--Now the object PO.PO_LINES_ALL is TABLE, not an mview.
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES_ALL';
OBJECT_TYPE         OWNER
TABLE               POSeek your help in understanding what is happening here.
Thanks in Advance,
jeneesh

Next time, prefix with APPS. when you show us the explain plan:
SQL> explain plan for
2 select
3 * from apps.po_lines; -- added the prefix of owner.Just like you prefixed with PO. when you showed us the query on PO_LINES_ALL. It ensures that you are using the synonym which you showed us.
Btw. PO_LINES_ALL, could still be a VIEW given your overview of the situation.
Anyway a filter "NULL IS NOT NULL" is indicative that the optimizer performed something called semantic query optimization (SQO).
SQO is the process of deducing new predicates based upon a) existing predicates in your query (which there is none), b) added predicates to your query (eg. by a VPD policy function), and c) declared constraints on the tables invovled in your query.
A typical example of when a "NOT is NOT NULL" predicate will show up is when for instance in the EMP table there is a declared constraint on EMPNO like this:
check(EMPNO > 0)And your query would hold a predicate that is inconsistent with the constraint, for instance like this:
select *
from EMP
where EMPNO <= 0Oracle will deduce that EMPNO cannot be both greater than zero (constraint) as well as smaller than or equal to zero (your query predicate), and will transform the query into:
select *
from EMP
where EMPNO <= 0
and NULL is NOT NULLThus preventing accessing the EMP table all together, and immediately returning this query with no data found.
Edited by: Toon Koppelaars on Mar 15, 2010 7:17 AM

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.

Understanding the COST column of an explain plan

Hello,
I executed the following query, and obtained the corresponding explain plan:
select * from isis.clas_rost where cour_off_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS               2     10     1540
TABLE ACCESS BY INDEX ROWID     ISIS     CLAS_ROST     2     10     1540
INDEX RANGE SCAN     ISIS     CLAS_ROST_N2     1 10
I don't understand how these cost values add up. What is the significance of the cost in each row of the explain plan output?
By comparison, here is another plan output for the following query:
select * from isis.clas_rost where clas_rost_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS               1     1     154
TABLE ACCESS BY INDEX ROWID     ISIS     CLAS_ROST     1     1     154
INDEX UNIQUE SCAN     ISIS     CLAS_ROST_U1     1 1
Thanks!

For the most part, you probably want to ignore the cost column. The cardinality column is generally what you want to pay attention to.
Ideally, the cost column is Oracle's estimate of the amount of work that will be required to execute a query. It is a unitless value that attempts to combine the cost of I/O and CPU (depending on the Oracle version and whether CPU costing is enabled) and to scale physical and logical I/O appropriately). As a unitless number, it doesn't really relate to something "real" like the expected number of buffer gets. It is also determined in part by initialization parameters,session settings, system statistics, etc. that may artificially increase or decrease the cost of certain operations.
Beyond that, however, cost is problematic because it is only as accurate as the optimizer's estimates. If the optimizer's estimates are accurate, that implies that the cost is reasonably representative (in the sense that a query with a cost of 200 will run in less time than a query with a cost of 20000). But if you're looking at a query plan, it's generally because you believe there may be a problem which means that you are inherently suspicious that some of the optimizer's estimates are incorrect. If that's the case, you should generally distrust the cost.
Justin

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

Need help understanding Explain Plan from 10046 trace

Below is a query and Explain Plan from a 10046 trace shown with trcanlzr.sql.
In the explain plan I don't understand what's happining at line ID 10 and 11. Specifically, is the result at line 11 rowids from lines 12 & 14? and then what? Are those rowids somehow used in line ID 10?
SELECT cp.cred_process_id, cp.provider_id,
       brdg_credentialing.get_appl_specialist(cp.cred_process_id,'R') specialist_name,
       brdg_cred_report_pkg.provider_name(cp.cred_process_id) provider_name,
       ctc_apptype.description appl_type_desc,
       TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)) init_received_dt,
       brdg_code_util.code_descr(brdg_credentialing.get_appl_status_cd_ctc_id(cp.cred_process_id)) appl_status_desc,
       brdg_credentialing.get_appl_prac_specialties(cp.cred_process_id,'Y') primary_specialty,
       cwh.city practice_city,
       UPPER (cwh.state) practice_state,
       TRUNC (ch.event_dt) specialist_assign_dt,
       DECODE (ctc_apptype.code,'INITPPO', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
               'REAPP', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
               'SPECCRED', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
               'TRANS', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
               'RECPPO', p.next_recred_dt,
               'RECAPP', p.next_recred_dt, NULL) sort_date,
               p.next_recred_dt
FROM brdg_cred_app_open_vw cp,
       brdg_cat_type_codes ctc_apptype,
       brdg_cred_work_history cwh,
       brdg_cred_history ch,
       brdg_providers p
WHERE cp.type_cd_ctc_id = ctc_apptype.cat_type_code_id
   AND ctc_apptype.category_cd = 'CRED'
   AND ctc_apptype.type_cd = 'APPTYPE'
   AND cp.cred_process_id = cwh.cred_process_id (+)
   AND cwh.primary_practice_flag (+) = 'Y'
   AND cp.cred_process_id = ch.cred_process_id
   AND ch.cred_history_id = (SELECT MAX(cred_history_id)
                               FROM brdg_cred_history
                              WHERE cred_process_id = cp.cred_process_id
                                AND event_cd_ctc_id = brdg_credentialing.get_event_ctc_id ('SEVENT','SPESTCHG'))
   AND cp.provider_id = p.provider_id (+)
   and brdg_credentialing.get_appl_specialist_id(cp.cred_process_id) = 5
ORDER BY 3 ASC, 3, 5, 12, 6
        Explain Plan Operation
ID   PID    Card     Rows    Cost      SearchCols /   Indexed Cols     Predicates
0:    1                       36   SELECT STATEMENT
1:    0     1       139       36    SORT ORDER BY
2:    1             139            . FILTER   [+]
3:    2     1       311       11   .. NESTED LOOPS OUTER
4:    3     1       311       10   ... NESTED LOOPS OUTER
5:    4     1       311        9   .... NESTED LOOPS
6:    5     1       311        8   ....+ NESTED LOOPS
7:    6     4        16        1   ....+. TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES
8:    7     4        16        1   ....+.. INDEX RANGE SCAN CAT_TYPE_CODE_UK 2/3 [+]   [+]
9:    6     1       311        2   ....+. TABLE ACCESS BY INDEX ROWID CRED_PROCESSES   [+]
10:    9   183     61927        1   ....+.. INDEX RANGE SCAN CDPR_CTCD_FK1 1/1 [+]   [+]
11:   10     1         3        2   ....+... NESTED LOOPS
12:   11     1        16        1   ....+.... TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES
13:   12     1        16        1   ....+....+ INDEX UNIQUE SCAN CTCD_PK 1/1 [+]   [+]
14:   11     1         3        1   ....+.... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]
15:    5     1        11        1   ....+ TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]
16:   15     1       311        1   ....+. INDEX UNIQUE SCAN CDHT_PK 1/1 [+]   [+]
17:   16     1       311            ....+.. SORT AGGREGATE
18:   17     1       526        2   ....+... TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]
19:   18    23      9950        1   ....+.... INDEX RANGE SCAN CDHT_CDPR_FK 1/1 [+]   [+]
20:    4     1       219        1   .... TABLE ACCESS BY INDEX ROWID PROVIDERS
21:   20     1       219        1   ....+ INDEX UNIQUE SCAN PROV_PK 1/1 [+] [+]
22:    3     1       311        1   ... TABLE ACCESS BY INDEX ROWID CRED_WORK_HISTORY   [+]
23:   22     3      1057        1   .... INDEX RANGE SCAN CDWH_CDPR_FK 1/1 [+]   [+]
24:    2   172                      .. INLIST ITERATOR
25:   24     1       172        1   ... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]
26:    2     1         0        2   .. TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]
27:   26    23      2004        1   ... INDEX RANGE SCAN CDHT_CDPR_FK 1/1 [+]   [+]
(1) X/Y: Where X is the number of searched columns from index, which has a total of Y columns.
(2) Actual rows returned by operation (average if there were more than 1 execution).
   2 - filter( NOT EXISTS (SELECT 0 FROM "PPO"."CAT_TYPE_CODES" "BRDG_CAT_TYPE_CODES" WHERE
              "CODE"="BRDG_CODE_UTIL"."ID_CODE"("BRDG_CREDENTIALING"."GET_APPL_STATUS_CD_CTC_ID"(:B1)) AND
              ("TYPE_CD"='APPROVAL' OR "TYPE_CD"='DENIED' OR "TYPE_CD"='INACTIVE' OR "TYPE_CD"='TERMED') AND
              "CATEGORY_CD"='APPSTAT') AND NOT EXISTS (SELECT 0 FROM "PPO"."CRED_HISTORY" "BRDG_CRED_HISTORY"
              WHERE "CRED_PROCESS_ID"=:B2 AND "EVENT_CD_CTC_ID"="BRDG_CODE_UTIL"."GET_ID"('CRED','SEVENT','MSODC
   8 - access("CTC_APPTYPE"."CATEGORY_CD"='CRED' AND "CTC_APPTYPE"."TYPE_CD"='APPTYPE')
   9 - filter("BRDG_CREDENTIALING"."GET_APPL_SPECIALIST_ID"("CP"."CRED_PROCESS_ID")=5 AND
              ("CP"."INS_DT">=TO_DATE(' 2007-12-20 17:00:00', 'syyyy-mm-dd hh24:mi:ss') OR
              "CP"."TYPE_CD_CTC_ID"<>"BRDG_CODE_UTIL"."GET_ID"('CRED','APPTYPE','RECPPO')))
10 - access("CP"."TYPE_CD_CTC_ID"="CTC_APPTYPE"."CAT_TYPE_CODE_ID")
       filter( NOT EXISTS (SELECT 0 FROM "PPO"."CAT_TYPE_CODES"
              "CTC_APPTYPE","PPO"."CAT_TYPE_CODES" "CTC_TYPE" WHERE "CTC_TYPE"."CAT_TYPE_CODE_ID"=:B1 AND
              "CTC_TYPE"."CODE"="CTC_APPTYPE"."CODE" AND "CTC_APPTYPE"."TYPE_CD"='APPSENT' AND
              "CTC_APPTYPE"."CATEGORY_CD"='APPTYPE'))
13 - access("CTC_TYPE"."CAT_TYPE_CODE_ID"=:B1)
14 - access("CTC_APPTYPE"."CATEGORY_CD"='APPTYPE' AND "CTC_APPTYPE"."TYPE_CD"='APPSENT' AND
              "CTC_TYPE"."CODE"="CTC_APPTYPE"."CODE")
15 - filter("CP"."CRED_PROCESS_ID"="CH"."CRED_PROCESS_ID")
16 - access("CH"."CRED_HISTORY_ID"= (SELECT MAX("CRED_HISTORY_ID") FROM "PPO"."CRED_HISTORY"
              "BRDG_CRED_HISTORY" WHERE "CRED_PROCESS_ID"=:B1 AND
              "EVENT_CD_CTC_ID"="BRDG_CREDENTIALING"."GET_EVENT_CTC_ID"('SEVENT','SPESTCHG')))
18 - filter("EVENT_CD_CTC_ID"="BRDG_CREDENTIALING"."GET_EVENT_CTC_ID"('SEVENT','SPESTCHG'))
19 - access("CRED_PROCESS_ID"=:B1)
21 - access("CP"."PROVIDER_ID"="P"."PROVIDER_ID"(+))
22 - filter("CWH"."PRIMARY_PRACTICE_FLAG"(+)='Y')
23 - access("CP"."CRED_PROCESS_ID"="CWH"."CRED_PROCESS_ID"(+))
25 - access("CATEGORY_CD"='APPSTAT' AND ("TYPE_CD"='APPROVAL' OR "TYPE_CD"='DENIED' OR
              "TYPE_CD"='INACTIVE' OR "TYPE_CD"='TERMED') AND "CODE"="BRDG_CODE_UTIL"."ID_CODE"("BRDG_CREDENTIAL
              ING"."GET_APPL_STATUS_CD_CTC_ID"(:B1)))
26 - filter("EVENT_CD_CTC_ID"="BRDG_CODE_UTIL"."GET_ID"('CRED','SEVENT','MSODC'))
27 - access("CRED_PROCESS_ID"=:B1)

Welcome to the forums!
user11987210 wrote:
In the explain plan I don't understand what's happining at line ID 10 and 11. Specifically, is the result at line 11 rowids from lines 12 & 14? and then what? Are those rowids somehow used in line ID 10?
9:    6     1       311        2   ....+. TABLE ACCESS BY INDEX ROWID CRED_PROCESSES   [+]
10:    9   183     61927        1   ....+.. INDEX RANGE SCAN CDPR_CTCD_FK1 1/1 [+]   [+]
11:   10     1         3        2   ....+... NESTED LOOPS
12:   11     1        16        1   ....+.... TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES
13:   12     1        16        1   ....+....+ INDEX UNIQUE SCAN CTCD_PK 1/1 [+]   [+]
14:   11     1         3        1   ....+.... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]   The NESTED LOOPS operation (ID #11) has two children, ID #12 sometimes called the driving source, and ID #14 the inner loop. ID #14 is executed once for each row returned by ID #12. The results of ID #11 are then fed to ID #10 which performs an INDEX RANGE SCAN.
Hope this helps!

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

Understanding of Explain plan

Hi all,
Could you please provide me any article on how to read and understand the complete explain plan by step by step?
I am not much familiar with expalin paln.
Wolud be appreciated your help !!
Regards,
Vissu...
Edited by: vissu on Aug 10, 2010 2:13 AM

[ | http://www.lmgtfy.com/?q=Understanding+explain+plans+in+oracle+10g]
[| http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm]

Understanding CBO decisions, explain plan instability

Hi,
I have a situation where the explain plan for a SELECT statement changes
and performance takes a turn for the worse. The statement in question
executes well and has the desired explain plan but after an insertion
having a new eventtype ID the explain plan changes (doing lots of IO)
and remains bad until the SGA is flushed.
I would really like to know how to figure out how the CBO makes its
decisions and why it changes its mind over a 2min period. Any pointers
to get me started would be greatly appreciated.
Table has columns C_ID, R_ID, EVENTTYPE, ...
Regular indexes on (R_ID,C_ID) and EVENTTYPE.
The SELECT runs well as long as the compound index is used first
and runs poorly once a new EVENTTYPE is introduced (there are
approx 10 event types and a new one is being introduced) and its
index consulted first.
Thansk,
Darren

Delayed block cleanout really confused me. I don't see how
the details of block updates, SCNs and what is on disk relates
to explain plans and a SQL statement that changes from
performing well using the intended index to poorly using an index
on a column having low cardinality.
The SQL is actually quite trivial and a merely a lookup on this
single table.
SELECT * FROM table
WHERE c_id = :1 and r_id = :2 and eventtype = :3
Most of the time Oracle uses the intended index (r_id, c_id) and
performs well. As long as both columns are used in the condition
I don't think that ordering of them is an issue.
If the CBO uses stats which get updated nightly after sufficient
changes to the table then how can a statement change its execution
plans (for the same user) following a addition of a row having a
new EVENTTYPE value over a 2min period.
That is the reason that I want to see/understand what the CBO
is doing.
It turns out that adding a new index (C_ID, R_ID, EVENTTYPE) was
the bandaid needed to fix the problem but I'd like to get rid of
it if its not needed.
I'll look at these posts and try to get the differing plans back.
At this point I'll need to drop the new index and break the app
again and might receive some resistance to that.
Thanks for your input,
Darren

I want to understand Explain Plan

Dear Gurus,
I want learn/understand Explain Plan for query so as to tune the query.
OR I want to tune query by understanding their plan but how it help to tune query.
Could anybody give me link or material on above.
Thanking in advance
Sanjeev

If you don't want to read the Oracle documentation, then this book is excellent: Troubleshooting Oracle Performance - Christian Antognini
It does a great job of explaining execution plans.

Understanding meaning of a query's explain plan

Hi,
I have a simple query but its query plan is looking difficult for me to understand. Can someone help me explain step by step what happens inthe query. I mean "first step table emp is full scan , than next step is another table's scan..." etc - in that way. I can't make out and need help to understand.
SQL> explain plan for
2 SELECT ename,dname ,grade
3 from n1.salgrade salgrade ,n1.emp emp,n1.dept dept
4 where emp.deptno=dept.deptno and
5 emp.sal between salgrade.losal and salgrade.hisal;
SQL> select plan_table_output from table(dbms_xplan.display());
Plan hash value: 4131418678
| Id | Operation             | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |          |     1 |    36 |    12 (25)| 00:00:01 |
|* 1 | HASH JOIN            |          |     1 |    36 |    12 (25)| 00:00:01 |
|   2 |   MERGE JOIN          |          |     1 |    23 |     8 (25)| 00:00:01 |
|   3 |    SORT JOIN          |          |     5 |    50 |     4 (25)| 00:00:01 |
|   4 |     TABLE ACCESS FULL | SALGRADE |     5 |    50 |     3   (0)| 00:00:01 |
|* 5 |    FILTER             |          |       |       |            |          |
|* 6 |     SORT JOIN         |          |    14 |   182 |     4 (25)| 00:00:01 |
|   7 |      TABLE ACCESS FULL| EMP      |    14 |   182 |     3   (0)| 00:00:01 |
|   8 |   TABLE ACCESS FULL   | DEPT     |     4 |    52 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
   5 - filter("EMP"."SAL"<="SALGRADE"."HISAL")
   6 - access("EMP"."SAL">="SALGRADE"."LOSAL")
       filter("EMP"."SAL">="SALGRADE"."LOSAL")for example my question is why there is SORT JOIN on step no 6? does it mean that rows obtained from step 7 are sorted? than what is done during the step of FILTER?why there are so many joins. Basically I am not good in this area so need help.
Thanks
Edited by: orausern on Sep 23, 2010 11:58 AM

The operations are performed in the following order: 4, 3, 7, 6, 5, 2, 8, 1, 0. The Merge Join operation in Node 2 consumes the SALGRADE and EMP records produced by Node 3 and Node 5 respectively. Node 3 and Node 5 are therefore visited repeatedly during the Merge Join operation. Whenever Node 3 produces a SALGRADE record, Node 5 tries to produce matching EMP records. Node 6 produces EMP records that satisfy the condition EMP.SAL >= SALGRADE.LOSAL. Node 5 then checks if the EMP records produced by Node 6 satisfy the additional condition EMP.SAL <= SALGRADE.HISAL before releasing them. All the results of the Merge Join operation are stored in a hash table in memory. Once the construction of the hash table is fully complete, the DEPT table is scanned and each DEPT record is checked using the hash table.
Iggy

Looking for a book or link to understand indexes stats an explain plan

Please,
Where could I find a good book or link to leran more about indexes statistics:
My Concerns are:
How could I know indexes in the database that are most used,less used and used at all in order to get rid of the last one?
A book or link to fully undertstand how to analyze explain plan give some advices from that.
Thank a lot for your coperation

There is any link where I can find how to analyze explain plan output?Again, the manuals are usually a good place to start:
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#g42231

Help to understand the explain plan

Hi, Everyone,
i have query :
INSERT INTO ICM_UPSEL_1_ALL
select a.customer_no,a.pr_code_bbl,min(b.pr_code_pmm) pr_code_pmm,a.score,a.price_diff,a.flag
from ICM_UPSEL_MIN_PRDIFF_1 a, icm_pre b
where a.customer_no = b.customer_no
and a.pr_code_bbl=b.pr_code_bbl
and a.score = b.score
and a.flag = b.flag
and a.price_diff = b.price_diff
and b.price_diff > 0
and b.score >=0.5
and b.flag = 1
and b.price_diff > 0 and b.price_diff <= 10
group by a.customer_no,a.pr_code_bbl,a.score,a.price_diff,a.flag
This query is running in a pl/sql procedure. The explain plan for this query is :
Plan hash value: 3124235498
| Id | Operation                       | Name                           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT                |                                |     1 |   143 |     4 (25)| 00:00:01 |
|   1 | LOAD TABLE CONVENTIONAL        | ICM_UPSEL_1_ALL        |       |       |            |          |
|   2 |   HASH GROUP BY                 |                                |     1 |   143 |     4 (25)| 00:00:01 |
|   3 |    NESTED LOOPS                 |                                |       |       |            |          |
|   4 |     NESTED LOOPS                |                                |     1 |   143 |     3   (0)| 00:00:01 |
|* 5 |      TABLE ACCESS BY INDEX ROWID| ICM_UPSEL_MIN_PRDIFF_1 |     1 |    65 |     1   (0)| 00:00:01 |
|* 6 |       INDEX RANGE SCAN          | MPD_1_FLAG_IDX                 |     1 |       |     1   (0)| 00:00:01 |
|* 7 |      INDEX RANGE SCAN           | ICM_PRE_FLAG_IDX               |     1 |       |     2   (0)| 00:00:01 |
|* 8 |     TABLE ACCESS BY INDEX ROWID | ICM_PRE                |     1 |    78 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   5 - filter("A"."PRICE_DIFF">0 AND "A"."SCORE">=0.5 AND "A"."PRICE_DIFF"<=10)
   6 - access("A"."FLAG"=1)
   7 - access("B"."FLAG"=1)
   8 - filter("B"."PRICE_DIFF"<=10 AND "B"."SCORE">=0.5 AND "B"."PRICE_DIFF">0 AND
              "A"."CUSTOMER_NO"="B"."CUSTOMER_NO" AND "A"."PR_CODE_BBL"="B"."PR_CODE_BBL" AND "A"."SCORE"="B"."SCORE"
              AND "A"."PRICE_DIFF"="B"."PRICE_DIFF")
This query is running for 10 hours now and no result yet. Could anyone please help me where is going wrong... why is it taking so much time to insert the data...
The number of rows in ICM_UPSEL_MIN_PRDIFF_1 : 84,858
The number of rows in icm_pre : 455,500,944
All the columns are indexed.
My database version is 11.1.0.6 running on windows server 2003 R2.
Thanks in advance

Hi, Nikolay,
Please see the results below;
SELECT * FROM DBA_TAB_COL_STATISTICS
WHERE OWNER = 'SAST' AND TABLE_NAME = 'ICM_UPSEL_MIN_PRDIFF_1' AND COLUMN_NAME = 'FLAG';
TABLE_NAME
COLUMN_NAME
NUM_DISTINCT
LOW_VALUE
HIGH_VALUE
DENSITY
NUM_NULLS
NUM_BUCKETS
LAST_ANALYZED
SAMPLE_SIZE
GLOBAL_STATS
USER_STATS
AVG_COL_LEN
HISTOGRAM
SAST    ICM_UPSEL_MIN_PRDIFF_1    FLAG    1    C102    C102    0.00000584543291182618    0    1    16/07/13 10:01:42    5544    YES    NO    3    FREQUENCY
SELECT * FROM DBA_TAB_STATISTICS WHERE OWNER = 'SAST' AND TABLE_NAME = 'ICM_UPSEL_MIN_PRDIFF_1';
TABLE_NAME
PARTITION_NAME
PARTITION_POSITION
SUBPARTITION_NAME
SUBPARTITION_POSITION
OBJECT_TYPE
NUM_ROWS
BLOCKS
EMPTY_BLOCKS
AVG_SPACE
CHAIN_CNT
AVG_ROW_LEN
AVG_SPACE_FREELIST_BLOCKS
NUM_FREELIST_BLOCKS
AVG_CACHED_BLOCKS
AVG_CACHE_HIT_RATIO
SAMPLE_SIZE
LAST_ANALYZED
GLOBAL_STATS
USER_STATS
STATTYPE_LOCKED
STALE_STATS
SAST    ICM_UPSEL_MIN_PRDIFF_1
TABLE    84858    874    0    0    0    62    0    0
84858    16/07/13 10:02:00    YES    NO
NO
Thanks & Regards
Su

Please help to understand 10g explain plan

Hello
I am trying to optimize one query. I have taken explain plan of this query in 9i and 10g database both.
Explain plan for index scan is different in 9i and 10g. In 9i inedex was scaned with INDEX RANGE SCAN NON-UNIQUE and in 10g index is scanned with
INDEX RANGE SCAN.
Can anybody explain the difference of scanning an index in 9i and 10g? Cost in 9i was 74 and now in 10g it is 1134.
Thanks in advance

Well, if you tables structures and indexes are the same in both databases then that's unlikely to be an issue, however you need to check other factors such as whether statistics have been gathered for the data recently.
For helpful info on optimising queries and what to look out for read the following thread...
[When your query takes too long|http://forums.oracle.com/forums/thread.jspa?messageID=1812597#1812597]

Explain Plan Understanding

Similar Messages

Maybe you are looking for