Explain plan in OEM

Is there a way to print or save of the explain plan within OEM?

For saving the explain plan I don't see any options.
Printing you can do that only using File, Print. Or use a screen capture utility like ScreenHunter, Screen grabber, etc and past it in a document for later reference.
Eric

Similar Messages

Explain Plan different in SQLPlus then production

We have a query that is consuming 95%+ of the CPU in production, but the same query in sqlplus takes seconds. The explain plan through OEM is different than the explain plan in sqlplus, but the query is the same? Any thoughts?
Thanks.

Your explanation raises many question.
We have a query that is consuming 95%+ of the CPU in production, How do you measure this?
but the same query in sqlplus takes seconds.What do you mean, by running in production or running in sqlplus?
How do you run on production? I mean, do you run through any application or what?
Are they running under the same user?
It is possible to post both execution plans and a more explanation on what you are saying.

Oem explain plan produced doesn't correspond to explain plan with tkprof

Hello all,
I am running OEM on a 10.2.0.3 database and I have a very slow query with cognos 8 BI on my data warehouse.
I went to the dbconsole through OEM and connected to target database I went to look at the query execution and then got an explain plan.
Then I did a trace file and ran it throught tkprof.
When I look at both produced explain plan, I can see the tree looks the same exept the corresponding values. In OEM, it says I am going throug 18000 rows and in the tkprof result it says more like millions of records.
As anybody had these kind of results?
Shall I have more confidence in TKprof then OEM?
It is very important to me since I am being chalanged by an external DBA.

I would recommend you to get Christian Antogini´s book "Troublshooting Oracle Performance", (http://www.antognini.ch/top/) which explains everything you need to know when analyzing Oracle SQL Performance and Explain Plans.
If you properly trace your SQL Statement, you will get "STAT" lines in the trace file. These stat lines show you the actual number of rows processed per row source operation. Explain plan per default does only show you the "estimated" row counts for the row source operations no matter whether you use "explain=" in the tkprof call or OEM to get the explain plan. Tkprof reads the STAT lines from the trace and outputs a section which is similar to an execution plan but contains the "real" number of rows.
However, if you want to troubleshoot Oracle Performance, I would recommend you to run the statement with the hint /*+ GATHER_PLAN_STATISTICS */ or set statistics_level=ALL in your session (not database-wide!).
If you do, you can get an excellent execution plan with DBMS_XPLAN.DISPLAY_CURSOR containing both estimated rows as well as actual rows combined with the "number of starts" for e.g. nested loop joins.
Get the book, read it, and you will be able to discuss this issue with your external dba in a professional way. ;-)
Regards,
Martin
www.ora-solutions.net

OEM explain plan sown on SQL Details vs Tuning Advisor

In OEM, if I go to "Top SQL" and then get the "SQL Details" for a specific SQL Id there is a tab which shows the execution plan.
For the SQL I'm interested in, this plan shows very low values for cost, number of rows, etc. It also shows all table access being through indexes. It shows no values in the Time column.
Now on this page, if I click the button "Run SQL Tuning Advisor" and run an advisor it comes back with a recommendation that I'll ignore for now. Here's my real question. On the recommendations page there is a button "Original Explain Plan". If I click this the execution plan I get is similar but not exactly the same as the one I mentioned above on the SQL Details page. This one has very high values for cost, number of rows, etc. Some of the tables show as not using indexes.
What are the differences between these 2 pages? Is the first one an estimated plan and the second one the actual?
I've searched trying to find an explanation for this, but haven't. Thanks for any help explaining this.

I tired running SQL Tuning Advisor with DBMS_SQLTUNE package, I think the output will help you understand.
Oracle 10g SQL Tuning
Adith

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 cardinallity is way off compared to actual rows being returned

Database version 11.2.0.3
We have a small but rapidly growing datawarehouse which has OBIEE as its front end reporting tool. Our DBA has set up a automatic stats gathering method in OEM and we can see that it run and gathers stats on stale objects on a regular basis. So we know the statistics are upto date.
In checking some slow queries I can see that the cardinality being reported in explain plans is way off compared to what is actually being returned.
For example the actual number of rows returned are 8000 but the cardinality estimate is > 300,000.
Now as per an Oracle White paper(The Oracle Optimizer Explain the Explain Plan) having "multiple single column predicates on a single table" can affect cardinality estimates and in case of our query that is true. Here is the "WHERE Clause section" of the query
SQL> select D1.c1 as c1,
2         D1.c2 as c2,
3         D1.c3 as c3,
4         D1.c4 as c4,
5         D1.c5 as c5,
6         D1.c6 as c6,
7         D1.c7 as c7,
8         D1.c8 as c8,
9         D1.c9 as c9,
10         D1.c10 as c10,
11         D1.c11 as c11,
12         D1.c12 as c12,
13         D1.c13 as c13,
14         D1.c14 as c14,
15         D1.c15 as c15,
16         D1.c16 as c16
17    from (select D1.c4 as c1,
18                 D1.c5 as c2,
19                 D1.c3 as c3,
20                 D1.c1 as c4,
21                 D1.c6 as c5,
22                 D1.c7 as c6,
23                 D1.c2 as c7,
24                 D1.c8 as c8,
25                 D1.c9 as c9,
26                 D1.c10 as c10,
27                 D1.c9 as c11,
28                 D1.c11 as c12,
29                 D1.c2 as c13,
30                 D1.c2 as c14,
31                 D1.c12 as c15,
32                 'XYZ' as c16,
33                 ROW_NUMBER() OVER(PARTITION BY D1.c2, D1.c3, D1.c4, D1.c5, D1.c6, D1.c7, D1.c8, D1.c9, D1.c10, D1.c11, D1.c12 ORDER BY D1.c2 ASC, D1.c3 ASC, D1.c4 ASC, D1.c5 ASC, D1.c6 ASC, D1.c
ASC, D1.c8 ASC, D1.c9 ASC, D1.c10 ASC, D1.c11 ASC, D1.c12 ASC) as c17
34            from (select distinct D1.c1 as c1,
35                                  D1.c2 as c2,
36                                  'CHANNEL1' as c3,
37                                  D1.c3 as c4,
38                                  D1.c4 as c5,
39                                  D1.c5 as c6,
40                                  D1.c6 as c7,
41                                  D1.c7 as c8,
42                                  D1.c8 as c9,
43                                  D1.c9 as c10,
44                                  D1.c10 as c11,
45                                  D1.c11 as c12
46                    from (select sum(T610543.GLOBAL1_EXCHANGE_RATE * case
47                                       when T610543.X_ZEB_SYNC_EBS_FLG = 'Y' then
48                                        T610543.X_ZEB_AIA_U_REVN_AMT
49                                       else
50                                        0
51                                     end) as c1,
52                                 T536086.X_ZEBRA_TERRITORY as c2,
53                                 T526821.LEVEL9_NAME as c3,
54                                 T526821.LEVEL1_NAME as c4,
55                                 T577698.PER_NAME_FSCL_YEAR as c5,
56                                 T577698.FSCL_QTR as c6,
57                                 T31796.X_ZEBRA_TERRITORY as c7,
58                                 T31796.X_OU_NUM as c8,
59                                 T664055.TERRITORY as c9,
60                                 T536086.X_OU_NUM as c10,
61                                 T526821.LEVEL4_NAME as c11
62                            from W_INT_ORG_D        T613144 /* Dim_ZEB_W_INT_ORG_D_POS_Client_Attr_Direct */,
63                                 W_ZEBRA_REGION_D   T664055 /* Dim_ZEB_W_ZEBRA_REGION_D_POS_Client_Direct */,
64                                 W_DAY_D            T577698 /* Dim_ZEB_W_DAY_D_Order_Invoice_Date */,
65                                 WC_PRODUCT_HIER_DH T526821 /* Dim_WC_PRODUCT_HIER_DH */,
66                                 W_PRODUCT_D        T32069 /* Dim_W_PRODUCT_D */,
67                                 W_ORG_D            T31796,
68                                 W_ORG_D            T536086 /* Dim_ZEB_W_ORG_D_Reseller */,
69                                 W_ORDERITEM_TMP_F      T610543 /* Fact_ZEB_W_ORDERITEM_F_Direct */
70                           where (T610543.PR_OWNER_BU_WID = T613144.ROW_WID and
71                                 T577698.ROW_WID =
72                                 T610543.X_ZEB_AIA_TRXN_DT_WID and
73                                 T32069.ROW_WID = T526821.PROD_WID and
74                                 T32069.ROW_WID = T610543.ROOT_LN_PROD_WID and
75                                 T536086.ROW_WID = T610543.ACCNT_WID and
76                                 T31796.DATASOURCE_NUM_ID =
77                                 T610543.DATASOURCE_NUM_ID and
78                                 T31796.INTEGRATION_ID = T610543.VIS_PR_BU_ID and
79                                 T536086.DELETE_FLG = 'N' and
80                                 T610543.X_ZEB_DELETE_FLG = 'N' and
81                                 T613144.X_ZEB_REGION_WID = T664055.ROW_WID and
82                                 T577698.FSCL_DAY_OF_YEAR < 97 and
83                                 '2006' < T577698.PER_NAME_FSCL_YEAR and
84                                 T536086.X_OU_NUM <> '11073' and
85                                 T536086.X_ZEBRA_TERRITORY !=
86                                 'XX23' and
87                                 T536086.X_OU_NUM != '56791647728774' and
88                                 T536086.X_OU_NUM != '245395890' and
89                                 T536086.X_ZEBRA_TERRITORY !=
90                                 'STRATEGIC ACCTS 2' and
91                                 T526821.LEVEL2_NAME != 'Charges' and
92                                 T526821.LEVEL9_NAME != 'Unspecified' and
93                                 T536086.X_ZEBRA_TERRITORY !=
94                                 'XX1' and T536086.X_ZEBRA_TERRITORY !=
95                                 'XX2' and T536086.X_ZEBRA_TERRITORY !=
96                                 'XX3' and T536086.X_ZEBRA_TERRITORY !=
97                                 'XX4' and
98                                 (T536086.X_ZEBRA_TERRITORY in
99                                 ( ... In List of 22 values )) and
125                                 T32069.X_ZEB_EBS_PRODUCT_TYPE is null)
126                           group by T31796.X_ZEBRA_TERRITORY,
127                                    T31796.X_OU_NUM,
128                                    T526821.LEVEL1_NAME,
129                                    T526821.LEVEL4_NAME,
130                                    T526821.LEVEL9_NAME,
131                                    T536086.X_OU_NUM,
132                                    T536086.X_ZEBRA_TERRITORY,
133                                    T577698.FSCL_QTR,
134                                    T577698.PER_NAME_FSCL_YEAR,
135                                    T664055.TERRITORY) D1) D1) D1
136   where (D1.c17 = 1)
137 /
Elapsed: 00:00:35.19
Execution Plan
Plan hash value: 3285002974
| Id | Operation                                         | Name               | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT                                  |                    | 2145M| 2123G|       |   612K (1)| 03:03:47 |       |       |        |      |            |
|   1 | PX COORDINATOR                                   |                    |       |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)                             | :TQ10012           | 2145M| 2123G|       |   612K (1)| 03:03:47 |       |       | Q1,12 | P->S | QC (RAND) |
|* 3 |    VIEW                                           |                    | 2145M| 2123G|       |   612K (1)| 03:03:47 |       |       | Q1,12 | PCWP |            |
|* 4 |     WINDOW NOSORT                                 |                    | 2145M|   421G|       |   612K (1)| 03:03:47 |       |       | Q1,12 | PCWP |            |
|   5 |      SORT GROUP BY                                |                    | 2145M|   421G|   448G|   612K (1)| 03:03:47 |       |       | Q1,12 | PCWP |            |
|   6 |       PX RECEIVE                                  |                    | 2145M|   421G|       | 1740 (11)| 00:00:32 |       |       | Q1,12 | PCWP |            |
|   7 |        PX SEND HASH                               | :TQ10011           | 2145M|   421G|       | 1740 (11)| 00:00:32 |       |       | Q1,11 | P->P | HASH       |
|* 8 |         HASH JOIN BUFFERED                        |                    | 2145M|   421G|       | 1740 (11)| 00:00:32 |       |       | Q1,11 | PCWP |            |
|   9 |          PX RECEIVE                               |                    |   268K| 7864K|       |    93   (2)| 00:00:02 |       |       | Q1,11 | PCWP |            |
| 10 |           PX SEND HASH                            | :TQ10009           |   268K| 7864K|       |    93   (2)| 00:00:02 |       |       | Q1,09 | P->P | HASH       |
| 11 |            PX BLOCK ITERATOR                      |                    |   268K| 7864K|       |    93   (2)| 00:00:02 |       |       | Q1,09 | PCWC |            |
| 12 |             TABLE ACCESS FULL                     | W_ORG_D            |   268K| 7864K|       |    93   (2)| 00:00:02 |       |       | Q1,09 | PCWP |            |
| 13 |          PX RECEIVE                               |                    |   345K|    59M|       | 1491   (2)| 00:00:27 |       |       | Q1,11 | PCWP |            |
| 14 |           PX SEND HASH                            | :TQ10010           |   345K|    59M|       | 1491   (2)| 00:00:27 |       |       | Q1,10 | P->P | HASH       |
|* 15 |            HASH JOIN BUFFERED                     |                    |   345K|    59M|       | 1491   (2)| 00:00:27 |       |       | Q1,10 | PCWP |            |
| 16 |             PX RECEIVE                            |                    | 1321 | 30383 |       |     2   (0)| 00:00:01 |       |       | Q1,10 | PCWP |            |
| 17 |              PX SEND BROADCAST                    | :TQ10006           | 1321 | 30383 |       |     2   (0)| 00:00:01 |       |       | Q1,06 | P->P | BROADCAST |
| 18 |               PX BLOCK ITERATOR                   |                    | 1321 | 30383 |       |     2   (0)| 00:00:01 |       |       | Q1,06 | PCWC |            |
| 19 |                TABLE ACCESS FULL                  | W_ZEBRA_REGION_D   | 1321 | 30383 |       |     2   (0)| 00:00:01 |       |       | Q1,06 | PCWP |            |
|* 20 |             HASH JOIN                             |                    |   345K|    52M|       | 1488   (2)| 00:00:27 |       |       | Q1,10 | PCWP |            |
| 21 |              JOIN FILTER CREATE                   | :BF0000            | 9740 |   114K|       |     2   (0)| 00:00:01 |       |       | Q1,10 | PCWP |            |
| 22 |               PX RECEIVE                          |                    | 9740 |   114K|       |     2   (0)| 00:00:01 |       |       | Q1,10 | PCWP |            |
| 23 |                PX SEND HASH                       | :TQ10007           | 9740 |   114K|       |     2   (0)| 00:00:01 |       |       | Q1,07 | P->P | HASH       |
| 24 |                 PX BLOCK ITERATOR                 |                    | 9740 |   114K|       |     2   (0)| 00:00:01 |       |       | Q1,07 | PCWC |            |
| 25 |                  TABLE ACCESS FULL                | W_INT_ORG_D        | 9740 |   114K|       |     2   (0)| 00:00:01 |       |       | Q1,07 | PCWP |            |
| 26 |              PX RECEIVE                           |                    |   344K|    47M|       | 1486   (2)| 00:00:27 |       |       | Q1,10 | PCWP |            |
| 27 |               PX SEND HASH                        | :TQ10008           |   344K|    47M|       | 1486   (2)| 00:00:27 |       |       | Q1,08 | P->P | HASH       |
| 28 |                JOIN FILTER USE                    | :BF0000            |   344K|    47M|       | 1486   (2)| 00:00:27 |       |       | Q1,08 | PCWP |            |
|* 29 |                 HASH JOIN BUFFERED                |                    |   344K|    47M|       | 1486   (2)| 00:00:27 |       |       | Q1,08 | PCWP |            |
| 30 |                  JOIN FILTER CREATE               | :BF0001            | 35290 |   964K|       |    93   (2)| 00:00:02 |       |       | Q1,08 | PCWP |            |
| 31 |                   PX RECEIVE                      |                    | 35290 |   964K|       |    93   (2)| 00:00:02 |       |       | Q1,08 | PCWP |            |
| 32 |                    PX SEND HASH                   | :TQ10004           | 35290 |   964K|       |    93   (2)| 00:00:02 |       |       | Q1,04 | P->P | HASH       |
| 33 |                     PX BLOCK ITERATOR             |                    | 35290 |   964K|       |    93   (2)| 00:00:02 |       |       | Q1,04 | PCWC |            |
|* 34 |                      TABLE ACCESS FULL            | W_ORG_D            | 35290 |   964K|       |    93   (2)| 00:00:02 |       |       | Q1,04 | PCWP |            |
| 35 |                  PX RECEIVE                       |                    |   344K|    38M|       | 1392   (2)| 00:00:26 |       |       | Q1,08 | PCWP |            |
| 36 |                   PX SEND HASH                    | :TQ10005           |   344K|    38M|       | 1392   (2)| 00:00:26 |       |       | Q1,05 | P->P | HASH       |
| 37 |                    JOIN FILTER USE                | :BF0001            |   344K|    38M|       | 1392   (2)| 00:00:26 |       |       | Q1,05 | PCWP |            |
|* 38 |                     HASH JOIN BUFFERED            |                    |   344K|    38M|       | 1392   (2)| 00:00:26 |       |       | Q1,05 | PCWP |            |
| 39 |                      PX RECEIVE                   |                    | 93791 | 4671K|       |     7   (0)| 00:00:01 |       |       | Q1,05 | PCWP |            |
| 40 |                       PX SEND HASH                | :TQ10001           | 93791 | 4671K|       |     7   (0)| 00:00:01 |       |       | Q1,01 | P->P | HASH       |
| 41 |                        PX BLOCK ITERATOR          |                    | 93791 | 4671K|       |     7   (0)| 00:00:01 |       |       | Q1,01 | PCWC |            |
|* 42 |                         TABLE ACCESS FULL         | WC_PRODUCT_HIER_DH | 93791 | 4671K|       |     7   (0)| 00:00:01 |       |       | Q1,01 | PCWP |            |
|* 43 |                      HASH JOIN                    |                    |   894K|    57M|       | 1384   (2)| 00:00:25 |       |       | Q1,05 | PCWP |            |
| 44 |                       JOIN FILTER CREATE          | :BF0002            |   243K| 1904K|       |    48   (3)| 00:00:01 |       |       | Q1,05 | PCWP |            |
| 45 |                        PX RECEIVE                 |                    |   243K| 1904K|       |    48   (3)| 00:00:01 |       |       | Q1,05 | PCWP |            |
| 46 |                         PX SEND HASH              | :TQ10002           |   243K| 1904K|       |    48   (3)| 00:00:01 |       |       | Q1,02 | P->P | HASH       |
| 47 |                          PX BLOCK ITERATOR        |                    |   243K| 1904K|       |    48   (3)| 00:00:01 |       |       | Q1,02 | PCWC |            |
|* 48 |                           TABLE ACCESS FULL       | W_PRODUCT_D        |   243K| 1904K|       |    48   (3)| 00:00:01 |       |       | Q1,02 | PCWP |            |
| 49 |                       PX RECEIVE                  |                    |   894K|    50M|       | 1336   (2)| 00:00:25 |       |       | Q1,05 | PCWP |            |
| 50 |                        PX SEND HASH               | :TQ10003           |   894K|    50M|       | 1336   (2)| 00:00:25 |       |       | Q1,03 | P->P | HASH       |
| 51 |                         JOIN FILTER USE           | :BF0002            |   894K|    50M|       | 1336   (2)| 00:00:25 |       |       | Q1,03 | PCWP |            |
|* 52 |                          HASH JOIN                |                    |   894K|    50M|       | 1336   (2)| 00:00:25 |       |       | Q1,03 | PCWP |            |
| 53 |                           PX RECEIVE              |                    |   292 | 3504 |       |   136   (0)| 00:00:03 |       |       | Q1,03 | PCWP |            |
| 54 |                            PX SEND BROADCAST LOCAL| :TQ10000           |   292 | 3504 |       |   136   (0)| 00:00:03 |       |       | Q1,00 | P->P | BCST LOCAL |
| 55 |                             PX BLOCK ITERATOR     |                    |   292 | 3504 |       |   136   (0)| 00:00:03 |       |       | Q1,00 | PCWC |            |
|* 56 |                              TABLE ACCESS FULL    | W_DAY_D            |   292 | 3504 |       |   136   (0)| 00:00:03 |       |       | Q1,00 | PCWP |            |
| 57 |                           PX BLOCK ITERATOR       |                    | 4801K|   215M|       | 1199   (2)| 00:00:22 |     1 |    11 | Q1,03 | PCWC |            |
|* 58 |                            TABLE ACCESS FULL      | W_ORDERITEM_TMP_F | 4801K|   215M|       | 1199   (2)| 00:00:22 |     1 |    44 | Q1,03 | PCWP |            |
Note
   - dynamic sampling used for this statement (level=5)
Statistics
        498 recursive calls
       2046 db block gets
    1193630 consistent gets
      74398 physical reads
          0 redo size
     655170 bytes sent via SQL*Net to client
      11761 bytes received via SQL*Net from client
        541 SQL*Net roundtrips to/from client
         64 sorts (memory)
          0 sorts (disk)
       8090 rows processed
SQL>So my question is if, cardinality estimates are way off, is that an indicator that the explain plans being generated are sub-optimal?
Can you provide me with some tips or links to blog post or books on how I approach tuning such queries where cardinalities are not good?
Edited by: qqq on Apr 7, 2013 2:27 PM

As already asked in your other thread:
Please see the FAQ for how to post a tuning request and the information that you need to provide.
Part of that information is:
1. DDL for the table and indexes
2. The query being used
3. row counts for the table and for the predicates used in the query
4. info about stats. You did update the table and index stats didn't you?
5. The 'actual' execution plans.
An explain plan just shows what Oracle 'thinks' it is going to do. The actual plans show what Oracle actually 'did' do. Just because Oracle expected to save doesn't mean the savings were actually achieved.
When you post the plans use on the line before and on the line after to preserve formatting.
Your partial code is virtually unusable because of the missing conditions in the predicates. You need to use '!=' for 'not equals' if that's what those missing conditions are.
Please edit your post to use code tags, add the missing conditions and provide the other information needed for a tuning request.

Explain Plan in Raptor

Over all a very nice product. As with everything now it is difficult to place the raptor feature set in the over all product set. However any comparison is inevitable.
It would be nice if the explain plan option would ask for a default userid in case the table names are not fully qualified. This is how OEM works. It is a very convenient feature.

Say I get a sql from somewhere for explain plan. The sql is executed as user scott.
When I paste the sql in the worksheet(logged in as system) and ask for an explain plan - raptor will complain about table or view not existing (942)
If I do the same in OEM (9I). OEM will ask for a default parsing userid. You pick scott and all tables in the sql are automatically aliased as scott and out comes the explain plan.
Also is there option in raptor to pretty format an sql (Again similar to OEM)

Calculating the Size(KB) in the explain plan....

Hi
I executed a sql statement in SQL*PLUS and having enabled the tracing in OEM , among others , I read the Size in KiloBytes which the 'TABLE ACCESS FULL' segment of the explain plan returned.....
This number is 5.998,193KB
I used the vsize built-in function in order to get the total number in bytes of the physical representation of all the rows (about 53500) ....
So , I wrote :
select nvl(sum(vsize(farmak_code)),0)+nvl(sum(vsize(emp_name)),0)+nvl(sum(vsize(category)),0)+ .....+.....
from mitroo_farmakou
The result was 5794544 in bytes which is close to 5.998,193KB.
My question is :
The computation of the bytes in the explain plan (TABLE ACCESS FULL segment) is done by adding the vsize of all columns....????
Does anybody Knows...????
Thanks , a lot
Simon

I doubt it. For a large table that would be an incredibly expensive calculation.
I suspect that it is something closer to:
SQL> SELECT * FROM incident;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=137 Card=15603 Bytes=6818511)
   1    0   TABLE ACCESS (FULL) OF 'INCIDENT' (Cost=137 Card=15603 Bytes=6818511)
SQL> SELECT ROUND(num_rows * avg_row_len)
2 FROM user_tables
3 WHERE table_name = 'INCIDENT';
ROUND(NUM_ROWS*AVG_ROW_LEN)
                    6818449HTH
John

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?

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

Filter(NULL IS NOT NULL) in Explain Plan ??

Hi All,
Can someone please explain what this explain plan statement means? I see a filter(NULL IS NOT NULL) as the first statement - could not figure out why it came up so from googling.
My Query Used:
EXPLAIN PLAN FOR
MERGE INTO summary_bysrccd
USING
(SELECT LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))) AS SUMMARY_DATE,
os.acctnum,
ol.sourcecode AS sourcecode,
ol.sourcename AS sourcename,
count(1) cnt_articleview
FROM article_views os , master_sourcecode ol
where os.sourcecode = ol.sourcecode
AND os.acctnum IS NOT NULL
AND ol.sourcecode IS NOT NULL
AND os.requestdatetime IS NOT NULL
AND UPPER(os.success_ind) = 'S'
     AND (
          ('INCR' = 'FULL'
          AND (get_date_timestamp(os.requestdatetime) BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS')
          AND   os.entry_CreatedDate BETWEEN TO_DATE('22-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('28-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
          OR ('INCR' = 'FULL'
          AND os.entry_createddate BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS') )
group by LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))),
os.acctnum,ol.sourcecode,ol.sourcename) mrg_query
ON (ods_av_summary_bysrccd.acctnum = mrg_query.acctnum AND
ods_av_summary_bysrccd.summary_date=mrg_query.summary_date AND
ods_av_summary_bysrccd.sourcecode=mrg_query.sourcecode)
WHEN NOT MATCHED THEN
INSERT (SUMMARY_date,ACCTNUM,SOURCECODE,SOURCENAME,CNT_ARTICLEVIEW,ENTRY_LASTUPDATEDDATE)
VALUES(mrg_query.summary_date,mrg_query.acctnum,mrg_query.sourcecode,mrg_query.sourcename,
mrg_query.cnt_articleview,sysdate)
WHEN MATCHED THEN
UPDATE SET ods_av_summary_bysrccd.cnt_articleview=
CASE WHEN NVL('INCR','INCR') = 'FULL' THEN mrg_query.cnt_articleview
ELSE ods_av_summary_bysrccd.cnt_articleview+mrg_query.cnt_articleview
END,
ods_av_summary_bysrccd.entry_lastupdateddate=sysdate;My Explain Plan:
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 268591246
| Id | Operation                                 | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | MERGE STATEMENT                           |                           |     1 |   456 |       |     3   (0)| 00:00:01 |       |       |
|   1 | MERGE                                    | ODS_AV_SUMMARY_BYSRCCD    |       |       |       |            |          |       |       |
|   2 |   VIEW                                    |                           |       |       |       |            |          |       |       |
|   3 |    NESTED LOOPS OUTER                     |                           |     1 |   417 |       |     3   (0)| 00:00:01 |       |       |
|   4 |     VIEW                                  |                           |     1 |   360 |       |     5 (100)| 00:00:01 |       |       |
|   5 |      SORT GROUP BY                        |                           |     1 |    73 |   595M|            |          |       |       |
PLAN_TABLE_OUTPUT
|* 6 |       FILTER                              |                           |       |       |       |            |          |       |       |
|* 7 |        HASH JOIN                          |                           | 6975K|   485M| 3944K| 17594   (1)| 00:03:32 |       |       |
|   8 |         TABLE ACCESS FULL                 | ODS_MASTER_SOURCECODE     | 84021 | 2953K|       |   273   (1)| 00:00:04 |       |       |
|* 9 |         TABLE ACCESS BY GLOBAL INDEX ROWID| ODS_ARTICLE_VIEWS         | 7007K|   247M|       |   826   (0)| 00:00:10 |    33 |    33 |
|* 10 |          INDEX FULL SCAN                  | IDX_AV_ACCTNUM            |    25M|       |       |    26   (0)| 00:00:01 |       |       |
| 11 |     TABLE ACCESS BY GLOBAL INDEX ROWID    | ODS_AV_SUMMARY_BYSRCCD    |     1 |    57 |       |     3   (0)| 00:00:01 | ROWID | ROWID |
|* 12 |      INDEX UNIQUE SCAN                    | ODS_AV_SUMMARY_BYSRCCD_PK |     1 |       |       |     2   (0)| 00:00:01 |       |       |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   6 - filter(NULL IS NOT NULL)
   7 - access("OS"."SOURCECODE"="OL"."SOURCECODE")
   9 - filter("OS"."REQUESTDATETIME" IS NOT NULL AND "OS"."ENTRY_CREATEDDATE">=TO_DATE(' 2011-08-23 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss') AND "OS"."ENTRY_CREATEDDATE"<=TO_DATE(' 2011-08-27 23:59:59', 'syyyy-mm-dd hh24:mi:ss') AND UPPER("OS"."SUCCESS_IND")='S')
10 - filter("OS"."ACCTNUM" IS NOT NULL)
12 - access("ODS_AV_SUMMARY_BYSRCCD"."SUMMARY_DATE"(+)=INTERNAL_FUNCTION("MRG_QUERY"."SUMMARY_DATE") AND
              "ODS_AV_SUMMARY_BYSRCCD"."ACCTNUM"(+)="MRG_QUERY"."ACCTNUM" AND "ODS_AV_SUMMARY_BYSRCCD"."SOURCECODE"(+)="MRG_QUERY"."SOURCECODE")
Note
PLAN_TABLE_OUTPUT
   - dynamic sampling used for this statement

Hi Toon,
Thanks for the quick resolution. I went back and verified the table's colunm details and it has a NOT NULL constraint.
Regards,
Chaitanya
P.S: Is it ok if I ask you for some help regarding a production issue I have been encountering since 15 days but haev no clear resolution yet about what/why is the reason (the said issue is neither uniform nor regular - its affecting some modules and happening on some days - i shall give the full details if you are willing to have a look) - i shall start a new post or email you directly - yur convenience.

Explain plan results are different in SQL Developer than SQL Plus

My Environment:
SQL Developer 1.0.0.15.27
Platform where SQL Developer is running: Windows XP 2002 SP2
Oracle Database and Client 9.2.0.7
Optimizer_mode: FIRST_ROWS
I have the following SQL statement:
SELECT a1.comp_id
FROM temp_au_company a0, au_company a1
WHERE :b2 = a0.temp_emp_code
AND a0.comp_id = a1.comp_id
AND a0.sls_terr_code != a1.sls_terr_code
AND a1.last_mdfy_date > :b1
When I run an Explain in SQL Developer I get the following access path (which is the one I really want):
SELECT STATEMENT TABLE ACCESS(BY INDEX ROWID) FEDLINK.AU_COMPANY NESTED LOOPS INDEX(RANGE SCAN)
FEDLINK.UX2_TEMP_AU_COMPANY
INDEX(RANGE SCAN) FEDLINK.PX1_COMPANY
However, when I execute the statement with sql_trace turned on and use tkprof to generate the actual access path, the statement executes as follows (which is WAY more expensive):
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 3.58 6.68 28136 29232 0 0
total 3 3.58 6.69 28136 29232 0 0
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 979 (FEDLINK) (recursive depth: 1)
Rows Row Source Operation
0 NESTED LOOPS
0 TABLE ACCESS FULL AU_COMPANY
0 INDEX RANGE SCAN UX2_TEMP_AU_COMPANY (object id 49783)
Notice the FULL access of au_company.
I understand that SQL Developer has nothing to do with why the statement executed the way it did, but why is the Explain in SQL Developer different than the actual execution plan?
Added note....when I run the explain in SQL Plus it is the same as the actual execution. Here is the explain from SQL Plus:
explain plan for SELECT a1.comp_id
FROM temp_au_company a0, au_company a1
WHERE '1' = a0.temp_emp_code
AND a0.comp_id = a1.comp_id
AND a0.sls_terr_code != a1.sls_terr_code
AND a1.last_mdfy_date > '01-MAY-2006';
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 76 | 2597 |
| 1 | NESTED LOOPS | | 2 | 76 | 2597 |
| 2 | TABLE ACCESS FULL | AU_COMPANY | 2 | 42 | 2595 |
| 3 | INDEX RANGE SCAN | UX2_TEMP_AU_COMPANY | 1 | 17 | 2
Thanks,
Brenda

The explain is different (full scan of au_company in SQL Plus / index access in SQL Developer) even when I use variables in SQL Plus. Here is the output for SQL Plus using variables instead of literals:
SQL> variable b1 varchar2
SQL> variable b2 char
SQL> explain plan for SELECT a1.comp_id
2 FROM temp_au_company a0, au_company a1
3 WHERE :b2 = a0.temp_emp_code
4 AND a0.comp_id = a1.comp_id
5 AND a0.sls_terr_code != a1.sls_terr_code
6 AND a1.last_mdfy_date > :b1
7 /
Explained.
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 3184 | 118K| 2995 |
| 1 | HASH JOIN | | 3184 | 118K| 2995 |
| 2 | INDEX RANGE SCAN | UX2_TEMP_AU_COMPANY | 3187 | 54179 | 3 |
| 3 | TABLE ACCESS FULL | AU_COMPANY | 24009 | 492K| 2983 |
Any other ideas? They should be the same.
Brenda

Performance problem: Query explain plan changes in pl/sql vs. literal args

I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between 123 and 456;
Its performance was excellent with literal arguments (1 sec per execution).
But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
Ex:
CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
CURSOR LT_CURSOR IS
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between param1 AND param2;
BEGIN
FOR aRecord IN LT_CURSOR
LOOP
(print timestamp...)
END LOOP;
END runQuery;
Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
Solution:
Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
Downside: Query not cached for future use. Perfectly fine for this query's purpose.
Other suggestions are welcome.

AmandaSoosai wrote:
I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between 123 and 456;
Its performance was excellent with literal arguments (1 sec per execution).
But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
Ex:
CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
CURSOR LT_CURSOR IS
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between param1 AND param2;
BEGIN
FOR aRecord IN LT_CURSOR
LOOP
(print timestamp...)
END LOOP;
END runQuery;
Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
Solution:
Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
Downside: Query not cached for future use. Perfectly fine for this query's purpose.
Other suggestions are welcome.Best wild guess based on what you've posted is a bind variable mismatch (your column is declared as a NUMBER data type and your bind variable is declared as a VARCHAR for example). Unless you have histograms on the columns in question ... which, if you're using bind variables is usually a really bad idea.
A basic illustration of my guess
http://blogs.oracle.com/optimizer/entry/how_do_i_get_sql_executed_from_an_application_to_uses_the_same_execution_plan_i_get_from_sqlplus

Explain plan in OEM

Similar Messages

Maybe you are looking for