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]
Similar Messages
-
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 -
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 advanceHi, 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 advanceWell, 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] -
SQL Tuning - Not understanding the explain plan.
Hi All,
I am using 11g R2 and I have 2 questions about tuning a query.
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - ProductionMy parameters relevant to the optimizer are :
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUEThe query I would like to execute is pretty simple. It just returns some exceptions with a filter.
SELECT ERO.DVC_EVT_ID, E.DVC_EVT_DTTM
FROM D1_DVC_EVT E, D1_DVC_EVT_REL_OBJ ERO
WHERE ERO.MAINT_OBJ_CD = 'D1-DEVICE'
AND ERO.PK_VALUE1 = :H1
AND ERO.DVC_EVT_ID = E.DVC_EVT_ID
AND E.DVC_EVT_TYPE_CD IN ('END-GSMLOWLEVEL-EXCP-SEV-1', 'STR-GSMLOWLEVEL-EXCP-SEV-1')
ORDER BY E.DVC_EVT_DTTM DESC;The execution plan is the following :
Plan hash value: 3627978539
| Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| Pstart| Pstop | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem |
| 0 | SELECT STATEMENT | | 1 | | | 7131 (100)| | | 1181 |00:00:17.17 | 8627 | 2978 | | | |
| 1 | SORT ORDER BY | | 1 | 3137 | 275K| 7131 (1)| | | 1181 |00:00:17.17 | 8627 | 2978 | 80896 | 80896 |71680 (0)|
| 2 | NESTED LOOPS | | 1 | | | | | | 1181 |00:00:17.16 | 8627 | 2978 | | | |
| 3 | NESTED LOOPS | | 1 | 3137 | 275K| 7130 (1)| | | 2058 |00:00:08.09 | 6709 | 1376 | | | |
| 4 | TABLE ACCESS BY INDEX ROWID | D1_DVC_EVT_REL_OBJ | 1 | 3137 | 125K| 845 (1)| | | 2058 |00:00:04.37 | 820 | 799 | | | |
|* 5 | INDEX RANGE SCAN | D1T404S0 | 1 | 3137 | | 42 (0)| | | 2058 |00:00:00.08 | 27 | 23 | | | |
| 6 | PARTITION RANGE ITERATOR | | 2058 | 1 | | 1 (0)| KEY | KEY | 2058 |00:00:03.69 | 5889 | 577 | | | |
|* 7 | INDEX UNIQUE SCAN | D1T400P0 | 2058 | 1 | | 1 (0)| KEY | KEY | 2058 |00:00:03.66 | 5889 | 577 | | | |
|* 8 | TABLE ACCESS BY GLOBAL INDEX ROWID| D1_DVC_EVT | 2058 | 1 | 49 | 2 (0)| ROWID | ROWID | 1181 |00:00:09.05 | 1918 | 1602 | | | |
Peeked Binds (identified by position):
1 - (VARCHAR2(30), CSID=178): '271792300706'
Predicate Information (identified by operation id):
5 - access("ERO"."PK_VALUE1"=:H1 AND "ERO"."MAINT_OBJ_CD"='D1-DEVICE')
filter("ERO"."MAINT_OBJ_CD"='D1-DEVICE')
7 - access("ERO"."DVC_EVT_ID"="E"."DVC_EVT_ID")
8 - filter(("E"."DVC_EVT_TYPE_CD"='END-GSMLOWLEVEL-EXCP-SEV-1' OR "E"."DVC_EVT_TYPE_CD"='STR-GSMLOWLEVEL-EXCP-SEV-1'))So as you can see, row 8, I have a TABLE ACCESS BY GLOBAL INDEX ROWID. But what I am failling to see is how Oracle display a TABLE ACCESS BY GLOBAL INDEX ROWID without using any index. As thought that Oracle always got a ROWID because of an index.
I also have an index on the column DVC_EVT_TYPE_CD in my table (row 8 of the predicate information section)
And finally what would be your suggestion to improve the runtime of this query...
Many thanks.if I read the rowsource statistics information and the plan correctly then the table access in step 4 on D1_DVC_EVT_REL_OBJ needs 4.37 sec and accesses 820 buffers. If you had an index D1_DVC_EVT_REL_OBJ(MAINT_OBJ_CD, PK_VALUE1, DVC_EVT_ID) I assume that this table access could be avoided. To avoid the table access on D1_DVC_EVT an index on D1_DVC_EVT(DVC_EVT_ID, DVC_EVT_TYPE_CD, DVC_EVT_DTTM) should be sufficient.
I think these indexes would improve the performance of the given query but of course they would have a negative impact on DML performance on the table and they could influence other queries on the table. -
Understanding the Explain Plan.
Dear All,
I m having one sql statement which is running slow and it is fully remote statement means output gathered through using dblink, Here I m having the explan but not know how to use it. Pls guide me..
| Id | Operation | Name | Rows | Bytes |Temp Spc| Cost (%CPU)| Inst |
| 0 | SELECT STATEMENT REMOTE | | 12807 | 700K| PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------- | 10201 (1)| |
| 1 | HASH GROUP BY | | 12807 | 700K| 16 24K| 10201 (1)| |
| 2 | HASH JOIN | | 12807 | 700K| | 10023 (1)| |
| 3 | INDEX FULL SCAN | PK_ZONE_CD | 90 | 450 | | 1 (0)| WATER~ |
PLAN_TABLE_OUTPUT
| 4 | TABLE ACCESS BY INDEX ROWID| ACC_LOC1_TAB_1999 | 232 | 9744 | | 2318 (1)| WATER~ |
| 5 | NESTED LOOPS | | 12807 | 637K| | 10021 (1)| |
| 6 | TABLE ACCESS FULL | ACC_MST1_TAB | 55 | 495 | | 199 (4)| WATER~ |
| 7 | INDEX RANGE SCAN | ACC_LOC1_TAB_IDX03 | 2683 | | | 139 (1)| WATER~ |
Note
- 'PLAN_TABLE' is old version
- fully remote statement .Pls find the TKPROF output below...If any suggetion to make query fast.
select
z.vzmt_cd Zone
,a.alt_vert_cd vert_cd,a.alt_loc exec
,a.alt_inv_dt tr_dt
,'INVOICE' TR_TYPE
, 0 sls_ord
,sum(decode(alt_dc,1,alt_amt,2,(alt_amt*-1)))*-1 INV_amt
,0 coll_amt
,0 chq_r_amt
, 0 OUT_ST_AMT
from FAS.acc_loc1_tab_1999@MRP2_LIVE_LINK a, FAS.acc_mst1_tab@MRP2_LIVE_LINK m, FAS.vert_zone_mst1_tab@MRP2_LIVE_LINK z
where
a.alt_authdt between '01-APR-2009' AND '31-MAR-2010'
and a.alt_doc_typ ='JT09'
and a.alt_cd = m.amt_cd
and m.amt_grp_cd ='1301'
and substr(a.alt_cost,5,2) = z.vzmt_gl_cost
group by
z.vzmt_cd
,a.alt_vert_cd,a.alt_loc
,a.alt_inv_dt
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.29 0 0 0 0
Fetch 511 0.07 4.39 0 0 0 7641
total 513 0.07 4.69 0 0 0 7641
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 309
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.29 0 0 0 0
Fetch 511 0.07 4.39 0 0 0 7641
total 513 0.07 4.69 0 0 0 7641
Misses in library cache during parse: 0
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
0 statements EXPLAINed in this session.
Trace file: /oracle/admin/waterdb2/udump/waterdb2_ora_3721.trc
Trace file compatibility: 10.01.00
Sort options: default
1 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
559 lines in trace file.
29 elapsed seconds in trace file. -
Bitmap conversion explain plan
Hi friends,
I'm trying to understand the explain plan with queries in my oracle 9.2 database. I have read something about but it is difficult to me to understand why the optimizer uses "bitmap conversion [to rowids]", "bitmap and" and "bitmap conversion [from rowids]". I'm not sure if this is a good or a bad signal. Probably is just I always find bitmap conversion when I'm not happy with queries results timin.
I have not bitmap indexes created in my database, and perhaps is it suggesting me to create them?
Thanks for answers.Hi agemaia,
Take a look to this link:
http://www.dba-oracle.com/t_bitmap_conversion_to_rowid.htm
I think this answers your question, quite simple. I will write any other useful link. -
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,
jeneeshNext 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 PMPlease 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 -
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 explanationTaral 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 -
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! -
Oracle Gurus,
I am trying to understand the below explain plan which I generated using DBMS_XPLAN. This explain plan shows 380M cost, what do "M" and "K" mean here? If anyone has any good documentation to understand explain plan, please pass on.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | INSERT STATEMENT | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
| 1 | HASH UNIQUE | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
|* 2 | FILTER | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ10002 | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | P->S | QC (RAND) |
|* 5 | HASH JOIN BUFFERED | | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | PCWP | |
| 6 | PX RECEIVE | | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,02 | PCWP | |
| 7 | PX SEND HASH | :TQ10000 | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,00 | P->P | HASH |
| 8 | PX BLOCK ITERATOR | | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWC | |
|* 9 | TABLE ACCESS FULL | TOP10_UL_SECTOR_LUCENT | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWP | |
| 10 | PX RECEIVE | | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,02 | PCWP | |
| 11 | PX SEND HASH | :TQ10001 | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,01 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWC | |
|* 13 | TABLE ACCESS FULL | BH_UL_SECTOR_LUCENT | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWP | |
| 14 | SORT AGGREGATE | | 1 | 14 | | | | | | | |
| 15 | PARTITION RANGE ITERATOR| | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
|* 16 | INDEX SKIP SCAN | IDX2_BH_UL_SECTOR_LUCENT | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
-----------------------------------------------------------------------------------------------------------------------------------------------------Hello,
Once again K is number of (1000) rows fetched and M is for bytes repsentation. Check this oracle doc for reading xplan
Cost of the operation as estimated by the optimizer's query approach. Cost is not determined for table access operations. The value of this column does not have any particular unit of measurement; it is merely a weighted value used to compare costs of execution plans. The value of this column is a function of the CPU_COST and IO_COST columns
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i16971
Regards -
Explain Plan 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. -
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,
DarrenDelayed 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
Maybe you are looking for
-
Using Text Tool Freezes Photoshop CC 2014.2 x64 release
I have just updated Photoshop CC to 2014.2.0 -- 20140926.r.236 x64 release. Now I am experiencing an issue when I use the text tool to just type a few words on a new document or layer. The application seems to freeze up as soon as I start typing? I w
-
I need a new Nvidia card. I want the gtx 970 but I am concerned about the power supply. It is listed at 600 watts but I need 2- 8 pin power plugs to run most of the available cards. I notice there are 2 6 pin plugs in the box one black and one white.
-
When Deploying SharePoint 2010 solution using Powershell gives me nothing
When Deploying SharePoint 2010 solution using Powershell gives me nothing And when go to Central Admin >> System Settings >> Farm Management >> Manage Farm Solution I found my Solution Status is Deploying and still deploying and nothing.
-
hi .. i want to make receipt number not required in AR Because i already have Document number is active OR can i copy Document number to receipt number .. thank you kareem Edited by: Kareem on Feb 27, 2012 3:27 AM
-
How to place grouped items into another object with content collector tool?
Is it possible to paste a group into another object (i.e. frame) by using the Content Collector Tool while linking the content? Paste Into is either deselected or possibly whatever was last saved to the clipboard ends up inserting. I was able to pla