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.

Similar Messages

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

  • Explain plans differ:  same query, cloned databases.

    oracle 10.2.0.2.0
    solaris 10
    same query, different databases (cloned from same source), different explain plans.
    db parameters are identical.
    Any ideas?
    DB1 (production)
    SQL> explain plan for
      2  SELECT  V__101.*,   SHAPE.fid,SHAPE.numofpts,SHAPE.entity,SHAPE.points,
      3    SHAPE.rowid
      4  FROM
      5   (SELECT b.OBJECTID,b.CRT_DTE,b.CRT_SRC_CDE,b.CRT_AQUI_MTHD_CDE,b.CRT_USR_ID,
      6    b.ADT_ACTN_CDE,b.ADT_ACTN_DTE,b.ADT_ACTN_SRC_CDE,b.ADT_ACTN_USR_ID,
      7    b.TP_SITE_POINT_ID,b.SHAPE,b.SRC_ID,b.SRC_CRT_DTE,b.SRC_TYPE_CDE,
      8    b.LCTN_STAT_CDE,b.FRZN_LCTN_IND,b.TP_NOTES   FROM AMSOWNER.TP_SITE_POINT b
      9    WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM
    10    AMSOWNER.D101 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
      SDE.state_lineages l WHERE l.lineage_name = :source_lineage_name AND
    11   12    l.lineage_id <= :source_state_id) AND SDE_STATE_ID = :"SYS_B_0") UNION ALL
      SELECT a.OBJECTID,a.CRT_DTE,a.CRT_SRC_CDE,a.CRT_AQUI_MTHD_CDE,a.CRT_USR_ID,
    13   14    a.ADT_ACTN_CDE,a.ADT_ACTN_DTE,a.ADT_ACTN_SRC_CDE,a.ADT_ACTN_USR_ID,
    15    a.TP_SITE_POINT_ID,a.SHAPE,a.SRC_ID,a.SRC_CRT_DTE,a.SRC_TYPE_CDE,
    16    a.LCTN_STAT_CDE,a.FRZN_LCTN_IND,a.TP_NOTES   FROM AMSOWNER.A101 a,
    17    SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+
    18    HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID  FROM AMSOWNER.D101 WHERE
    19    DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
    20    l.lineage_name = :source_lineage_name AND l.lineage_id <= :source_state_id)
    21    AND SDE_STATE_ID > :"SYS_B_1") AND a.SDE_STATE_ID = SL.lineage_id AND
    22    SL.lineage_name = :source_lineage_name AND SL.lineage_id <=
    23    :source_state_id ) V__101 , AMSOWNER.F15 SHAPE where SHAPE.FID(+) =
    24    V__101.SHAPE;
    Explained.
    SQL>  @?/rdbms/admin/utlxplp.sql;
    PLAN_TABLE_OUTPUT
    Plan hash value: 254376361
    | Id  | Operation                         | Name             | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                  |                  |   113K|    49M|       |  2926   (1)| 00:00:41 |
    |*  1 |  HASH JOIN RIGHT OUTER            |                  |   113K|    49M|    17M|  2926   (1)| 00:00:41 |
    |   2 |   TABLE ACCESS FULL               | F15              |   113K|    15M|       |   344   (2)| 00:00:05 |
    |   3 |   VIEW                            |                  |   113K|    34M|       |   331   (2)| 00:00:05 |
    |   4 |    UNION-ALL                      |                  |       |       |       |            |          |
    |*  5 |     HASH JOIN RIGHT ANTI          |                  |   113K|  8948K|       |   332   (2)| 00:00:05 |
    |   6 |      VIEW                         | VW_NSO_1         |     1 |    13 |       |     2   (0)| 00:00:01 |
    |   7 |       NESTED LOOPS                |                  |     1 |    50 |       |     2   (0)| 00:00:01 |
    |   8 |        TABLE ACCESS BY INDEX ROWID| D101             |     1 |    39 |       |     1   (0)| 00:00:01 |
    |*  9 |         INDEX SKIP SCAN           | D101_IDX1        |     1 |       |       |     1   (0)| 00:00:01 |
    |* 10 |        INDEX UNIQUE SCAN          | LINEAGES_PK      |     1 |    11 |       |     1   (0)| 00:00:01 |
    |  11 |      TABLE ACCESS FULL            | TP_SITE_POINT    |   113K|  7512K|       |   329   (2)| 00:00:05 |
    |* 12 |     HASH JOIN ANTI                |                  |     1 |   375 |       |     5  (20)| 00:00:01 |
    |  13 |      NESTED LOOPS                 |                  |     1 |   349 |       |     2   (0)| 00:00:01 |
    |  14 |       TABLE ACCESS BY INDEX ROWID | A101             |     1 |   338 |       |     1   (0)| 00:00:01 |
    |* 15 |        INDEX RANGE SCAN           | A101_STATEID_IX1 |     1 |       |       |     1   (0)| 00:00:01 |
    |* 16 |       INDEX UNIQUE SCAN           | LINEAGES_PK      |     1 |    11 |       |     1   (0)| 00:00:01 |
    |* 17 |      VIEW                         | VW_NSO_2         |     1 |    26 |       |     2   (0)| 00:00:01 |
    |  18 |       NESTED LOOPS                |                  |     1 |    50 |       |     2   (0)| 00:00:01 |
    |* 19 |        INDEX FULL SCAN            | D101_PK          |     1 |    39 |       |     1   (0)| 00:00:01 |
    |* 20 |        INDEX UNIQUE SCAN          | LINEAGES_PK      |     1 |    11 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access("SHAPE"."FID"(+)="V__101"."SHAPE")
       5 - access("B"."OBJECTID"="$nso_col_1")
       9 - access("SDE_STATE_ID"=TO_NUMBER(:SYS_B_0))
           filter("SDE_STATE_ID"=TO_NUMBER(:SYS_B_0))
      10 - access("L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
      12 - access("A"."OBJECTID"="$nso_col_1" AND "A"."SDE_STATE_ID"="$nso_col_2")
      15 - access("A"."SDE_STATE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
      16 - access("SL"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
                  "A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
           filter("SL"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
      17 - filter("$nso_col_2"<=TO_NUMBER(:SOURCE_STATE_ID))
      19 - access("SDE_STATE_ID">TO_NUMBER(:SYS_B_1))
           filter("SDE_STATE_ID">TO_NUMBER(:SYS_B_1))
      20 - access("L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
    47 rows selected.DB2 (staging)
    SQL> explain plan for
      2  SELECT  V__101.*,   SHAPE.fid,SHAPE.numofpts,SHAPE.entity,SHAPE.points,
      SHAPE.rowid
    FROM
      3    4    5   (SELECT b.OBJECTID,b.CRT_DTE,b.CRT_SRC_CDE,b.CRT_AQUI_MTHD_CDE,b.CRT_USR_ID,
      b.ADT_ACTN_CDE,b.ADT_ACTN_DTE,b.ADT_ACTN_SRC_CDE,b.ADT_ACTN_USR_ID,
      6    7    b.TP_SITE_POINT_ID,b.SHAPE,b.SRC_ID,b.SRC_CRT_DTE,b.SRC_TYPE_CDE,
      8    b.LCTN_STAT_CDE,b.FRZN_LCTN_IND,b.TP_NOTES   FROM AMSOWNER.TP_SITE_POINT b
      9    WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM
    10    AMSOWNER.D101 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
    11    SDE.state_lineages l WHERE l.lineage_name = :source_lineage_name AND
    12    l.lineage_id <= :source_state_id) AND SDE_STATE_ID = :"SYS_B_0") UNION ALL
    13    SELECT a.OBJECTID,a.CRT_DTE,a.CRT_SRC_CDE,a.CRT_AQUI_MTHD_CDE,a.CRT_USR_ID,
    14    a.ADT_ACTN_CDE,a.ADT_ACTN_DTE,a.ADT_ACTN_SRC_CDE,a.ADT_ACTN_USR_ID,
    15    a.TP_SITE_POINT_ID,a.SHAPE,a.SRC_ID,a.SRC_CRT_DTE,a.SRC_TYPE_CDE,
    16    a.LCTN_STAT_CDE,a.FRZN_LCTN_IND,a.TP_NOTES   FROM AMSOWNER.A101 a,
    17    SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+
      HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID  FROM AMSOWNER.D101 WHERE
    18   19    DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
    20    l.lineage_name = :source_lineage_name AND l.lineage_id <= :source_state_id)
    21    AND SDE_STATE_ID > :"SYS_B_1") AND a.SDE_STATE_ID = SL.lineage_id AND
    22    SL.lineage_name = :source_lineage_name AND SL.lineage_id <=
    23    :source_state_id ) V__101 , AMSOWNER.F15 SHAPE where SHAPE.FID(+) =
    24    V__101.SHAPE;
    Explained.
    SQL>  @?/rdbms/admin/utlxplp.sql;
    PLAN_TABLE_OUTPUT
    Plan hash value: 4287458713
    | Id  | Operation                         | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                  |                  |   145 | 68150 |   401   (1)| 00:00:06 |
    |   1 |  NESTED LOOPS OUTER               |                  |   145 | 68150 |   401   (1)| 00:00:06 |
    |   2 |   VIEW                            |                  |   145 | 47125 |   328   (1)| 00:00:05 |
    |   3 |    UNION-ALL                      |                  |       |       |            |          |
    |*  4 |     HASH JOIN ANTI                |                  |   144 | 10224 |   324   (1)| 00:00:05 |
    |   5 |      TABLE ACCESS FULL            | TP_SITE_POINT    |   145 |  8410 |   322   (1)| 00:00:05 |
    |   6 |      VIEW                         | VW_NSO_1         |     1 |    13 |     2   (0)| 00:00:01 |
    |   7 |       NESTED LOOPS                |                  |     1 |    50 |     2   (0)| 00:00:01 |
    |*  8 |        TABLE ACCESS BY INDEX ROWID| D101             |     1 |    39 |     1   (0)| 00:00:01 |
    |*  9 |         INDEX SKIP SCAN           | D101_IDX1        |     1 |       |     1   (0)| 00:00:01 |
    |* 10 |        INDEX UNIQUE SCAN          | LINEAGES_PK      |     1 |    11 |     1   (0)| 00:00:01 |
    |* 11 |     FILTER                        |                  |       |       |            |          |
    |  12 |      NESTED LOOPS                 |                  |     1 |   349 |     2   (0)| 00:00:01 |
    |  13 |       TABLE ACCESS BY INDEX ROWID | A101             |     1 |   338 |     1   (0)| 00:00:01 |
    |* 14 |        INDEX RANGE SCAN           | A101_STATEID_IX1 |     1 |       |     1   (0)| 00:00:01 |
    |* 15 |       INDEX UNIQUE SCAN           | LINEAGES_PK      |     1 |    11 |     1   (0)| 00:00:01 |
    |* 16 |      FILTER                       |                  |       |       |            |          |
    |  17 |       NESTED LOOPS                |                  |     1 |    50 |     2   (0)| 00:00:01 |
    |* 18 |        TABLE ACCESS BY INDEX ROWID| D101             |     1 |    39 |     1   (0)| 00:00:01 |
    |* 19 |         INDEX RANGE SCAN          | D101_IDX1        |     1 |       |     1   (0)| 00:00:01 |
    |* 20 |        INDEX UNIQUE SCAN          | LINEAGES_PK      |     1 |    11 |     1   (0)| 00:00:01 |
    |  21 |   TABLE ACCESS BY INDEX ROWID     | F15              |     1 |   145 |     1   (0)| 00:00:01 |
    |* 22 |    INDEX UNIQUE SCAN              | F15_UK1          |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       4 - access("B"."OBJECTID"="$nso_col_1")
       8 - filter("DELETED_AT"<=TO_NUMBER(:SOURCE_STATE_ID))
       9 - access("SDE_STATE_ID"=TO_NUMBER(:SYS_B_0))
           filter("SDE_STATE_ID"=TO_NUMBER(:SYS_B_0))
      10 - access("L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
                  "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
      11 - filter( NOT EXISTS (SELECT /*+ HASH_AJ */ 0 FROM "AMSOWNER"."D101"
                  "D101","SDE"."STATE_LINEAGES" "L" WHERE :B1>TO_NUMBER(:SYS_B_1) AND
                  "DELETED_AT"="L"."LINEAGE_ID" AND "L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
                  "L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID) AND "SDE_STATE_ID"=:B2 AND
                  "SDE_DELETES_ROW_ID"=:B3 AND "DELETED_AT"<=TO_NUMBER(:SOURCE_STATE_ID) AND
                  "SDE_STATE_ID">TO_NUMBER(:SYS_B_1)))
      14 - access("A"."SDE_STATE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
      15 - access("SL"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
                  "A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
           filter("SL"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
      16 - filter(:B1>TO_NUMBER(:SYS_B_1))
      18 - filter("DELETED_AT"<=TO_NUMBER(:SOURCE_STATE_ID))
      19 - access("SDE_DELETES_ROW_ID"=:B1 AND "SDE_STATE_ID"=:B2)
           filter("SDE_STATE_ID">TO_NUMBER(:SYS_B_1))
      20 - access("L"."LINEAGE_NAME"=TO_NUMBER(:SOURCE_LINEAGE_NAME) AND
                  "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=TO_NUMBER(:SOURCE_STATE_ID))
      22 - access("SHAPE"."FID"(+)="V__101"."SHAPE")
    58 rows selected.

    rocr wrote:
    oracle 10.2.0.2.0
    solaris 10
    same query, different databases (cloned from same source), different explain plans.
    db parameters are identical.
    DB1 (production)
    | Id  | Operation                         | Name             | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                  |                  |   113K|    49M|       |  2926   (1)| 00:00:41 |DB2 (staging)
    | Id  | Operation                         | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                  |                  |   145 | 68150 |   401   (1)| 00:00:06 |
    If you check the execution plans it's quite obvious that the two environments can not be identical. If you have the same (amount of) data, then one of the two estimates is way off. Which one is in the right ballpark, how many rows are returned by the query? The same applies to the remaining operation ids of the plan, which estimate is correct?
    It's very likely that the underlying table/index statistics are not the same, and therefore you get different plans.
    By the way, you're using bind variables, therefore the output of the EXPLAIN PLAN is only of limited use, since the actual plan at run time might be completely different due to bind variable peeking and potentially histograms created on some of the columns (which is the default in 10g due to the "FOR ALL COLUMNS SIZE AUTO" method_opt default parameter value).
    If you haven't disabled the pre-configured statistics collection job that runs every night in 10g, you might get different statistics due to this job already.
    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

    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.

  • Browser response time slow but Analyzer fast with same query

    Hi all,
    We have a very complex query (structures and cell formulas).  When I drill and filter on a specific characteristic the action takes anything between 7 and 15 minutes when using the browser. The same query in Analyzer performing the same drilling action takes less than 35 seconds.
    Our architecture is as follows:
    - Relevant cubes are indexed on BWA
    - WebDynPro for Java
    We can see that the BWA is hit for a short time then the CPU utilization is back to 0%.  When doing '&profiling=x' on the browser I can see that the most of the time is spent on 'Get result set' / 'Get provider result set' for the Java events and on the OLAP side most time is spent on the 'Get result set' event.
    Interestingly enough - when disabling myself as a user for BIA use (NO_BIA_USE) in my user profile I get the same response time on the browser.
    So, does anyone have an idea of what may be the cause of the slow response time when using the browser?
    Thanks
    Edited by: Cobus van Rooyen on May 10, 2010 8:49 PM

    Hi,
    The reason is most likely because of the event ID 3200 where data transfer takes place from OLAP to frontend browser.
    Record a RSTT trace for this and if you are able to see frequent calls to "Apply State XML" and "Get Result Set" then apply the SAP Note 1428850. Otherwise see which function module is causing an error.
    If trace runtime is less but in browser still it takes long time then this might be because of the compression of HTPP responses, which can be confirmed by observing the sent and received data volumns from the HTTP server requests/responses. For more information refer SAP Note 746666.
    Imran...

  • 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

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

  • Different Ordered Result-Sets With Same Query.

    I am executing a very simple query which returns a name and an id. It is order by name preaty simple.
    BUT. returs different if the framework is english or french.
    <?xml version="1.0" standalone="yes"?>
    <NewDataSet>
    <Table>
    <DATAUNITID>11920</DATAUNITID>
    <NAME>(FR) Atlantis</NAME>
    </Table>
    <Table>
    <DATAUNITID>11922</DATAUNITID>
    <NAME>(FR) Beaumont</NAME>
    </Table>...
    ========================================================
    <?xml version="1.0" standalone="yes"?>
    <NewDataSet>
    <Table>
    <DATAUNITID>12006</DATAUNITID>
    <NAME>AVRANCHES</NAME>
    </Table>
    <Table>
    <DATAUNITID>12005</DATAUNITID>
    <NAME>CARENTAN</NAME>
    </Table>
    Any thoughts?
    Thanks in advance,
    Frank

    Hi Satria,
    You can detach the query in Bex analyser.
    Once you open the workbook, right click context menu,
    has the option to delete the query from work book.
    The query can be reinserted again.
    However a better solution would be to make the format changes in the workbook properties and save the changes.
    Regards,
    Nitin

  • 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

  • Images look different with same white balance

    Hey folks,
    Just ran some tests between a Nikon D300 and a Nikon D7000. I pulled both images into Lightroom 3.4 (PC), and matched the white balance using the White Balance Selector tool and a WhiBal card in a test image. And even though they now have the same white balance, the colors are distinctly different. How is this possible? (The same image shot with a D200 looks nearly identical to the D300.) Examples:
    D7000
    D300
    All other specs the same:
    Nikon 17-55mm f/2.8 @50mm
    1/80 @ f/5.6, ISO 200
    RAW
    Color space: AdobeRGB
    Picture Control setting: SD (standard)
    Custom white balance from WhiBal card, matched in Lightroom 3.4: 5200, +38
    I need to be able to shoot with multiple bodies and sync them so I don't have to adjust the batches separately.
    Thanks in advance

    WB is not the only factor involved in how colour is created in a digital image. The WB just sets the colour temperature. How the colour is created is effected by many other factors, hence calibration profiles. By calibrating the sensor you can produce a standardised response for a particular individual sensor. You could then carefully match this with a different sensor. However there will always be subtle differences. It would be far easier when requiring a particular shoot to have exactly the same look, to use one camera and one lens to achieve it.
    When making a film,  directors, such as Hitchcock, would insist on not only using the same film stock, from the same batch, but in the case of Vertigo even had the same water source used for all processing to achieve the look he was after.

  • Results showing mismatch with same query

    Hi,
    The below query results in different fashion, when i use for one Panelist_Id it gives 13 records, and when i pull the whole record set it give only 5 records for the same
    Panelist_id.
    Here are queries:
    select row_number() over (partition by panelist_id order by start_media_day) seq_ctr
    , panelist_id
    , start_media_day
    , end_media_day
    , ((end_media_day -start_media_day )+ 1) no_of_days
    from (
    select panelist_id
    , media_day start_media_day
    , lead(media_day) over (partition by panelist_id order by panelist_id, media_day) end_media_day
    , day_diff
    from (
    select panelist_id
    , media_day
    , day_diff
    , lag(day_diff) over(partition by panelist_id order by panelist_id,media_day) p_status
    from (SELECT panelist_id,
    MEDIA_DAY,
    Case When LEAD (MEDIA_DAY, 1, 0)
    OVER (PARTITION BY panelist_id ORDER BY QE_CODE ASC NULLS LAST)
    - MEDIA_DAY < 0 THEN 9999 ELSE
    LEAD (MEDIA_DAY, 1, 0)
    OVER (PARTITION BY panelist_id ORDER BY QE_CODE ASC NULLS LAST)
    - MEDIA_DAY END
    DAY_DIFF
    FROM PPMDP_QUALEDITS
    WHERE QE_CODE = 'MISS' AND PANELIST_ID='1539620-6'
    where day_diff > 1
    or p_status is null
    or p_status > 1
    where day_diff = 1
    ---------------------------------------------------------------------------------------------------------------------Results 13 records.
    select row_number() over (partition by panelist_id order by start_media_day) seq_ctr
    , panelist_id
    , start_media_day
    , end_media_day
    , ((end_media_day -start_media_day )+ 1) no_of_days
    from (
    select panelist_id
    , media_day start_media_day
    , lead(media_day) over (partition by panelist_id order by panelist_id, media_day) end_media_day
    , day_diff
    from (
    select panelist_id
    , media_day
    , day_diff
    , lag(day_diff) over(partition by panelist_id order by panelist_id,media_day) p_status
    from (SELECT panelist_id,
    MEDIA_DAY,
    Case When LEAD (MEDIA_DAY, 1, 0)
    OVER (PARTITION BY panelist_id ORDER BY QE_CODE ASC NULLS LAST)
    - MEDIA_DAY < 0 THEN 9999 ELSE
    LEAD (MEDIA_DAY, 1, 0)
    OVER (PARTITION BY panelist_id ORDER BY QE_CODE ASC NULLS LAST)
    - MEDIA_DAY END
    DAY_DIFF
    FROM PPMDP_QUALEDITS
    WHERE QE_CODE = 'MISS' /*AND PANELIST_ID='1539620-6'*/
    where day_diff > 1
    or p_status is null
    or p_status > 1
    where day_diff = 1
    ---------------------------------------------------------------------------------------------------------------------Results 150000+ records.
    And when I look for PANELIST_ID='1539620-6' from this 150000+ records it resulted 5 records.
    Can someone help in getting where the error is?
    Many thanks in advance.
    Regards,
    Sriniwas Gutti
    Edited by: guttis on Oct 26, 2009 8:48 PM

    Hi,
    The below query results in different fashion, when i use for one Panelist_Id it gives 13 records, and when i pull the whole record set it give only 5 records for the same Panelist_id.
    Here are queries:
    select row_number() over (partition by panelist_id order by start_media_day) seq_ctr
    , panelist_id
    , start_media_day
    , end_media_day
    , ((end_media_day -start_media_day )+ 1) no_of_days
    from (
    select panelist_id
    , media_day start_media_day
    , lead(media_day) over (partition by panelist_id order by panelist_id, media_day) end_media_day
    , day_diff
    from (
    select panelist_id
    , media_day
    , day_diff
    , lag(day_diff) over(partition by panelist_id order by panelist_id,media_day) p_status
    from (SELECT panelist_id,
    MEDIA_DAY,
    Case When LEAD (MEDIA_DAY, 1, 0)
    OVER (PARTITION BY panelist_id ORDER BY QE_CODE ASC NULLS LAST)
    - MEDIA_DAY < 0 THEN 9999 ELSE
    LEAD (MEDIA_DAY, 1, 0)
    OVER (PARTITION BY panelist_id ORDER BY QE_CODE ASC NULLS LAST)
    - MEDIA_DAY END
    DAY_DIFF
    FROM PPMDP_QUALEDITS
    WHERE QE_CODE = 'MISS' AND PANELIST_ID='1539620-6'
    where day_diff > 1
    or p_status is null
    or p_status > 1
    where day_diff = 1
    ---------------------------------------------------------------------------------------------------------------------Results 13 records.
    select row_number() over (partition by panelist_id order by start_media_day) seq_ctr
    , panelist_id
    , start_media_day
    , end_media_day
    , ((end_media_day -start_media_day )+ 1) no_of_days
    from (
    select panelist_id
    , media_day start_media_day
    , lead(media_day) over (partition by panelist_id order by panelist_id, media_day) end_media_day
    , day_diff
    from (
    select panelist_id
    , media_day
    , day_diff
    , lag(day_diff) over(partition by panelist_id order by panelist_id,media_day) p_status
    from (SELECT panelist_id,
    MEDIA_DAY,
    Case When LEAD (MEDIA_DAY, 1, 0)
    OVER (PARTITION BY panelist_id ORDER BY QE_CODE ASC NULLS LAST)
    - MEDIA_DAY < 0 THEN 9999 ELSE
    LEAD (MEDIA_DAY, 1, 0)
    OVER (PARTITION BY panelist_id ORDER BY QE_CODE ASC NULLS LAST)
    - MEDIA_DAY END
    DAY_DIFF
    FROM PPMDP_QUALEDITS
    WHERE QE_CODE = 'MISS' /*AND PANELIST_ID='1539620-6'*/
    where day_diff > 1
    or p_status is null
    or p_status > 1
    where day_diff = 1
    ---------------------------------------------------------------------------------------------------------------------Results 150000+ records.
    And when I look for PANELIST_ID='1539620-6' from this 150000+ records it resulted 5 records.
    Can someone help in getting where the error is?
    Many thanks in advance.
    Regards,
    Sriniwas Gutti

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

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

  • Same query, same dataset, same ddl setup, but wildly different explain plan

    Hello o fountains of oracle knowledge!
    We have a problem that caused us a full stop when rolling out a new version of our system to a customer and a whole Sunday to boot.
    The scenario is as follows:
    1. An previous version database schema
    2. The current version database schema
    3. A migration script to migrate the old schema to the new
    So we perform the following migration:
    1. Export the previous version database schema
    2. Import into a new schema called schema_old
    3. Create a new schema called schema_new
    4. Run migration script which creates objects, copies data, creates indexes etc etc in schema_new
    The migration runs fine in all environments (development, test and production)
    In our development and test environments performance is stellar, on the customer production server the performance is terrible.
    This using the exact same export file (from the production environment) and performing the exact same steps with the exact same migration script.
    Database version is 10.2.0.1.0 EE on all databases. OS is Microsoft Windows Server 2003 EE SP2 on all servers.
    The system is not in any sense under a heavy load (we have tested with no other load than ourselves).
    Looking at the explain plan for a query that is run frequently and does not use bind variables we see wildly different explain plans.
    The explain plan cost on our development and test servers is estimated to *7* for this query and there are no full table scans.
    On the production server the cost is *8433* and there are two full table scans of which one is on the largest table.
    We have tried to run analyse on all objects with very little effect. The plan changed very slightly, but still includes the two full table scans on the problem server and the cost is still the same.
    All tables and indexes are identical (including storage options), created from the same migration script.
    I am currently at loss for where to look? What can be causing this? I assume this could be caused by some parameter that is set on the server, but I don't know what to look for.
    I would be very grateful for any pointers.
    Thanks,
    Håkon

    Thank you for your answer.
    We collected statistics only after we determined that the production server where not behaving according to expectations.
    In this case we used TOAD and the tool within to collect statistics for all objects. We used 'Analyze' and 'Compute Statistics' options.
    I am not an expert, so sorry if this is too naive an approach.
    Here is the query:SELECT count(0)  
    FROM score_result sr, web_scorecard sc, product p
    WHERE sr.score_final_decision like 'VENT%'  
    AND sc.CREDIT_APPLICATION_ID = sr.CREDIT_APPLICATION_ID  
    AND sc.application_complete='Y'   
    AND p.product = sc.web_product   
    AND p.inactive_product = '2' ;I use this as an example, but the problem exists for virtually all queries.
    The output from the 'good' server:
    | Id  | Operation                      | Name                  | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT               |                       |     1 |    39 |     7   (0)|
    |   1 |  SORT AGGREGATE                |                       |     1 |    39 |            |
    |   2 |   NESTED LOOPS                 |                       |     1 |    39 |     7   (0)|
    |   3 |    NESTED LOOPS                |                       |     1 |    30 |     6   (0)|
    |   4 |     TABLE ACCESS BY INDEX ROWID| SCORE_RESULT          |     1 |    17 |     4   (0)|
    |   5 |      INDEX RANGE SCAN          | SR_FINAL_DECISION_IDX |     1 |       |     3   (0)|
    |   6 |     TABLE ACCESS BY INDEX ROWID| WEB_SCORECARD         |     1 |    13 |     2   (0)|
    |   7 |      INDEX UNIQUE SCAN         | WEB_SCORECARD_PK      |     1 |       |     1   (0)|
    |   8 |    TABLE ACCESS BY INDEX ROWID | PRODUCT               |     1 |     9 |     1   (0)|
    |   9 |     INDEX UNIQUE SCAN          | PK_PRODUCT            |     1 |       |     0   (0)|
    ---------------------------------------------------------------------------------------------The output from the 'bad' server:
    | Id  | Operation                 | Name                  | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT          |                       |     1 |    32 |  8344   (3)|
    |   1 |  SORT AGGREGATE           |                       |     1 |    32 |            |
    |   2 |   HASH JOIN               |                       | 10887 |   340K|  8344   (3)|
    |   3 |    TABLE ACCESS FULL      | PRODUCT               |     6 |    42 |     3   (0)|
    |   4 |    HASH JOIN              |                       | 34381 |   839K|  8340   (3)|
    |   5 |     VIEW                  | index$_join$_001      | 34381 |   503K|  2193   (3)|
    |   6 |      HASH JOIN            |                       |       |       |            |
    |   7 |       INDEX RANGE SCAN    | SR_FINAL_DECISION_IDX | 34381 |   503K|   280   (3)|
    |   8 |       INDEX FAST FULL SCAN| SCORE_RESULT_PK       | 34381 |   503K|  1371   (2)|
    |   9 |     TABLE ACCESS FULL     | WEB_SCORECARD         |   489K|  4782K|  6137   (4)|
    ----------------------------------------------------------------------------------------I hope the formatting makes this readable.
    Stats (from SQL Developer), good table:NUM_ROWS     489716
    BLOCKS     27198
    AVG_ROW_LEN     312
    SAMPLE_SIZE     489716
    LAST_ANALYZED     15.12.2009
    LAST_ANALYZED_SINCE     15.12.2009Stats (from SQL Developer), bad table:
    NUM_ROWS     489716
    BLOCKS     27199
    AVG_ROW_LEN     395
    SAMPLE_SIZE     489716
    LAST_ANALYZED     17.12.2009
    LAST_ANALYZED_SINCE     17.12.2009I'm unsure what would cause the difference in average row length.
    I could obviously try to tune our sql-statements to work on the server not behaving better, but I would rather understand why they are different and make sure that we can expect similar behaviour between environments.
    Thank you again for trying to help me.
    Håkon
    Edited by: ergates on 17.des.2009 05:57
    Edited by: ergates on 17.des.2009 06:02

Maybe you are looking for