Execution plan of a query changed

Dear Experts,
One of the SQL's running fine prior has a problem now. It just takes too long to execute. Tuning advisor recommends a profile setting with 55% benefit and no other recommendations.
Using profile hasn't helped much. I would like to check execution plan history of this SQL. Is there V$ view where this info gets populated in terms of hash values??
Thanks.

See DBA_HIST_SQLSTAT for historic execution stats and get the plans from DBMS_XPLAN.DISPLAY_AWR.
e.g.
select sn.snap_id
,      sn.end_interval_time
,      st.module
,      st.sql_id
,      st.plan_hash_value
,      rows_processed_delta rws
,      executions_delta     execs
,      elapsed_time_delta   elp
,      cpu_time_delta       cpu
,      buffer_gets_delta    gets
,      iowait_delta         io
from   dba_hist_snapshot sn
,      dba_hist_sqlstat st
where st.snap_id            = sn.snap_id
and    st.sql_id             = '<sql_id>'
order by sn.snap_id desc; and
select * from table(dbms_xplan.display_awr('<sql_id>'));This AWR data depends on your AWR retention period - which is far too short at the default 8 days but requires more space for longer obviously - and whether the SQL is regularly in the top N.
Edited by: Dom Brooks on Jul 12, 2012 9:29 AM

Similar Messages

Effect of RLS policy (VPD) on execution plan of a query

Hi
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Regards,
Amardeep Sidhu

Amardeep Sidhu wrote:
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
VPD is supposed to be invisible - which is why you get minimal information about security predicates in the standard trace file. However, if you reference a table with a security preidcate in your query, the table is effectively replaced by an inline view of the form: "select * from original_table where {security_predicate}", and the result is then optimised. So the effects of the security predicate is just the same as you writing the predicate into the query.
Apart from your use of v$sql_plan to show the change in plan and the new predicates, you can see the effects of the predicates by setting event 10730 with 10046. In current versions of Oracle this causes the substitute view being printed in the trace file.
Bear in mind that security predicates can be very complex - including subqueries - so the effect isn't just that of including the selectivity of "another simple predicate".
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Think of the effect of changing the SQL by hand - and how you would need to optimise the resultant query. Sometimes you do need to modify your indexing to help the security predicates, sometimes it won't make enough difference to matter.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
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.

How to skip existing execution plan for a query

Hi,
I want to skip existng execution plan for a query which I am executing often. I dont want it to use the same execution plan everytime. Please let me know if any method is there skip the existing execution plan.
Thanks in advance.......
Edited by: 900105 on Dec 1, 2011 4:52 AM

Change the query so it is syntactically different, but has the same semantics (meaning). That way CBO will reparse it and you might get a new execution plan.
One simple way to do that is to add a dummy predicate ( 45=45) to the where clause. The predicate must be changed every time the query is executed ( 46=46 , 47=47 ,… ).
Iordan Iotzov
http://iiotzov.wordpress.com/

How to capture the execution plan for a query

HI All,
Can anyone please help me in finding out the command to capture the execution plan for a query.
Execution plan for select * from EMP where <Condtions>
it is getting executed successfully but i need to get the proper execution plan for the same.
Thanks

971830 wrote:
i want to know where execution plan gets generated??
in PMON of server process or in shared pool??
i know that optimixer create execution plan..It is stored in Library Cache (present inside Shared Pool ).
select * from v$sql_plan;An absolute beautiful white paper :
Refer this -- www.sagelogix.com/sagelogix/SearchResults/SAGE015052
Also -- http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/XPVSP/Default.aspx
HTH
Ranit B.

Execution plans for a Query

Hi,
       As per documentation i learnt, For Every SQL statement i.e Executed , it will generate 23 Executions plan for a single query. The Runtime Engine will choose the Best Execution plan for Fetch Operation.
    In which Data dictionary view , do i have to check all those 23 Executions plans..
Thanks

startup wrote:
Hi,
       As per documentation i learnt, For Every SQL statement i.e Executed , it will generate 23 Executions plan for a single query. The Runtime Engine will choose the Best Execution plan for Fetch Operation.
    In which Data dictionary view , do i have to check all those 23 Executions plans..
Thanks
please post URL to document that says 23 Execute Plans are generated.

Different execution plan for same query but for different condition value

Hi All,
I'm facing a strange situation where same query for different condition not working.
1--
Select top 10 * from revenuefact(nolock)
where feecode ='OW4'
2--
Select top 10 * from revenuefact(nolock)
where feecode ='BTE'
1st query is returning result easily but 2nd query is taking too long. Column
feecode has already Non-clustered index and Clustered index is also available for another col RevenueSID.
I was surprised when checked the query execution plan for both the above queries which is quite different (as per attached below). Can anyone suggest me the reason behind it.
And solution for the same. One more thing that data for feecode BTE is inserting through different source instead of others feecode and table contains more than 300 million rows.

When I speak with people inside Microsoft who work with the optimizer, the refuse to accept the work "bug" when a query produces the correct result, but with a suboptimal plan. They prefer to use the word "limitation".
The limitation here is that when the optimizer compares two plans, it only looks at the estimated cost. As far as I know, it does not perform any analysis from the perspective "what if the statistics are wrong"? They do provide the hint OPTIMIZE
FOR UNKNOWN, but that does not work then there is a constant as in this case.
The optimizer will surely distinguish between TOP 10 and TOP 10000000. With the latter, you have all reason to expect a Clustered Index Scan no matter which value you search for - unless you pick a value for which the histogram indicates that there are no
rows.
Interesting enough, I was able to reproduce the situation in my Northgale database, which is an inflated version of Northwind, and where statistics should be accurate.
SELECT TOP 10 * FROM Orders WHERE EmployeeID = 8
results in a CI scan, and so does also EmployeeID = 7, and even 5. There are only 2292 rows out of a total of 344305 rows. If I try EmployeeID 808 for which there are 1797, the optimizer goes for the index seek.
Erland Sommarskog, SQL Server MVP, [email protected]

How do you view the execution plan of a query?

I want to see if a particular index was used for a specific query....

Becareful. You are in the Forum of OBIEE. It's much more a database question.
You can read an plan with a lot of tool. Toad permit it and I assume that Sql Developer also must give it.
Otherwise, you can use the basic command of Oracle as explain plan :
http://gerardnico.com/wiki/database/oracle/explain_plan
Cheers
Nico

Same Query returning different result (Different execution plan)

Hi all,
To day i have discovered a strange thing: a query that return a different result when using a different execution plan.
The query :
SELECT *
FROM schema.table@database a
WHERE     column1 IN ('3')
       AND column2 = '101'
       AND EXISTS
              (SELECT null
                 FROM schema.table2 c
                WHERE a.column3 = SUBSTR (c.column1, 2, 12));where schema.table@database is a remote table.
when executed with the hint /*+ ordered use_nl(a c) */ these query return no result and its execution plan is :
Rows     Row Source Operation
      0 NESTED LOOPS (cr=31 r=0 w=0 time=4894659 us)
   4323   SORT UNIQUE (cr=31 r=0 w=0 time=50835 us)
   4336    TABLE ACCESS FULL TABLE2 (cr=31 r=0 w=0 time=7607 us)
      0   REMOTE (cr=0 r=0 w=0 time=130536 us)When i changed the execution plan with the hint /*+ use_hash(c a) */
Rows     Row Source Operation
   3702 HASH JOIN SEMI (cr=35 r=0 w=0 time=497839 us)
22556   REMOTE (cr=0 r=0 w=0 time=401176 us)
   4336   TABLE ACCESS FULL TABLE2 (cr=35 r=0 w=0 time=7709 us)It seem that when the execution plan have changed the remote query return no result.
It'is a bug or i have missed somthing ?
PS: The two table are no subject to insert or update statement.
Oracle version : 9.2.0.2.0
System version : HP-UX v1
Thanks.

H.Mahmoud wrote:
Oracle version : 9.2.0.2.0
System version : HP-UX v1Hard to say. You're using a very old and deprecated version of the database, and one that was known to contain bugs.
9.2.0.7 was really the lowest version of 9i that was considered to be 'stable', but even so, it's old and lacking in many ways.
Consider upgrading to the latest database version at your earliest opportunity. (or at least apply patches up to the latest 9i version before querying if there is bugs in your really low buggy version)

Oracle 10g Diff in execution plan query with binding var Vs without

We recently did 10g upgrade. In 10g, execution plan differs for query with binding var(thru jdbc etc) Vs without it as given below. For query with binding var,
it chooses poor execution plan(no index is used, full scan is done etc). everything worked fine in 9i. To rectify the problem, we have to hint query with right index,join etc. but i dont like this solution.
I would rather prefer to correct database to choose right execution path instead of eacy query level. but not sure what causes the issue.
Does anybody came across this issue? if so, Please share your experiences. Thanks for the help. Do let me know if you need more info.
1. Query without binding bar:
select * from test where col1 = :1 and col2 = :2
1. Query without binding bar:
select * from test where col1 = 'foo' and col2= 'bar'

I am not an expert but in my humble opinion it is the developer's responsability to ensure the correct explain plan is used before deploying code to production, if the explain plan returned by the DB is bad, then the use of a hint is perfectly acceptable.
Check this out: http://lcgapp.cern.ch/project/CondDB/snapshot/performance.html
Excerpt:
Bind variable peeking. If an SQL query contains bind variables, the optimal execution plan may depend on the values of those variables. When the Oracle query optimizer chooses the execution plan for such a query, it may indeed look at the values of all bind variables involved: this is known as "bind variable peeking".
In summary, the execution plan used for a given SQL query cannot be predicted a priori because it depends on the presence and quality of statistics and on the values of bind variables used at the time the query was first executed (hard-parsed). As a consequence of this instability of execution plans, very different performances may be observed for the same SQL query. In COOL, this issue is addressed by adding Oracle hints to the queries, to make sure that the same (good) plan is used in all cases, even with unreliable statistics or unfavourable bind variables.
Edited by: Rodolfo Ferrari on Jun 3, 2009 9:40 PM

Query Rewrite (QSM-01263) and Views in Execution Plan

Hello!
I created a query rewrite enabled materialized view from a query, which contains only tables (no views). Query rewrite didn't work, so i checked the query with dbms_mview.explan_rewrite, which told my that my query contains references to views or dictionary tables. I checked my query again, but there are only tables, no views, no dictionary tables.
When I look in the execution plan of my query I see that the query optimizer generates views, I guess from my subquery (?). "A view definition was processed, either from a stored view...or as defined by steps...".
I suppose that's the reason why my query rewrite doesn't work. All my other mat views are working fine, so the usual parameters (query_rewrite_enabled, integrity, etc.) are set correctly.
Do you have any ideas how to get my query rewrite enabled work?
Thanks!

Modifying the query (potentially with hints) so that Oracle doesn't do the view transformation would be one option.

Explain SQL Query execution plan: Oracle

Dear Masters,
Kindly help me to understand execution plan for an SQL statement. I have following SQL execution plan for a query in system. How should I interpret it. I thank You in advace for your guidance.
SELECT STATEMENT ( Estimated Costs = 1.372.413 , Estimated #Rows = 0 )
       5 NESTED LOOPS
         ( Estim. Costs = 1.372.413 , Estim. #Rows = 3.125 )
         Estim. CPU-Costs = 55.798.978.498 Estim. IO-Costs = 1.366.482
           2 TABLE ACCESS BY INDEX ROWID MSEG
             ( Estim. Costs = 1.326.343 , Estim. #Rows = 76.717 )
             Estim. CPU-Costs = 55.429.596.575 Estim. IO-Costs = 1.320.451
             Filter Predicates
               1 INDEX RANGE SCAN MSEG~R
                 ( Estim. Costs = 89.322 , Estim. #Rows = 60.069.500 )
                 Search Columns: 1
                 Estim. CPU-Costs = 2.946.739.229 Estim. IO-Costs = 89.009
                 Access Predicates
           4 TABLE ACCESS BY INDEX ROWID MKPF
             ( Estim. Costs = 1 , Estim. #Rows = 1 )
             Estim. CPU-Costs = 4.815 Estim. IO-Costs = 1
             Filter Predicates
               3 INDEX UNIQUE SCAN MKPF~0
                 Search Columns: 3
                 Estim. CPU-Costs = 3.229 Estim. IO-Costs = 0
                 Access Predicates

Hi Panjak,
Yeahh, there's a huge unperformatic SQL statment, what I can see from this acces plan is:
1 DBO decided to start the query on index R on MSEG, using only part of the index (only one column) with no good uniqueness, accessing disk IO-Costs for this (60mi records), and expecting many interactions (loops) in memory to filter, see CPU-Costs.
So with the parameters you gave to SQL, they start in a very bad way.
2 After that program will access the MSEG commanded by what was found on First step, also with a huge loading from DB and filtering (another where criteria on MSEG fields, not found on index R), reducing the result set to 76.717 rows.
3/4 With this, program goes direct to primary key index on MKPF with direct access (optimized access) and follow to access database table MKPF.
5 At last will "loop" the result sets from MSEG and MKPF, mixing the tuplas generating the final result set.
Do you want to share your SQL, the parameters you are sending and code which generate it with us?
Regards, Fernando Da Ró

One query - one database - different execution plan for different users.

Hi everyone.
I've encountered one of the strangest things I've ever seen with Oracle. I'm hoping that someone else here has seen something like this before and solved it! On an 11g database I have a query that runs differently depending on which user runs it. If the owner of the tables or someone with the DBA role runs the query I get a perfect execution plan. If someone else runs it, I get a really bad execution plan - though the query still executes. So it almost seems like depending on who is running the query, the optimizer might not have access to the same statistics?? I'm really grasping at straws here - any help would be greatfully accepted!!!
Here is the query and the two plans for it...
On TASD as a General User (Bad execution plan) - CA17062 is USER
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.3.0
Connected as ca17062
SQL> explain plan for
select w.worker_id, w.worker_name
from worker_v                   w,
       worker_cost_centre_v       c
where w.worker_id = c.worker_id
   and c.effective_date <= trunc(sysdate)
   and c.expiration_date >= trunc(sysdate)
   and c.cost_centre = '100033'
   and pkg_taw_security.user_worker_access('CA17062',
                                           'TIMEKEEPER',
                                           w.worker_id,
                                           trunc(sysdate)) = 1
order by w.worker_name;
Explained
Executed in 0.234 seconds
PLAN_TABLE_OUTPUT
Plan hash value: 1726112176
| Id | Pid | Ord | Operation                      | Name                   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 |     |   8 | SELECT STATEMENT               |                        |    18 | 1800 |   606   (1)| 00:00:01 |
|   1 |   0 |   7 | SORT ORDER BY                 |                        |    18 | 1800 |   606   (1)| 00:00:01 |
|* 2 |   1 |   6 |   HASH JOIN                    |                        |    18 | 1800 |   605   (1)| 00:00:01 |
|   3 |   2 |   3 |    VIEW                        | WORKER_COST_CENTRE_V   |    18 |   558 |    19   (0)| 00:00:01 |
|* 4 |   3 |   2 |     TABLE ACCESS BY INDEX ROWID| WORKER_COST_CENTRE_TBL |    18 |   522 |    19   (0)| 00:00:01 |
|* 5 |   4 |   1 |      INDEX RANGE SCAN          | WORKER_CC_CC_IDX       |    29 |       |     3   (0)| 00:00:01 |
|* 6 |   2 |   5 |    VIEW                        | WORKER_V               |   161K|    10M|   584   (1)| 00:00:01 |
|   7 |   6 |   4 |     TABLE ACCESS FULL          | WORKER_TBL             |   161K| 3466K|   584   (1)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("W"."WORKER_ID"="C"."WORKER_ID")
   4 - filter("X"."EXPIRATION_DATE">=TRUNC(SYSDATE@!))
PLAN_TABLE_OUTPUT
   5 - access("X"."COST_CENTRE"='100033' AND "X"."EFFECTIVE_DATE"<=TRUNC(SYSDATE@!))
   6 - filter("PKG_TAW_SECURITY"."USER_WORKER_ACCESS"('CA17062','TIMEKEEPER',"W"."WORKER_ID",TRUN
              C(SYSDATE@!))=1)
About
- XPlan v1.2 by Adrian Billington (http://www.oracle-developer.net)
23 rows selected
Executed in 0.577 seconds
WORKER_ID WORKER_NAME
123703    FADDEN, CLAYTON
11131     HAHN, BRAD
33811     HALL, MAUREEN
53934     JANES, CATHERINE
Executed in 35.241 seconds
On TASD as the owner of the tables or as someone with the DBA role (Good Execution) - TAS is USER:
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.3.0
Connected as tas
SQL> explain plan for
select w.worker_id, w.worker_name
from worker_v                   w,
       worker_cost_centre_v       c
where w.worker_id = c.worker_id
   and c.effective_date <= trunc(sysdate)
   and c.expiration_date >= trunc(sysdate)
   and c.cost_centre = '100033'
   and pkg_taw_security.user_worker_access('CA17062',
                                           'TIMEKEEPER',
                                           w.worker_id,
                                           trunc(sysdate)) = 1
order by w.worker_name;
Explained
Executed in 0.203 seconds
PLAN_TABLE_OUTPUT
Plan hash value: 3435904055
| Id | Pid | Ord | Operation                      | Name                   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 |     |   8 | SELECT STATEMENT               |                        |    18 |   918 |    38   (3)| 00:00:01 |
|   1 |   0 |   7 | SORT ORDER BY                 |                        |    18 |   918 |    38   (3)| 00:00:01 |
|   2 |   1 |   6 |   NESTED LOOPS                 |                        |       |       |            |          |
|   3 |   2 |   4 |    NESTED LOOPS                |                        |    18 |   918 |    37   (0)| 00:00:01 |
|* 4 |   3 |   2 |     TABLE ACCESS BY INDEX ROWID| WORKER_COST_CENTRE_TBL |    18 |   522 |    19   (0)| 00:00:01 |
|* 5 |   4 |   1 |      INDEX RANGE SCAN          | WORKER_CC_CC_IDX       |    29 |       |     3   (0)| 00:00:01 |
|* 6 |   3 |   3 |     INDEX UNIQUE SCAN          | WORKER_PK              |     1 |       |     0   (0)| 00:00:01 |
|   7 |   2 |   5 |    TABLE ACCESS BY INDEX ROWID | WORKER_TBL             |     1 |    22 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("X"."EXPIRATION_DATE">=TRUNC(SYSDATE@!))
   5 - access("X"."COST_CENTRE"='100033' AND "X"."EFFECTIVE_DATE"<=TRUNC(SYSDATE@!))
PLAN_TABLE_OUTPUT
   6 - access("X"."WORKER_ID"="X"."WORKER_ID")
       filter("PKG_TAW_SECURITY"."USER_WORKER_ACCESS"('CA17062','TIMEKEEPER',"X"."WORKER_ID",TRUN
              C(SYSDATE@!))=1)
About
- XPlan v1.2 by Adrian Billington (http://www.oracle-developer.net)
23 rows selected
Executed in 0.624 seconds
WORKER_ID WORKER_NAME
123703    FADDEN, CLAYTON
11131     HAHN, BRAD
33811     HALL, MAUREEN
53934     JANES, CATHERINE
Executed in 1.307 seconds
THANKS!!!
Cory Aston

I reran the whole thing - with full declared view names and display_cursor. Here are the results...
On TASD as CA17062 (BAD EXECUTION PLAN)
SQL> set linesize 160
SQL> set serveroutput off
SQL>
SQL> select /*+ gather_plan_statistics */
2         w.worker_id, w.worker_name
3    from tas.worker_v                   w,
4         tas.worker_cost_centre_v       c
5   where w.worker_id = c.worker_id
6     and c.effective_date <= trunc(sysdate)
7     and c.expiration_date >= trunc(sysdate)
8     and c.cost_centre = '100033'
9     and tas_user.pkg_taw_security.user_worker_access('CA17062',
10                                             'TIMEKEEPER',
11                                             w.worker_id,
12                                             trunc(sysdate)) = 1
13   order by w.worker_name;
WORKER_ID WORKER_NAME
123703    FADDEN, CLAYTON
11131     HAHN, BRAD
33811     HALL, MAUREEN
53934     JANES, CATHERINE
SQL>
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID gs5vtgany8vbv, child number 3
select /*+ gather_plan_statistics */        w.worker_id, w.worker_name
from tas.worker_v                   w,        tas.worker_cost_centre_v
      c where w.worker_id = c.worker_id    and c.effective_date <=
trunc(sysdate)    and c.expiration_date >= trunc(sysdate)    and
c.cost_centre = '100033'    and tas_user.pkg_taw_security.user_worker_ac
cess('CA17062',
'TIMEKEEPER',                                            w.worker_id,
                                         trunc(sysdate)) = 1 order by
w.worker_name
Plan hash value: 1726112176
| Id | Operation                      | Name                   | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   0 | SELECT STATEMENT               |                        |      1 |        |      4 |00:00:18.52 |     947K|       |       |          |
|   1 | SORT ORDER BY                 |                        |      1 |      4 |      4 |00:00:18.52 |     947K| 2048 | 2048 | 2048 (0)|
|* 2 |   HASH JOIN                    |                        |      1 |      4 |      4 |00:00:15.84 |     947K| 1348K| 1348K| 791K (0)|
|   3 |    VIEW                        | WORKER_COST_CENTRE_V   |      1 |      4 |      4 |00:00:00.01 |      18 |       |       |          |
|* 4 |     TABLE ACCESS BY INDEX ROWID| WORKER_COST_CENTRE_TBL |      1 |      4 |      4 |00:00:00.01 |      18 |       |       |          |
|* 5 |      INDEX RANGE SCAN          | WORKER_CC_CC_IDX       |      1 |     29 |     21 |00:00:00.01 |       3 |       |       |          |
|* 6 |    VIEW                        | WORKER_V               |      1 |    161K|      4 |00:00:15.84 |     946K|       |       |          |
|   7 |     TABLE ACCESS FULL          | WORKER_TBL             |      1 |    161K|    160K|00:00:00.09 |    2135 |       |       |          |
Predicate Information (identified by operation id):
   2 - access("W"."WORKER_ID"="C"."WORKER_ID")
   4 - filter("X"."EXPIRATION_DATE">=TRUNC(SYSDATE@!))
   5 - access("X"."COST_CENTRE"='100033' AND "X"."EFFECTIVE_DATE"<=TRUNC(SYSDATE@!))
   6 - filter("PKG_TAW_SECURITY"."USER_WORKER_ACCESS"('CA17062','TIMEKEEPER',"W"."WORKER_ID",TRUNC(SYSDATE@!))=1)
Note
   - cardinality feedback used for this statement
39 rows selected.
SQL>
On TASD as TAS: (GOOD EXECUTION PLAN)
SQL> set serveroutput off
SQL>
SQL> select /*+ gather_plan_statistics */
2         w.worker_id, w.worker_name
3    from tas.worker_v                   w,
4         tas.worker_cost_centre_v       c
5   where w.worker_id = c.worker_id
6     and c.effective_date <= trunc(sysdate)
7     and c.expiration_date >= trunc(sysdate)
8     and c.cost_centre = '100033'
9     and tas_user.pkg_taw_security.user_worker_access('CA17062',
10                                             'TIMEKEEPER',
11                                             w.worker_id,
12                                             trunc(sysdate)) = 1
13   order by w.worker_name;
WORKER_ID WORKER_NAME
123703    FADDEN, CLAYTON
11131     HAHN, BRAD
33811     HALL, MAUREEN
53934     JANES, CATHERINE
SQL>
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID gs5vtgany8vbv, child number 1
select /*+ gather_plan_statistics */        w.worker_id, w.worker_name
from tas.worker_v                   w,        tas.worker_cost_centre_v
      c where w.worker_id = c.worker_id    and c.effective_date <=
trunc(sysdate)    and c.expiration_date >= trunc(sysdate)    and
c.cost_centre = '100033'    and tas_user.pkg_taw_security.user_worker_ac
cess('CA17062',
'TIMEKEEPER',                                            w.worker_id,
                                         trunc(sysdate)) = 1 order by
w.worker_name
Plan hash value: 3435904055
| Id | Operation                      | Name                   | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   0 | SELECT STATEMENT               |                        |      1 |        |      4 |00:00:00.01 |     185 |       |       |          |
|   1 | SORT ORDER BY                 |                        |      1 |      4 |      4 |00:00:00.01 |     185 | 2048 | 2048 | 2048 (0)|
|   2 |   NESTED LOOPS                 |                        |      1 |        |      4 |00:00:00.01 |     185 |       |       |          |
|   3 |    NESTED LOOPS                |                        |      1 |      4 |      4 |00:00:00.01 |     181 |       |       |          |
|* 4 |     TABLE ACCESS BY INDEX ROWID| WORKER_COST_CENTRE_TBL |      1 |      4 |      4 |00:00:00.01 |      18 |       |       |          |
|* 5 |      INDEX RANGE SCAN          | WORKER_CC_CC_IDX       |      1 |     29 |     21 |00:00:00.01 |       3 |       |       |          |
|* 6 |     INDEX UNIQUE SCAN          | WORKER_PK              |      4 |      1 |      4 |00:00:00.01 |     163 |       |       |          |
|   7 |    TABLE ACCESS BY INDEX ROWID | WORKER_TBL             |      4 |      1 |      4 |00:00:00.01 |       4 |       |       |          |
Predicate Information (identified by operation id):
   4 - filter("X"."EXPIRATION_DATE">=TRUNC(SYSDATE@!))
   5 - access("X"."COST_CENTRE"='100033' AND "X"."EFFECTIVE_DATE"<=TRUNC(SYSDATE@!))
   6 - access("X"."WORKER_ID"="X"."WORKER_ID")
       filter("PKG_TAW_SECURITY"."USER_WORKER_ACCESS"('CA17062','TIMEKEEPER',"X"."WORKER_ID",TRUNC(SYSDATE@!))=1)
Note
   - cardinality feedback used for this statement
39 rows selected.
SQL>

Question for SQL execution plan, strange..

HI, all
We meet a strange problem for a execution plan. First, we have a StoreProc, it runs around less than 20 secs. One day, it runs more than 5 mins (Execution plan 1). I checked all the index (fragmentation is low and Scan density is high), and re-run the update
statistics, but the performance still have no any improvement.
This is very strange for me, why the query becomes slow suddenly on one day (we will know the performance immedidately because it is a daily function, user will report to us if the performance is low, we only got complain today.)?
Finally, we tested in two ways.
1. We run the below update statistic command with one index - "update statistics dbo.PCMS_CARD_TRANS MGM_IDX_PCMS_TRANS_TIME_PROCESSING"
Result: It runs under 20 secs.
2. We create a new index - "MGM_IDX_Test_TRANS_TIME"
Result: It runs around 1 second, but I checked the execution plan (Execution plan 2) didn't change and the new index is not use for it...we feel strange again on it......
All information was included in below:
Table - PCMS_CARD_TRANS, PCMS_CARD_PROFILE.
VIEW - PCMS_V_CR_CARD_STOCK
StoreProc: PCMS_CardRoom_GetProcessedCardStock
Index: All zipped.

USE [PCMS]
GO
/****** Object: View [dbo].[PCMS_V_CR_CARD_STOCK] Script Date: 4/9/2014 4:30:54 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE VIEW [dbo].[PCMS_V_CR_CARD_STOCK]
AS
SELECT dbo.PCMS_CARD_PROFILE.CARD_ID, dbo.PCMS_CARD_PROFILE.TYPE_CODE, dbo.PCMS_CARD_PROFILE.COLOR_SET_CODE,
dbo.PCMS_CARD_PROFILE.VENDOR_ID, dbo.PCMS_CARD_PROFILE.CARD_STATUS, dbo.PCMS_CARD_PROFILE.LOC, dbo.PCMS_CARD_PROFILE.LOC_ID,
dbo.PCMS_CARD_PROFILE.LAST_TRANS_NO, dbo.PCMS_CARD_COLOR_SET_MASTER.COLOR_SET_DESC, dbo.PCMS_CARD_TYPE.TYPE_DESC,
dbo.PCMS_CARD_PROFILE.DECK_AMOUNT, dbo.PCMS_CARD_PROFILE.USAGE_TYPE, dbo.PCMS_CARD_PROFILE.STORAGE_ID,
dbo.PCMS_CARD_PROFILE.STORAGE, dbo.PCMS_CARD_TYPE.CARD_TYPE_GROUP
FROM dbo.PCMS_CARD_PROFILE INNER JOIN
dbo.PCMS_CARD_COLOR_SET_MASTER ON
dbo.PCMS_CARD_PROFILE.COLOR_SET_CODE = dbo.PCMS_CARD_COLOR_SET_MASTER.COLOR_SET_CODE INNER JOIN
dbo.PCMS_CARD_TYPE ON dbo.PCMS_CARD_PROFILE.TYPE_CODE = dbo.PCMS_CARD_TYPE.TYPE_CODE
WHERE (dbo.PCMS_CARD_COLOR_SET_MASTER.ENABLED = 1) AND (dbo.PCMS_CARD_TYPE.ENABLED = 1)
GO
EXEC sys.sp_addextendedproperty @name=N'MS_DiagramPane1', @value=N'[0E232FF0-B466-11cf-A24F-00AA00A3EFFF, 1.00]
Begin DesignProperties =
Begin PaneConfigurations =
Begin PaneConfiguration = 0
NumPanes = 4
Configuration = "(H (1[40] 4[20] 2[20] 3) )"
End
Begin PaneConfiguration = 1
NumPanes = 3
Configuration = "(H (1 [50] 4 [25] 3))"
End
Begin PaneConfiguration = 2
NumPanes = 3
Configuration = "(H (1 [50] 2 [25] 3))"
End
Begin PaneConfiguration = 3
NumPanes = 3
Configuration = "(H (4 [30] 2 [40] 3))"
End
Begin PaneConfiguration = 4
NumPanes = 2
Configuration = "(H (1 [56] 3))"
End
Begin PaneConfiguration = 5
NumPanes = 2
Configuration = "(H (2 [66] 3))"
End
Begin PaneConfiguration = 6
NumPanes = 2
Configuration = "(H (4 [50] 3))"
End
Begin PaneConfiguration = 7
NumPanes = 1
Configuration = "(V (3))"
End
Begin PaneConfiguration = 8
NumPanes = 3
Configuration = "(H (1[56] 4[18] 2) )"
End
Begin PaneConfiguration = 9
NumPanes = 2
Configuration = "(H (1 [75] 4))"
End
Begin PaneConfiguration = 10
NumPanes = 2
Configuration = "(H (1[66] 2) )"
End
Begin PaneConfiguration = 11
NumPanes = 2
Configuration = "(H (4 [60] 2))"
End
Begin PaneConfiguration = 12
NumPanes = 1
Configuration = "(H (1) )"
End
Begin PaneConfiguration = 13
NumPanes = 1
Configuration = "(V (4))"
End
Begin PaneConfiguration = 14
NumPanes = 1
Configuration = "(V (2))"
End
ActivePaneConfig = 0
End
Begin DiagramPane =
Begin Origin =
Top = 0
Left = 0
End
Begin Tables =
Begin Table = "PCMS_CARD_PROFILE"
Begin Extent =
Top = 6
Left = 38
Bottom = 265
Right = 212
End
DisplayFlags = 280
TopColumn = 0
End
Begin Table = "PCMS_CARD_COLOR_SET_MASTER"
Begin Extent =
Top = 6
Left = 250
Bottom = 121
Right = 426
End
DisplayFlags = 280
TopColumn = 0
End
Begin Table = "PCMS_CARD_TYPE"
Begin Extent =
Top = 6
Left = 464
Bottom = 121
Right = 637
End
DisplayFlags = 280
TopColumn = 0
End
End
End
Begin SQLPane =
End
Begin DataPane =
Begin ParameterDefaults = ""
End
Begin ColumnWidths = 13
Width = 284
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
End
End
Begin CriteriaPane =
Begin ColumnWidths = 11
Column = 1440
Alias = 900
Table = 1170
Output = 720
Append = 1400
NewValue = 1170
SortType = 1350
SortOrder = 1410
GroupBy = 1350
Filter = 1350
Or = 1350
Or = 1350
Or = 1350
End
End
End
' , @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=N'VIEW',@level1name=N'PCMS_V_CR_CARD_STOCK'
GO
EXEC sys.sp_addextendedproperty @name=N'MS_DiagramPaneCount', @value=1 , @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=N'VIEW',@level1name=N'PCMS_V_CR_CARD_STOCK'
GO
USE [PCMS]
GO
/****** Object: Index [IDX_PCMS_CARD_PROFILE_LOC] Script Date: 4/9/2014 4:39:51 PM ******/
CREATE NONCLUSTERED INDEX [IDX_PCMS_CARD_PROFILE_LOC] ON [dbo].[PCMS_CARD_PROFILE]
[LOC] ASC,
[LOC_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [IDX_PCMS_CARD_PROFILE_LOC_USAGE] Script Date: 4/9/2014 4:39:56 PM ******/
CREATE NONCLUSTERED INDEX [IDX_PCMS_CARD_PROFILE_LOC_USAGE] ON [dbo].[PCMS_CARD_PROFILE]
[LOC] ASC,
[USAGE_TYPE] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [IDX_PCMS_CARD_PROFILE_STORAGE] Script Date: 4/9/2014 4:40:01 PM ******/
CREATE NONCLUSTERED INDEX [IDX_PCMS_CARD_PROFILE_STORAGE] ON [dbo].[PCMS_CARD_PROFILE]
[STORAGE] ASC,
[STORAGE_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [MGM_IDX_PCMS_CARD_PROFILE_CARD_ID] Script Date: 4/9/2014 4:40:07 PM ******/
CREATE NONCLUSTERED INDEX [MGM_IDX_PCMS_CARD_PROFILE_CARD_ID] ON [dbo].[PCMS_CARD_PROFILE]
[CARD_ID] ASC,
[STORAGE] ASC,
[CARD_STATUS] ASC,
[LOC] ASC
INCLUDE ( [TYPE_CODE],
[COLOR_SET_CODE],
[LOC_ID]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [MGM_IDX_PCMS_CARD_PROFILE_CARD_STATUS] Script Date: 4/9/2014 4:40:12 PM ******/
CREATE NONCLUSTERED INDEX [MGM_IDX_PCMS_CARD_PROFILE_CARD_STATUS] ON [dbo].[PCMS_CARD_PROFILE]
[CARD_STATUS] ASC,
[VENDOR_ID] ASC,
[LOC] ASC
INCLUDE ( [CARD_ID],
[TYPE_CODE],
[COLOR_SET_CODE],
[USAGE_TYPE],
[DECK_AMOUNT],
[LAST_TRANS_NO]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [PK_PCMS_CARD_PROFILE] Script Date: 4/9/2014 4:40:18 PM ******/
ALTER TABLE [dbo].[PCMS_CARD_PROFILE] ADD CONSTRAINT [PK_PCMS_CARD_PROFILE] PRIMARY KEY CLUSTERED
[CARD_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO

Impact on undo_retention on plan of a query ..

HI All ,
Yesterday , we changed the undo_retention on our site and after the database reboot plan of one query changed . Except this we did't made any changes . So , I want to know is anybody here also faced the situation like this . Is really undo_retention changed the plan of the query ???
regds
Rahul

RahulG wrote:
Hi Experts ,
your views required here ....
What version of Oracle
What was the query
What was the plan before the restart
What was the plan after the restart
Use dbms_xplan (or similar) to format the plan, and don't forget to show the predicate section
Use the "code" tags (see footnote) to make the test readable.
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

Can Oracle make mistakes while making execution plan?

Env: Running Oracle DB 11g Rel 1.
Is it possible that oracle may use a different execution plan for the same query depending on the environment where its running due to any reason. I am running an oracle report 6i/10g which has started to take too long to run but at the same time runs better/faster while in sql*plus or toad. Report has nothing more than a query (like: no pl/sql, or triggers with sqls).
Is it also possible that depending on the different environment that runs the query or user profile, oracle might be using a different (may be bad) execution plan. Though at the same time database is same, no parameters are changed at run time explicitly by user or application. Base table of the query are all analyzed on regular basis.
Or, is it possible that at some point in time in the past, the same query had a bad plan and oracle kept using it from the cache (though I can't find any doc which would support this). I think that estimated plan might be bad based on past statistics but actual plan shouldn't be same bad as estimated. Does clearing the cache help?
Any insight or links to docs are appreciated.

ocp9i wrote:
Env: Running Oracle DB 11g Rel 1.
Is it possible that oracle may use a different execution plan for the same query depending on the environment where its running due to any reason. That is after all what cost based optimisation is.. taking the existing factors into consideration for determining the execution plans. Different factors may apply for future executions of that SQL - which could mean a different execution plan.
CBO does not mean that there will be a consistent-always-the-same execution plan for a SQL. It can and often will differ over time.
I am running an oracle report 6i/10g which has started to take too long to run but at the same time runs better/faster while in sql*plus or toad.You cannot evaluate performance using elapsed execution time - that is a flawed approach. The very same query can run a lot faster after the 1st execution as the 1st execution did expensive physical I/O from disk. Subsequent execution of that query will find the data in the buffer cache and instead of physical I/O, do cheaper logical I/O.
Also, reporting will typically include rendering. This is an added overhead that a plain SQL select in comparison will not have.
So you need to be careful in how you match the performance of a query like this. There's a lot more to it than meets the eye.
Or, is it possible that at some point in time in the past, the same query had a bad plan and oracle kept using it from the cache (though I can't find any doc which would support this). How do you know that this is a bad execution plan? How do you know that the report SQL uses a different execution plan than what your plain SQL select test does?
If the query is exactly the same (proper shared SQL), then there will be a single execution plan for that query. The 1st time that the query is hard parsed, this execution plan is created. Subsequent processes/sessions will use the very same execution plan (soft parsing) until that cursor is aged from the Shared Pool.
Thus if you are firing off an identical query via Reports and something like SQL*Plus.. chances are excellent that both is using the exact same execution plan.
Any insight or links to docs are appreciated.Suggest that you look at the Oracle Concepts guide. You'll find it via http://tahiti.oracle.com

Execution plan of a query changed

Similar Messages

Maybe you are looking for