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.

Similar Messages

  • 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

  • Oracle SQL Developer O/P and Toad O/P is Different for Same QUERY.

    Hi,
    can any one calrify me why i'm getting different result when i run the same QUERY in Oracle Developer and TOAD.
    When i Ran a Query in TOAD i could see Null&Data in a column called Customer_Category but when i Ran the same Query in Oracle SQL Developer i'm getting all Null N i couldnt see any data in the column.
    i have not performed any DDL r DML statement, just i got the Query and i Ran it in TOAD & Oracle SQL Developer.
    I found that the OUT PUT is different for perticular column.
    Thanks in Advance....

    > I found that the OUT PUT is different for perticular column.
    The RENDERING of data from Oracle (or any other server such as a POP3 server, web server, etc) IS DONE BY THE CLIENT.
    So to repeat - RENDERING IS DONE BY THE CLIENT.
    If one client selects to display the output received from the server differently than another client, it is a CLIENT ISSUE.
    It is not a server issue. It is not a SQL issue. It is not a PL/SQL issue.
    In other words, wrong forum for this question. You have a pure client side rendering problem which has absolutely nothing to do with SQL and/or PL/SQL.

  • Why can the explain plan be different from 2 exact set of structures

    hi,
    i have from a view some base tables let's say A , B, C & D
    this query is running very slow . so from the same database , i created tables A1 , B1, C1,& D1 from the above tables.
    i created some new indexes on A1 to D1 tables and the results returned to me is fast.
    i did an exlain plan
    so i drop the indexes on the original A to D table and created the new indexes as per A1 to D1 and analyzed them. and i also did an explain plan
    but the query is still running slow and also the explain plan is different to the one from A1 to D1 (the one that running fast)
    pls help me to understand how/why can this happen ?
    tks & rdgs

    hi,
    precisely i could have been providing insufficient information but i am too inexperienced to be able to give you the required information and i am also not very sure where i could get the info so that you all can advise me further.
    but this is from the user_tables , the only difference i see is that
    under LOGGING table A to E is 'YES'
    TABLE_NAME     TABLESPACE_NAME     PCT_FREE     LOGGING     BACKED_UP     NUM_ROWS     BLOCKS     CACHE     TABLE_LOCK     PARTITIONED
    A1          OWNER1          10          NO          N     37332          883         N     ENABLED     NO
    B1          OWNER1          10          NO          N     43458          861         N     ENABLED     NO
    C1          OWNER1          10          NO          N     823828          7826         N     ENABLED     NO
    D1          OWNER1          10          NO          N     881176          14646         N     ENABLED     NO
    E1          OWNER1          10          NO          N     18868          223         N     ENABLED     NO
    A          OWNER1          10          YES          N     37040          880         N     ENABLED     NO
    B          OWNER1          10          YES          N     43386          880         N     ENABLED     NO
    C          OWNER1          10          YES          N     823820          7684         N     ENABLED     NO
    D          OWNER1          50          YES          N     880948          26624         N     ENABLED     NO
    E          OWNER1          10          YES          N     18690          244         N     ENABLED     NOtks & rdgs

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

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

  • Differenet Explain Plan for Same Query

    DB Version : 11.2.0.3
    OS Version : AIX 6
    I have two Queries ( The Difference between Them Only 940 and 584 ) When I Generate Explain Plan Different Output Why ? Why CPU time is Different Each Time
    First Query Statement  :
    INSERT INTO TempSearchResult (t_aid,
                                  t_umidl,
                                  t_umidh,
                                  X_CREA_DATE_TIME_MESG)
       SELECT z.aid,
              z.mesg_s_umidl,
              z.mesg_s_umidh,
              z.mesg_crea_date_time
         FROM (  SELECT m.aid,
                        m.mesg_s_umidl,
                        m.mesg_s_umidh,
                        m.mesg_crea_date_time
                   FROM RSMESG_ESIDE m
                  WHERE 1 = 1
                        AND m.mesg_crea_date_time BETWEEN TO_DATE (
                                                             '20120131 10:00:00',
                                                             'YYYYMMDD HH24:MI:SS')
                                                      AND TO_DATE (
                                                             '20120131 13:00:00',
                                                             'YYYYMMDD HH24:MI:SS')
                        AND m.mesg_frmt_name = 'Swift'
                        AND m.mesg_sender_x1 = 'SOGEFRPPXXX'
                        AND m.mesg_nature = 'FINANCIAL_MSG'
                        AND m.mesg_type LIKE '950'
               ORDER BY mesg_crea_date_time) z
        WHERE ROWNUM <= 5000
    Explain Plan for First Query :
    PLAN_TABLE_OUTPUT
    Plan hash value: 3901722890
    | Id  | Operation                                 | Name              | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | INSERT STATEMENT                          |                   |  2866 |   134K|   197   (3)| 00:00:03 |       |       |
    |   1 |  LOAD TABLE CONVENTIONAL                  | TEMPSEARCHRESULT  |       |       |            |          |       |       |
    |*  2 |   COUNT STOPKEY                           |                   |       |       |            |          |       |       |
    |   3 |    VIEW                                   |                   |  2866 |   134K|   197   (3)| 00:00:03 |       |       |
    |*  4 |     SORT ORDER BY STOPKEY                 |                   |  2866 |   333K|   197   (3)| 00:00:03 |       |       |
    |   5 |      NESTED LOOPS                         |                   |  2866 |   333K|   196   (2)| 00:00:03 |       |       |
    PLAN_TABLE_OUTPUT
    |   6 |       NESTED LOOPS                        |                   |  1419 |   148K|   196   (2)| 00:00:03 |       |       |
    |*  7 |        HASH JOIN                          |                   |  1419 |   141K|   196   (2)| 00:00:03 |       |       |
    |   8 |         NESTED LOOPS                      |                   |    91 |  1911 |     2   (0)| 00:00:01 |       |       |
    |   9 |          TABLE ACCESS BY INDEX ROWID      | SUSER             |     1 |    10 |     1   (0)| 00:00:01 |       |       |
    |* 10 |           INDEX UNIQUE SCAN               | IX_SUSER          |     1 |       |     0   (0)| 00:00:01 |       |       |
    |* 11 |          INDEX FULL SCAN                  | PK_SUNITUSERGROUP |    91 |  1001 |     1   (0)| 00:00:01 |       |       |
    |  12 |         PARTITION RANGE SINGLE            |                   |  1450 |   114K|   193   (2)| 00:00:03 |     2 |     2 |
    |* 13 |          TABLE ACCESS BY LOCAL INDEX ROWID| RMESG             |  1450 |   114K|   193   (2)| 00:00:03 |     2 |     2 |
    |* 14 |           INDEX SKIP SCAN                 | IX_RMESG          |   415 |       |    14  (15)| 00:00:01 |     2 |     2 |
    |* 15 |        INDEX UNIQUE SCAN                  | PK_SMSGUSERGROUP  |     1 |     5 |     0   (0)| 00:00:01 |       |       |
    |* 16 |       INDEX UNIQUE SCAN                   | PK_SBICUSERGROUP  |     2 |    24 |     0   (0)| 00:00:01 |       |       |
    PLAN_TABLE_OUTPUT
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
       2 - filter(ROWNUM<=5000)
       4 - filter(ROWNUM<=5000)
       7 - access("X_INST0_UNIT_NAME"="UNIT")
      10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
      11 - access("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
           filter("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
    PLAN_TABLE_OUTPUT
      13 - filter("RMESG"."MESG_SENDER_X1"='SOGEFRPPXXX' AND "RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND
                  "RMESG"."MESG_FRMT_NAME"='Swift')
      14 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-31 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "RMESG"."MESG_TYPE"='950' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-31 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
           filter("RMESG"."MESG_TYPE"='950')
      15 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
      16 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
    40 rows selected.
    Second query
    INSERT INTO TempSearchResult (t_aid,
                                  t_umidl,
                                  t_umidh,
                                  X_CREA_DATE_TIME_MESG)
       SELECT z.aid,
              z.mesg_s_umidl,
              z.mesg_s_umidh,
              z.mesg_crea_date_time
         FROM (  SELECT  m.aid,
                        m.mesg_s_umidl,
                        m.mesg_s_umidh,
                        m.mesg_crea_date_time
                   FROM RSMESG_ESIDE m
                  WHERE 1 = 1
                        AND m.mesg_crea_date_time BETWEEN TO_DATE (
                                                             '20120117 10:00:00',
                                                             'YYYYMMDD HH24:MI:SS')
                                                      AND TO_DATE (
                                                             '20120117 13:00:00',
                                                             'YYYYMMDD HH24:MI:SS')
                        AND m.mesg_frmt_name = 'Swift'
                        AND m.mesg_sender_x1 = 'SOGEFRPPGSS'
                        AND m.mesg_nature = 'FINANCIAL_MSG'
                        AND m.mesg_type LIKE '548'
               ORDER BY mesg_crea_date_time) z
        WHERE ROWNUM <= 5000
    Explain Plan For Second Query :
    PLAN_TABLE_OUTPUT
    Plan hash value: 4106071428
    | Id  | Operation                                  | Name              | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | INSERT STATEMENT                           |                   |  1073 | 51504 |       |  2622   (1)| 00:00:32 |       |       |
    |   1 |  LOAD TABLE CONVENTIONAL                   | TEMPSEARCHRESULT  |       |       |       |            |          |       |       |
    |*  2 |   COUNT STOPKEY                            |                   |       |       |       |            |          |       |       |
    |   3 |    VIEW                                    |                   |  1073 | 51504 |       |  2622   (1)| 00:00:32 |       |       |
    |*  4 |     SORT ORDER BY STOPKEY                  |                   |  1073 |   124K|       |  2622   (1)| 00:00:32 |       |       |
    |   5 |      NESTED LOOPS                          |                   |  1073 |   124K|       |  2621   (1)| 00:00:32 |       |       |
    PLAN_TABLE_OUTPUT
    |   6 |       NESTED LOOPS                         |                   |   531 | 56817 |       |  2621   (1)| 00:00:32 |       |       |
    |   7 |        NESTED LOOPS                        |                   |   531 | 54162 |       |  2621   (1)| 00:00:32 |       |       |
    |   8 |         NESTED LOOPS                       |                   |   543 | 49413 |       |  2621   (1)| 00:00:32 |       |       |
    |   9 |          TABLE ACCESS BY INDEX ROWID       | SUSER             |     1 |    10 |       |     1   (0)| 00:00:01 |       |       |
    |* 10 |           INDEX UNIQUE SCAN                | IX_SUSER          |     1 |       |       |     0   (0)| 00:00:01 |       |       |
    |  11 |          PARTITION RANGE SINGLE            |                   |   543 | 43983 |       |  2621   (1)| 00:00:32 |     2 |     2 |
    |* 12 |           TABLE ACCESS BY LOCAL INDEX ROWID| RMESG             |   543 | 43983 |       |  2621   (1)| 00:00:32 |     2 |     2 |
    |  13 |            BITMAP CONVERSION TO ROWIDS     |                   |       |       |       |            |          |       |       |
    |  14 |             BITMAP AND                     |                   |       |       |       |            |          |       |       |
    |  15 |              BITMAP CONVERSION FROM ROWIDS |                   |       |       |       |            |          |       |       |
    |* 16 |               INDEX RANGE SCAN             | IX_SENDER         | 25070 |       |       |   894   (1)| 00:00:11 |     2 |     2 |
    PLAN_TABLE_OUTPUT
    |  17 |              BITMAP CONVERSION FROM ROWIDS |                   |       |       |       |            |          |       |       |
    |  18 |               SORT ORDER BY                |                   |       |       |   408K|            |          |       |       |
    |* 19 |                INDEX RANGE SCAN            | IX_RMESG          | 25070 |       |       |  1405   (1)| 00:00:17 |     2 |     2 |
    |* 20 |         INDEX UNIQUE SCAN                  | PK_SUNITUSERGROUP |     1 |    11 |       |     0   (0)| 00:00:01 |       |       |
    |* 21 |        INDEX UNIQUE SCAN                   | PK_SMSGUSERGROUP  |     1 |     5 |       |     0   (0)| 00:00:01 |       |       |
    |* 22 |       INDEX UNIQUE SCAN                    | PK_SBICUSERGROUP  |     2 |    24 |       |     0   (0)| 00:00:01 |       |       |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       2 - filter(ROWNUM<=5000)
       4 - filter(ROWNUM<=5000)
      10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
      12 - filter("RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND "RMESG"."MESG_FRMT_NAME"='Swift')
      16 - access("RMESG"."MESG_SENDER_X1"='SOGEFRPPGSS')
      19 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
           filter("RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd
                  hh24:mi:ss') AND "RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss'))
      20 - access("X_INST0_UNIT_NAME"="UNIT" AND "SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
      21 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
    PLAN_TABLE_OUTPUT
      22 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
    45 rows selected.
    Table Structure TEMPSEARCHRESULT
    CREATE GLOBAL TEMPORARY TABLE TEMPSEARCHRESULT
      T_AID                  NUMBER(3),
      T_UMIDL                NUMBER(10),
      T_UMIDH                NUMBER(10),
      X_CREA_DATE_TIME_MESG  DATE
    ON COMMIT PRESERVE ROWS
    NOCACHE;
    CREATE INDEX SIDE.TEMP_SEARCH_INDEX ON SIDE.TEMPSEARCHRESULT
    (T_AID, T_UMIDL, T_UMIDH, X_CREA_DATE_TIME_MESG);

    Again Thank you For your amazing Answer.
    For indexes it's a balance. Check this query which is Simple
    Select * from RMESGI generated Explain Plan for it to see effect of indexes .
    PLAN_TABLE_OUTPUT
    Plan hash value: 1686435785
    | Id  | Operation           | Name  | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |       |    11M|  8920M|   376K  (1)| 01:15:20 |      |        |
    |   1 |  PARTITION RANGE ALL|       |    11M|  8920M|   376K  (1)| 01:15:20 |    1 |     12 |
    |   2 |   TABLE ACCESS FULL | RMESG |    11M|  8920M|   376K  (1)| 01:15:20 |    1 |     12 |
    ---------------------------------------------------------------------------------------------1:15:20 For table access and Full Scan Also , I generate new Indexes on the table like the following
    CREATE TABLE RMESG(
            aid NUMBER(3) NOT NULL,
            mesg_s_umidl NUMBER(10) NOT NULL,
            mesg_s_umidh NUMBER(10) NOT NULL,
            mesg_validation_requested CHAR(18) NOT NULL,
            mesg_validation_passed CHAR(18) NOT NULL,
            mesg_class CHAR(16) NOT NULL,
            mesg_is_text_readonly NUMBER(1) NOT NULL,
            mesg_is_delete_inhibited NUMBER(1) NOT NULL,
            mesg_is_text_modified NUMBER(1) NOT NULL,
            mesg_is_partial NUMBER(1) NOT NULL,
            mesg_crea_mpfn_name CHAR(24) NOT NULL,
            mesg_crea_rp_name CHAR(24) NOT NULL,
            mesg_crea_oper_nickname CHAR(151) NOT NULL,
            mesg_crea_date_time DATE NOT NULL,
            mesg_mod_oper_nickname CHAR(151) NOT NULL,
            mesg_mod_date_time DATE NOT NULL,
            mesg_frmt_name VARCHAR2(17) NOT NULL,
            mesg_nature CHAR(14) NOT NULL,
            mesg_sender_x1 CHAR(11) NOT NULL,
            mesg_sender_corr_type VARCHAR2(24) NOT NULL,
            mesg_uumid VARCHAR2(50) NOT NULL,
            mesg_uumid_suffix NUMBER(10) NOT NULL,
            x_own_lt CHAR(8) NOT NULL,
            x_inst0_unit_name VARCHAR2(32) default 'NONE' NOT NULL,
            x_category CHAR(1) NOT NULL,
            archived NUMBER(1) NOT NULL,
            restored NUMBER(1) NOT NULL,
            mesg_related_s_umid CHAR(16) NULL,
            mesg_status CHAR(12) NULL,
            mesg_crea_appl_serv_name CHAR(24) NULL,
            mesg_verf_oper_nickname CHAR(151) NULL,
            mesg_data_last NUMBER(10) NULL,
            mesg_token NUMBER(10) NULL,
            mesg_batch_reference VARCHAR2(46) NULL,
            mesg_cas_sender_reference VARCHAR2(40) NULL,
            mesg_cas_target_rp_name VARCHAR2(20) NULL,
            mesg_ccy_amount VARCHAR2(501) NULL,
            mesg_copy_service_id VARCHAR2(4) NULL,
            mesg_data_keyword1 VARCHAR2(80) NULL,
            mesg_data_keyword2 VARCHAR2(80) NULL,
            mesg_data_keyword3 VARCHAR2(80) NULL,
            mesg_delv_overdue_warn_req NUMBER(1) NULL,
            mesg_fin_ccy_amount VARCHAR2(24) NULL,
            mesg_fin_value_date CHAR(6) NULL,
            mesg_is_live NUMBER(1) NULL,
            mesg_is_retrieved NUMBER(1) NULL,
            mesg_mesg_user_group VARCHAR2(24) NULL,
            mesg_network_appl_ind CHAR(3) NULL,
            mesg_network_delv_notif_req NUMBER(1) NULL,
            mesg_network_obso_period NUMBER(10) NULL,
            mesg_network_priority CHAR(12) NULL,
            mesg_possible_dup_creation VARCHAR2(8) NULL,
            mesg_receiver_alia_name VARCHAR2(32) NULL,
            mesg_receiver_swift_address CHAR(12) NULL,
            mesg_recovery_accept_info VARCHAR2(80) NULL,
            mesg_rel_trn_ref VARCHAR2(80) NULL,
            mesg_release_info VARCHAR2(32) NULL,
            mesg_security_iapp_name VARCHAR2(80) NULL,
            mesg_security_required NUMBER(1) NULL,
            mesg_sender_x2 VARCHAR2(21) NULL,
            mesg_sender_x3 VARCHAR2(21) NULL,
            mesg_sender_x4 VARCHAR2(21) NULL,
            mesg_sender_branch_info VARCHAR2(71) NULL,
            mesg_sender_city_name VARCHAR2(36) NULL,
            mesg_sender_ctry_code VARCHAR2(3) NULL,
            mesg_sender_ctry_name VARCHAR2(71) NULL,
            mesg_sender_institution_name VARCHAR2(106) NULL,
            mesg_sender_location VARCHAR2(106) NULL,
            mesg_sender_swift_address CHAR(12) NULL,
            mesg_sub_format VARCHAR2(6) NULL,
            mesg_syntax_table_ver VARCHAR2(8) NULL,
            mesg_template_name VARCHAR2(32) NULL,
            mesg_trn_ref VARCHAR2(16) NULL,
            mesg_type CHAR(3) NULL,
            mesg_user_issued_as_pde NUMBER(1) NULL,
            mesg_user_priority_code CHAR(4) NULL,
            mesg_user_reference_text VARCHAR2(30) NULL,
            mesg_zz41_is_possible_dup NUMBER(1) NULL,
            x_fin_ccy CHAR(3) NULL,
            x_fin_amount NUMBER(21,4) NULL,
            x_fin_value_date DATE NULL,
            x_fin_ocmt_ccy CHAR(3) NULL,
            x_fin_ocmt_amount NUMBER(21,4) NULL,
            x_receiver_x1 CHAR(11) NULL,
            x_receiver_x2 VARCHAR2(21) NULL,
            x_receiver_x3 VARCHAR2(21) NULL,
            x_receiver_x4 VARCHAR2(21) NULL,
            last_update DATE NULL,
            set_id NUMBER(10) NULL,
            mesg_requestor_dn VARCHAR2(101) NULL,
            mesg_service VARCHAR2(31) NULL,
            mesg_request_type VARCHAR2(31) NULL,
            mesg_identifier VARCHAR2(31) NULL,
            mesg_xml_query_ref1 VARCHAR2(101) NULL,
            mesg_xml_query_ref2 VARCHAR2(101) NULL,
            mesg_xml_query_ref3 VARCHAR2(101) NULL,
            mesg_appl_sender_reference VARCHAR2(51) NULL,
            mesg_payload_type VARCHAR2(31) NULL,
            mesg_sign_digest_reference VARCHAR2(41) NULL,
            mesg_sign_digest_value VARCHAR2(51) NULL,
            mesg_use_pki_signature NUMBER(1) NULL
    PARTITION BY RANGE(MESG_CREA_DATE_TIME) (
        PARTITION SIDE_MIN VALUES LESS THAN (TO_DATE(20000101, 'YYYYMMDD')) TABLESPACE TBS_SIDEDB_DA_01);
    CREATE UNIQUE INDEX SIDE.IX_PK_RMESG on SIDE.RMESG (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) LOCAL;
    ALTER TABLE SIDE.RMESG ADD CONSTRAINT IX_PK_RMESG PRIMARY KEY (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) USING INDEX SIDE.IX_PK_RMESG;
    CREATE INDEX SIDE.ix_rmesg_cassender ON SIDE.rmesg (MESG_CAS_SENDER_REFERENCE) LOCAL;
    CREATE INDEX SIDE.ix_rmesg_creationdate ON SIDE.rmesg (MESG_CREA_DATE_TIME) LOCAL;
    CREATE INDEX SIDE.ix_rmesg_trnref ON SIDE.rmesg (MESG_TRN_REF) LOCAL;
    CREATE INDEX SIDE.ix_rmesg_uumid ON SIDE.rmesg (MESG_UUMID, MESG_UUMID_SUFFIX) LOCAL;
    CREATE INDEX SIDE.IX_UNIT_NAME_RMESG on RMESG(mesg_crea_date_time,X_INST0_UNIT_NAME) LOCAL;
    CREATE INDEX SIDE.IX_RMESG on RMESG(mesg_crea_date_time ,mesg_type,x_fin_ccy) LOCAL;
    CREATE INDEX SIDE.IX_NAME_FORMAT_TYPE_RMESG on RMESG(mesg_frmt_name,mesg_sub_format,mesg_type,mesg_crea_date_time ) LOCAL;same Explain Plan Same Result .
    I always remember TOM Quote "full scans are not evil, indexes are not good"
    Which Mean Something Wrong Goes with Indexes , the partition depend on MESG_CREA_DATE_TIME Column I create Index for this column but same explain plan Appear every time. With Same Time.
    Thank you
    Osama

  • Explain plan for same query in three databases

    Hi,
    We have three databases dev, uat and test, all have same init parameters and almost same data. We are running a query which runs long on dev and on uat and test it runs very fast, the explain plan on uat and test shows a cost of around 4000 but on dev the cost is 20000. Statistics were collected on three instances 2 days ago and the objects are also same.
    My question is what else should I look for this optimizer behaviour? the database version is 10.2.0.3.
    Please help.
    Thanks
    Clin

    user627471 wrote:
    Hi,
    We have three databases dev, uat and test, all have same init parameters and almost same data. We are running a query which runs long on dev and on uat and test it runs very fast, the explain plan on uat and test shows a cost of around 4000 but on dev the cost is 20000. Statistics were collected on three instances 2 days ago and the objects are also same.
    My question is what else should I look for this optimizer behaviour? the database version is 10.2.0.3.
    Please help.
    Thanks
    Clinpost both EXPLAIN PLAN here

  • 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 results for same query on different servers

    1. database being converted from 7.3.4 to 9.2
    2. query is executed on both servers
    3. different results!
    The tables and data are the same, and indexes are setup on new server. EXPLAIN PLAN was run on both but with (predictably) widely different results.
    I know, not much detail here, but has anyone ever ran into anything like this?
    Thanks,
    Pat

    Folks,
    Here is the relevant information for this problem. The attributes have been changed for confidentiality. If you need any other information let me know.
    Thanks,
    Pat
    Query:
    SELECT
    one,two,three,four,a.five,six,seven,
    a.eight,a.nine,
    to_char(ten,'99999.99'),to_char(eleven,'99999.99'),
    to_char(twelve,'99999.99'),to_char(thirteen,'99999.99'),
    fourteen,fifteen,sixteen,seventeen,eighteen,
    nineteen,twenty,twentyone
    FROM
    table1 a,
    table2 b
    WHERE
    a.five = b.five
    AND one = 'X'
    AND six = ' '
    AND three != 12345
    AND three IN
    (SELECT DISTINCT
    three
    FROM table3
    WHERE
    one = 'X'
    AND twentytwo = 'XYZ'
    AND twentythree != 0
    AND twentyfour != 0
    AND twentyfive = 'Y'
    AND (a.five IN
    (SELECT DISTINCT
    five
    FROM table1
    WHERE
    one = 'X'
    AND three IN (12345)
    Table1:
    one          varchar2(1)     not null     PK
    two          varchar2(20)     not null     PK
    three          number(5)     not null     PK
    four          number(2)     not null     PK
    five          number(6)     not null     PK
    six          varchar2(4)     not null     PK
    seven          number(4)     not null
    eight          varchar2(8)     not null
    nine          date          not null
    ten          number(7,2)
    eleven     number(7,2)
    twelve     number(7,2)
    thirteen     number(7,2)
    Table2:
    five          number(6)     not null     PK
    fourteen     varchar2(5)     not null
    fifteen     varchar2(5)     not null
    sixteen     varchar2(2)     not null
    seventeen     varchar2(35)     not null
    eighteen     varchar2(4)     not null
    nineteen     varchar2(2)
    twenty     varchar2(1)
    twentyone     number(6)
    Table3:
    one          varchar2(1)     not null     PK
    twentytwo     varchar2(12)     not null     PK
    two          varchar2(20)     not null     PK
    three          number(5)     not null     PK
    four          number(2)     not null     PK
    twentysix     number(2)     not null     PK
    twentyfive     varchar2(1)     not null
    nine          date          not null
    twentythree     number(13,8)     not null
    twentyfour     number(12,8)     not null
    twentyseven     varchar2(1)     not null
    eight          varchar2(8)     not null
    Explain - Oracle9i (default, with CBO):
    SELECT STATEMENT
    RECURSIVE EXECUTION SYS_LE_3_0
    RECURSIVE EXECUTION SYS_LE_3_1
    TEMP TABLE TRANSFORMATION
    HASH JOIN
    HASH JOIN
    HASH JOIN
    TABLE ACCESS FULL SYS_TEMP_0FD9D6603_AB874A
    TABLE ACCESS BY INDEX ROWID TABLE1
    BITMAP CONVERSION TO ROWIDS
    BITMAP AND
    BITMAP MERGE
    BITMAP KEY ITERATION
    TABLE ACCESS FULL SYS_TEMP_0FD9D6603_AB874A
    BITMAP CONVERSION FROM ROWIDS
    INDEX RANGE SCAN TABLE1INDEX03
    BITMAP MERGE
    BITMAP KEY ITERATION
    TABLE ACCESS FULL SYS_TEMP_0FD9D6602_AB874A
    BITMAP CONVERSION FROM ROWIDS
    INDEX RANGE SCAN TABLE1INDEX04
    TABLE ACCESS FULL SYS_TEMP_0FD9D6602_AB874A
    TABLE ACCESS FULL TABLE2
    Query results - Oracle9i (with CBO):
    X|A | 1| 0| 22| | 1|08-MAR-02|XYZ | | 24.00| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|B | 2| 1| 22| | 7|04-DEC-01|XYZ | | 3.25| 8.00| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|C | 3| 1| 22| | 1|14-AUG-02|XYZ | | 10.35| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|D | 4| 1| 22| | 6|11-JUL-02|XYZ | | .00| 13.90| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    (approximately 4550 rows returned)
    Explain - Oracle9i (ALTER SESSION SET OPTIMIZER_METHOD=RULE;):
    SELECT STATEMENT
    MERGE JOIN
    SORT JOIN
    NESTED LOOPS
    NESTED LOOPS
    VIEW VW_NSO_1
    SORT UNIQUE
    TABLE ACCESS BY INDEX ROWID TABLE3
    INDEX RANGE SCAN TABLE3INDEXPK
    TABLE ACCESS BY INDEX ROWID TABLE1
    INDEX RANGE SCAN TABLE1INDEX03
    TABLE ACCESS BY INDEX ROWID TABLE2
    INDEX UNIQUE SCAN TABLE2INDEXPK
    SORT JOIN
    VIEW VW_NSO_2
    SORT UNIQUE
    TABLE ACCESS BY INDEX ROWID TABLE1
    INDEX RANGE SCAN TABLE1INDEX03
    Explain - Oracle 7.3.4:
    SELECT STATEMENT
    MERGE JOIN
    SORT JOIN
    NESTED LOOPS
    NESTED LOOPS
    VIEW
    SORT UNIQUE
    TABLE ACCESS BY ROWID TABLE3
    INDEX RANGE SCAN TABLE3INDEX03
    TABLE ACCESS BY ROWID TABLE1
    INDEX RANGE SCAN TABLE1INDEX03
    TABLE ACCESS BY ROWID TABLE2
    INDEX UNIQUE SCAN TABLE2INDEXPK
    SORT JOIN
    VIEW
    SORT UNIQUE
    TABLE ACCESS BY ROWID TABLE1
    INDEX RANGE SCAN TABLE1INDEX03
    Query results - Oracle 7.3.4:
    X|A | 1| 0| 22| | 1|08-MAR-02|XYZ | | 24.00| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|B | 2| 1| 22| | 7|04-DEC-01|XYZ | | 3.25| 8.00| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|C | 3| 1| 22| | 1|14-AUG-02|XYZ | | 10.35| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|D | 4| 1| 22| | 6|11-JUL-02|XYZ | | .00| 13.90| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    (approximately 1150 rows returned)
    Indexes (used):
    TABLE1INDEX03     (three)
    TABLE1INDEX04     (five)
    TABLE2INDEXPK     (five)
    TABLE3INDEXPK     (one,twentytwo,two,three,four,twentysix)
    Discussion:
    Notice the repeating result for X,E,5,5,23,.... in the Oracle9i retrieval using CBO.
    The execution of this query returned approximately four times the number of rows as
    Oracle 7.3.4 using RBO. This is a function of how many "fours" there are in table3
    that have matching "threes and fours" in table1. If you put a DISTINCT clause at the
    very front of the query (SELECT DISTINCT one,two,three ....) then the result is
    accurate and the same as Oracle 7.3.4. In one execution of this query, 27,000 rows
    are expected to be returned, but the server returned over 1 million rows!
    When RBO was used on Oracle9i, the results were identical to the ones on Oracle 7.3.4.

  • SQL Explain differs with same query

    DB 1: Oracle EE 11gR1 64-bit
    DB 2: Oracle XE 11gR2 64-bit
    Both on OEL 64-bit
    DB 1 does not do a SORT related to the subquery whereas DB 2 does do a SORT. Otherwise EXPLAN PLAN identical. But performance on DB 2 noticeably faster.
    Here is the SQL:
    select col4
    from tab1 join tab2 on tab1.col1 = tab2.col1
    where tab2.col3 = (select max(col3) from tab3);
    Explain plan (brief)
    DB 2:
    FILTER-
    HASH JOIN
    SORT
    DB 1:
    FILTER
    HASH JOIN
    Any hints (no pun) on what might cause this to occur? Is the optimizer different from XE 11gR4 and EE 11gR1 (wouldn't think so)? Or is it a parameter setting, memory or temp space (default settings apply for both DBs).
    Thanks

    Yes, the optimizer is different in 11gR2 than 11gR1. Also the optimizer in Enterprise Edition will have more choices available than in XE (partitioning, for example; parallel processing, since XE uses only 1 CPU), but in this case I doubt the difference is that deep.
    Besides optimizer differences, you need to consider these questions first when you see different plans:
    Is the volume of data the same in both databases?
    Are statistics up to date in both databases?
    Are statistics gathered the same way in each database?
    For anything more specific we need to see the 4-digit oracle version for each database, exact explain plans (copy-paste), and possibly some CREATE TABLE and INSERT statements if someone wants to reproduce what you are seeing in their database.

  • Different variable values for same query inserted 6 times in One workbook.

    Hi,
    We have one workbook with the same query inserted on 6 different tabs (sheets in excel), a variable on Business Unit that is different for each tab.
    How can we control the variable input in BW2004s such that the different BU values are processed for each tab.
    At present the BU value input in the "variable pop-up screen" over rides all the fixed variables on the different tabs.
    Generous points will be awarded for useful solution.
    Thanks,
    Jasmine

    Hi,
    I am  trying to use filters for executing 2 queries in a Web App. I have 2 dataproviders (one for each query), and I am trying to use filters for say Version.
    The URL is
    /sap/bw/BEx?cmd=ldoc&TEMPLATE_ID=ZTW_XXX&DATA_PROVIDER_1= DP1&FILTER_IOBJNM_1=0VERSION&FILTER_VALUE_1=F01&DATA_PROVIDER_2= DP2&FILTER_IOBJNM_2=0VERSION&FILTER_VALUE_2=F02.
    This doesnot work. Both queries get filtered on both 'F01' and 'F02'.
    I am trying to filter DP1 by F01 and DP2 by F02.
    Any help is appreciated.
    Thanks,
    NS

  • Significant difference in response times for same query running on Windows client vs database server

    I have a query which is taking a long time to return the results using the Oracle client.
    When I run this query on our database server (Unix/Solaris) it completes in 80 seconds.
    When I run the same query on a Windows client it completes in 47 minutes.
    Ideally I would like to get a response time equivalent on the Windows client to what I get when running this on the database server.
    In both cases the query plans are the same.
    The query and plan is shown below :
    {code}
    SQL> explain plan
      2  set statement_id = 'SLOW'
      3  for
      4  SELECT DISTINCT /*+ FIRST_ROWS(503) */ objecttype.id_object
      5  FROM documents objecttype WHERE objecttype.id_type_definition = 'duotA9'
      6  ;
    Explained.
    SQL> select * from table(dbms_xplan.display('PLAN_TABLE','SLOW','TYPICAL'));
    PLAN_TABLE_OUTPUT
    | Id  | Operation          | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)|
    |   0 | SELECT STATEMENT   |           |  2852K|    46M|       | 69851   (1)|
    |   1 |  HASH UNIQUE       |           |  2852K|    46M|   153M| 69851   (1)|
    |*  2 |   TABLE ACCESS FULL| DOCUMENTS |  2852K|    46M|       | 54063   (1)|
    {code}
    Are there are configuration changes that can be done on the Oracle client or database to improve the response times for the query when it is running from the client?
    The version on the database server is 10.2.0.1.0
    The version of the oracle client is also 10.2.0.1.0
    I am happy to provide any further information if required.
    Thank you in advance.

    I have a query which is taking a long time to return the results using the Oracle client.
    When I run this query on our database server (Unix/Solaris) it completes in 80 seconds.
    When I run the same query on a Windows client it completes in 47 minutes.
    There are NO queries that 'run' on a client. Queries ALWAYS run within the database server.
    A client can choose when to FETCH query results. In sql developer (or toad) I can choose to get 10 rows at a time. Until I choose to get the next set of 10 rows NO rows will be returned from the server to the client; That query might NEVER complete.
    You may get the same results depending on the client you are using. Post your question in a forum for whatever client you are using.

  • Query select 1 row Explain plan shows different no of rows

    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE    10.2.0.1.0      Production
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    SQL> set autot on
    SQL> select session_id from dba_fga_audit_trail;
    SESSION_ID
         24001
    1 row selected.
    Elapsed: 00:00:00.00
    Execution Plan
    Plan hash value: 1613626607
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |          | 41678 |   203K|   507   (1)| 00:00:07 |
    |   1 |  TABLE ACCESS FULL| FGA_LOG$ | 41678 |   203K|   507   (1)| 00:00:07 |
    ------------------------------------------------------------------------------In the above query it is selecting only one row
    but in E Plan it is showing 41678 rows selected.
    Am i wrong somewhere ?
    Regards
    Singh

    The number of rows processed to get your one record

  • PR Item Text Different for same Material in the same Plant.

    I have a Query for SAP MM.
    Below is the Scenario:
    User raises a PR through SAP for a particular Material (Spare) which belongs to an Equipment.
    Let's say in Plant A, we have an Equipment 10001 & it has a sub-Equipment as 1000112 & further it has a spare which belongs to the sub-equipment as 1000001.
    Now when the user raises a PR for 1000001 then he wants to automatically populate the information in the Item Detail Text tab  such as:
    Equipment No.: 10001
    Sub-Equipment No.: 1000112
    The above text enables the vendor to track & source the correct material.
    The problem here is that the same material is being used in the same plant for another equipment also, hence we cant just update the PO text in the Material Master record.
    How to map the above in the std SAP system???
    Require your help / expert comments.
    Regards,
    Yogesh.

    Hello friend,
                      i feel that u want to send the material to the supplier of that equipment for sum work,
    then it would b better that u maintain the supplier model no. or manufacturing part no. which u can give in the detail.
    it would be better to give the manufacturer part no. The manufacturer can more easil track the part by giving the manufacturer part no, rather then giving your own SAP No.
    and regarding the SUB-Equipment and its part no. there is no standard functionality.
    Regards,
    yk
    Edited by: 1234_abcd on Apr 1, 2010 5:27 PM

Maybe you are looking for