Impact on undo_retention on plan of a query ..

HI All ,
Yesterday , we changed the undo_retention on our site and after the database reboot plan of one query changed . Except this we did't made any changes . So , I want to know is anybody here also faced the situation like this . Is really undo_retention changed the plan of the query ???
regds
Rahul

RahulG wrote:
Hi Experts ,
your views required here ....
What version of Oracle
What was the query
What was the plan before the restart
What was the plan after the restart
Use dbms_xplan (or similar) to format the plan, and don't forget to show the predicate section
Use the "code" tags (see footnote) to make the test readable.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

Similar Messages

Effect of RLS policy (VPD) on execution plan of a query

Hi
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Regards,
Amardeep Sidhu

Amardeep Sidhu wrote:
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
VPD is supposed to be invisible - which is why you get minimal information about security predicates in the standard trace file. However, if you reference a table with a security preidcate in your query, the table is effectively replaced by an inline view of the form: "select * from original_table where {security_predicate}", and the result is then optimised. So the effects of the security predicate is just the same as you writing the predicate into the query.
Apart from your use of v$sql_plan to show the change in plan and the new predicates, you can see the effects of the predicates by setting event 10730 with 10046. In current versions of Oracle this causes the substitute view being printed in the trace file.
Bear in mind that security predicates can be very complex - including subqueries - so the effect isn't just that of including the selectivity of "another simple predicate".
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Think of the effect of changing the SQL by hand - and how you would need to optimise the resultant query. Sometimes you do need to modify your indexing to help the security predicates, sometimes it won't make enough difference to matter.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.

How to capture the execution plan for a query

HI All,
Can anyone please help me in finding out the command to capture the execution plan for a query.
Execution plan for select * from EMP where <Condtions>
it is getting executed successfully but i need to get the proper execution plan for the same.
Thanks

971830 wrote:
i want to know where execution plan gets generated??
in PMON of server process or in shared pool??
i know that optimixer create execution plan..It is stored in Library Cache (present inside Shared Pool ).
select * from v$sql_plan;An absolute beautiful white paper :
Refer this -- www.sagelogix.com/sagelogix/SearchResults/SAGE015052
Also -- http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/XPVSP/Default.aspx
HTH
Ranit B.

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/

How to skip existing execution plan for a query

Hi,
I want to skip existng execution plan for a query which I am executing often. I dont want it to use the same execution plan everytime. Please let me know if any method is there skip the existing execution plan.
Thanks in advance.......
Edited by: 900105 on Dec 1, 2011 4:52 AM

Change the query so it is syntactically different, but has the same semantics (meaning). That way CBO will reparse it and you might get a new execution plan.
One simple way to do that is to add a dummy predicate ( 45=45) to the where clause. The predicate must be changed every time the query is executed ( 46=46 , 47=47 ,… ).
Iordan Iotzov
http://iiotzov.wordpress.com/

Explain Plan of a query.

I want to know the concept of this 'Explain Plan' of a query & why it is used. Could u also give the syntax of how a explain plan for a query can be done. Please help in solving the doubt as it is urgent.

Hi,
set autotrace traceonly explain or
-- create your plan table in your schema (only once)
@ ?/rdbms/admin/utlxplan
-- populate the plan table for your select
explain plan for select ...;
-- display output out of the PLAN_TABLE
@ ?/rdbms/admin/ultxplsRegards
Laurent

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

Fix a plan of the query

Hi,
I want to set execution plan of a query. This query is dynamically created by the application according to IN parameters. Actually the query is not using proper index.
Can we use outline. If yes then please give me the syntax for the same.
Please suggest what to do in the situation.
Thanks

Yes.
SQL_TEXT
select /*+ first_rows */ nvl(lad.DBID,1) dbid, applid,lesseeid,
crdec, lad.Instlmode,lad.branchid nbfc_branchid,ldt.INST_PD_FULL
,ncm.customerid,customername, nvl(lad.proposalmodby,lad.propos
alcrby) proposalmodby,lad.status lea_status,Trim(to_char(lad.amt
fin,'999,999,999,999,999,990.90')) amtfin, lad.emi emi,lad.dpd d
pd,lad.bucket bucket,lad.npa_stageid npa_stageid, lad.schemeid,p
roductflag from lea_agreement_dtl lad, nbfc_customer_m ncm, LOAN
DETAILtable ldt Where ldt.AgreementID(+) = lad.AgreementID and
lad.lesseeid=ncm.customerid and lad.STATUS = :V00001 and lad.b
ranchid = :V00002 and lad.productflag = :V00003 and lad.FIRSTSOU
RCEID = :V00004 and lad.FIRSTSOURCE = :V00005 and lad.AUTHDATE b
etween TO_DATE(:V00006,'DD/MM/RRRR') and TO_DATE(:V00007,'DD/MM
/RRRR') and rownum <= 50 order by applid desc
OPERATION      OPTIONS     OBJECT_NAME     COST     Bytes
SELECT STATEMENT               9
COUNT      STOPKEY
NESTED LOOPS                9     104
NESTED LOOPS      OUTER          7     82
TABLE ACCESS     BY INDEX ROWID     LEA_AGREEMENT_DTL     5     73
INDEX      RANGE SCAN     LEA_AGREEMENT_DTL_IDX1     4
TABLE ACCESS     BY INDEX ROWID     LOAN_DETAIL_TABLE     3     9
INDEX      UNIQUE SCAN     SYS_C0021211     2
TABLE ACCESS      BY INDEX ROWID     NBFC_CUSTOMER_M     3     22
INDEX      UNIQUE SCAN     NBFC_CUSTOMER_M_PK     2
Now we want to use CR_DECISION_M_AUTHDATE_IDX1 index in place of LEA_AGREEMENT_DTL_IDX1. Bcz CR_DECISION_M_AUTHDATE_IDX1 has AUTHDATE column in it and is faster than other index.
Thanks
Ratan

Query plan changes when query is used in CREATE TABLE AS

We've puzzled by the fact that EXPLAIN PLAN gives a much different output for a SELECT statement than it does when the same statement is used for CREATE TABLE . . . AS SELECT.
The bad part is that the CREATE TABLE version performs very badly, and that's what we want the query for.
Why does this happen? Is there a difference (from the database's point of view) between retrieving a set of rows to display to the user and putting that same set into a new table? Doesn't this make it harder to diagnose and fix query performance problems?
Here's our query:
create table query_test AS
select term, parentTerm, apidb.tab_to_string(cast(collect(trim(to_char(internal)))
                   as apidb.varchartab), ', ') as internal
             from (
                 select distinct ga.organism as term,
                                 ga.species as parentTerm,
                                 tn.taxon_id as internal
                 from apidb.GeneAttributes ga, SRES.TaxonName tn, sres.Taxon t,
                      dots.AaSequence aas, dots.SecondaryStructure ss
                 where ga.organism = tn.name
           and tn.taxon_id = t.taxon_id
                   and t.taxon_id = aas.taxon_id
   and aas.aa_sequence_id = ss.aa_sequence_id
           and t.rank != 'species'
           union
                 select distinct ga.species as term,
                   '' as parentTerm,
                                 ts.taxon_id as internal
                 from apidb.GeneAttributes ga, SRES.TaxonName tn, apidb.taxonSpecies ts,
                      dots.aasequence aas, dots.SecondaryStructure ss
                 where ga.organism = tn.name
                  and tn.taxon_id = ts.taxon_id
                  and ts.taxon_id = aas.taxon_id
                 and aas.aa_sequence_id = ss.aa_sequence_id
   group by term,parentTerm;Without the CREATE TABLE, the plan looks like this:
| Id | Operation                             | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | CREATE TABLE STATEMENT                |                           | 2911 | 5986K|       | 18840   (1)| 00:03:47 |
|   1 | LOAD AS SELECT                       | QUERY_TEST                |       |       |       |            |          |
|   2 |   VIEW                                |                           | 2911 | 5986K|       | 18669   (1)| 00:03:45 |
|   3 |    SORT GROUP BY                      |                           | 2911 |   332K|       | 18660   (1)| 00:03:44 |
|   4 |     VIEW                              |                           | 2911 |   332K|       | 18659   (1)| 00:03:44 |
|   5 |      SORT UNIQUE                      |                           | 2911 |   292K|       | 18659   (6)| 00:03:44 |
|   6 |       UNION-ALL                       |                           |       |       |       |            |          |
|* 7 |        HASH JOIN                      |                           | 2907 |   292K| 2160K| 17762   (1)| 00:03:34 |
|   8 |         TABLE ACCESS FULL             | GENEATTRIBUTES10650       | 40957 | 1679K|       |   795   (1)| 00:00:10 |
|* 9 |         HASH JOIN                     |                           | 53794 | 3204K| 1552K| 16675   (1)| 00:03:21 |
|* 10 |          HASH JOIN                    |                           | 37802 | 1107K|       | 12326   (1)| 00:02:28 |
|* 11 |           HASH JOIN                   |                           | 37945 |   629K|       | 10874   (1)| 00:02:11 |
| 12 |            INDEX FAST FULL SCAN       | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|       |    33   (0)| 00:00:01 |
| 13 |            INDEX FAST FULL SCAN       | AASEQUENCEIMP_REVIX6      | 7886K|    82M|       | 10816   (1)| 00:02:10 |
|* 14 |           TABLE ACCESS FULL           | TAXON                     |   514K| 6530K|       | 1450   (1)| 00:00:18 |
| 15 |          TABLE ACCESS FULL            | TAXONNAME                 |   760K|    22M|       | 2721   (1)| 00:00:33 |
|* 16 |        HASH JOIN                      |                           |     4 |   380 |       |   886   (1)| 00:00:11 |
| 17 |         NESTED LOOPS                  |                           |   730 | 64970 |       |   852   (1)| 00:00:11 |
|* 18 |          HASH JOIN                    |                           |     1 |    78 |       |   847   (1)| 00:00:11 |
| 19 |           NESTED LOOPS                |                           |       |       |       |            |          |
| 20 |            NESTED LOOPS               |                           |    17 |   612 |       |    51   (0)| 00:00:01 |
| 21 |             TABLE ACCESS FULL         | TAXONSPECIES10646         |    12 |    60 |       |     3   (0)| 00:00:01 |
|* 22 |             INDEX RANGE SCAN          | TAXONNAME_IND01           |     1 |       |       |     2   (0)| 00:00:01 |
| 23 |            TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |       |     4   (0)| 00:00:01 |
| 24 |           TABLE ACCESS FULL           | GENEATTRIBUTES10650       | 40957 | 1679K|       |   795   (1)| 00:00:10 |
|* 25 |          INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |   768 | 8448 |       |     5   (0)| 00:00:01 |
| 26 |         INDEX FAST FULL SCAN          | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|       |    33   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   7 - access("GA"."ORGANISM"="TN"."NAME")
   9 - access("TN"."TAXON_ID"="T"."TAXON_ID")
10 - access("T"."TAXON_ID"="TAXON_ID")
11 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
14 - filter("T"."RANK"<>'species')
16 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
18 - access("GA"."ORGANISM"="TN"."NAME")
22 - access("TN"."TAXON_ID"="TS"."TAXON_ID")
25 - access("TS"."TAXON_ID"="TAXON_ID")
46 rows selected.With the CREATE TABLE, the plan for the SELECT alone looks like this:
| Id | Operation                           | Name                      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                           |     2 |   234 | 1786   (1)| 00:00:22 |
|   1 | SORT GROUP BY                      |                           |     2 |   234 | 1786   (1)| 00:00:22 |
|   2 |   VIEW                              |                           |     2 |   234 | 1785   (1)| 00:00:22 |
|   3 |    SORT UNIQUE                      |                           |     2 |   198 | 1785 (48)| 00:00:22 |
|   4 |     UNION-ALL                       |                           |       |       |            |          |
|* 5 |      HASH JOIN                      |                           |     1 |   103 |   949   (1)| 00:00:12 |
|   6 |       NESTED LOOPS                  |                           |   199 | 19303 |   915   (1)| 00:00:11 |
|   7 |        NESTED LOOPS                 |                           |    13 | 1118 |   850   (1)| 00:00:11 |
|   8 |         NESTED LOOPS                |                           |    13 |   949 |   824   (1)| 00:00:10 |
|   9 |          VIEW                       | VW_DTP_E387155E           |    13 |   546 |   797   (1)| 00:00:10 |
| 10 |           HASH UNIQUE               |                           |    13 |   546 |   797   (1)| 00:00:10 |
| 11 |            TABLE ACCESS FULL        | GENEATTRIBUTES10650       | 40957 | 1679K|   795   (1)| 00:00:10 |
| 12 |          TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |     3   (0)| 00:00:01 |
|* 13 |           INDEX RANGE SCAN          | TAXONNAME_IND02           |     1 |       |     2   (0)| 00:00:01 |
|* 14 |         TABLE ACCESS BY INDEX ROWID | TAXON                     |     1 |    13 |     2   (0)| 00:00:01 |
|* 15 |          INDEX UNIQUE SCAN          | PK_TAXON                  |     1 |       |     1   (0)| 00:00:01 |
|* 16 |        INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |    15 |   165 |     5   (0)| 00:00:01 |
| 17 |       INDEX FAST FULL SCAN          | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|    33   (0)| 00:00:01 |
| 18 |      NESTED LOOPS                   |                           |     1 |    95 |   834   (1)| 00:00:11 |
| 19 |       NESTED LOOPS                  |                           |     1 |    89 |   833   (1)| 00:00:10 |
|* 20 |        HASH JOIN                    |                           |     1 |    78 |   828   (1)| 00:00:10 |
| 21 |         NESTED LOOPS                |                           |       |       |            |          |
| 22 |          NESTED LOOPS               |                           |    13 |   949 |   824   (1)| 00:00:10 |
| 23 |           VIEW                      | VW_DTP_2AAE9FCE           |    13 |   546 |   797   (1)| 00:00:10 |
| 24 |            HASH UNIQUE              |                           |    13 |   546 |   797   (1)| 00:00:10 |
| 25 |             TABLE ACCESS FULL       | GENEATTRIBUTES10650       | 40957 | 1679K|   795   (1)| 00:00:10 |
|* 26 |           INDEX RANGE SCAN          | TAXONNAME_IND02           |     1 |       |     2   (0)| 00:00:01 |
| 27 |          TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |     3   (0)| 00:00:01 |
| 28 |         TABLE ACCESS FULL           | TAXONSPECIES10646         |    12 |    60 |     3   (0)| 00:00:01 |
|* 29 |        INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |   768 | 8448 |     5   (0)| 00:00:01 |
|* 30 |       INDEX RANGE SCAN              | SECONDARYSTRUCTURE_REVIX9 |     1 |     6 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   5 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
13 - access("ITEM_1"="TN"."NAME")
14 - filter("T"."RANK"<>'species')
15 - access("TN"."TAXON_ID"="T"."TAXON_ID")
16 - access("T"."TAXON_ID"="TAXON_ID")
20 - access("TN"."TAXON_ID"="TS"."TAXON_ID")
26 - access("ITEM_1"="TN"."NAME")
29 - access("TS"."TAXON_ID"="TAXON_ID")
30 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
50 rows selected.Edited by: JohnI on Jul 18, 2011 2:19 PM
Edited by: JohnI on Jul 18, 2011 2:28 PM

Charles Hooper wrote a series of blog entries on a similar topic some time ago: http://hoopercharles.wordpress.com/2010/12/15/select-statement-is-fast-insert-into-using-the-select-statement-is-brutally-slow-1/ (including a lot of useful comments) and two following articles. I have to confess that I did not read the posts again - but I think you will find some good ideas how to analyze the problem.
Regards
Martin Preiss

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

How do you view the execution plan of a query?

I want to see if a particular index was used for a specific query....

Becareful. You are in the Forum of OBIEE. It's much more a database question.
You can read an plan with a lot of tool. Toad permit it and I assume that Sql Developer also must give it.
Otherwise, you can use the basic command of Oracle as explain plan :
http://gerardnico.com/wiki/database/oracle/explain_plan
Cheers
Nico

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.

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/

Explain plan for running query

Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
Shareef

912856 wrote:
Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
ShareefYOu can also use dbms_xplain to generate plan used in v$sql. like for example
SQL>SELECT SQL_ID, CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select * from em%';
SQL_ID CHILD_NUMBER
6kd5fkqdjb8fu 0
SQL>SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('6kd5fkqdjb8fu',0,'ALLSTATS'));If you need the actual tuntime statistics used by sql statement then you need to put hint /*+ gather_plan_statistics */ in sql ststement, something like
select /*+ gather_plan_statistics */ * from emp;
and then generate the explain plan for this
Have a look
http://hoopercharles.wordpress.com/2010/03/01/dbms_xplan-format-parameters/
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

Explain Plan understand technique & Query optimizing check list

Hello gurus,
Can some body help me with doc available or your experience to tell on how to understand Explain Plan & Query optimizing check list.
Thanks..

That's correct,
But unfortunately the institute is pretty far from home.. and travelling time will be high..
I am a working man..
Please suggest if some good book or link.
Thanks.

Impact on undo_retention on plan of a query ..

Similar Messages

Maybe you are looking for