Explain plan for select distinct
I got 1 of the online test and there the question has been asked. I have already answered but curious to cross-check my response with your advice...
Question
Explain what information plan if the show room in SQL indicates that a separate select statement is made in the SQL.
The choices are:
Sort by a join
b sort by
c single fate
d sort aggregate
group e - sort by
My answer
I gave aggregates of SORT but it seems that his unique kind, because when I run explain plan then I see (unique) hash. Please guide
SEPARATE will identify unique rows. So in the given choice it would be KIND of UNIQUE. But oracle could go other plans as UNIQUE HASH or same INDEX FULL SCAN.
Look at the oracle does not SORT.
SQL> select distinct ename from emp; ENAME ------ SMITH BLAKE CLARK KING ADAMS TURNER ALLEN SCOTT JONES MARTIN WARD 11 rows selected. SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------- SQL_ID 6b32yqumjmp9b, child number 0 ------------------------------------- select distinct ename from emp Plan hash value: 984151148 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 3 (100)| | | 1 | HASH UNIQUE | | 11 | 66 | 3 (34)| 00:00:01 | | 2 | TABLE ACCESS FULL| EMP | 11 | 66 | 2 (0)| 00:00:01 | --------------------------------------------------------------------------- 14 rows selected.
Let me make an explicit ORDER BY for her to performa SORT.
SQL> select distinct ename from emp order by 1; ENAME ------ ADAMS ALLEN BLAKE CLARK JONES KING MARTIN SCOTT SMITH TURNER WARD 11 rows selected. SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------- SQL_ID f72vjx5rmm0z4, child number 0 ------------------------------------- select distinct ename from emp order by 1 Plan hash value: 725351111 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 4 (100)| | | 1 | SORT UNIQUE | | 11 | 66 | 3 (34)| 00:00:01 | | 2 | TABLE ACCESS FULL| EMP | 11 | 66 | 2 (0)| 00:00:01 | --------------------------------------------------------------------------- 14 rows selected. SQL>
Version - 10.2.0.5.0
Tags: Database
Similar Questions
-
explain plan for the same query diff
Hi experts,
Please, help me understand explain the plan. I have tow Server (server and two server). The server are same table, even the type of database, even version Oracle (gr 11 (2), same operating system (linux Redhat 5.5) and same table and index.
but when I explain the plan for the same query on the two server. I got diff--diff to explain the plan. reason it has different, according to my understanding, it should be same. explain please, I share the explain plan and lower indices for the two server.
Server a
SQL > col COLUMN_NAME format a20
SQL > select index_name, column_name, position_colonne from user_ind_columns where table_name = 'LOAN_RUNNING_DETAILS_SOUTH"of order 1.
INDEX_NAME COLUMN_NAME POSITION_COLONNE
------------------------------ -------------------- ---------------
DATE_IND1_S LOANDATETIME 1
IND_MSI_LN_LNS1_S MSISDN 1
IND_MSI_LN_LNS1_S LOANDATETIME 2
IND_MSI_LN_LNS1_S LOANSTATUS 3
LAST_INDEX L_INDX_MSISDN_S 1
MSISDN L_INDX_MSISDN_S 2
SQL > select decode (status, 'N/a', 'Part Hdr', 'Global') ind_type, index_name, NULL nom_partition, status
2 from user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH '.
3 union
4. Select 'Local' ind_type, index_name, nom_partition, status
5 to user_ind_partitions where index-name in (select index_name in user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH')
6 order of 1,2,3;
IND_TYPE INDEX_NAME NOM_PARTITION STATUS
-------- ------------------------------ ------------------------------ --------
Global DATE_IND1_S VALID
Global IND_MSI_LN_LNS1_S VALID
Global L_INDX_MSISDN_S VALID
SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME < = sysdate-2 and LOANDATETIME > sysdate-15 and LOANTYPE = 1;
He explained.
SQL > SQL > set line 200
@?/rdbms/admin/utlxpls.sql
SQL >
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 3659874059
------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1448K | 58 M | 21973 (2) | 00:04:24 | | |
|* 1 | FILTER | | | | | | | |
| 2. PARTITION LIST ALL | | 1448K | 58 M | 21973 (2) | 00:04:24 | 1. 11.
|* 3 | TABLE ACCESS FULL | LOAN_RUNNING_DETAILS_SOUTH | 1448K | 58 M | 21973 (2) | 00:04:24 | 1. 11.
------------------------------------------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - filter(SYSDATE@!-2>SYSDATE@!-15)
3 - filter("LOANTYPE"=1 AND "LOANDATETIME">SYSDATE@!-15 AND "LOANDATETIME"<=SYSDATE@!-2)
16 selected lines.
Second server
SQL > select index_name, column_name, position_colonne from user_ind_columns where table_name = 'LOAN_RUNNING_DETAILS_SOUTH"of order 1.
INDEX_NAME COLUMN_NAME POSITION_COLONNE
------------------------------ -------------------- ---------------
DATE_IND1_S LOANDATETIME 1
IND_MSI_LN_LNS1_S MSISDN 1
IND_MSI_LN_LNS1_S LOANDATETIME 2
IND_MSI_LN_LNS1_S LOANSTATUS 3
LAST_INDEX L_INDX_MSISDN_S 1
MSISDN L_INDX_MSISDN_S 2
SQL > select decode (status, 'N/a', 'Part Hdr', 'Global') ind_type, index_name, NULL nom_partition, status
2 from user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH '.
Union
3 4 Select 'Local' ind_type, index_name, nom_partition, status
5 to user_ind_partitions where index-name in (select index_name in user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH')
6 order of 1,2,3;
IND_TYPE INDEX_NAME NOM_PARTITION STATUS
-------- ------------------------------ ------------------------------ --------
Global DATE_IND1_S VALID
Global IND_MSI_LN_LNS1_S VALID
Global L_INDX_MSISDN_S VALID
SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME < = sysdate-2 and LOANDATETIME > sysdate-15 and LOANTYPE = 1;
SQL > set line 200
@?/rdbms/admin/utlxpls.sql
SQL >
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1161680601
----------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
----------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2. 84. 5 (0) | 00:00:01 | | |
|* 1 | FILTER | | | | | | | |
|* 2 | TABLE ACCESS BY INDEX ROWID | LOAN_RUNNING_DETAILS_SOUTH | 2. 84. 5 (0) | 00:00:01 | ROWID | ROWID |
|* 3 | INDEX RANGE SCAN | DATE_IND1_S | 2. | 3 (0) | 00:00:01 | | |
----------------------------------------------------------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - filter(SYSDATE@!-2>SYSDATE@!-15)
2 - filter ("LOANTYPE" = 1)
3 - access("LOANDATETIME">SYSDATE@!-15 AND "LOANDATETIME"<=SYSDATE@!-2)
17 selected lines.
Reg,
Hard
Hi , HemantKChitale,
I also update statistics manual as you say, but not see 'TABLE ACCESS FULL' good result
What should I do? my need of production tuning, but I cannot able tune this...
SQL > exec dbms_stats.gather_table_stats (-online 'ttt' ownname, tabname => 'LOAN_RUNNING_DETAILS_SOUTH', cascade => TRUE, estimate_percent => NULL, method_opt => 'for all columns size 254', => of degree 4);
PL/SQL procedure successfully completed.
SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME<=sysdate-2 and="" loandatetime="">sysdate-15 and LOANTYPE = 1;
He explained.
SQL > set line 200
@?/rdbms/admin/utlxpls.sql
SQL >
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 3659874059
------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1874K | 75 M | 19626 (2) | 00:03:56 | | |
|* 1 | FILTER | | | | | | | |
| 2. PARTITION LIST ALL | | 1874K | 75 M | 19626 (2) | 00:03:56 | 1. 11.
|* 3 | TABLE ACCESS FULL | LOAN_RUNNING_DETAILS_SOUTH | 1874K | 75 M | 19626 (2) | 00:03:56 | 1. 11.
------------------------------------------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - filter(SYSDATE@!-2>SYSDATE@!-15)
3 - filter("LOANDATETIME">SYSDATE@!-15 AND "LOANTYPE"=1 AND "LOANDATETIME")<>
16 selected lines.
-
Compare the implementation plans for SELECT and DELETE
Hello
Version: 10.2.0.3
I REMOVE slow running in the Production db. I can't import and data, or run the REMOVE to get the Plan. For now, I managed to get the history of the plan.
However I would like to know if it is reasonable to assume the plans to SELECT and DELETE the same?
Rgds,
GuenounGugui wrote:
HelloVersion: 10.2.0.3
I REMOVE slow running in the Production db. I can't import and data, or run the REMOVE to get the Plan. For now, I managed to get the history of the plan.
However I would like to know if it is reasonable to assume the plans to SELECT and DELETE the same?
Rgds,
GuenounDo not understand your question.
Because I can very easy do a:explain plan for
remove from... where...;And then take a look at the plan generated in the PLAN_TABLE.
However, I guess that plans for a DELETE and a SELECT statement must be the same, because they need to finish work on the same data, in any case...
A simple test showed that I'm right.PLAN_ID OPERATION OPTIONS OBJECT_TYPE COST CARDINALITY BYTES ---------- ------------------------------ -------------------- ------------------------------ ---------- ----------- ---------- 3 DELETE STATEMENT 177714 7702839 3 DELETE 3 TABLE ACCESS FULL TABLE 177714 7702839 4 SELECT STATEMENT 179707 7702839 3928447890 4 TABLE ACCESS FULL TABLE 179707 7702839 3928447890 -
Impossible to extract plan for SQL_ID
Hi all
and thanks for the help.
on 11.2.0.3 on Win 2008 Server I run
explain plan for
Select the machine sid, osuser v$ session;
Select * from table (dbms_xplan.display_cursor (null, null, 'ALLSTATS'));
And I get:
NOTE: cannot fetch SQL_ID plan: 382zzpu0dtfwn, CHILD_NUMBER: 2
Check the value of SQL_ID and CHILD_NUMBER;
But if I run
explain plan for
Select the machine sid, osuser v$ session;
-SELECT PLAN_TABLE_OUTPUT IN THE TABLE (DBMS_XPLAN. DISPLAY());
It would be OK and I EXPLAIN the PLAN:
Hash value of plan: 644658511
---------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
---------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 142. 0 (0) | 00:00:01 |
| 1. NESTED LOOPS | | 1. 142. 0 (0) | 00:00:01 |
| 2. NESTED LOOPS | | 1. 129. 0 (0) | 00:00:01 |
|* 3 | TABLE FIXED FULL | X$ KSUSE | 1. 103. 0 (0) | 00:00:01 |
|* 4 | FIXED FIXED INDEX TABLE | X$ KSLWT (ind:1) | 1. 26. 0 (0) | 00:00:01 |
|* 5 | FIXED FIXED INDEX TABLE | X$ KSLED (ind:2) | 1. 13. 0 (0) | 00:00:01 |
---------------------------------------------------------------------------------------------
What is the problem? Thanks for help.
You mix your methods.
SQL id 382zzpu0dtfwn is literally
explain plan for select machine, sid, osuser from v$session ;
When you make a plan to explain it, the api appropriate DBMS_XPLAN DBMS_XPLAN DISPLAY.
When you perform a physical implementation - and not with explain plan - then DBMS_XPLAN. DISPLAY_CURSOR is the api proper.
If you want the actual execution statistics, then you must run really AND you need statistics_level all or the gather_plan_statistics indicator
explain plan for select machine, sid, osuser from v$session where 1=0; plan FOR succeeded. select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ------------------- Plan hash value: 3405918260 ---------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 142 | 0 (0)| | |* 1 | FILTER | | | | | | | 2 | NESTED LOOPS | | 1 | 142 | 0 (0)| 00:00:01 | | 3 | NESTED LOOPS | | 1 | 129 | 0 (0)| 00:00:01 | |* 4 | FIXED TABLE FULL | X$KSUSE | 1 | 103 | 0 (0)| 00:00:01 | |* 5 | FIXED TABLE FIXED INDEX| X$KSLWT (ind:1) | 1 | 26 | 0 (0)| 00:00:01 | |* 6 | FIXED TABLE FIXED INDEX | X$KSLED (ind:2) | 1 | 13 | 0 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(NULL IS NOT NULL) 4 - filter("S"."INST_ID"=USERENV('INSTANCE') AND BITAND("S"."KSSPAFLG",1)<>0 AND BITAND("S"."KSUSEFLG",1)<>0) 5 - filter("S"."INDX"="W"."KSLWTSID") 6 - filter("W"."KSLWTEVT"="E"."INDX") 22 rows selected alter session set statistics_level = all; session SET altered. select machine, sid, osuser from v$session where 1=0; no rows selected select * from table(dbms_xplan.display_cursor(null,null,'allstats last')); PLAN_TABLE_OUTPUT ------------------- SQL_ID 6wq0xktdw9kxz, child number 0 ------------------------------------- select machine, sid, osuser from v$session where 1=0 Plan hash value: 3405918260 ---------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | ---------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 0 |00:00:00.01 | |* 1 | FILTER | | 1 | | 0 |00:00:00.01 | | 2 | NESTED LOOPS | | 0 | 1 | 0 |00:00:00.01 | | 3 | NESTED LOOPS | | 0 | 1 | 0 |00:00:00.01 | |* 4 | FIXED TABLE FULL | X$KSUSE | 0 | 1 | 0 |00:00:00.01 | |* 5 | FIXED TABLE FIXED INDEX| X$KSLWT (ind:1) | 0 | 1 | 0 |00:00:00.01 | |* 6 | FIXED TABLE FIXED INDEX | X$KSLED (ind:2) | 0 | 1 | 0 |00:00:00.01 | ---------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(NULL IS NOT NULL) 4 - filter(("S"."INST_ID"=USERENV('INSTANCE') AND BITAND("S"."KSSPAFLG",1)<>0 AND BITAND("S"."KSUSEFLG",1)<>0)) 5 - filter("S"."INDX"="W"."KSLWTSID") 6 - filter("W"."KSLWTEVT"="E"."INDX") 27 rows selected -
Explain Plan shows not good results.
Hi gurus,
Please help me understand under question.
Whenever I have do explain plan on any sql statements he says as explained but when retriving explain plan output it shows same results again and again.
DB - 11 GR 2 Stand alone
ASM - configured.
OS - RHEL 6.2.
SQL > select count (*) in the t2114;
COUNT (*)
----------
639292
SQL > explain plan for select count (*) from t2114;
He explained.
SQL > @?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1497650422
----------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 6634. 524K | 2993 (19) | 00:00:01 |
| 1. SORT ORDER BY | 6634. 524K | 2993 (19) | 00:00:01 |
| 2. TABLE ACCESS BY INDEX ROWID | T2210 | 6634. 524K | 2947 (17) | 00:00:01 |
|* 3 | INDEX RANGE SCAN | T2210_T | 6842. 108 (22) | 00:00:01 |
----------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
3 - access("T2210".") C490008000 ' =: SYS_B_0 AND "T2210".» C490009100 ' =: SYS_B_2.
(AND "T2210". ' C301363300 '= TO_NUMBER (:SYS_B_1)).
16 selected lines.
SQL > explain the plan for
2. SELECT T2114. C1 FROM T2114 WHERE ((T2114. C1000000001 =: 'SYS_B_0') AND (T2114. C536871442 =: 'SYS_B_1') AND (T2114. C536871477 =: 'SYS_B_2') AND ((: "SYS_B_3" - T2114.)) (C3) > =: 'SYS_B_4') AND ((: "SYS_B_5" - T2114.)) (C3) < =: 'SYS_B_6') AND (T2114. C1000000217 AS: 'SYS_B_7') AND (T2114. C536871478 <: 'SYS_B_8')) ORDER BY C1000000161 DESC,: 'SYS_B_9' ASC;
He explained.
SQL > SELECT * FROM TABLE (dbms_xplan.display);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1497650422
----------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 6634. 524K | 2993 (19) | 00:00:01 |
| 1. SORT ORDER BY | 6634. 524K | 2993 (19) | 00:00:01 |
| 2. TABLE ACCESS BY INDEX ROWID | T2210 | 6634. 524K | 2947 (17) | 00:00:01 |
|* 3 | INDEX RANGE SCAN | T2210_T | 6842. 108 (22) | 00:00:01 |
----------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
3 - access("T2210".") C490008000 ' =: SYS_B_0 AND "T2210".» C490009100 ' =: SYS_B_2.
(AND "T2210". ' C301363300 '= TO_NUMBER (:SYS_B_1)).
16 selected lines.In the future, please do not use * on object.
Use the owner, object_type, object_name
You avoid output unreadable in doing so.In the output that you show, you would need to know where the PUBLIC synonym points, by querying dba_synonyms or all_synonyms.
If she SYS. Plan_table, you can drop ARADMIN. PLAN_TABLE.
If there is no PLAN_TABLE SYS, you have to solve this problem.-----------
Sybrand Bakker
Senior Oracle DBA -
what code is better-how reading explain plan
10g. How to read explain plan
explain planexplain plan for with av as ( SELECT last_name, salary, department_id, round(avg(salary) over (partition by department_id) ) avg_sal FROM employees ) select * from av where salary > avg_sal order by last_name; select * from table(dbms_xplan.display)
Plan hash value: 1582291400 ---------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 107 | 5671 | 5 (40)| 00:00:01 | | 1 | SORT ORDER BY | | 107 | 5671 | 5 (40)| 00:00:01 | |* 2 | VIEW | | 107 | 5671 | 4 (25)| 00:00:01 | | 3 | WINDOW SORT | | 107 | 1605 | 4 (25)| 00:00:01 | | 4 | TABLE ACCESS FULL| EMPLOYEES | 107 | 1605 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("SALARY">"AVG_SAL")explain plan for SELECT a.last_name, a.salary, a.department_id, b.salavg FROM employees a, (SELECT department_id, AVG(salary) salavg FROM employees GROUP BY department_id) b WHERE a.department_id = b.department_id AND a.salary > b.salavg order by last_name select * from table(dbms_xplan.display)Plan hash value: 802276651 ---------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 165 | 5610 | 8 (25)| 00:00:01 | |* 1 | FILTER | | | | | | | 2 | SORT GROUP BY | | 165 | 5610 | 8 (25)| 00:00:01 | |* 3 | HASH JOIN | | 3296 | 109K| 7 (15)| 00:00:01 | | 4 | TABLE ACCESS FULL| EMPLOYEES | 107 | 2889 | 3 (0)| 00:00:01 | | 5 | TABLE ACCESS FULL| EMPLOYEES | 107 | 749 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("A"."SALARY">SUM("SALARY")/COUNT("SALARY")) 3 - access("A"."DEPARTMENT_ID"="DEPARTMENT_ID")Rahul India wrote:
---------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 107 | 5671 | 5 (40)| 00:00:01 | | 1 | SORT ORDER BY | | 107 | 5671 | 5 (40)| 00:00:01 | |* 2 | VIEW | | 107 | 5671 | 4 (25)| 00:00:01 | | 3 | WINDOW SORT | | 107 | 1605 | 4 (25)| 00:00:01 | | 4 | TABLE ACCESS FULL| EMPLOYEES | 107 | 1605 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("SALARY">"AVG_SAL")----------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 165. 5610 | 8 (25) | 00:00:01 |
|* 1 | FILTER |
| 2. GROUP SORT BY | 165. 5610 | 8 (25) | 00:00:01 |
|* 3 | HASH JOIN | 3296. 109K | 7 (15) | 00:00:01 |
| 4. TABLE ACCESS FULL | EMPLOYEES | 107. 2889 | 3 (0) | 00:00:01 |
| 5. TABLE ACCESS FULL | EMPLOYEES | 107. 749. 3 (0) | 00:00:01 |
----------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - filter("A".") SALARY "> SUM ("SALARY") COUNT ("SALARY"))"
3 - access("A".") DEPARTMENT_ID "=" DEPARTMENT_ID")As a general rule, there is no way, you can decide which is the best plan without knowing what data happens in the request, and what will come out.
You will notice, among other things, that Oracle has used a view complex merger to change your query with the aggragate inline view in a simple join with aggregation end (see http://jonathanlewis.wordpress.com/2007/03/08/transformation-and-optimisation/ for invasive how it may be). With a different dataset the optimizer might decide to regroup before joining - just the way you wrote the application.An essential difference between your two plans is (as others have pointed out) that one of them analyse the table twice, the other once - however, the other key difference is that the whole dataset COULD BE relevant to be sorted by the analytical application and resources used in the genre could well take on the resources used by a second analysis and integration of a single column.
The difference is irrelevant in this case - but the difference exists and must be considered in the greatest examples.
You could also write the query to use a subquery to correlated - which the optimizer may rewrite the same plan 'join then aggregate' one of your queries achieved - but once again as an intelligent agent, you can decide that (in some cases), the best plan is the subquery filter implied by the form of the SQL.
Concerning
Jonathan Lewis -
Hello
can someone point me to full details of the Plan, including how to understand the syntax in the statement "3-filter...". "marked in red.
This cross-history. I expect to see <>(not the equal sign) between these columns, but there is nothing:
Actual results is also 14 ranks, but I do not see that the figure anywhere in the plan, only "12" will be one any correlation between the numbers of plan and result?
T1 (col_1 number): 1 2 3 4 T2 (col_1 number): 3 4 5 6 SQL> explain plan for select t1.col_1 from t1, t2 where t1.col_1 != t2.col_1; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------ Plan hash value: 1967407726 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 12 | 312 | 6 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 12 | 312 | 6 (0)| 00:00:01 | | 2 | TABLE ACCESS FULL| T1 | 4 | 52 | 2 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL| T2 | 3 | 39 | 1 (0)| 00:00:01 | --------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter("T1"."COL_1""T2"."COL_1") ---/*XXX Note ----- - dynamic sampling used for this statementthe cost based optimizer uses internal statistics to determine the number of rows that an operation will be back. For the simple query in your example, these estimates would be quite accurate if statistics have been sufficient - but they are not since we see the dynamic sampling note that indicates the missing statistics: http://blogs.oracle.com/optimizer/entry/dynamic_sampling_and_its_impact_on_the_optimizer
-- without statistics --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 12 | 312 | 13 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 12 | 312 | 13 (0)| 00:00:01 | | 2 | TABLE ACCESS FULL| T1 | 4 | 52 | 4 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL| T2 | 3 | 39 | 2 (0)| 00:00:01 | --------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter("T1"."ID"<>"T2"."ID") Note ----- - dynamic sampling used for this statement (level=2) -- gather statistics exec dbms_stats.gather_table_stats(user, 'T1') exec dbms_stats.gather_table_stats(user, 'T2') -- with statistics (we see the 4 * 4 = 16 rows we expect) --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 16 | 96 | 13 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 16 | 96 | 13 (0)| 00:00:01 | | 2 | TABLE ACCESS FULL| T1 | 4 | 12 | 4 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL| T2 | 4 | 12 | 2 (0)| 00:00:01 | --------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter("T1"."ID"<>"T2"."ID")The filter says that operation 3 complete analysis results are filtered by the given condition. If we had clues you might see an access descriptor.
Concerning
Martin Preiss
-
I ran some queries and their plan to explain in the sql developer. I not issue an insert or update all statement. No change to the database, but when I tried to unplug it wonder there are a few changes and ask me if I want to commit or rollback etc.
Why so much? I'm afraid to choose an any of them because I don't know who has change his talk.
It has happened several times and feel that it has something to with market explain plan in SQL developer.
Everyone comments on it? I'd appreciate that.
TX,I guess that changes made to the plan table (where your explain plan command goes).
TUBBY_TUBBZ?select PLAN_ID from plan_table; no rows selected Elapsed: 00:00:00.01 TUBBY_TUBBZ?explain plan for select PLAN_ID from plan_table; Explained. Elapsed: 00:00:00.00 TUBBY_TUBBZ?select PLAN_ID from plan_table; PLAN_ID ------------------ 33 33 2 rows selected. Elapsed: 00:00:00.01 TUBBY_TUBBZ?Which, if you trace through the synonym you will find that it is a global temporary table owned by SYS.
GLOBAL TEMPORARY TABLE "SYS"."PLAN_TABLE$"So you can save your changes or not, it won't matter because the data will disappear when your session disconnects.
-
3 clues on 3 different columns, but explain plan shows full table scan for select queries
I have a table - used and have index - functional ind1 (upper (f_name)), index - (emp_id) ind2 ind3 (upper (l_name) functional on 3 columns diffferent - what, emp_id, l_name respectively.) Now when I check explain plans for sub queries, they all have two shows complete table for the employee of the table scan. FYI - employee table is non-parittioned.
Can someone tell me why 3 indices are not used here?
(1) select emp_id, upper (f_name), upper (l_name) of the employee
(2) select upper (f_name), mp_id, upper (l_name) of the employee
where upper (f_name) = upper (f_name)
and emp_id = emp_id
and upper (l_name) = upper (l_name)
If I can push oracle (version 11) to use these indexes somewho - maybe using tips? Any help is appreciated.
Observations: SQL> desc emp1; Name Null? Type ----------------------------------------- -------- ----------------- EMPID NOT NULL NUMBER F_NAME NOT NULL VARCHAR2(3) L_NAME NOT NULL VARCHAR2(3) SALARY NUMBER JOB_ROLE VARCHAR2(5) DEPTID NUMBER create index idx2 on emp1(empid); create index idx1 on emp1(upper(f_name) ); create index idx3 on emp1(f_name,empid, l_name); exec dbms_stats.gather_table_stats(user,'EMP1', cascade=>true); 8 rows selected. SQL> explain plan for 2 select /*+ index_join(e idx1 idx2 idx3)*/ upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ------------------------------------------------------------------------- 8 rows selected. SQL> explain plan for 2 select upper(f_name),empid,upper(l_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ------------------------------------------------------------------------- 8 rows selected. SQL> explain plan for 2 select /*+ index_ffs(e idx3)*/ upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 2496145112 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FAST FULL SCAN| IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ----------------------------------------------------------------------------- 8 rows selected. SQL> explain plan for 2 select /*+ index(e idx3)*/ upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ------------------------------------------------------------------------- 8 rows selected. SQL> explain plan for 2 select upper(f_name),empid,upper(l_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 | ------------------------------------------------------------------------- 8 rows selected. SQL> drop index idx3; Index dropped. SQL> explain plan for 2 select upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3330885630 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 18 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| EMP1 | 20000 | 175K| 18 (0)| 00:00:01 | -------------------------------------------------------------------------- 8 rows selected. SQL> create index idx3 on emp1(f_name,empid, l_name ); Index created. SQL> explain plan for 2 select upper(l_name),empid, upper(f_name) from emp1 e; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3449967945 ------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20000 | 175K| 14 (0)| 00:00:01 | | 1 | INDEX FULL SCAN | IDX3 | 20000 | 175K| 14 (0)| 00:00:01 |
-
Difference of cardinality estimate on explain plan and implementation plan
I think some of you know the 5% rule, which is explained in the note on metalink # 68992.1.
In short, this means that (with bind peeking out voltage)
It is also well explained fundamentals of the CBO by Jonathan Lewis.- c1 > :b1 : 5% of selectivity - c1 >= :b1 :5% of selectivity - c1 between :b1 and :b2 : 0.25% of selectivity (5% * 5%)
But I found a few odd cases where the 5% rule is broken DURATION estimate.
The most interesting part is explain plan watch again the 5% rule.
Why the difference?
I think that with bind peeking out, explain the plan and the implementation plan should show the same things.
(Assuming that all values of the environment are identical)
Am I wrong?
It's the long story to tell, but simple test cases will show what I mean.
* Disable bind peeking. *UKJA@ukja102> @version BANNER --------------------------------------------------------------------- --------------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod PL/SQL Release 10.2.0.1.0 - Production CORE 10.2.0.1.0 Production TNS for 32-bit Windows: Version 10.2.0.1.0 - Production NLSRTL Version 10.2.0.1.0 - Production UKJA@ukja102> UKJA@ukja102> set echo on UKJA@ukja102> UKJA@ukja102> drop table t1 purge; Table dropped. Elapsed: 00:00:00.09 UKJA@ukja102> UKJA@ukja102> create table t1(c1 int, c2 int) 2 ; Table created. Elapsed: 00:00:00.01 UKJA@ukja102> UKJA@ukja102> insert into t1 2 select 1, level 3 from dual 4 connect by level <= 10000 5 union all 6 select 2, level 7 from dual 8 connect by level <= 1000 9 union all 10 select 3, level 11 from dual 12 connect by level <= 100 13 union all 14 select 4, level 15 from dual 16 connect by level <= 10 17 union all 18 select 5, level 19 from dual 20 connect by level <= 1 21 ; 11111 rows created. Elapsed: 00:00:00.32 UKJA@ukja102> UKJA@ukja102> exec dbms_stats.gather_table_stats(user, 't1', method_opt=>'for all columns size 1'); PL/SQL procedure successfully completed.
In the following result, explain the plan following the 5% rule.UKJA@ukja102> UKJA@ukja102> alter session set "_optim_peek_user_binds" = false;
(11111 * 0.05 = 555)
But the term plan does'nt follow the 5% rule. It uses its own densityUKJA@ukja102> UKJA@ukja102> explain plan for 2 select count(*) 3 from t1 4 where c1 > :b1 5 ; Explained. Elapsed: 00:00:00.01 UKJA@ukja102> UKJA@ukja102> @plan UKJA@ukja102> select * from table(dbms_xplan.display) 2 / PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 3724264953 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 3 | 6 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 3 | | | |* 2 | TABLE ACCESS FULL| T1 | 556 | 1668 | 6 (0)| 00:00:01 | --------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("C1">TO_NUMBER(:B1)) 14 rows selected. Elapsed: 00:00:00.01
(11111 * density (c1) = 11111 * 0.2 = 2222)
the 5% rule seems to beUKJA@ukja102> select /*+ gather_plan_statistics */ 2 count(*) 3 from t1 4 where c1 > :b1 5 ; COUNT(*) ---------- 1111 Elapsed: 00:00:00.00 UKJA@ukja102> UKJA@ukja102> @stat UKJA@ukja102> select * from table 2 (dbms_xplan.display_cursor(null,null,'allstats cost last')); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- SQL_ID 0nmqsysmr3ap9, child number 0 ------------------------------------- select /*+ gather_plan_statistics */ count(*) from t1 where c1 > :b1 Plan hash value: 3724264953 -------------------------------------------------------------------------------- ------------------ | Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A- Time | Buffers | -------------------------------------------------------------------------------- ------------------ | 1 | SORT AGGREGATE | | 1 | 1 | | 1 |00:00 :00.01 | 23 | |* 2 | TABLE ACCESS FULL| T1 | 1 | 2223 | 6 (0)| 1111 |00:00 :00.01 | 23 | -------------------------------------------------------------------------------- ------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("C1">:B1) 18 rows selected.
-applied to explain the plan always
-applied at the level of enforcement only when density 5 < %. When the density > 5%, he uses the density not 5%
I'm not sure it's a designed feature or a bug.
But estimates of different cardinality explain a plan and DURATION (with bind peeking out voltage) is not that desirable thing.
One's opinion on this?
Dion ChoSorry to take some time to get back on this one.
I can reproduce your results in 10.2.0.1, but the anomaly is not present in 9.2.0.8 and 10.2.0.3 and 11.1.0.6.
As Charles, the calculation has a boundary condition when a num_diistinct falls below 20
(i.e. when a value is more than 5% of the total data set - average).However, the fact that explain the plan and the run time you give estimates of different cardinality is a bug.
Everything they say, they should say the same thing at least that the introduction of the variable binding
introduced a possible type conversion or the NLS conversion feature that has changed the
calculation of the expected cardinality. In this case there is no reason why the use of links should be
cause confusion - so we can reasonably assume that it is a bug.Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
http://www.jlcomp.demon.co.UK"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." (Stephen Hawking)
-
decide to move to optimization soon. Book says join faster that the subquery in this example because the analyses involved. The "cost" to the subquery appears lower than the cost for the join. So it is confusing to me - aka How should I be interpreting this.
Plan of subquery:
join plan
as you can see that the plan for the subquery has less than a cost. Could someone explain these outputs as to which application is more effective. I need to start somewhere.
Thank you!
The BEST way to get help when you ask questions is:
1 ask questions on SPECIFIC things
2. tell us EXACTLY what term, value, etc. ask abaout
Book says join faster that the subquery in this example because the analyses involved. The "cost" to the subquery appears lower than the cost for the join. So it is confusing to me - aka How should I be interpreting this.
OK - what BOOK are you talking about? There is not much interest to mention a book if you're not going to tell us which book it and provide a link to it and even a page number. This gives us the SCOPE of your question.
This "cost for the subquery" are you talking about? Be specifc. It is in one of the plans that you posted? What plan? Whose cost is it? For example, you could say:
I have a question for the foreground below. Why is the cost to the xx line lower than the cost of the second plan on line AA?
This question refers CLEARLY to the info we're talking. The way in which you stating the question, we try to guess what plan and the lines you want to say.
subquery plan:
join plan
as you can see the subquery plan has less of a cost. Could someone explain from these outputs as to which query is more efficient. I need to start from somewhere.
Are you talking about line #1 in each of these plans?
Please edit your post and tell us EXACTLY what you ask in the topic and refer to values and SPECIFIC lines. Also post a link to the book and a reference to a page number you got the information from.
The optimizer generally chooses the REAL implementation with the lowest cost plan. It is not clear whether the plans that you have posted are ACTUAL spending plans that Oracle really determined and used or just explain plans.for what Oracle thought it might use.
If the statistics are not up-to-date these plans do not yet reflect the reality of the data.
And if the amount of data is a small number of blocks or other of these plans can run better than the other in reality.
You can find this Oracle white paper "Explain the Plan explaining" useful
-
How to capture the execution plan for a query
Hi all
Can someone help me please to find the command to capture the execution plan for a query.
Execution plan for select * from EMP where < condition >
Is getting executed successfully, but I need to get the appropriate for the same execution plan.
Thank youRead the Doc
-
I have a subscription, it's almost over, but I need to change plans and cannot select one I need in the menu plan for change, and I can't cancel. Is it possible to cancel it?
Hello
Please contact support by calling/chat for cancellation requests and billing queries:
* Be sure to stay connected with your Adobe ID before accessing the link above *.
You can also check the help below document:
https://helpx.Adobe.com/x-productkb/policy-pricing/cancel-membership-subscription.html
Please go through the Adobe - General conditions of subscription as well.
-
Question 1: The button "Buy now" does not work when you select a plan.
How to reproduce the problem:
1. go in terms of pricing and membership creative cloud | Adobe Creative Cloud
2. choose a plan, then click on 'buy now '.
3. you go to a blank page instead of the next steps in the payment.
Question 2: Can not select "Monthly Plan" for a "unique App."
How to reproduce the problem:
1. go into "https://creative.adobe.com/plans".
2. under "Unique App", select a product and then try to select the "monthly Plan" in the second menu drop-down.
3. for some reason, it isn't get selected and the price is replaced with the ellipsis (...). I expect the monthly price to appear.
Please notify.
Thank you.
Contact adobe during the time pst support by clicking here and, when available, click on "still need help," http://helpx.adobe.com/x-productkb/global/service-ccm.html
-
Need help with understanding explain plan
Hi all
I'm trying to understand the subject of the explain Plan, and while I was reading a document and from there I found one of the query that is below:
Query
SELECT A.customer_name,
Count (distinct b.invoice_id) 'open invoices. "
Count (c.invoice_id) "open invoice".
Clients has,
b invoices,
c invoices_items
WHERE b.invoice_status = 'OPEN'
AND A.customer_id = b.customer_id
AND c.invoice_id (+) = b.invoice_id
A.customer_name GROUP
Explain Plan
See attached file...
I appreciate if someone explain this attached plan really explain in detail for my purpose of learning. Thanks in advance
Concerning
Muzz
I'm trying to understand the subject of the explain Plan
Excellent!
I suggest you just started reading the book of Maria Colgan white "Explain the explain Plan".
This white paper examines the different lines, you will see in a plan and what they mean.
Maybe you are looking for
-
Thread freeze trying to navigate the menu
I'm currently developing a monitoring software for an industrial machine. On the main thread, I treat all the events of the user interface, and in an AsyncTimer, I am purchasing data (via CPB). I protect my data using CmtNewLock, CmtGetLock and CmtRe
-
Get updates for Vista on a stand-alone computer
My brother has a computer at home that is not connected to the internet. Its operating system is VISTA Home Basic 32-bit. The computer came with it and had no updates loaded to it. Is there a way for me to download or to get all updates and servic
-
What is the cod of error 0 x 80240036? How to fix?
After the system recovery try update error cod happen has windows.
-
Aspire E15 (E5-551-T2HE) is not correctly identified Chipset drivers
Neither recognition driver AMD or the centre Acer seem to be able to identify the Chipset driver for this model - I found that the Spain Media Markt is the model for the Chipset: AMD A76M CHT, cannot confirm with Spanish customer support. Someone kno
-
Windows Movie Maker - have 6 minutes of audio spliced, I would like to publish in the form of an audio clip with no video. I heard that this is possible, and it all works, the 'framework' includes 6 more minutes of space without air circulation that