Dicoverer Viewer is Slow Compared to DiscovererPlus for same query...why ??

Hi,
I have a report whcih runs from a custom table which gets populated daily in the night.
It retrieves aroun 98000 records widout parameters.
The report runs in around 4-5 seconds in Discoverer Plus wheras in
Discoverer Viewer it is taking almost 45-50 seconds...Could anyone please advice as to what could be
the reason and can we do some thing to make the Viewer equally fast as Viewer is the Discoverer Tool
we are giving the users access to and with this speed it would not be acceptable.
Plz Advice ASAP.
Thanks,
VJ

Hello Raptole,
Thanks for using Apple Support Communities.
For more information on this, take a look at:
OS X Mountain Lion: If your Mac runs slowly
http://support.apple.com/kb/PH10798
Mac OS X: Setting up Login, Startup items
http://support.apple.com/kb/ht2602
Log in as the user who wishes to have a login item or as an admin user.
Choose System Preferences from the Apple menu.
Choose Accounts from the View menu.
Click the name of the user.
Mac OS X 10.4 or later: Click the Login Items button.
select things you dont need and Click the "minus" button.
Best of luck,
Mario

Similar Messages

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

  • 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

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

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

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

  • 2LIS_02_HDR - Multiple records coming for same EBELN, why?

    Hello All,
    I ran a setup table for init and tested extraction in rsa3 for  data source 2LIS_02_HDR , only one EBELN and it retrievs 3 records for same EBELN. As per my understanding the header data comes from EKKO hence it should bring only one record but retireves multiple records,I want to know why this happens?
    thanks
    V Pola
    Edited by: V pola on Jan 30, 2008 5:35 PM

    Hi,
    Thanks for your reply. The link does not explain why 2LIS_02_HDr retrieves multiple records instead of one.
    Thanks
    V Pola

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

  • Slow, then fast execution of same query

    I have a test query:
    dbxml> query 'count(collection()/Quots/QuotVerificationInstance/@lastModifiedDate[.="2009-09-07"])'
    With this index:
    Index: node-attribute-substring-string for node {}:lastModifiedDate
    The first time I run the query in the shell, it takes a while:
    Query - Finished query execution, time taken = 29656ms
    The second time I run the query, it's a more acceptable speed:
    Query - Finished query execution, time taken = 735ms
    Can anyone explain the difference in search speed? The slow, fast pattern is pretty consistent (I've tried fresh shell sessions a few times and get the same initial slow search followed by the quicker one.)
    What I'm trying to do is allow on-demand generation of a table showing the number of records modified per day and per month. The test date I'm searching for above is the date of insertion of records so it returns a comparatively large result set at the moment, but 29-odd seconds is way too slow to make the query comfortable. I've added a substring index because sometimes I want a partial date search (e.g. when counting records modified per month). I remember reading that a substring index doubles as an equality index. The date is stored simply as a string, not a date type.
    What am I missing? I'd like to understand the difference in execution times, but basically I need it to run more quickly for simultaneous date queries. I'd be grateful for any pointers.
    Tim

    Hi Viyacheslav
    I think it's perhaps too much trouble for us both for me to try and share the container -- my managers would want assurances about copyright (the data is part of a previously published dictionary), and I'd have to build a smaller one as the current file is > 500MB. But thanks for your interest.
    My container setup is pretty simple. It's around 45000 small XML files added to a node container for a read only database (no environment). I have 16 indices supporting a range of different searches and a couple of reports, and the only index relevant to the @lastModifiedDate search is the node-attribute-substring-string index mentioned above (when I tried other edge or equality indexes I deleted the substring index). The query script I intended would be instantiated purely to run the one query and then die each time, so I don't see there being any chance of getting past an initial slow query if that's the behaviour. Because that first query finds around 37000 matches among the 45000 dates, it's understandable that it would take a while but I'm not sure why it speeds up in the shell from the second time round. An obvious suggestion would be that some form of optimisation is taking place in the shell, but I don't understand the workings of DBXML well enough to guess how. Even if this is the case, knowing that it happens wouldn't help me speed up my query due to the life cycle of the script.
    Perhaps I should just generate these stats on a daily basis rather than generating them on-demand, or else try a different approach at getting the counts. But thanks again for the comments.
    Tim

  • Explain plan different for same query

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

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

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

  • 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

Maybe you are looking for