Oracle Explain Plan

Hi,
I am looking for a good tutorial which explain on how to use explain plain with some examples.
If you know some online page then let me know.
--Harvey.

http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
http://www.orafaq.com/node/1420
Edited by: Ora on May 9, 2011 11:33 PM

Similar Messages

SQL Explain Plan tutorial links

Hello experts
I don't know anything about sql explain plan. I would like to learn it. I read several Oracle documents However I don't understand clearly. Do you know any article or powerpoint related to sql explain plan basics for beginners?
Thanks a lot for your help.

944258 wrote:
Hello experts
I don't know anything about sql explain plan. I would like to learn it. I read several Oracle documents However I don't understand clearly. Do you know any article or powerpoint related to sql explain plan basics for beginners?
Thanks a lot for your help.http://www.lmgtfy.com/?q=oracle+explain+plan+tutorial

Query tunning in Oracle using Explain Plan

Adding to my below question: I have now modified the query and the path shownby 'Explain plan' has reduced. The 'Time' column of plan_table is also showing much lesser value. However, some people are suggesting me to consider the time required by the query to execute on Toad. Will it be practical? Please help!!
Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...
Edited by: 885901 on Sep 20, 2011 2:10 AM

885901 wrote:
Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...how fast is fast enough?

What are the privileges required for explain plan in Oracle 11g database

I am facing the problem in doing a explain plan for a view in Oracle 11g database. When I select from the view like this:
select * from zonewisearpu
It does a select on the view but when I give explain plan like
explain plan for
select * from zonewisearpu
I get the error like insufficient privileges.
Please let me know if things are getting missed out as I guess system level privileges are required to execute this.
I hope, my question is clear.
It’s a humble request to revert urgently if possible as I need to complete a task and do not know the way out.
Regards

975148 wrote:
Thanks for your reply. I have found out that an explain plan is possible on the user's own objects and is not possible on the granted objects from a different schema. For eg, if I do a explain plan on a view querying on tables from a different view, it would not allow the explain plan to proceed. This could mean that explain plan needs different privileges than just a select.
Requesting for a revert to this.
Here is a simple test case that I have perfomed
SQL> create user test1 identified by test1;
User created.
SQL> create user test2 identified by test1;
User created.
SQL> grant connect, resource to test1,test2;
Grant succeeded.
SQL> create table test1.tab1 as select * from v$session;
Table created.
SQL> connect test2/test1
Conencted.
SQL> show user
USER is "TEST2"
SQL>
SQL> explain plan for
2 select sid,serial#,status,username from test1.tab1 where username<> '';
Explained.
SQL>
So, as can be seen I am able to do a explain plan from user test2 for tables belong to user test1.
As far as privileges are concerned, following is the list
SQL> select * from dba_role_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE                        GRANTED_ROLE                   ADM DEF
TEST1                          CONNECT                        NO YES
TEST1                          RESOURCE                       NO YES
TEST2                          CONNECT                        NO YES
TEST2                          RESOURCE                       NO YES
SQL>
SQL> select grantee,owner,table_name,privilege from dba_tab_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE    OWNER      TABLE_NAME           PRIVILEGE
TEST2      TEST1      TAB1                 SELECT
SQL>
SQL> select * from dba_sys_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE    PRIVILEGE                      ADM
TEST1      UNLIMITED TABLESPACE           NO
TEST2      UNLIMITED TABLESPACE           NO
SQL>

Oracle not using its own explain plan

When I run a simple select query on an indexed column on a large (30 million records) table oracle creates a plan using the indexed column and at a cost of 4. However, what it actually does is do a table scan (I can see this in the 'Long Operations' tab in OEM).
The funny thing is that I have the same query in a ADO application and when the query is run from there, the same plan is created but no table scan is done - and the query returns in less than a second. However, with the table scan it is over a minute.
When run through SQL plus Oracle creates a plan including the table scan at a cost of 19030.
In another (dot net) application I used the: "Alter session set optimizer_index_caching=100" and "Alter session set optimizer_index_cost_adj=10" to try to force the optimizer to use the index. It creates the expected plan, but still does the table scan.
The query is in the form of:
"Select * from tab where indexedcol = something"
Im using Oracle 9i 9.2.0.1.0
Any ideas as I'm completely at a loss?

Hello
It sounds to me like this has something to do with bind variable peeking which was introduced in 9i. If the predicate is
indexedcolumn = :bind_variablethe first time the query is parsed by oracle, it will "peek" at the value in the bind variable and see what it is and will generate an execution plan based on this. That same plan will be used for matching SQL.
If you use a litteral, it will generate the plan based on that, and will generate a separate plan for each litteral you use (depending on the value of the cursor_sharing initialisation parameter).
This can cause there to be a difference between the execution plan seen when issuing EXPLAIN PLAN FOR, and the actual exectuion plan used when the query is run.
Have a look at the following example:
tylerd@DEV2> CREATE TABLE dt_test_bvpeek(id number, col1 number)
2 /
Table created.
Elapsed: 00:00:00.14
tylerd@DEV2> INSERT
2 INTO
3      dt_test_bvpeek
4 SELECT
5      rownum,
6      CASE
7          WHEN MOD(rownum, 5) IN (0,1,2,3) THEN
8              1
9          ELSE
10              MOD(rownum, 5)
11          END
12      END
13 FROM
14      dual
15 CONNECT BY
16      LEVEL <= 100000
17 /
100000 rows created.
Elapsed: 00:00:00.81
tylerd@DEV2> select count(*), col1 from dt_test_bvpeek group by col1
2 /
COUNT(*)       COL1
     80000          1
     20000          4
2 rows selected.
Elapsed: 00:00:00.09
tylerd@DEV2> CREATE INDEX dt_test_bvpeek_i1 ON dt_test_bvpeek(col1)
2 /
Index created.
Elapsed: 00:00:00.40
tylerd@DEV2> EXEC dbms_stats.gather_table_stats( ownname=>USER,-
tabname=>'DT_TEST_BVPEEK',-
method_opt=>'FOR ALL INDEXED COLUMNS SIZE 254',-
cascade=>TRUE -
);PL/SQL procedure successfully completed.
Elapsed: 00:00:00.73
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3      *
4 FROM
5      dt_test_bvpeek
6 WHERE
7      col1 = 1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |                | 78728 |   538K|    82 (52)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 78728 |   538K|    82 (52)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=1)
13 rows selected.
Elapsed: 00:00:00.06The execution plan for col1=1 was chosen because oracle was able to see that based on the statistics, col1=1 would result in most of the rows from the table being returned.
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3      *
4 FROM
5      dt_test_bvpeek
6 WHERE
7      col1 = 4
8 /
Explained.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 3223879139
| Id | Operation                   | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |                   | 21027 |   143K|    74 (21)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| DT_TEST_BVPEEK    | 21027 |   143K|    74 (21)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | DT_TEST_BVPEEK_I1 | 21077 |       |    29 (28)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("COL1"=4)
14 rows selected.
Elapsed: 00:00:00.04This time, the optimiser was able to see that col1=4 would result in far fewer rows so it chose to use an index. Look what happens however when we use a bind variable with EXPLAIN PLAN FOR - especially the number of rows the optimiser estimates to be returned from the table
tylerd@DEV2> var an_col1 NUMBER
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3      *
4 FROM
5      dt_test_bvpeek
6 WHERE
7      col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |                | 49882 |   340K|   100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 |   340K|   100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.04
tylerd@DEV2>
tylerd@DEV2> exec :an_col1:=4;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3      *
4 FROM
5      dt_test_bvpeek
6 WHERE
7      col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |                | 49882 |   340K|   100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 |   340K|   100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.07For both values of the bind variable, the optimiser has no idea what the value will be so it has to make a calculation based on a formula which results in it estimating that the query will return roughly half of the rows in the table, and so it chooses a full scan.
Now when we actually run the query, the optimiser can take advantage of bind variable peeking and have a look at the value the first time round and base the execution plan on that:
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      *
3 FROM
4      dt_test_bvpeek
5 WHERE
6      col1 = :an_col1
7 /
80000 rows selected.
Elapsed: 00:00:10.98
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      operation,
3      options,
4      object_name
5 FROM
6      v$sql_plan
7 WHERE
8      sql_id = '9t52uyyq67211'
9 /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   FULL                           DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.03It saw that the bind variable value was 1 and that this would return most of the rows in the table so it chose a full scan.
tylerd@DEV2> exec :an_col1:=4
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      *
3 FROM
4      dt_test_bvpeek
5 WHERE
6      col1 = :an_col1
7 /
20000 rows selected.
Elapsed: 00:00:03.50
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      operation,
3      options,
4      object_name
5 FROM
6      v$sql_plan
7 WHERE
8      sql_id = '9t52uyyq67211'
9 /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   FULL                           DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.01Even though the value of the bind variable changed, the optimiser saw that it already had a cached version of the sql statement along with an execution plan, so it used that rather than regenerating the plan. We can check the reverse of this by causing the statement to be invalidated and re-parsed - there's lots of ways, but I'm just going to rename the table:
Elapsed: 00:00:00.03
tylerd@DEV2> alter table dt_test_bvpeek rename to dt_test_bvpeek1
2 /
Table altered.
Elapsed: 00:00:00.01
tylerd@DEV2>
20000 rows selected.
Elapsed: 00:00:04.81
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      operation,
3      options,
4      object_name
5 FROM
6      v$sql_plan
7 WHERE
8      sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   BY INDEX ROWID                 DT_TEST_BVPEEK1
INDEX                          RANGE SCAN                     DT_TEST_BVPEEK_I1
3 rows selected.
80000 rows selected.
Elapsed: 00:00:10.61
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT
2      operation,
3      options,
4      object_name
5 FROM
6      v$sql_plan
7 WHERE
8      sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   BY INDEX ROWID                 DT_TEST_BVPEEK1
INDEX                          RANGE SCAN                     DT_TEST_BVPEEK_I1
3 rows selected.This time round, the optimiser peeked at the bind variable the first time the statement was exectued and found it to be 4, so it based the execution plan on that and chose an index range scan. When the statement was executed again, it used the plan it had already executed.
HTH
David

"Explain Plan" in Oracle SQL Developer is greyed out

Hi all,
I know this is not the right place to post this, but I have look around and do not know where to post question about Oracle SQL Developer - I presume this tool is also discussed here in this forum.
My question is very simple (I presume):
1. I installed Oracle SQL Developer 3.0.04.
2. I added a new DB connection to a DB hosted in one of my servers in the LAN.
3. However, when I am writing some SQL queries, I intend to use the "Explain Plan" feature, but it is being greyed out (disabled).
4. How can I enable it back?

Hello,
{forum:id=260}
Regards
Marcus

Oracle rownum wrong explain plan

SCOTT@oracle10g>create table t as select * from dba_objects;
Table created.
SCOTT@oracle10g>alter table t modify CREATED date not null;
Table altered.
SCOTT@oracle10g>insert into t select * from t;
50416 rows created.
SCOTT@oracle10g>insert into t select * from t;
100832 rows created.
SCOTT@oracle10g>insert into t select * from t;
201664 rows created.
SCOTT@oracle10g>commit;
Commit complete.
SCOTT@oracle10g>create index t_created on t(created) nologging;
Index created.
SCOTT@oracle10g>select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for 32-bit Windows: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
SCOTT@oracle10g>set autot trace
SCOTT@oracle10g>select t.owner,t.object_name   from
2 (select rid from (
3 select rownum rn,rid from
4 (select rowid rid from t order by created)
5 where rownum<100035)
6 where rn>100000) h, t
7 where t.rowid=h.rid;
34 rows selected.
Execution Plan
Plan hash value: 3449471415
| Id | Operation           | Name      | Rows | Bytes |TempSpc| Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT    |           |   100K|    11M|       | 4776   (2)| 0
0:00:58 |
|* 1 | HASH JOIN          |           |   100K|    11M| 3616K| 4776   (2)| 0
0:00:58 |
|* 2 |   VIEW              |           |   100K| 2442K|       | 1116   (2)| 0
0:00:14 |
|* 3 |    COUNT STOPKEY    |           |       |       |       |            |
        |
|   4 |     VIEW            |           |   440K| 5157K|       | 1116   (2)| 0
0:00:14 |
|   5 |      INDEX FULL SCAN| T_CREATED |   440K| 9024K|       | 1116   (2)| 0
0:00:14 |
|   6 |   TABLE ACCESS FULL | T         |   440K|    39M|       | 1237   (2)| 0
0:00:15 |
Predicate Information (identified by operation id):
   1 - access("T".ROWID="RID")
   2 - filter("RN">100000)
   3 - filter(ROWNUM<100035)
Note
   - dynamic sampling used for this statement
Statistics
          0 recursive calls
          0 db block gets
       5814 consistent gets
          0 physical reads
          0 redo size
       1588 bytes sent via SQL*Net to client
        422 bytes received via SQL*Net from client
          4 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
         34 rows processed
here ,oracle don't choose the best explain plan ,I think becase oracle compute cadinality 100k ,so it don't choose nest loop,why oracle can't compute cardinality 35 here ??
|* 2 |   VIEW              |           |   100K| 2442K|       | 1116   (2)| 0
SCOTT@oracle10g>select t.owner,t.object_name   from t where rowid in
2      (select rid from (
3      select rownum rn,rid from
4      (select rowid rid from t order by created)
5      where rownum<100035)
6      where rn>100000)
7
SCOTT@oracle10g>/
34 rows selected.
Execution Plan
Plan hash value: 1566335206
| Id | Operation                   | Name      | Rows | Bytes | Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT            |           |     1 |   107 | 1586   (2)| 0
0:00:20 |
|   1 | NESTED LOOPS               |           |     1 |   107 | 1586   (2)| 0
0:00:20 |
|   2 |   VIEW                      | VW_NSO_1 |   100K| 1172K| 1116   (2)| 0
0:00:14 |
|   3 |    HASH UNIQUE              |           |     1 | 2442K|            |
        |
|* 4 |     VIEW                    |           |   100K| 2442K| 1116   (2)| 0
0:00:14 |
|* 5 |      COUNT STOPKEY          |           |       |       |            |
        |
|   6 |       VIEW                  |           |   440K| 5157K| 1116   (2)| 0
0:00:14 |
|   7 |        INDEX FULL SCAN      | T_CREATED |   440K| 9024K| 1116   (2)| 0
0:00:14 |
|   8 |   TABLE ACCESS BY USER ROWID| T         |     1 |    95 |     1   (0)| 0
0:00:01 |
Predicate Information (identified by operation id):
   4 - filter("RN">100000)
   5 - filter(ROWNUM<100035)
Note
   - dynamic sampling used for this statement
Statistics
          0 recursive calls
          0 db block gets
        301 consistent gets
          0 physical reads
          0 redo size
       1896 bytes sent via SQL*Net to client
        422 bytes received via SQL*Net from client
          4 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
         34 rows processed
SCOTT@oracle10g>select /*+ordered use_nl(t)*/ t.owner,t.object_name   from
2 (select rid from (
3 select rownum rn,rid from
4 (select rowid rid from t order by created)
5 where rownum<100035)
6 where rn>100000) h, t
7 where t.rowid=h.rid;
34 rows selected.
Execution Plan
Plan hash value: 3976541160
| Id | Operation                   | Name      | Rows | Bytes | Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT            |           |   100K|    11M|   101K (1)| 0
0:20:16 |
|   1 | NESTED LOOPS               |           |   100K|    11M|   101K (1)| 0
0:20:16 |
|* 2 |   VIEW                      |           |   100K| 2442K| 1116   (2)| 0
0:00:14 |
|* 3 |    COUNT STOPKEY            |           |       |       |            |
        |
|   4 |     VIEW                    |           |   440K| 5157K| 1116   (2)| 0
0:00:14 |
|   5 |      INDEX FULL SCAN        | T_CREATED |   440K| 9024K| 1116   (2)| 0
0:00:14 |
|   6 |   TABLE ACCESS BY USER ROWID| T         |     1 |    95 |     1   (0)| 0
0:00:01 |
Predicate Information (identified by operation id):
   2 - filter("RN">100000)
   3 - filter(ROWNUM<100035)
Note
   - dynamic sampling used for this statement
Statistics
          0 recursive calls
          0 db block gets
        304 consistent gets
          0 physical reads
          0 redo size
       1588 bytes sent via SQL*Net to client
        422 bytes received via SQL*Net from client
          4 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
         34 rows processed

jinyu wrote:
Thanks for your great reply and posting ,could you tell me why subquery has the least cost here ??
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 107 | 1586 (2)| 00:00:20 |
| 1 | NESTED LOOPS | | 1 | 107 | 1586 (2)| 00:00:20 |
| 2 | VIEW | VW_NSO_1 | 100K| 1172K| 1116 (2)| 00:00:14 |
| 3 | HASH UNIQUE | | 1 | 2442K| | |
|* 4 | VIEW | | 100K| 2442K| 1116 (2)| 00:00:14 |
|* 5 | COUNT STOPKEY | | | | | |
| 6 | VIEW | | 440K| 5157K| 1116 (2)| 00:00:14 |
| 7 | INDEX FULL SCAN | T_CREATED | 440K| 9024K| 1116 (2)| 00:00:14 |
| 8 | TABLE ACCESS BY USER ROWID| T | 1 | 95 | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------------------->
You'll notice that as a result of a "driving" IN subquery Oracle has done a hash unique operation (line 3) on the rowids produced by the subquery. At this point the optimizer has lost all knowledge of the number of distinct values for that data column in the subquery and come back with the cardinality of one. The re-appearance of 100K as the cardinality in line 2 is an error, but I don't think the optimizer has used that value in later arithmetic.
Given the cardinality of one, the obvious path into the T table is a nested loop.
The same type of probelm appears when you use the table() operator in joins - you can use the cardinality() hint to try an tell Oracle how many rows the table() will produce, but that doesn't tell it how many distinct values there are in join columns - and that's an important detail when you work out the join cardinality and method).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

Explain plan cost it increases after migrating Oracle 9.2.0 to 10.2.0.3

Hi:
Recently the migration was made, we are testing (I'm developer) the performance in some querys, but the majority is but slow,I do not understand the reason because the new equipment has processing capacity much more.
for example , a report , in 9i it is executed in 45 segs, in 10G it is executed in 10 minutes!!!
Another example: the next explain plan, it's the same query and the same parameters . In oracle 9i COST=799 In Oracle 10G COST=2337
What happens? Any idea?
In oracle 9i COST=799
SELECT STATEMENT Hint=HINT: FIRST_ROWS 1 799
SORT GROUP BY 1 74 799
VIEW 1 74 786
SORT GROUP BY 1 100 786
TABLE ACCESS BY INDEX ROWID SMRPCMT 1 27 1
NESTED LOOPS 1 100 774
NESTED LOOPS 3 219 773
NESTED LOOPS 3 177 772
NESTED LOOPS 3 171 771
NESTED LOOPS 3 123 770
TABLE ACCESS BY INDEX ROWID SFBETRM 7 K 73 K 22
INDEX RANGE SCAN SFBETRM_KEY_INDEX2 7 K 24
TABLE ACCESS BY INDEX ROWID SGBSTDN 1 31 1
INDEX UNIQUE SCAN PK_SGBSTDN 1
TABLE ACCESS BY INDEX ROWID STVMAJR 1 16 1
INDEX UNIQUE SCAN PK_STVMAJR 1
TABLE ACCESS BY INDEX ROWID STVCAMP 1 2 1
INDEX UNIQUE SCAN PK_STVCAMP 1
INDEX RANGE SCAN SMRPATR_KEY_INDEX 1 14 1
INDEX RANGE SCAN SMRPCMT_KEY_INDEX 1 1
In Oracle 10G COST=2337
SELECT STATEMENT Hint=FIRST_ROWS 1 2337
SORT GROUP BY 1 66 2337
VIEW 1 66 2336
SORT GROUP BY 1 158 2336
NESTED LOOPS 1 158 2335
NESTED LOOPS 1 142 2334
NESTED LOOPS 1 140 2333
NESTED LOOPS 1 126 2332
NESTED LOOPS 3 297 2330
TABLE ACCESS BY INDEX ROWID SFBETRM 7 K 73 K 67
INDEX RANGE SCAN SFBETRM_KEY_INDEX2 7 K 6
TABLE ACCESS BY INDEX ROWID SGBSTDN 1 89 1
INDEX UNIQUE SCAN PK_SGBSTDN 1 1
TABLE ACCESS BY INDEX ROWID SMRPCMT 1 27 1
INDEX RANGE SCAN SMRPCMT_KEY_INDEX 1 1
INDEX RANGE SCAN SMRPATR_KEY_INDEX 1 14 1
TABLE ACCESS BY INDEX ROWID STVCAMP 1 2 1
INDEX UNIQUE SCAN PK_STVCAMP 1 1
TABLE ACCESS BY INDEX ROWID STVMAJR 1 16 1
INDEX UNIQUE SCAN PK_STVMAJR 1 1
Thank you so much by advance.
(sorry by my bad english)

"Cost", as determined by the CBO, is a relative number, not an absolute number. A "cost" of 799 in 9i is not the same as a "cost" of 799 in 10g.
The CBO is 10g is substantially different as compared to 9i. Performance issues encountered after the upgrade are not uncommon. Pl refer to these MOS Doc to help troubleshoot your issue -
754931.1 - Cost Based Optimizer - Common Misconceptions and Issues - 10g and Above
466181.1 - 10g Upgrade Companion
I would also recommend you upgrade to 10.2.0.4, as it is the latest and most stable version of 10g.
HTH
Srini

Explain plan for timesten and Oracle

we have a base table in our Oracle 10g database. We created a DSN for this in timesten 7.0 database and are able to connect. Now we have created 3 materialized views in timesten on top of the Oracle Base Table. How can we get the explain plan in timesten to find out when the table is being called by a custom java application, the materialized views are being used or not ? Please advice

Hi Can you help me in this regards,
i am getting the following error. Can you tell me how can i get rid of them?
Command> call ttcachestart();
15001: User lacks privilege ADMIN

Oracle Hint not causing any change to explain plan

Hi,
I was facing a problem about ORA-00600 for using Connect by Prior query,
details of which are at -
Connect by Prior - ORA-00600: internal error code, arguments: [kkqcbydrv:1
As is documented by Oracle, workaround for this is to use /*+ NO_UNNEST */ in query.
I displayed the explain plan for original query and after putting hint in query.
There is no difference in the explain plans, I am a starter for explain plans and don't know much of it.
But shouldn't the hint cause some change in explain plan?
Even the hash values as mentioned in explain plans are same.
Thanks in advance.
Av.

Perhaps it would help if you put the query (with the hint) and the explain plan here.

Interpreting explain plans oracle 11gr2

Hi,
We are using oracle 11.2.0.3 and plan on evaluating a series of explain plans to determine index/partitioning strategy for a large fact table +a ssociarted dimensions in data warehouse.
Whilst we plan on running a selection of these to get actaul times, wish to evalaute many more eplain plans to guage efficiency of data model.
In terms of interpreting we are going on basis of the lower the row count/cpu cost the better the performance should be.
Plan on using autotrace for these as well.
Any downsides to this /shoudl we look out for anything esle with explain plan.
Is autotrace suffciient in this repsect.
Have also found the time in execution plan can often bear no resembalnce to actaul execution plan.
Any other tips on interpreting explain plans woudl eb appreacited.
Whilst I understand the real times will only come thorugh running the queries want to do prep work with explain plans before run them all.
Thanks
Edited by: user5716448 on 02-Mar-2013 08:26

Don't rely on the cost to tell you how efficient a SQL is. It is based on estimates that are not always correct. Its best use is to tell if something has changed when doing SQL variations - it can and does happen that a lower cost version will use more resources as per AUTOTRACE than a higher-cost version of the SQL.
Also make absoutely sure that the tuned SQL returns the same results as the original :)
Using AUTOTRACE was a good decision. It will provide run-time metrics for your SQL as well as automatically generate execution plans. It does not list CPU usage, which is avialable from V$SQL. Lower resources listed by AUTOTRACE should accompany faster run times in general.

Explain plan, Oracle 10g, AWR, ASH etc etc

Hi,
I'm obviously not searching on the right terms but using one of the following : AWR, ASH, ADDM, isn't it possible to get the explain plan for a certain SQL_ID after the fact?
I was sure that using ash and specifying the SQL_ID that one could have the explain plan, but I don't have it in the ASH Report. We don't have Grid in place, only snapshots taken every hour.
cheers.

Thankyou both for your very quick replies, just what I needed.
Edited by: mattyb on Mar 25, 2009 2:06 PM

Problems with explain plan and statement

Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AM

tobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Cpu time is not getting displayed in explain plan

Hi All,
I am trying to analyze one query using explain plan .like below
1) explain plan for
SELECT /*+ parallel(tsp,8) use_hash( tsp tp) */ count(1)
FROM router tp,
receiver tsp
WHERE tp.rs = tsp.rp
AND creater_date >=to_date('04032009000000','ddmmyyyyhh24miss')
and tsp.XVF is not null
and tp.XVF is not null
and tp.role_name='BR';
2)@$ORACLE_HOME/rdbms/admin/utlxpls.sql
But i am getting only following columns in result .
| Id | Operation | Name | Rows | Bytes | Cost |
No Cpu time preset .
How can i extimate CPU time ?
Pls help
Thanks

am_73798 wrote:
I am trying to analyze one query using explain plan .like below
But i am getting only following columns in result .
| Id | Operation | Name | Rows | Bytes | Cost |
No Cpu time preset .
How can i extimate CPU time ?You need to mention your database version (4-digits, e.g. 9.2.0.8).
In Oracle 9i CPU costing is disabled by default, you need to gather WORKLOAD system statistics to enable the CPU costing.
In 10g CPU costing is enabled by default and uses default NOWORKLOAD system statistics if no WORKLOAD system statistics have been gathered. It can only be disabled by setting an undocumented parameter or by changing the OPTIMIZER_FEATURES_ENABLE parameter back to 9i compatibility.
You can check the status of your system statistics by running the following query in SQL*Plus:
column sname format a20
column pname format a20
column pval2 format a20
select
sname
, pname
, pval1
, pval2
from
sys.aux_stats$;Can you show us the actual (complete) output you get from "utlxpls.sql"? Use the \ tag to preserve formatting here:
\output
\will show asoutput
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

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

Oracle Explain Plan

Similar Messages

Maybe you are looking for