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]

Similar Messages

Invoice Split for same customer but for different output types

Hi Gurus,
I have a requirement from the customers. A new output type has to be created with reference to the old type and for this output type a new driver program and SAP script was created with reference to the old one.They wants invoice split to be happened based on item level PO number. That was done successfully.
This invoice split logic was written in the billing routine RV60C901(Customized).
But now they came back with a issue that the invoice split should be done only if they use the new output type but not for the old one. That means for the same customer for one output type invoice split should be done based on item level po number and for one output type it should not. How can this be controlled for a particular
output type?
This output types will not be used in the billing routine as the split happens at the sales order level. Is there any configuration that allows split for a particular output type.
Please suggest me how to proceed???

Hi,
In the invoice split routine check if it is possible to find the output type making use of field symbols.
Just check in debug if the variable for output type is available as follows:-
(Program Name)variable name.
Regads,
Ankur Parab

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)

Same query at same time, but different execution plans from two schemas

Hi!
We just had some performance problems in our production system and I would like to ask for some advice from you.
We had a select-query that was run from USER1 on SCHEMA1, and it ran a table scan on a huge table.
Using session browser in TOAD I copied the Sql-statement, logged on SCHEMA1 and ran the same query. I got a different execution plan where I avoided the table scan.
So my question is:
How is it possible that the same query get different execution plans when running in two different schemas at the same time.
Some more information:
The user USER1 runs "alter session set current_schema=SCHEMA1;" when it logs on. Besides that it doesn't do anything so session parameter values are the same for USER1 and SCHEMA1.
SCHEMA1 is the schema owning the tables.
ALL_ROWS is used for both USER1 and SCHEMA1
Our database:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
PL/SQL Release 9.2.0.8.0 - Production
CORE 9.2.0.8.0 Production
TNS for Linux: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production
Anybody has some suggestions to why I experience different execution plan for the same query, run at the same time, but from different users?

Thanks for clarification of the schema structure.
What happens if instead of setting the current session schema to SCHEMA1, if you simply add the schema name to alle tables, views and other objects inside your select statement?
As in select * from schema1.dual;I know that this is not what you want eventually, but it might help to find any misleading objects.
Furthermore it is not clear what you meant with: "avoided a table scan".
Did you avoid a full table scan (FTS) or was the table completely removed from the execution plan?
Can you post both plans?
Edited by: Sven W. on Mar 30, 2010 5:27 PM

Explain plan is different for same query

Hi all,
I have a query, which basically selects some columns from a remote database view. The query is as follows:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
Now, i am working on two environments, one is production and other is development. Production environment has following specification:
1. Remotedb = Oracle9i, Linux OS
2. Database on which query is running = Oracle10g, Linux OS
Development environment has following specification:
1. Remotedb = Oracle10g, Windows OS
2. Database on which query is running = Oracle10g, Linux OS
Both databases in development and production environments are on different machines.
when i execute the above query on production, i see full table scans on both tables in execution plan(TOAD), but when i execute the query in development, i see that both remote database tables are using index.
Why am i getting different execution plans on both databases? is there is any difference of user rights/priviliges or there is a difference of statistics on both databases. I have checked the statistics for both tables on Production and Development databases, they are updated.
This issue is creating a performance disaster in our Production system. Any kind of help or knowledge sharing is appreciated.
Thank you and Best Regards.

select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
I assume that tab1.date is a date column. You are doing an implizit type conversion here. I think the way how those conversions are done, was changed from 9i to 10g. So that in 10g index usage is possible, while in 9i is not (not very sure about this).
Change your query to this:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = to_date('01-JAN-2003','DD-MON-YYYY')
and tab2.country_code = 'GB';
But compare and consider the results. Especially if the column tab1.date holds time values too.
and tab1.date = to_date('01-JAN-2003','DD-MON-YYYY')is not the same as
and to_char(tab1.date) = '01-JAN-2003'maybe you must change to
and tab1.date >= to_date('01-JAN-2003','DD-MON-YYYY')
and tab1.date < to_date('01-JAN-2003','DD-MON-YYYY') + 1Depends on your data.

Explain plan different for same query

Hi all,
I have a query, which basically selects some columns from a remote database view. The query is as follows:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
Now, i am working on two environments, one is production and other is development. Production environment has following specification:
1. Remotedb = Oracle9i, Linux OS
2. Database on which query is running = Oracle10g, Linux OS
Development environment has following specification:
1. Remotedb = Oracle10g, Windows OS
2. Database on which query is running = Oracle10g, Linux OS
Both databases in development and production environments are on different machines.
when i execute the above query on production, i see full table scans on both tables in execution plan(TOAD), but when i execute the query in development, i see that both remote database tables are using index.
Why am i getting different execution plans on both databases? is there is any difference of user rights/priviliges or there is a difference of statistics on both databases. I have checked the statistics for both tables on Production and Development databases, they are updated.
This issue is creating a performance disaster in our Production system. Any kind of help or knowledge sharing is appreciated.
Thank you and Best Regards.

We ran into a similar situation yesterday morning, though our implementation was easier than yours. Different plans in development and production though both systems were 10gR2 at the time. Production was doing a Merge Join Cartesian (!) instead of nested loop joins. Our DBA figured out that the production stats had been locked for some tables preventing stat refresh; she unlocked them and re-analyzed so which fixed our problem.
Of some interest was discovering that I got different execution plans from the same UPDATE via EXPLAIN PLAN and SQL*PLUS AUTOTRACE in development. Issue appears to have been bind peeking. Converting bind variables to constants yielded the AUTOTRACE plan, as did turning bind peeking off while using the bind variables. CURSOR_SHARING was set to EXACT too.
Message was edited by:
riedelme

Different query plans for same query on same DB

Hi,
HP-Ux
Oracle Database 10.2.0.4
We are experiencing a strange issue. One of our night batch process is taking invariably more time to execute. The process does not consume time at 1 particular query. Everyday we find a new query taking more time than previous execution.
Now, when we see the explain plan while the query is executing, we see NESTED LOOP SEMI (with improper index being used). At the same time if we take the query and see the explain plan seperately, we get HASH JOIN SEMI (with proper index being used). Also, if we execute this query with the values as in procedure, it finishes within mili seconds (as it should).
The tables and indexes are analyzed everyday before the process starts.
Can anybody explain, why the same query shows two different plans at the same time ?
Thanks a lot in advance :)

Aalap Sharma wrote:
HP-Ux
Oracle Database 10.2.0.4
We are experiencing a strange issue. One of our night batch process is taking invariably more time to execute. The process does not consume time at 1 particular query. Everyday we find a new query taking more time than previous execution.
Now, when we see the explain plan while the query is executing, we see NESTED LOOP SEMI (with improper index being used). At the same time if we take the query and see the explain plan seperately, we get HASH JOIN SEMI (with proper index being used). Also, if we execute this query with the values as in procedure, it finishes within mili seconds (as it should).
The tables and indexes are analyzed everyday before the process starts.
Can anybody explain, why the same query shows two different plans at the same time ?As already mentioned, you might hit typical issues in 10.2: The column workload based SIZE AUTO statistics gathering feature and/or bind variable peeking.
How do you analyze the tables and indexes before the process starts? Can you share the exact call with parameters?
Some ideas:
1. If your process is "new", then the column workload monitoring of the database might recognize the column usage pattern and generate histograms on some of your columns. It might take a while until the workload has been established so that all columns got histograms according to the workload (It needs a certain number of usages/executions before the workload is registered as relevant). Until then you might get different execution plans each time the statistics are refreshed due to new histograms being added.
2. If the default 10g statistics gathering job is active, it might gather different statistics during the night than your individual job that runs prior to the processing. This could be one possible explanation why you get different plans on the next day.
3. "Bind Variable Peeking" is possibly another issue you might run into. How do you test the query so that you get a different, well performing plan? Does your original statement use bind variables? Do you use literals to reproduce? Note that using EXPLAIN PLAN on statements involving bind variables can lie, since it doesn't perform bind variable peeking by default.
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/

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>

Explain Plan for same query

Same query is taking different times in two databses.
Both dababases are similar being refreshed from one.
Below are the the explain plan from both queries.
Can anything be conclusive from this information.
Second explain plan is for a faster execution.
SELECT STATEMENT ALL_ROWSCost: 245,393
18 PX COORDINATOR
17 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
16 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
15 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
14 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
13 HASH JOIN PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 15 Bytes: 129,220 Cardinality: 2,485
2 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 15 Bytes: 129,220 Cardinality: 2,485
1 TABLE ACCESS FULL TABLE myschema.team Cost: 15 Bytes: 129,220 Cardinality: 2,485
12 TABLE ACCESS BY LOCAL INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT myschema.mytable Cost: 18,117 Bytes: 4,777,136 Cardinality: 183,736
11 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT Cost: 198,125 Bytes: 300,959,928 Cardinality: 8,359,998
8 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
7 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT
6 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10001
5 TABLE ACCESS FULL TABLE myschema.dim Cost: 12 Bytes: 450 Cardinality: 45
10 PX PARTITION RANGE ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 38 Cardinality: 183,736 Partition #: 17
9 INDEX RANGE SCAN INDEX PARALLEL_COMBINED_WITH_PARENT myschema.IDX_TDATE_DC_FLAG Cost: 38 Cardinality: 183,736 Partition #: 17
SELECT STATEMENT CHOOSECost: 2,830
14 PX COORDINATOR
13 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
12 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
11 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
10 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
9 HASH JOIN BUFFERED PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 19 Bytes: 129,272 Cardinality: 2,486
2 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 19 Bytes: 129,272 Cardinality: 2,486
1 TABLE ACCESS FULL TABLE myschema.team Cost: 19 Bytes: 129,272 Cardinality: 2,486
8 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
7 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10001 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
6 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed #1 - #5
5 MAT_VIEW REWRITE ACCESS FULL MAT_VIEW REWRITE PARALLEL_COMBINED_WITH_PARENT myschema.matv_2 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed
Edited by: user610910 on Feb 13, 2009 5:12 AM

SELECT STATEMENT CHOOSE Cost: 2,830
14 PX COORDINATOR
13 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
       12 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
           11 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
         10 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
     9 HASH JOIN BUFFERED PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
             4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
        3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 19 Bytes: 129,272 Cardinality: 2,486
      2 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 19 Bytes: 129,272 Cardinality: 2,486
1 TABLE ACCESS FULL TABLE MYSCHEMA.TEAM Cost: 19 Bytes: 129,272 Cardinality: 2,486
8 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
     7 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10001 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
   6 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208    Partition #: 13 Partitions accessed #1 - #5
5 MAT_VIEW REWRITE ACCESS FULL MAT_VIEW REWRITE PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MATVW Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed #1 - #5
SELECT STATEMENT ALL_ROWSCost: 245,393
18 PX COORDINATOR
    17 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
      16 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
          15 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
            14 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
                   13 HASH JOIN PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
     3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 15 Bytes: 129,220 Cardinality: 2,485
         2 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 15 Bytes: 129,220 Cardinality: 2,485
             1 TABLE ACCESS FULL TABLE MYSCHEMA.TEAM Cost: 15 Bytes: 129,220 Cardinality: 2,485
12 TABLE ACCESS BY LOCAL INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MY_TABLE Cost: 18,117 Bytes: 4,777,136 Cardinality: 183,736
     11 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT Cost: 198,125 Bytes: 300,959,928 Cardinality: 8,359,998
    8 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
          7 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT
                   6 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10001
                      5 TABLE ACCESS FULL TABLE MYSCHEMA.DIM Cost: 12 Bytes: 450 Cardinality: 45
10 PX PARTITION RANGE ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 38 Cardinality: 183,736 Partition #: 17
           9 INDEX RANGE SCAN INDEX PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MY_IDX Cost: 38 Cardinality: 183,736 Partition #: 17 I think this one looks better.

How to fix different execution plan for different bind variable values?

Please find the below query. The execution plan is fine. The problem That I am facing is in some cases for different bind variable values execution plan gets changed and degrades performance. I have used 6 tables here and all of the tables have histogram on all columns. Database version is Oracle 10g and the value of method_opt is 'For all columns size auto'
SELECT l.LineNumber INTO :b0
FROM Lines l ,LineVersions lv ,Statuses s
WHERE (((((((((((l.serviceContractId=:b1 AND l.LineId<>:b2)
AND lv.LineId=l.LineId) AND lv.StatusId=s.StatusId)
AND s.Code IN ('EPR','ERE','EEP','ERP','PRP','PRD','AAC'))
AND NOT (s.CODE='AAC' AND lv.activeto<TO_DATE(:b3,:b4)))
AND lv.EquipmentDetailId=:b5) AND lv.RouteDetailId=:b6)
AND (lv.cargoDetailId=:b7 OR lv.cargoDetailId IN
(SELECT i_cd1.cargoDetailId
FROM CargoDetails i_cd1 ,CargoDetails i_cd2 ,CargoCommodities i_cc1 ,
CargoCommodities i_cc2 WHERE
((((((i_cd2.cargoDetailId=:b7 AND i_cd1.cargoDetailId<>:b7)
AND i_cd1.ServiceContractId=:b1) AND i_cd1.cargoTypeId=i_cd2.cargoTypeId)
AND i_cc1.cargoDetailId=i_cd1.cargoDetailId)
AND i_cc2.cargoDetailId=i_cd2.cargoDetailId)
AND i_cc1.commodityId=i_cc2.commodityId))))
AND ((lv.customerGroupId IS NULL AND :b11=0) OR lv.customerGroupId IN
(SELECT cgm1.customerGroupId
FROM CustomerGroupMembers cgm1 ,CustomerGroupMembers cgm2 ,CustomerGroups cg1
WHERE (((cgm2.customerGroupId=:b11 AND cgm1.customerNoId=cgm2.customerNoId)
AND cg1.CustomerGroupId=cgm1.CustomerGroupId)
AND cg1.ServiceContractId=l.ServiceContractId)))) AND lv.linetype='C')
AND ROWNUM=1)
After searching in several blogs I have found the below solutions. Please see it and let me know it is correct or not
Solution 1:-Get rid of histogram that does nothing but messes up execution plan by giving below command
exec dbms_stats.gather_table_stats(owner, tablename, method_opt => 'for all columns size 1', cascade => true);
As 6 tables are there I need to execute above command 6 times.
Solution 2:- Use stored outline. Not sure how to get the best execution plan.
I am looking for answers ASAP. Thanks in advance

As you have probably read, bind variables and histograms do not mix well.
Histograms suggest that you have skew in your data such that different values should get different plans
Bind variables exist so that SQL with different supplied values can be shared.
Mix the two together and at parse time with bind variable peeking you get plans for specific values shared for all values.
The solutions you have mentioned are the common approaches, together with a third - use literals not binds if you've got data skew (i.e. your histograms are justified) and don't want shared SQL.
I would have thought that getting rid of some of these histograms may be the right approach if you're none of your application SQL is using literals to benefit from them.
Can you confirm your version of Oracle.
Further reading:
http://jonathanlewis.wordpress.com/2009/05/06/philosophy-1/
http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/
http://richardfoote.wordpress.com/2008/01/04/dbms_stats-method_opt-default-behaviour-changed-in-10g-be-careful/

The same query but different plan?

Hi all
I don't understand why the same query but Oracle use different plan
explain plan for select far.id,fab.id
from agent_body fab
INNER JOIN agent_ref far ON (far.bodyid = fab.id)
WHERE fab.id=72449;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 18 | 2 (0)| 00:00:01 | | |
| 1 | NESTED LOOPS | | 1 | 18 | 2 (0)| 00:00:01 | | |
| 2 | PARTITION HASH SINGLE | | 1 | 6 | 1 (0)| 00:00:01 | 4 | 4 |
|* 3 | INDEX UNIQUE SCAN | PK_AGENT_BODY | 1 | 6 | 1 (0)| 00:00:01 | 4 | 4 |
| 4 | PARTITION HASH ALL | | 1 | 12 | 1 (0)| 00:00:01 | 1 | 4 |
| 5 | TABLE ACCESS BY LOCAL INDEX ROWID| AGENT_REF | 1 | 12 | 1 (0)| 00:00:01 | 1 | 4 |
|* 6 | INDEX RANGE SCAN | IXAGRAD | 1 | | 1 (0)| 00:00:01 | 1 | 4 |
Predicate Information (identified by operation id):
3 - access("FAB"."ID"=72449)
6 - access("FAR"."BODYID"=72449)
AND
explain plan for select far.id,fab.id
from agent_ref far,agent_body fab
where fab.id=far.bodyid and far.id=2219306;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 18 | 2 (0)| 00:00:01 | | |
| 1 | NESTED LOOPS | | 1 | 18 | 2 (0)| 00:00:01 | | |
| 2 | PARTITION HASH SINGLE | | 1 | 12 | 1 (0)| 00:00:01 | 3 | 3 |
| 3 | TABLE ACCESS BY LOCAL INDEX ROWID| AGENT_REF | 1 | 12 | 1 (0)| 00:00:01 | 3 | 3 |
|* 4 | INDEX UNIQUE SCAN | PK_AGENT_REF | 1 | | 1 (0)| 00:00:01 | 3 | 3 |
| 5 | PARTITION HASH ITERATOR | | 3348K| 19M| 1 (0)| 00:00:01 | KEY | KEY |
|* 6 | INDEX UNIQUE SCAN | PK_AGENT_BODY | 3348K| 19M| 1 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
4 - access("FAR"."ID"=2219306)
6 - access("FAB"."ID"="FAR"."BODYID")
Can anyone explain to me?
Thanks

user554265 wrote:
Hi all
I don't understand why the same query but Oracle use different plan
explain plan for select far.id,fab.id
from agent_body fab
INNER JOIN agent_ref far ON (far.bodyid = fab.id)
WHERE fab.id=72449;
AND
explain plan for select far.id,fab.id
from agent_ref far,agent_body fab
where fab.id=far.bodyid and far.id=2219306;
Can anyone explain to me?Perhaps this makes a difference...
WHERE fab.id=72449; and
and far.id=2219306; Essentially the two queries ARE different.

Best practice for a same query against 2 different tables

Hello all,
I want to extract info about tablespaces storage, both permanent and temporary. For that I use 2 different cursors that do exactly the same query but against a different table (dba_data_files and dba_temp_files).
CURSOR permanentTBSStorageInfo (tablespaceName VARCHAR2) IS
SELECT file_name, bytes, autoextensible, maxbytes, increment_by
FROM dba_data_files
WHERE tablespace_name = tablespaceName;
CURSOR temporaryTBSStorageInfo (tablespaceName VARCHAR2) IS
SELECT file_name, bytes, autoextensible, maxbytes, increment_by
FROM dba_temp_files
WHERE tablespace_name = tablespaceName;
First I'm bothered that I have to use 2 cursors to execute the same query against 2 different tables. Is there no another way around?
Then I fetch the results of this cursors in 2 different loops because I didn't find a way to dynamically call the cursors. I am looking for best practice here, knowing that I will do the same parsing against the results of the 2 cursors.
Thank you,

Hi
Check whether the below query is helpful or not
select      fs.tablespace_name "Tablespace",
     fs.tempspace "Temp MB",
     df.totalspace "Total MB"
     from
     (select
     tablespace_name,
     round(sum(bytes) / 1048576) TotalSpace
     from
     dba_data_files
     group by
     tablespace_name
     ) df,
     (select
     tablespace_name,
     round(sum(bytes) / 1048576) tempSpace
     from
     dba_temp_files
     group by
     tablespace_name
     ) fs
     where
     df.tablespace_name = fs.tablespace_name;
Thanks

Same query with different execution plan

Hello All,
I wonder why does sql server create different execution plan for these below queries ?
Thanks.

You can look at the expected query plan. Either visually in SSMS, or alternatively, you can run the query after the instruction SET SHOWPLAN_TEXT ON.
The Optimizer is the component of SQL Server that determines how the query is executed. It is cost based. It will assess different execution plans, estimate the cost of each of them and then select the cheapest. In this context, cheapest means the one with
the shortest runtime.
In your particular case, the estimation for the second query is, that scanning just a small part of the nonclustered index and then looking up the table data of the qualifying rows is the cheapest approach, because the estimated number of qualifying rows
is low.
In the first query, it estimated that looking up the many qualifying rows there would be too expensive, and that it would be cheaper to simply scan the entire clustered index, and simply filter out all unwanted rows. Note that the clustered index includes
the actual table data.
Gert-Jan

ICal has dropped a monthly event for the previous four months....... why did it disappear? and where is it? It was the same event but a different day each month.

iCal has dropped a monthly event for the previous four months....... why did it disappear? and where is it? It was the same event but a different day each month.

I installed this same digitizer in my T|X some weeks ago. Some discussion of my experience may be found in this Usenet posting and subsequent thread.
The stock digitizer in my T|X had always had some significant alignment issues (for which PowerDigi was able to compensate very nicely) and sensitivity which was uneven, but which usually required a heavier touch than I liked.
Eventually, it began to develop a “dead spot” near the upper left. My T|X was under warranty, so I probably ought to have sent it in to Palm to be repaired, but I wasn't willing to be without it for the required amount of time, and I've heard enough reports of other T|X owners getting unsatisfactory results this way. I'd heard enough good reports about the PDAPARTS.COm digitizer, that I decided that the only acceptable way to repair my T|X would be to install one of those.
After however many weeks it has been, I am still very pleased with the results. It continues to work flawlessly; it is much more sensitive, so it doesn't require nearly so heavy a touch, and I very much like the hard feel that it has, compared to the spongier feel of the stock digitizer.
My wife's T|X still has its stock digitizer, and it has so far not shown any of the same problems that mine did, or for which the T|X has become notorious, but the feel is noticeably inferior. She's content with it the way it is, but I think that if I were to ever buy another T|X for myself, I wouldn't wait for the stock digitizer to fail. The PDAPARTS.COM digitizer is simply superior in every imaginable way; and, in my opinion, a T|X with the PDAPARTS.COM digitizer installed is sufficiently superior to one with the stock digitizer (even if it isn't defective) to be very much worth the expense and trouble of installing it.
Post relates to: Palm TX

Same sqlID with different execution plan and Elapsed Time (s), Executions time

Hello All,
The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
17th Oct 18th Oct
221,808,602
21
2tc2d3u52rppt
213,170,100
72,495,618
9c8wqzz7kyf37
209,239,059
71,477,888
9c8wqzz7kyf37
139,331,777
1
7b0kzmf0pfpzn
144,813,295
1
0cqc3bxxd1yqy
102,045,818
1
8vp1ap3af0ma5
128,892,787
16,673,829
84cqfur5na6fg
89,485,065
1
5kk8nd3uzkw13
127,467,250
16,642,939
1uz87xssm312g
67,520,695
8,058,820
a9n705a9gfb71
104,490,582
12,443,376
a9n705a9gfb71
62,627,205
1
ctwjy8cs6vng2
101,677,382
15,147,771
3p8q3q0scmr2k
57,965,892
268,353
akp7vwtyfmuas
98,000,414
1
0ybdwg85v9v6m
57,519,802
53
1kn9bv63xvjtc
87,293,909
1
5kk8nd3uzkw13
52,690,398
0
9btkg0axsk114
77,786,274
74
1kn9bv63xvjtc
34,767,882
1,003
bdgma0tn8ajz9
Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
The other big difference is the average read time on two days
Tablespace IO Stats
17th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
947,766
59
4.24
4.86
185,084
11
2,887
6.42
UNDOTBS2
517,609
32
4.27
1.00
112,070
7
108
11.85
INDUS_MST_DATA01
288,994
18
8.63
8.38
52,541
3
23,490
7.45
INDUS_TRN_INDX01
223,581
14
11.50
2.03
59,882
4
533
4.26
TEMP
198,936
12
2.77
17.88
11,179
1
732
2.13
INDUS_LOG_DATA01
45,838
3
4.81
14.36
348
0
1
0.00
INDUS_TMP_DATA01
44,020
3
4.41
16.55
244
0
1,587
4.79
SYSAUX
19,373
1
19.81
1.05
14,489
1
0
0.00
INDUS_LOG_INDX01
17,559
1
4.75
1.96
2,837
0
2
0.00
SYSTEM
7,881
0
12.15
1.04
1,361
0
109
7.71
INDUS_TMP_INDX01
1,873
0
11.48
13.62
231
0
0
0.00
INDUS_MST_INDX01
256
0
13.09
1.04
194
0
2
10.00
UNDOTBS1
70
0
1.86
1.00
60
0
0
0.00
STG_DATA01
63
0
1.27
1.00
60
0
0
0.00
USERS
63
0
0.32
1.00
60
0
0
0.00
INDUS_LOB_DATA01
62
0
0.32
1.00
60
0
0
0.00
TS_AUDIT
62
0
0.48
1.00
60
0
0
0.00
18th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
980,283
91
1.40
4.74

The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
You wrote with different execution plan, I think, you saw plans. It is very difficult, you get old plan.
I think Execution plans is not changed in different days, if you not added index or ...
What say ADDM report about this script?
As you know, It is normally, different Elapsed Time for same statement in different day.
It is depend your database workload.
It think you must use SQL Access and SQl Tuning advisor for this script.
You can get solution for slow running problem.
Regards
Mahir M. Quluzade

Different execution plan for same query but for different condition value

Similar Messages

Maybe you are looking for