Different 'execution plans' for same sql in 10R2

DB=10.2.0.5
OS=RHEL 3
Im not sure of this, but seeing different plans for same SQL.
select sql_text from v$sqlarea where sql_id='92mb4z83fg4st'; <---TOP SQL from AWR
SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","LOGINSUCCESSFLG",
"ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE"
FROM "BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY";
SQL> set autotrace traceonly
SQL> SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","LOGINSUCCESSFLG",
"ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE"
FROM "BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY"; 2 3
1822203 rows selected.
Execution Plan
Plan hash value: 568996432
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1803K| 75M| 2919 (2)| 00:00:36 |
| 1 | TABLE ACCESS FULL| ENDUSERLOGINATTEMPTHISTORY | 1803K| 75M| 2919 (2)| 00:00:36 |
Statistics
0 recursive calls
0 db block gets
133793 consistent gets
0 physical reads
0 redo size
76637183 bytes sent via SQL*Net to client
1336772 bytes received via SQL*Net from client
121482 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1822203 rows processed
===================================== another plan ===============
SQL> select * from TABLE(dbms_xplan.display_awr('92mb4z83fg4st'));
15 rows selected.
Execution Plan
Plan hash value: 3015018810
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY_AWR |
Note
- rule based optimizer used (consider using cbo)
Statistics
24 recursive calls
24 db block gets
49 consistent gets
0 physical reads
0 redo size
1529 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
15 rows processed
=========second one shows only 15 rows...
Which one is correct ?

Understood, second plan is for self 'dbms_xplan'.
Anyhow I opened a new session where I did NOT on 'auto-trace'. but plan is somewhat than the original.
SQL> /
PLAN_TABLE_OUTPUT
SQL_ID 92mb4z83fg4st
SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","
LOGINSUCCESSFLG","ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE" FROM
"BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY"
Plan hash value: 568996432
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | | | 2919 (100)| |
| 1 | TABLE ACCESS FULL| ENDUSERLOGINATTEMPTHISTORY | 1803K| 75M| 2919 (2)| 00:00:36 |
15 rows selected.
I am just wondering, which plan is the accurate and which I need to believe ?

Similar Messages

  • 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]

  • 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/

  • Different execution plans for the same sql

    Hi,
    Im testing our new 10gR2 database on Linux and I can't understand why the same query use different plan.
    Here are the details.
    Table name: invoice_detail
    Records: About 10,670,900
    Columns:
    No
    seq (the primary key is No+Seq). Each invoices contains +/- 10 invoice_details.
    category ( <- 10 different values )
    State ( <- 3 different values )
    Basically, I have an index on the primary key and another index on Category + State.
    My request:
    select *
    from invoice_detail
    where no=123456 <- Best index to use
    and state <> 'CANCEL'
    and category = 'INVOICE'
    If i run this query from Toad or sql+, that's fine.
    The same query (i'm watching it from EM) executed via Forms use the category+state index.
    When I first import the database, the last thing I do is to run DBMS_STATS.GATHER_DATABASE_STATS.
    At this point, Forms use the right index.
    The day after (after the database has been analyzed with the predefined job via EM) Forms use the wrong index.
    I re-analyzed everything with exec DBMS_STATS.GATHER_DATABASE_STATS but the problem is still there.
    Thanks in advance

    I'm already using bind variables.
    I changed the "Estimated Percentage" to 100% in "Gather Optimizer Statistics Default Options" and now it seems to use the correct index. I'm stressed because I dont understand why it chooses different plan for the same sql.
    Actually, my users test the migration 1 day after I load all the data (drop schema-create schema-load data-analyze database) and at this point everythings go fine. After the second analyze of the database, the DB choose the wrong indexes.
    I really cannot migrate until I understand why it happens.
    Any ideas?
    TIA

  • Different execution plans for the same SQL query

    Good afternoon,
    My customer is sending an SQL query that goes slower after some time.
    He has verified the exection plan, and this seems to change after some time.
    At first (when the database has just been restarted), it looks like this:
    Rows Row Source Operation
    3 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE1> PARTITION: 1 1
    22 NESTED LOOPS
    3 VIEW
    3 MINUS
    14215 SORT UNIQUE
    14215 NESTED LOOPS
    14215 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
    14215 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE2> PARTITION: 1 1
    14215 INDEX UNIQUE SCAN <INDEX2> (object id 26024)
    14212 SORT UNIQUE
    14212 REMOTE
    18 INDEX RANGE SCAN <INDEX1> (object id 25911)
    After a while, this becomes:
    Rows Row Source Operation
    8 NESTED LOOPS
    14218 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
    8 VIEW
    113744 MINUS
    202151524 SORT UNIQUE
    14218 NESTED LOOPS
    14218 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
    14218 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE2> PARTITION: 1 1
    14218 INDEX UNIQUE SCAN <INDEX_2> (object id 26024)
    202037780 SORT UNIQUE
    14210 REMOTE
    At regular intervals a "coalesce" of the <INDEX2> is scheduled.
    Do you have any idea what might cause this different plans? (it's heavily impacting performance, because the second execution plan takes 5 times more time)
    Thanks
    Dominique
    Edited by: scampsd on May 17, 2011 1:42 PM

    scampsd wrote:
    Good afternoon,
    My customer is sending an SQL query that goes slower after some time.
    He has verified the exection plan, and this seems to change after some time.
    At first (when the database has just been restarted), it looks like this:
    At regular intervals a "coalesce" of the <INDEX2> is scheduled.
    Do you have any idea what might cause this different plans? (it's heavily impacting performance, because the second execution plan takes 5 times more time)Something on your system is changing. Unfortunately if finding out what were easy you would have done it already
    You have isolated a couple of things. What happends of you disable the index maintenance?
    It is odd that performance as you described it degrands merely because of time the database has been up

  • Different plan for same SQL in different version of DB

    Hello,
    At client side i have upgraded database from 11.2.0.1.0 to 11.2.0.2.0 . and after that i am facing performance related issue.
    is this happen because of up-gradation ?
    for testing i have created two different version db (i.e 11.2.0.1.0 to 11.2.0.2.0 ) with same volume and same parameter. now i am executing same query then i am getting different plan.
    please help me to resolve this issue..

    Which issue? CBO is upgraded with every new release! So, yes, execution plans may change because of that.
    And sensible DBA's first upgrade a test database.
    Also no statement is to be seen.
    Secondly, you can always set optimizer_features_enable to the lower release.
    Finally, please look up 'upgradation' in an English dictionary. You won't find it!!!
    Sybrand Bakker
    Senior Oracle DBA

  • 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>

  • Why two different explain plan for same objects?

    Believe or not there are two different databases, one for processing and one for reporting, plan is show different for same query. Table structure and indexes are same. It's 11G
    Thanks
    Good explain plan .. works fine..
    Plan
    SELECT STATEMENT  ALL_ROWSCost: 12,775  Bytes: 184  Cardinality: 1                                                                        
         27 SORT UNIQUE  Cost: 12,775  Bytes: 184  Cardinality: 1                                                                   
              26 NESTED LOOPS                                                              
                   24 NESTED LOOPS  Cost: 12,774  Bytes: 184  Cardinality: 1                                                         
                        22 HASH JOIN  Cost: 12,772  Bytes: 178  Cardinality: 1                                                    
                             20 NESTED LOOPS SEMI  Cost: 30  Bytes: 166  Cardinality: 1                                               
                                  17 NESTED LOOPS  Cost: 19  Bytes: 140  Cardinality: 1                                          
                                       14 NESTED LOOPS OUTER  Cost: 16  Bytes: 84  Cardinality: 1                                     
                                            11 VIEW DSSADM. Cost: 14  Bytes: 37  Cardinality: 1                                
                                                 10 NESTED LOOPS                           
                                                      8 NESTED LOOPS  Cost: 14  Bytes: 103  Cardinality: 1                      
                                                           6 NESTED LOOPS  Cost: 13  Bytes: 87  Cardinality: 1                 
                                                                3 INLIST ITERATOR            
                                                                     2 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOB_FAMILY_TBL Cost: 10  Bytes: 51  Cardinality: 1       
                                                                          1 INDEX RANGE SCAN INDEX DSSODS.DRV_PS_JOB_FAMILY_TBL_CL_SETID Cost: 9  Cardinality: 1 
                                                                5 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_JOBCODE Cost: 3  Bytes: 36  Cardinality: 1            
                                                                     4 INDEX RANGE SCAN INDEX DSSADM.STAN_JB_FN_IDX Cost: 2  Cardinality: 1       
                                                           7 INDEX UNIQUE SCAN INDEX (UNIQUE) DSSODS.DRV_PS_JOBCODE_TBL_SEQ_KEY_RPT Cost: 0  Cardinality: 1                 
                                                      9 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOBCODE_TBL_RPT Cost: 1  Bytes: 16  Cardinality: 1                      
                                            13 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PSXLATITEM_RPT Cost: 2  Bytes: 47  Cardinality: 1                                
                                                 12 INDEX RANGE SCAN INDEX DSSODS.PK_DRV_RIXLATITEM_RPT Cost: 1  Cardinality: 1                           
                                       16 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_JOBCODE Cost: 3  Bytes: 56  Cardinality: 1                                     
                                            15 INDEX RANGE SCAN INDEX DSSADM.DIM_JOBCODE_EXPDT1 Cost: 2  Cardinality: 1                                
                                  19 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOB_RPT Cost: 11  Bytes: 438,906  Cardinality: 16,881                                          
                                       18 INDEX RANGE SCAN INDEX DSSODS.DRV_PS_JOB_JOBCODE_RPT Cost: 2  Cardinality: 8                                     
                             21 INDEX FAST FULL SCAN INDEX (UNIQUE) DSSADM.Z_PK_JOBCODE_PROMPT_TBL Cost: 12,699  Bytes: 66,790,236  Cardinality: 5,565,853                                               
                        23 INDEX RANGE SCAN INDEX DSSADM.DIM_PERSON_EMPL_RCD_SEQ_KEY Cost: 1  Cardinality: 1                                                    
                   25 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_PERSON_EMPL_RCD Cost: 2  Bytes: 6  Cardinality: 1                                                         This bad plan ... show merge join cartesian and full table ..
    Plan
    SELECT STATEMENT  ALL_ROWSCost: 3,585  Bytes: 237  Cardinality: 1                                                              
         26 SORT UNIQUE  Cost: 3,585  Bytes: 237  Cardinality: 1                                                         
              25 NESTED LOOPS SEMI  Cost: 3,584  Bytes: 237  Cardinality: 1                                                    
                   22 NESTED LOOPS  Cost: 3,573  Bytes: 211  Cardinality: 1                                               
                        20 MERGE JOIN CARTESIAN  Cost: 2,864  Bytes: 70,446  Cardinality: 354                                          
                             17 NESTED LOOPS                                     
                                  15 NESTED LOOPS  Cost: 51  Bytes: 191  Cardinality: 1                                
                                       13 NESTED LOOPS OUTER  Cost: 50  Bytes: 180  Cardinality: 1                           
                                            10 HASH JOIN  Cost: 48  Bytes: 133  Cardinality: 1                      
                                                 6 NESTED LOOPS                 
                                                      4 NESTED LOOPS  Cost: 38  Bytes: 656  Cardinality: 8            
                                                           2 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DIM_JOBCODE Cost: 14  Bytes: 448  Cardinality: 8       
                                                                1 INDEX RANGE SCAN INDEX REPORT2.STAN_PROM_JB_IDX Cost: 6  Cardinality: 95 
                                                           3 INDEX RANGE SCAN INDEX REPORT2.SETID_JC_IDX Cost: 2  Cardinality: 1       
                                                      5 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DIM_JOBCODE Cost: 3  Bytes: 26  Cardinality: 1            
                                                 9 INLIST ITERATOR                 
                                                      8 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOB_FAMILY_TBL Cost: 10  Bytes: 51  Cardinality: 1            
                                                           7 INDEX RANGE SCAN INDEX REPORT2.DRV_PS_JOB_FAMILY_TBL_CL_SETID Cost: 9  Cardinality: 1       
                                            12 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PSXLATITEM_RPT Cost: 2  Bytes: 47  Cardinality: 1                      
                                                 11 INDEX RANGE SCAN INDEX REPORT2.PK_DRV_RIXLATITEM_RPT Cost: 1  Cardinality: 1                 
                                       14 INDEX UNIQUE SCAN INDEX (UNIQUE) REPORT2.DRV_PS_JOBCODE_TBL_SEQ_KEY_RPT Cost: 0  Cardinality: 1                           
                                  16 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOBCODE_TBL_RPT Cost: 1  Bytes: 11  Cardinality: 1                                
                             19 BUFFER SORT  Cost: 2,863  Bytes: 4,295,552  Cardinality: 536,944                                     
                                  18 TABLE ACCESS FULL TABLE REPORT2.DIM_PERSON_EMPL_RCD Cost: 2,813  Bytes: 4,295,552  Cardinality: 536,944                                
                        21 INDEX RANGE SCAN INDEX (UNIQUE) REPORT2.Z_PK_JOBCODE_PROMPT_TBL Cost: 2  Bytes: 12  Cardinality: 1                                          
                   24 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOB_RPT Cost: 11  Bytes: 1,349,920  Cardinality: 51,920                                               
                        23 INDEX RANGE SCAN INDEX REPORT2.DRV_PS_JOB_JOBCODE_RPT Cost: 2  Cardinality: 8                                          

    user550024 wrote:
    I am really surprise that the stat for good sql are little old. I just computed the states of bad sql so they are uptodate..
    There is something terribly wrong..Not necessarily. Just using the default stats collection I've seen a few cases of things suddenly going wrong. As the data increases, it gets closer to an edge case where the inadequacy of the statistics convinces the optimizer to do a wrong plan. To fix, I could just go into dbconsole, set the stats back to a time when they worked, and locked them. In most cases it's definitely better to figure out what is really going on, though, to give the optimizer better information to work with. Aside from the value of learning how to do it, for some cases it's not so simple. Also, many think the default settings of the database statistic collection may be wrong in general (in 10.2.x, at least). So much depends on your application and data that you can't make too many generalizations. You have to look at the evidence and figure it out. There is still a steep learning curve for the tools to look at the evidence. People are here to help with that.
    Most of the time it works better than a dumb rule based optimizer, but at the cost of a few situations where people are smarter than computers. It's taken a lot of years to get to this point.

  • 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/

  • Execution of TestStand-Sequence in LabVIEW via TS-API: Different Execution times for same sequence

    Hello Forum-Members,
    I have a problem concerning the execution of an TestStand-Sequence in LabVIEW. I have created a VI that offers the ability to choose a TestStand-Sequence-File and then executes the sequence using the TestStand-API. The implementation is based on an example in C++-Application found following this link:
    http://forums.ni.com/t5/NI-TestStand/Unreleased-references-using-engine-API-in-C/m-p/2927314#M46034
    The implementation works quite solid in case the VI is executed the first time. The VI processes the chosen sequence in a acceptable duration.
    But in case the execution is started a second time, the execution of the sequence takes ca. 30sec more than in the first case.
    Until now I have not found a solution and hope someones got a hint concerning this problem...
    I am using LabVIEW 2013 and TestStand 2013.
    I have attached my own VI, a sample sequence with a small sample VI, so you can reproduce the problem.
    Kind regards,
    TobiKi
    Solved!
    Go to Solution.
    Attachments:
    Exe-TestStand-Sequence.vi ‏25 KB
    Sequenz.vi ‏8 KB
    Test-Sequenz.seq ‏5 KB

    Hi Norbert,
    first thanks for your answer.
    What would be a reasonable way to replace the "Execution.WaitForEndEx"? My first idea is to get the respective thread of the execution and use the "Thread.WaitForEnd".
    To clarify my problem:
    The execution of the sequence itself takes longer time and so the execution of the calling VI. I have attached pictures of the log file of the first and second execution.
    Further I don't get any dialog popups during the shutdown of TestStand. (I have activated the "ReportObjectLeaks" using the "DebugOptions") While developing the attached VI I've gotten several popups. But these popups disappeared after closing all references.
    Maybe you have another hint how to locate the problem.
    TobiKi
    Attachments:
    FirstExecution_20-08-2014.png ‏16 KB
    SecondExecution_20-08-2014.png ‏16 KB

  • Multiple Executions Plans for the same SQL statement

    Dear experts,
    awrsqrpt.sql is showing multiple executions plans for a single SQL statement. How is it possible that one SQL statement will have multiple Executions Plans within the same AWR report.
    Below is the awrsqrpt's output for your reference.
    WORKLOAD REPOSITORY SQL Report
    Snapshot Period Summary
    DB Name         DB Id    Instance     Inst Num Release     RAC Host
    TESTDB          2157605839 TESTDB1               1 10.2.0.3.0  YES testhost1
                  Snap Id      Snap Time      Sessions Curs/Sess
    Begin Snap:     32541 11-Oct-08 21:00:13       248     141.1
      End Snap:     32542 11-Oct-08 21:15:06       245     143.4
       Elapsed:               14.88 (mins)
       DB Time:               12.18 (mins)
    SQL Summary                            DB/Inst: TESTDB/TESTDB1  Snaps: 32541-32542
                    Elapsed
       SQL Id      Time (ms)
    51szt7b736bmg     25,131
    Module: SQL*Plus
    UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(ACCT_DR_BAL,
    0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND TEST_ACC_NB = ACCT_ACC_NB(+)) WHERE
    TEST_BATCH_DT = (:B1 )
    SQL ID: 51szt7b736bmg                  DB/Inst: TESTDB/TESTDB1  Snaps: 32541-32542
    -> 1st Capture and Last Capture Snap IDs
       refer to Snapshot IDs witin the snapshot range
    -> UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(AC...
        Plan Hash           Total Elapsed                 1st Capture   Last Capture
    #   Value                    Time(ms)    Executions       Snap ID        Snap ID
    1   2960830398                 25,131             1         32542          32542
    2   3834848140                      0             0         32542          32542
    Plan 1(PHV: 2960830398)
    Plan Statistics                        DB/Inst: TESTDB/TESTDB1  Snaps: 32541-32542
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
    Stat Name                                Statement   Per Execution % Snap
    Elapsed Time (ms)                            25,131       25,130.7     3.4
    CPU Time (ms)                                23,270       23,270.2     3.9
    Executions                                        1            N/A     N/A
    Buffer Gets                               2,626,166    2,626,166.0    14.6
    Disk Reads                                      305          305.0     0.3
    Parse Calls                                       1            1.0     0.0
    Rows                                        371,735      371,735.0     N/A
    User I/O Wait Time (ms)                         564            N/A     N/A
    Cluster Wait Time (ms)                            0            N/A     N/A
    Application Wait Time (ms)                        0            N/A     N/A
    Concurrency Wait Time (ms)                        0            N/A     N/A
    Invalidations                                     0            N/A     N/A
    Version Count                                     2            N/A     N/A
    Sharable Mem(KB)                                 26            N/A     N/A
    Execution Plan
    | Id  | Operation                    | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | UPDATE STATEMENT             |                 |       |       |  1110 (100)|          |
    |   1 |  UPDATE                      | TEST            |       |       |            |          |
    |   2 |   TABLE ACCESS FULL          | TEST            |   116K|  2740K|  1110   (2)| 00:00:14 |
    |   3 |   TABLE ACCESS BY INDEX ROWID| ACCT            |     1 |    26 |     5   (0)| 00:00:01 |
    |   4 |    INDEX RANGE SCAN          | ACCT_DT_ACC_IDX |     1 |       |     4   (0)| 00:00:01 |
    Plan 2(PHV: 3834848140)
    Plan Statistics                        DB/Inst: TESTDB/TESTDB1  Snaps: 32541-32542
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
    Stat Name                                Statement   Per Execution % Snap
    Elapsed Time (ms)                                 0            N/A     0.0
    CPU Time (ms)                                     0            N/A     0.0
    Executions                                        0            N/A     N/A
    Buffer Gets                                       0            N/A     0.0
    Disk Reads                                        0            N/A     0.0
    Parse Calls                                       0            N/A     0.0
    Rows                                              0            N/A     N/A
    User I/O Wait Time (ms)                           0            N/A     N/A
    Cluster Wait Time (ms)                            0            N/A     N/A
    Application Wait Time (ms)                        0            N/A     N/A
    Concurrency Wait Time (ms)                        0            N/A     N/A
    Invalidations                                     0            N/A     N/A
    Version Count                                     2            N/A     N/A
    Sharable Mem(KB)                                 26            N/A     N/A
    Execution Plan
    | Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | UPDATE STATEMENT             |              |       |       |     2 (100)|          |
    |   1 |  UPDATE                      | TEST         |       |       |            |          |
    |   2 |   TABLE ACCESS BY INDEX ROWID| TEST         |     1 |    28 |     2   (0)| 00:00:01 |
    |   3 |    INDEX RANGE SCAN          | TEST_DT_IND  |     1 |       |     1   (0)| 00:00:01 |
    |   4 |   TABLE ACCESS BY INDEX ROWID| ACCT         |     1 |    26 |     4   (0)| 00:00:01 |
    |   5 |    INDEX RANGE SCAN          | INDX_ACCT_DT |     1 |       |     3   (0)| 00:00:01 |
    Full SQL Text
    SQL ID       SQL Text
    51szt7b736bm UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL, 0) +
                  NVL(ACCT_DR_BAL, 0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND PB
                 RN_ACC_NB = ACCT_ACC_NB(+)) WHERE TEST_BATCH_DT = (:B1 )Your input is highly appreciated.
    Thanks for taking your time in answering my question.
    Regards

    Oracle Lover3 wrote:
    Dear experts,
    awrsqrpt.sql is showing multiple executions plans for a single SQL statement. How is it possible that one SQL statement will have multiple Executions Plans within the same AWR report.If you're using bind variables and you've histograms on your columns which can be created by default in 10g due to the "SIZE AUTO" default "method_opt" parameter of DBMS_STATS.GATHER__STATS it is quite normal that you get different execution plans for the same SQL statement. Depending on the values passed when the statement is hard parsed (this feature is called "bind variable peeking" and enabled by default since 9i) an execution plan is determined and re-used for all further executions of the same "shared" SQL statement.
    If now your statement ages out of the shared pool or is invalidated due to some DDL or statistics gathering activity it will be re-parsed and again the values passed in that particular moment will determine the execution plan. If you have skewed data distribution and a histogram in place that reflects that skewness you might get different execution plans depending on the actual values used.
    Since this "flip-flop" behaviour can sometimes be counter-productive if you're unlucky and the values used to hard parse the statement leading to a plan that is unsuitable for the majority of values used afterwards, 11g introduced the "adaptive" cursor sharing that attempts to detect such a situation and can automatically re-evaluate the execution plan of the statement.
    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/

  • 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

  • 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

  • Tool to find the execution plan of a SQL query

    Hi,
    I new to Oracle. I come from the SQL Server world.
    I would like to know what tool(s) should I use to identify the execution plan for a SQL statement and to see if a query is missing indices.
    Thanks,
    Paul

    Use SQL*PLUS.
    SQL> select dummy from dual;
    D
    X
    SQL> set autotrace on explain
    SQL> r
      1* select dummy from dual
    D
    X
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=2)
       1    0   TABLE ACCESS (FULL) OF 'DUAL' (TABLE) (Cost=2 Card=1 Bytes
              =2)
    SQL> set autot off
    SQL> explain plan for select dummy from dual;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 1157671242
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
    8 rows selected.
    SQL> disconnect
    Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
    With the Partitioning, Oracle Label Security, OLAP and Data Mining options
    SQL>

  • 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

Maybe you are looking for

  • Hard drive size for macbook pro

    I have filled my hard drive storage and I would like to increase the storage size.  What is the maximum size of drive I can go up to?  I believe today that I have a 320 GB storage device.

  • File ownership changes on deploy changes

    In my web server 7.0 environment everything installed with owner:group of webservd:webservd. This is fine. I am using Cgistub and executing all cgi scripts by a different system user. I need to do this to execute ssh, because I don't want to give web

  • How to parse the message received into  WF_WS_JMS_IN queue agent from web service

    Hi, I am using Service Invocation Framework to raise business event and call the external web services.  The web service is called and we got the synchronous response back to EBS into a inbound agent WF_WS_JMS_IN. Once the message is received here th

  • Why can't Premiere Pro CC start?

    It never moves past the loading screen and just crashes. It's run flawlessly in the past, just this night it's being difficult. I've tried rebooting Creative Cloud by logging in and out - and of course the PC. I've also tried running it in compabilit

  • Click to Call not showing in Chrome Extensions

    Hi Guys I have downloaded and installed skype but the extension is not showing in chrome. I uninstalled and reinstalled and still not working. I have windows 8.1 but am not using the metro tiles, just skype for desktop. James JAMES MATHERS LICENCED P