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

Similar Messages

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

DECODE is changing the explain plan

I have a statement with a decode function in the where clause like this:
AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)When I a pass -1 as parameter for cropgroup the filter would result in "AND '-1' = '-1' and the statement is executed in less than 2 seconds. When I leave out this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan is so much different and why not using index scans in the statement without decode.
Below the explain plans and tkprofs for 1 (without decode) and 2 (with decode).
*explain 1*
{code}
SQL Statement which produced this data:
select * from table(dbms_xplan.display)
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 7080 | 2413K| | 43611 (2)|
| 1 | SORT ORDER BY | | 7080 | 2413K| 5224K| 43611 (2)|
|* 2 | FILTER | | | | | |
|* 3 | HASH JOIN | | 7156 | 2438K| | 43075 (2)|
| 4 | TABLE ACCESS FULL | DWH_ABS_DETERMINATION | 17745 | 363K| | 83 (0)|
|* 5 | HASH JOIN OUTER | | 7156 | 2292K| | 42991 (2)|
|* 6 | HASH JOIN | | 7156 | 1355K| | 42907 (2)|
|* 7 | HASH JOIN | | 6987 | 1187K| | 19170 (2)|
|* 8 | HASH JOIN | | 6947 | 963K| | 10376 (1)|
|* 9 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3 | 144 | | 3 (0)|
| 10 | NESTED LOOPS | | 6907 | 897K| | 8577 (1)|
|* 11 | HASH JOIN | | 2264 | 187K| | 1782 (2)|
| 12 | TABLE ACCESS BY INDEX ROWID | SAMPLE | 190 | 4370 | | 17 (0)|
| 13 | NESTED LOOPS | | 2264 | 152K| | 107 (1)|
| 14 | NESTED LOOPS | | 12 | 552 | | 25 (0)|
|* 15 | TABLE ACCESS FULL | SDG_USER | 12 | 288 | | 13 (0)|
| 16 | TABLE ACCESS BY INDEX ROWID| SDG | 1 | 22 | | 1 (0)|
|* 17 | INDEX UNIQUE SCAN | PK_SDG | 1 | | | 0 (0)|
|* 18 | INDEX RANGE SCAN | FK_SAMPLE_SDG | 597 | | | 2 (0)|
| 19 | TABLE ACCESS FULL | SAMPLE_USER | 1078K| 16M| | 1669 (1)|
|* 20 | INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | | 2 (0)|
| 21 | TABLE ACCESS FULL | ALIQUOT_USER | 3403K| 29M| | 1781 (3)|
| 22 | TABLE ACCESS FULL | TEST | 3423K| 104M| | 8775 (2)|
|* 23 | TABLE ACCESS FULL | RESULT | 3435K| 65M| | 23718 (2)|
| 24 | VIEW | PLATE | 21787 | 2851K| | 84 (2)|
|* 25 | FILTER | | | | | |
| 26 | TABLE ACCESS FULL | PLATE | 21787 | 574K| | 84 (2)|
|* 27 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 28 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 29 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 30 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 31 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
Predicate Information (identified by operation id):
2 - filter(("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1)) AND ("GROUP_ID" IS NULL
OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
"OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B2)) AND ("GROUP_ID" IS NULL OR EXISTS (SELECT /*+
*/ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND
"GROUP_ID"=:B3)) AND ("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B4)))
3 - access("U_ABS_DETERMINATION"="DETERMINATION_ASSIGNMENT")
5 - access("PLT"."PLATE_ID"(+)="PLATE_ID")
6 - access("TEST_ID"="TEST_ID")
7 - access("ALIQUOT_ID"="ALIQUOT_ID")
8 - access("ALIQUOT_ID"="ALIQUOT_ID")
9 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
11 - access("SAMPLE_ID"="SAMPLE_ID")
15 - filter("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE"='QC' AND
"U_WEEK_OF_PROCESSING"=TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY"=TO_NUMBER(:YEAR))
17 - access("SDG_ID"="SDG_ID")
18 - access("SDG_ID"="SDG_ID")
20 - access("SAMPLE_ID"="SAMPLE_ID")
23 - filter("NAME"='End result')
25 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1))
27 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
28 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
29 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
30 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
31 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
Note
- 'PLAN_TABLE' is old version
{code}
*tkprof 1*
{code}
TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:21:47 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT sdu.u_crop_group,
sd.name as sdg_name,
ad.variety_name,
ad.batch_number,
a.name as aliquot_name,
sau.u_box_code as box_code,
sau.u_box_position as box_position,
t.name as test_name,
r.original_result,
plt.name as plate_name,
concat(chr(a.plate_row + 64),a.plate_column) as plate_position,
au.u_replicate_number as replicate_number
FROM lims_sys.sdg sd,
lims_sys.sdg_user sdu,
lims_sys.sample sa,
lims_sys.sample_user sau,
lims_sys.aliquot a,
lims_sys.aliquot_user au,
lims_sys.test t,
lims_sys.result r,
lims_sys.plate plt,
lims_sys.abs_determination ad
WHERE sd.sdg_id = sdu.sdg_id
AND sd.sdg_id = sa.sdg_id
AND sa.sample_id = sau.sample_id
AND sau.sample_id = a.sample_id
AND a.aliquot_id = au.aliquot_id
AND au.aliquot_id = t.aliquot_id
AND t.test_id = r.test_id
AND plt.plate_id (+) = a.plate_id
AND sdu.u_abs_determination = ad.determination_assignment
AND a.status IN ('V','P','C')
AND r.name = 'End result'
AND sdu.u_client_type = 'QC'
AND sdu.u_year_of_sample_delivery = (:year)
AND sdu.u_week_of_processing = (:week)
--AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
ORDER BY box_code, box_position, replicate_number
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 1.15 1.16 0 0 0 0
Fetch 1 8.53 16.10 227649 241266 0 500
total 3 9.68 17.27 227649 241266 0 500
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows Row Source Operation
500 SORT ORDER BY (cr=241266 pr=227649 pw=0 time=16104631 us)
21311 FILTER (cr=241266 pr=227649 pw=0 time=16246749 us)
21311 HASH JOIN (cr=241266 pr=227649 pw=0 time=16225434 us)
17745 TABLE ACCESS FULL DWH_ABS_DETERMINATION (cr=374 pr=0 pw=0 time=69 us)
21311 HASH JOIN RIGHT OUTER (cr=240892 pr=227649 pw=0 time=16170607 us)
21895 VIEW PLATE (cr=316 pr=0 pw=0 time=43825 us)
21895 FILTER (cr=316 pr=0 pw=0 time=43823 us)
21895 TABLE ACCESS FULL PLATE (cr=316 pr=0 pw=0 time=31 us)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
21311 HASH JOIN (cr=240576 pr=227649 pw=0 time=16106174 us)
21311 HASH JOIN (cr=133559 pr=121596 pw=0 time=9594130 us)
21311 HASH JOIN (cr=94323 pr=83281 pw=0 time=6917067 us)
21311 HASH JOIN (cr=86383 pr=75547 pw=0 time=5509672 us)
7776 HASH JOIN (cr=8134 pr=0 pw=0 time=285364 us)
7776 TABLE ACCESS BY INDEX ROWID SAMPLE (cr=572 pr=0 pw=0 time=27152 us)
7876 NESTED LOOPS (cr=377 pr=0 pw=0 time=488287 us)
99 HASH JOIN (cr=160 pr=0 pw=0 time=4168 us)
99 TABLE ACCESS FULL SDG_USER (cr=53 pr=0 pw=0 time=1209 us)
5719 TABLE ACCESS FULL SDG (cr=107 pr=0 pw=0 time=17 us)
7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr=217 pr=0 pw=0 time=623 us)(object id 45990)
1079741 TABLE ACCESS FULL SAMPLE_USER (cr=7562 pr=0 pw=0 time=24 us)
3307948 TABLE ACCESS FULL ALIQUOT (cr=78249 pr=75547 pw=0 time=3331129 us)
3406836 TABLE ACCESS FULL ALIQUOT_USER (cr=7940 pr=7734 pw=0 time=556 us)
3406832 TABLE ACCESS FULL TEST (cr=39236 pr=38315 pw=0 time=3413192 us)
3406832 TABLE ACCESS FULL RESULT (cr=107017 pr=106053 pw=0 time=6848487 us)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
select 'x'
from
dual
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 1 0.00 0.00 0 0 0 1
total 3 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows Row Source Operation
1 FAST DUAL (cr=0 pr=0 pw=0 time=3 us)
begin :id := sys.dbms_transaction.local_transaction_id; end;
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 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 3 0.00 0.00 0 0 0 0
Execute 3 1.15 1.16 0 0 0 1
Fetch 2 8.53 16.10 227649 241266 0 501
total 8 9.68 17.27 227649 241266 0 502
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 30 0.00 0.00 0 0 0 0
Execute 30 0.00 0.00 0 0 0 0
Fetch 30 0.00 0.00 0 40 0 10
total 90 0.00 0.00 0 40 0 10
Misses in library cache during parse: 0
3 user SQL statements in session.
30 internal SQL statements in session.
33 SQL statements in session.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
Trace file compatibility: 10.01.00
Sort options: default
8 sessions in tracefile.
3 user SQL statements in trace file.
30 internal SQL statements in trace file.
33 SQL statements in trace file.
6 unique SQL statements in trace file.
633 lines in trace file.
23 elapsed seconds in trace file.
{code}

explain 2
SQL Statement which produced this data:
select * from table(dbms_xplan.display)
PLAN_TABLE_OUTPUT
| Id | Operation                               | Name                     | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT                        |                          |    71 | 24779 |   857   (1)|
|   1 | SORT ORDER BY                          |                          |    71 | 24779 |   857   (1)|
|* 2 |   FILTER                                |                          |       |       |            |
|* 3 |    TABLE ACCESS BY INDEX ROWID          | RESULT                   |     1 |    20 |     4   (0)|
|   4 |     NESTED LOOPS                        |                          |    72 | 25128 |   856   (1)|
|   5 |      NESTED LOOPS                       |                          |    70 | 23030 |   576   (1)|
|* 6 |       HASH JOIN OUTER                   |                          |    69 | 20493 |   369   (1)|
|   7 |        NESTED LOOPS                     |                          |    69 | 11247 |   285   (0)|
|   8 |         NESTED LOOPS                    |                          |    69 | 10626 |   147   (0)|
|   9 |          NESTED LOOPS                   |                          |    23 | 2438 |    78   (0)|
| 10 |           NESTED LOOPS                  |                          |    23 | 2070 |    32   (0)|
| 11 |            NESTED LOOPS                 |                          |     1 |    67 |    15   (0)|
| 12 |             NESTED LOOPS                |                          |     1 |    45 |    14   (0)|
|* 13 |              TABLE ACCESS FULL          | SDG_USER                 |     1 |    24 |    13   (0)|
| 14 |              TABLE ACCESS BY INDEX ROWID| DWH_ABS_DETERMINATION    |     1 |    21 |     1   (0)|
|* 15 |               INDEX UNIQUE SCAN         | PK_DWH_ABS_DETERMINATION |     1 |       |     0   (0)|
| 16 |             TABLE ACCESS BY INDEX ROWID | SDG                      |     1 |    22 |     1   (0)|
|* 17 |              INDEX UNIQUE SCAN          | PK_SDG                   |     1 |       |     0   (0)|
| 18 |            TABLE ACCESS BY INDEX ROWID | SAMPLE                   |   190 | 4370 |    17   (0)|
|* 19 |             INDEX RANGE SCAN            | FK_SAMPLE_SDG            |   597 |       |     2   (0)|
| 20 |           TABLE ACCESS BY INDEX ROWID   | SAMPLE_USER              |     1 |    16 |     2   (0)|
|* 21 |            INDEX UNIQUE SCAN            | PK_SAMPLE_USER           |     1 |       |     1   (0)|
|* 22 |          TABLE ACCESS BY INDEX ROWID    | ALIQUOT                  |     3 |   144 |     3   (0)|
|* 23 |           INDEX RANGE SCAN              | FK_ALIQUOT_SAMPLE        |     3 |       |     2   (0)|
| 24 |         TABLE ACCESS BY INDEX ROWID     | ALIQUOT_USER             |     1 |     9 |     2   (0)|
|* 25 |          INDEX UNIQUE SCAN              | PK_ALIQUOT_USER          |     1 |       |     1   (0)|
| 26 |        VIEW                             | PLATE                    | 21787 | 2851K|    84   (2)|
|* 27 |         FILTER                          |                          |       |       |            |
| 28 |          TABLE ACCESS FULL              | PLATE                    | 21787 |   574K|    84   (2)|
|* 29 |          INDEX UNIQUE SCAN              | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
| 30 |       TABLE ACCESS BY INDEX ROWID       | TEST                     |     1 |    32 |     3   (0)|
|* 31 |        INDEX RANGE SCAN                 | FK_TEST_ALIQUOT          |     1 |       |     2   (0)|
|* 32 |      INDEX RANGE SCAN                   | FK_RESULT_TEST           |     2 |       |     2   (0)|
|* 33 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
|* 34 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
|* 35 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
|* 36 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
Predicate Information (identified by operation id):
   2 - filter(("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
              "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1)) AND ("GROUP_ID"
              IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
              "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B2)) AND ("GROUP_ID" IS NULL OR EXISTS
              (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
              "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B3)) AND ("GROUP_ID" IS NULL OR EXISTS
              (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
              "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B4)))
   3 - filter("NAME"='End result')
   6 - access("PLT"."PLATE_ID"(+)="PLATE_ID")
13 - filter("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE"='QC' AND
              "U_WEEK_OF_PROCESSING"=TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY"=TO_NUMBER(:YEAR) AND
              DECODE(:CROPCODE,(-1),'-1',"U_CROP_GROUP")=DECODE(:CROPCODE,(-1),'-1',:CROPCODE))
15 - access("U_ABS_DETERMINATION"="DETERMINATION_ASSIGNMENT")
17 - access("SDG_ID"="SDG_ID")
19 - access("SDG_ID"="SDG_ID")
21 - access("SAMPLE_ID"="SAMPLE_ID")
22 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
23 - access("SAMPLE_ID"="SAMPLE_ID")
25 - access("ALIQUOT_ID"="ALIQUOT_ID")
27 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
              "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1))
29 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
31 - access("ALIQUOT_ID"="ALIQUOT_ID")
32 - access("TEST_ID"="TEST_ID")
33 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
34 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
35 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
36 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
Note
   - 'PLAN_TABLE' is old version
tkprof 2
TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:28:26 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_5456.trc
Sort options: default
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
SELECT sdu.u_crop_group,
       sd.name as sdg_name,
       ad.variety_name,
       ad.batch_number,
       a.name as aliquot_name,
       sau.u_box_code as box_code,
       sau.u_box_position as box_position,
       t.name as test_name,
       r.original_result,
       plt.name as plate_name,
       concat(chr(a.plate_row + 64),a.plate_column) as plate_position,
       au.u_replicate_number as replicate_number
FROM lims_sys.sdg sd,
     lims_sys.sdg_user sdu,
     lims_sys.sample sa,
     lims_sys.sample_user sau,
     lims_sys.aliquot a,
     lims_sys.aliquot_user au,
     lims_sys.test t,
     lims_sys.result r,
     lims_sys.plate plt,
     lims_sys.abs_determination ad
WHERE sd.sdg_id = sdu.sdg_id
AND sd.sdg_id = sa.sdg_id
AND sa.sample_id = sau.sample_id
AND sau.sample_id = a.sample_id
AND a.aliquot_id = au.aliquot_id
AND au.aliquot_id = t.aliquot_id
AND t.test_id = r.test_id
AND plt.plate_id (+) = a.plate_id
AND sdu.u_abs_determination = ad.determination_assignment
AND a.status IN ('V','P','C')
AND r.name = 'End result'
AND sdu.u_client_type = 'QC'
AND sdu.u_year_of_sample_delivery = (:year)
AND sdu.u_week_of_processing = (:week)
AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
ORDER BY box_code, box_position, replicate_number
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.45       0.87          0          0          0           0
Fetch        1      1.00       0.99          0     221420          0         500
total        3      1.46       1.86          0     221420          0         500
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows     Row Source Operation
    500 SORT ORDER BY (cr=221420 pr=0 pw=0 time=992364 us)
21311   FILTER (cr=221420 pr=0 pw=0 time=1128970 us)
21311    TABLE ACCESS BY INDEX ROWID RESULT (cr=221420 pr=0 pw=0 time=1086345 us)
42623     NESTED LOOPS (cr=217549 pr=0 pw=0 time=30006317 us)
21311      NESTED LOOPS (cr=174880 pr=0 pw=0 time=809278 us)
21311       NESTED LOOPS (cr=110117 pr=0 pw=0 time=553538 us)
21311        HASH JOIN OUTER (cr=46182 pr=0 pw=0 time=319102 us)
21311         TABLE ACCESS BY INDEX ROWID ALIQUOT (cr=45866 pr=0 pw=0 time=193037 us)
29088          NESTED LOOPS (cr=39885 pr=0 pw=0 time=320084 us)
   7776           NESTED LOOPS (cr=24267 pr=0 pw=0 time=156721 us)
   7776            NESTED LOOPS (cr=937 pr=0 pw=0 time=78954 us)
     99             NESTED LOOPS (cr=454 pr=0 pw=0 time=3826 us)
     99              NESTED LOOPS (cr=253 pr=0 pw=0 time=2833 us)
     99               TABLE ACCESS FULL SDG_USER (cr=53 pr=0 pw=0 time=1531 us)
     99               TABLE ACCESS BY INDEX ROWID DWH_ABS_DETERMINATION (cr=200 pr=0 pw=0 time=956 us)
     99                INDEX UNIQUE SCAN PK_DWH_ABS_DETERMINATION (cr=101 pr=0 pw=0 time=438 us)(object id 46965)
     99              TABLE ACCESS BY INDEX ROWID SDG (cr=201 pr=0 pw=0 time=707 us)
     99               INDEX UNIQUE SCAN PK_SDG (cr=101 pr=0 pw=0 time=330 us)(object id 46071)
   7776             TABLE ACCESS BY INDEX ROWID SAMPLE (cr=483 pr=0 pw=0 time=16261 us)
   7776              INDEX RANGE SCAN FK_SAMPLE_SDG (cr=217 pr=0 pw=0 time=562 us)(object id 45990)
   7776            TABLE ACCESS BY INDEX ROWID SAMPLE_USER (cr=23330 pr=0 pw=0 time=64710 us)
   7776             INDEX UNIQUE SCAN PK_SAMPLE_USER (cr=15554 pr=0 pw=0 time=33728 us)(object id 46012)
21311           INDEX RANGE SCAN FK_ALIQUOT_SAMPLE (cr=15618 pr=0 pw=0 time=43423 us)(object id 45346)
21895         VIEW PLATE (cr=316 pr=0 pw=0 time=43833 us)
21895          FILTER (cr=316 pr=0 pw=0 time=21936 us)
21895           TABLE ACCESS FULL PLATE (cr=316 pr=0 pw=0 time=37 us)
      0           INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
21311        TABLE ACCESS BY INDEX ROWID ALIQUOT_USER (cr=63935 pr=0 pw=0 time=182479 us)
21311         INDEX UNIQUE SCAN PK_ALIQUOT_USER (cr=42624 pr=0 pw=0 time=99160 us)(object id 45386)
21311       TABLE ACCESS BY INDEX ROWID TEST (cr=64763 pr=0 pw=0 time=219096 us)
21311        INDEX RANGE SCAN FK_TEST_ALIQUOT (cr=42669 pr=0 pw=0 time=129354 us)(object id 46222)
21311      INDEX RANGE SCAN FK_RESULT_TEST (cr=42669 pr=0 pw=0 time=125893 us)(object id 45940)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
select 'x'
from
dual
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        1      0.00       0.00          0          0          0           1
total        3      0.00       0.00          0          0          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows     Row Source Operation
      1 FAST DUAL (cr=0 pr=0 pw=0 time=6 us)
begin :id := sys.dbms_transaction.local_transaction_id; end;
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          2           0
Execute      1      0.00       0.00          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          0          2           1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.01       0.00          0          0          2           0
Execute      3      0.45       0.87          0          0          0           1
Fetch        2      1.00       0.99          0     221420          0         501
total        8      1.46       1.87          0     221420          2         502
Misses in library cache during parse: 2
Misses in library cache during execute: 2
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       43      0.01       0.00          0          0         12           0
Execute    128      0.00       0.01          0          0          0           0
Fetch      178      0.00       0.00          0        383          0         465
total      349      0.01       0.02          0        383         12         465
Misses in library cache during parse: 5
Misses in library cache during execute: 5
    3 user SQL statements in session.
128 internal SQL statements in session.
131 SQL statements in session.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_5456.trc
Trace file compatibility: 10.01.00
Sort options: default
       1 session in tracefile.
       3 user SQL statements in trace file.
     128 internal SQL statements in trace file.
     131 SQL statements in trace file.
      19 unique SQL statements in trace file.
    1352 lines in trace file.
     287 elapsed seconds in trace file.

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

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

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!

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.

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.

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

Understanding CBO decisions, explain plan instability

Similar Messages

Maybe you are looking for