EXPLAIN PLAN, TKPROF AUTO TRACE usages in detail please

Hi,
Can you please suggest me with some examples to tune the query with better performance.
Thanks,
Lakshman.

If the docs given in your other thread is not enough, take a look to this one :
When your query takes too long ...
Nicolas.

Similar Messages

  • [8i] Can someone help me on using explain plan, tkprof, etc.?

    I am trying to follow the instructions at When your query takes too long ...
    I am trying to figure out why a simple query takes so long.
    The query is:
    SELECT COUNT(*) AS tot_rows FROM my_table;It takes a good 5 minutes or so to run (best case), and the result is around 22 million (total rows).
    My generic username does not (evidently) allow access to PLAN_TABLE, so I had to log on as SYSTEM to run explain plan. In SQL*Plus, I typed in:
    explain plan for (SELECT COUNT(*) AS tot_rows FROM my_table);and the response was "Explained."
    Isn't this supposed to give me some sort of output, or am I missing something?
    Then, the next step in the post I linked is to use tkprof. I see that it says it will output a file to a path specified in a parameter. The only problem is, I don't have access to the db's server. I am working remotely, and do not have any way to remotely (or directly) access the db server. Is there any way to have the file output to my local machine, or am I just S.O.L.?

    SomeoneElse used "create table as" (CTAS), wich automatically gathers the stats. You can see the differende before and after stats clearly in this example.
    This is the script:
    drop table ttemp;
    create table ttemp (object_id number not null, owner varchar2(30), object_name varchar2(200));
    alter table ttemp add constraint ttemp_pk primary key (object_id);
    insert into ttemp
    select object_id, owner, object_name
    from dba_objects
    where object_id is not null;
    set autotrace on
    select count(*) from ttemp;
    exec dbms_stats.gather_table_stats('PROD','TTEMP');
    select count(*) from ttemp;And the result:
    Table dropped.
    Table created.
    Table altered.
    46888 rows created.
      COUNT(*)
         46888
    1 row selected.
    Execution Plan
               SELECT STATEMENT Optimizer Mode=CHOOSE
       1         SORT AGGREGATE
       2    1      TABLE ACCESS FULL PROD.TTEMP
    Statistics
              1  recursive calls
              1  db block gets
            252  consistent gets
              0  physical reads
            120  redo size
              0  PX remote messages sent
              0  PX remote messages recv'd
              0  buffer is pinned count
              0  workarea memory allocated
              4  workarea executions - optimal
              1  rows processed
    PL/SQL procedure successfully completed.
      COUNT(*)
         46888
    1 row selected.
    Execution Plan
               SELECT STATEMENT Optimizer Mode=CHOOSE (Cost=4 Card=1)
       1         SORT AGGREGATE (Card=1)
       2    1      INDEX FAST FULL SCAN PROD.TTEMP_PK (Cost=4 Card=46 K)
    Statistics
              1  recursive calls
              2  db block gets
            328  consistent gets
              0  physical reads
           8856  redo size
              0  PX remote messages sent
              0  PX remote messages recv'd
              0  buffer is pinned count
              0  workarea memory allocated
              4  workarea executions - optimal
              1  rows processed

  • Need help understanding Explain Plan from 10046 trace

    Below is a query and Explain Plan from a 10046 trace shown with trcanlzr.sql.
    In the explain plan I don't understand what's happining at line ID 10 and 11. Specifically, is the result at line 11 rowids from lines 12 & 14? and then what? Are those rowids somehow used in line ID 10?
    SELECT cp.cred_process_id, cp.provider_id,
           brdg_credentialing.get_appl_specialist(cp.cred_process_id,'R') specialist_name,
           brdg_cred_report_pkg.provider_name(cp.cred_process_id) provider_name,
           ctc_apptype.description appl_type_desc,
           TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)) init_received_dt,
           brdg_code_util.code_descr(brdg_credentialing.get_appl_status_cd_ctc_id(cp.cred_process_id)) appl_status_desc,
           brdg_credentialing.get_appl_prac_specialties(cp.cred_process_id,'Y') primary_specialty,
           cwh.city practice_city,
           UPPER (cwh.state) practice_state,
           TRUNC (ch.event_dt) specialist_assign_dt,
           DECODE (ctc_apptype.code,'INITPPO', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
                   'REAPP', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
                   'SPECCRED', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
                   'TRANS', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
                   'RECPPO', p.next_recred_dt,
                   'RECAPP', p.next_recred_dt, NULL) sort_date,
                   p.next_recred_dt
      FROM brdg_cred_app_open_vw cp,
           brdg_cat_type_codes ctc_apptype,
           brdg_cred_work_history cwh,
           brdg_cred_history ch,
           brdg_providers p
    WHERE cp.type_cd_ctc_id = ctc_apptype.cat_type_code_id
       AND ctc_apptype.category_cd = 'CRED'
       AND ctc_apptype.type_cd = 'APPTYPE'
       AND cp.cred_process_id = cwh.cred_process_id (+)
       AND cwh.primary_practice_flag (+) = 'Y'
       AND cp.cred_process_id = ch.cred_process_id
       AND ch.cred_history_id = (SELECT MAX(cred_history_id)
                                   FROM brdg_cred_history
                                  WHERE cred_process_id = cp.cred_process_id
                                    AND event_cd_ctc_id = brdg_credentialing.get_event_ctc_id ('SEVENT','SPESTCHG'))
       AND cp.provider_id = p.provider_id (+)
       and brdg_credentialing.get_appl_specialist_id(cp.cred_process_id) = 5
    ORDER BY 3 ASC, 3, 5, 12, 6
            Explain Plan Operation
    ID   PID    Card     Rows    Cost      SearchCols  /   Indexed Cols     Predicates 
    0:    1                       36   SELECT STATEMENT   
    1:    0     1       139       36    SORT ORDER BY   
    2:    1             139            . FILTER   [+]  
    3:    2     1       311       11   .. NESTED LOOPS OUTER   
    4:    3     1       311       10   ... NESTED LOOPS OUTER   
    5:    4     1       311        9   .... NESTED LOOPS   
    6:    5     1       311        8   ....+ NESTED LOOPS   
    7:    6     4        16        1   ....+. TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES   
    8:    7     4        16        1   ....+.. INDEX RANGE SCAN CAT_TYPE_CODE_UK 2/3 [+]   [+]  
    9:    6     1       311        2   ....+. TABLE ACCESS BY INDEX ROWID CRED_PROCESSES   [+]  
    10:    9   183     61927        1   ....+.. INDEX RANGE SCAN CDPR_CTCD_FK1 1/1 [+]   [+]  
    11:   10     1         3        2   ....+... NESTED LOOPS   
    12:   11     1        16        1   ....+.... TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES   
    13:   12     1        16        1   ....+....+ INDEX UNIQUE SCAN CTCD_PK 1/1 [+]   [+]  
    14:   11     1         3        1   ....+.... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]  
    15:    5     1        11        1   ....+ TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]  
    16:   15     1       311        1   ....+. INDEX UNIQUE SCAN CDHT_PK 1/1 [+]   [+]  
    17:   16     1       311            ....+.. SORT AGGREGATE   
    18:   17     1       526        2   ....+... TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]  
    19:   18    23      9950        1   ....+.... INDEX RANGE SCAN CDHT_CDPR_FK 1/1 [+]   [+]  
    20:    4     1       219        1   .... TABLE ACCESS BY INDEX ROWID PROVIDERS   
    21:   20     1       219        1   ....+ INDEX UNIQUE SCAN PROV_PK 1/1 [+]  [+]  
    22:    3     1       311        1   ... TABLE ACCESS BY INDEX ROWID CRED_WORK_HISTORY   [+] 
    23:   22     3      1057        1   .... INDEX RANGE SCAN CDWH_CDPR_FK 1/1 [+]   [+]  
    24:    2   172                      .. INLIST ITERATOR   
    25:   24     1       172        1   ... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]  
    26:    2     1         0        2   .. TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]  
    27:   26    23      2004        1   ... INDEX RANGE SCAN CDHT_CDPR_FK 1/1 [+]   [+]  
    (1) X/Y: Where X is the number of searched columns from index, which has a total of Y columns.
    (2) Actual rows returned by operation (average if there were more than 1 execution).
       2 - filter( NOT EXISTS (SELECT 0 FROM "PPO"."CAT_TYPE_CODES" "BRDG_CAT_TYPE_CODES" WHERE
                  "CODE"="BRDG_CODE_UTIL"."ID_CODE"("BRDG_CREDENTIALING"."GET_APPL_STATUS_CD_CTC_ID"(:B1)) AND
                  ("TYPE_CD"='APPROVAL' OR "TYPE_CD"='DENIED' OR "TYPE_CD"='INACTIVE' OR "TYPE_CD"='TERMED') AND
                  "CATEGORY_CD"='APPSTAT') AND  NOT EXISTS (SELECT 0 FROM "PPO"."CRED_HISTORY" "BRDG_CRED_HISTORY"
                  WHERE "CRED_PROCESS_ID"=:B2 AND "EVENT_CD_CTC_ID"="BRDG_CODE_UTIL"."GET_ID"('CRED','SEVENT','MSODC
       8 - access("CTC_APPTYPE"."CATEGORY_CD"='CRED' AND "CTC_APPTYPE"."TYPE_CD"='APPTYPE')
       9 - filter("BRDG_CREDENTIALING"."GET_APPL_SPECIALIST_ID"("CP"."CRED_PROCESS_ID")=5 AND
                  ("CP"."INS_DT">=TO_DATE(' 2007-12-20 17:00:00', 'syyyy-mm-dd hh24:mi:ss') OR
                  "CP"."TYPE_CD_CTC_ID"<>"BRDG_CODE_UTIL"."GET_ID"('CRED','APPTYPE','RECPPO')))
      10 - access("CP"."TYPE_CD_CTC_ID"="CTC_APPTYPE"."CAT_TYPE_CODE_ID")
           filter( NOT EXISTS (SELECT 0 FROM "PPO"."CAT_TYPE_CODES"
                  "CTC_APPTYPE","PPO"."CAT_TYPE_CODES" "CTC_TYPE" WHERE "CTC_TYPE"."CAT_TYPE_CODE_ID"=:B1 AND
                  "CTC_TYPE"."CODE"="CTC_APPTYPE"."CODE" AND "CTC_APPTYPE"."TYPE_CD"='APPSENT' AND
                  "CTC_APPTYPE"."CATEGORY_CD"='APPTYPE'))
      13 - access("CTC_TYPE"."CAT_TYPE_CODE_ID"=:B1)
      14 - access("CTC_APPTYPE"."CATEGORY_CD"='APPTYPE' AND "CTC_APPTYPE"."TYPE_CD"='APPSENT' AND
                  "CTC_TYPE"."CODE"="CTC_APPTYPE"."CODE")
      15 - filter("CP"."CRED_PROCESS_ID"="CH"."CRED_PROCESS_ID")
      16 - access("CH"."CRED_HISTORY_ID"= (SELECT MAX("CRED_HISTORY_ID") FROM "PPO"."CRED_HISTORY"
                  "BRDG_CRED_HISTORY" WHERE "CRED_PROCESS_ID"=:B1 AND
                  "EVENT_CD_CTC_ID"="BRDG_CREDENTIALING"."GET_EVENT_CTC_ID"('SEVENT','SPESTCHG')))
      18 - filter("EVENT_CD_CTC_ID"="BRDG_CREDENTIALING"."GET_EVENT_CTC_ID"('SEVENT','SPESTCHG'))
      19 - access("CRED_PROCESS_ID"=:B1)
      21 - access("CP"."PROVIDER_ID"="P"."PROVIDER_ID"(+))
      22 - filter("CWH"."PRIMARY_PRACTICE_FLAG"(+)='Y')
      23 - access("CP"."CRED_PROCESS_ID"="CWH"."CRED_PROCESS_ID"(+))
      25 - access("CATEGORY_CD"='APPSTAT' AND ("TYPE_CD"='APPROVAL' OR "TYPE_CD"='DENIED' OR
                  "TYPE_CD"='INACTIVE' OR "TYPE_CD"='TERMED') AND "CODE"="BRDG_CODE_UTIL"."ID_CODE"("BRDG_CREDENTIAL
                  ING"."GET_APPL_STATUS_CD_CTC_ID"(:B1)))
      26 - filter("EVENT_CD_CTC_ID"="BRDG_CODE_UTIL"."GET_ID"('CRED','SEVENT','MSODC'))
      27 - access("CRED_PROCESS_ID"=:B1)

    Welcome to the forums!
    user11987210 wrote:
    In the explain plan I don't understand what's happining at line ID 10 and 11. Specifically, is the result at line 11 rowids from lines 12 & 14? and then what? Are those rowids somehow used in line ID 10?
    9:    6     1       311        2   ....+. TABLE ACCESS BY INDEX ROWID CRED_PROCESSES   [+]  
    10:    9   183     61927        1   ....+.. INDEX RANGE SCAN CDPR_CTCD_FK1 1/1 [+]   [+]  
    11:   10     1         3        2   ....+... NESTED LOOPS   
    12:   11     1        16        1   ....+.... TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES   
    13:   12     1        16        1   ....+....+ INDEX UNIQUE SCAN CTCD_PK 1/1 [+]   [+]  
    14:   11     1         3        1   ....+.... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]   The NESTED LOOPS operation (ID #11) has two children, ID #12 sometimes called the driving source, and ID #14 the inner loop. ID #14 is executed once for each row returned by ID #12. The results of ID #11 are then fed to ID #10 which performs an INDEX RANGE SCAN.
    Hope this helps!

  • Explain Plan from TKPROF trace file.

    Hello,
    My procedure is taking time for that i have trace on in procedure fo find explain plan of particular query.
    Using below statement Trace is on.
       EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE = TRUE';
       EXECUTE IMMEDIATE 'ALTER SESSION SET TIMED_STATISTICS = TRUE';Now for getting expalin plan from TKPROF i have used below statement but for some query i have found explain paln and some case i cant found explain plan.
    tkprof mf_ora_23773.trc mf_ora_23773.txt explain =abc/abc
    can u please help me to analyze where i m wrong?
    Thanks.

    First of all, you should best avoid using the explain= clause on the tkprof command line.
    This will run explain plan on the statement in the trace file, and that explain plan can even be wrong, as there is no information on datatypes in the trace file.
    The real explain plan data is flushed to the trace file, when the program issues commit or rollback. Oracle always issues an implicit commit when the program disconnects, so when you run the program to completion you should have explain plan output in your trace files.
    You won't get explain plan output if you don't have access to the objects in the SQL statement. Also recursive SQL won't produce explain plan result.
    One would need to see part of your trace file to verify your assertion the explain clause doesn't always work.
    Sybrand Bakker
    Senior Oracle DBA

  • How to proceed further once the explain plan and trace files are generated?

    Hi Friends,
    I need to improve the performance of on of the views that i am working on.
    As suggested in the thread - http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0 , i gave generated the explain plan and the trace file.
    From the explain plan, we can see the expensive operations for the query.
    Can any one please tell, how to proceed further from here on i.e. how to make this expensive operations less expensive?
    For ex: FULL TABLE SCAN might be an expensive operation when the table has indexes.In such cases, how can we avoid such operations to make query faster?
    Regards,
    Sreekanth Munagala.

    Hi Veena,
    An earlier post by you regarding P45 is as below
    Starter report P45(3) / P46 efiling for UK
    from my understanding though i have not worked on GB Payroll you have said that you deleted IT 65 details of leaver,however there must be clusters generated in system from where the earlier data needs to be deleted and may be that is why you are facing the issue.
    In Indian payroll when we execute text file for efiling of tax after challan mapping all the data compiles and sits in PCL cluster and therefore we are unable to generate form 16 with proper output,here we delete the clusters and rerun again the mappings and then check form 16.
    Hope this might help you,Experts have suggested you earlier also,they may correct me for this.
    Salil

  • Cost in Explain Plan

    Hi all,
    Is the "COST" column in explain plan CPU or MEMORY usage cost? or both
    Thanks

    I am not sure this is also documented with same detail level.
    http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/optimops.htm#sthref860 says:
    >
    The cost is an estimated value proportional to the expected resource use needed to execute the statement with a particular plan. The optimizer calculates the cost of access paths and join orders based on the estimated computer resources, which includes I/O, CPU, and memory.
    >
    and http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/ex_plan.htm#sthref1110 says
    >
    Cost of the operation as estimated by the optimizer's query approach. Cost is not determined for table access operations. The value of this column does not have any particular unit of measurement; it is merely a weighted value used to compare costs of execution plans. The value of this column is a function of the CPU_COST and IO_COST columns.
    >
    Edited by: P. Forstmann on 6 avr. 2011 08:38

  • How can i paste the explain plan from toad..

    Hello all
    I tried taking a snap of the explain plan from toad but in this forum the paste option is disabled...please help

    964145 wrote:
    I tried taking a snap of the explain plan from toad but in this forum the paste option is disabled...please helpI don't know, but it is a waste of time since explain plans from Toad are not useful.
    Please read the forum FAQ on providing information for a tuning request, it describes how to generate an explain plan that can be shared.
    {message:id=9360003}
    This is an example.
    SQL> explain plan for
      2  select * from dual;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3543395131
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
    --------------------------------------------------------------------------

  • Explain plan output format

    Dear All,
    Please let me know how to publish my explain plan output properly here. Earlier i used [code]  .....  [/code]
    Thanks,
    Kods

    Who knows?
    Are you just looking at random explain plans to find a problem?
    Or did you look at the explain plan for a specific performance problem?
    Please format code and explain plan output with code tags.
    See also this thread, How to post a SQL tuning request:
    HOW TO: Post a SQL statement tuning request - template posting
    At the end of the day are the row estimates accurate?
    If they are, then everything's probably ok.
    If not, then everything might be ok or it might not be.
    Merge Join Cartesian + Buffer Sort operations are often, but not always, an indication of a problem particularly when the associated estimates are inaccurate for whatever reason.

  • Oem explain plan produced doesn't correspond to explain plan with tkprof

    Hello all,
    I am running OEM on a 10.2.0.3 database and I have a very slow query with cognos 8 BI on my data warehouse.
    I went to the dbconsole through OEM and connected to target database I went to look at the query execution and then got an explain plan.
    Then I did a trace file and ran it throught tkprof.
    When I look at both produced explain plan, I can see the tree looks the same exept the corresponding values. In OEM, it says I am going throug 18000 rows and in the tkprof result it says more like millions of records.
    As anybody had these kind of results?
    Shall I have more confidence in TKprof then OEM?
    It is very important to me since I am being chalanged by an external DBA.

    I would recommend you to get Christian Antogini´s book "Troublshooting Oracle Performance", (http://www.antognini.ch/top/) which explains everything you need to know when analyzing Oracle SQL Performance and Explain Plans.
    If you properly trace your SQL Statement, you will get "STAT" lines in the trace file. These stat lines show you the actual number of rows processed per row source operation. Explain plan per default does only show you the "estimated" row counts for the row source operations no matter whether you use "explain=" in the tkprof call or OEM to get the explain plan. Tkprof reads the STAT lines from the trace and outputs a section which is similar to an execution plan but contains the "real" number of rows.
    However, if you want to troubleshoot Oracle Performance, I would recommend you to run the statement with the hint /*+ GATHER_PLAN_STATISTICS */ or set statistics_level=ALL in your session (not database-wide!).
    If you do, you can get an excellent execution plan with DBMS_XPLAN.DISPLAY_CURSOR containing both estimated rows as well as actual rows combined with the "number of starts" for e.g. nested loop joins.
    Get the book, read it, and you will be able to discuss this issue with your external dba in a professional way. ;-)
    Regards,
    Martin
    www.ora-solutions.net

  • Why tkprof did not show explain plan for some sql statements

    Hi,
    I did a trace for one of the session, hoping to find the explain plan for its tkprof. However, I only get this:
    INSERT INTO AUDIT_TABLE
    VALUES
    ( :B1 , :B2 , :B3 , :B4 , :B5 , :B6 , :B8 , :B7 )
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute   3698      8.08      59.41       3348        566      19092        3698
    Fetch        0      0.00       0.00          0          0          0           0
    total     3699      8.08      59.42       3348        566      19092        3698
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: CHOOSE
    Parsing user id: 30     (recursive depth: 2)
    ********************************************************************************Any idea why the explain plan is missing?
    Also looking at the above statistics, what can I conclude?

    Thanks John. What's ur take on this statistics then?
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute   1798     12.23      36.75       1758       5404       7418        1798
    Fetch        0      0.00       0.00          0          0          0           0
    total     1798     12.23      36.75       1758       5404       7418        1798
    Misses in library cache during parse: 0
    Optimizer mode: CHOOSE
    Parsing user id: 30     (recursive depth: 1)
    ********************************************************************************

  • Explain plan not displayed in sql trace file

    Hello,
    I don't understand why in sql trace file, after tkprof transformation, for several queries the explain plan is displayed and for several queries, no explain plan is displayed.
    How can I have the explain plan for all queries?
    Thanks for your help.

    Was this a trace started on an already running task? Was the trace stopped before the task completed? Did the trace file reach its set size limit before the task compled?
    In all three cases above you would have cursors that were not closed and stats information not written to the trace file resulting in incomplete data for some SQL.
    HTH -- Mark D Powell --

  • Does bigger explain plan in TKPROF output indicate something wrong with SQL

    We were tracing some database sessions.
    Using TKPROF we were able to read the trace file.
    we have noticed that some of the SQL ( 1-2 lines SQL statements) were showing up atleast
    150 lines of explain plan.
    So we realized that the sql statements are badly written.
    Based on that above can we come into the following conclusion:
    - for 1-2 lines of SQL Statement if there is 100+ lines of explain plan in TKPROF report, it indicates the SQL statement
    is wrongly written ?

    johnpau2013 wrote:
    We were tracing some database sessions.
    Using TKPROF we were able to read the trace file.
    we have noticed that some of the SQL ( 1-2 lines SQL statements) were showing up atleast
    150 lines of explain plan.
    So we realized that the sql statements are badly written.
    Based on that above can we come into the following conclusion:
    - for 1-2 lines of SQL Statement if there is 100+ lines of explain plan in TKPROF report, it indicates the SQL statement
    is wrongly written ?The only rule that is always true for tuning SQL, is that NO rule is ALWAYS true for every SQL statement &
    every data distribution.
    it depends
    post actual example, so we can see what you see.

  • Reg:Tkprof, awr, explain plan, autotrace analysis

    hi friends.
    can any one give description about below subject..........
    Tkprof,
    awr,
    explain plan,
    autotrace analysis
    if possible kindly mentioned some example for each OR provide some to read.
    regards,
    Rajnish

    They're all described in the Oracle Documentation, example:
    http://www.oracle.com/pls/db112/search?remark=quick_search&word=AWR&partno=
    Look in the [Performance Tuning Guide|http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/toc.htm] for examples/exaplanations.
    Randolf Geist sums it all up very nice here: http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
    More examples can be found on http://asktom.oracle.com
    and on this forum by simply doing a search.

  • OEM explain plan sown on SQL Details vs Tuning Advisor

    In OEM, if I go to "Top SQL" and then get the "SQL Details" for a specific SQL Id there is a tab which shows the execution plan.
    For the SQL I'm interested in, this plan shows very low values for cost, number of rows, etc. It also shows all table access being through indexes. It shows no values in the Time column.
    Now on this page, if I click the button "Run SQL Tuning Advisor" and run an advisor it comes back with a recommendation that I'll ignore for now. Here's my real question. On the recommendations page there is a button "Original Explain Plan". If I click this the execution plan I get is similar but not exactly the same as the one I mentioned above on the SQL Details page. This one has very high values for cost, number of rows, etc. Some of the tables show as not using indexes.
    What are the differences between these 2 pages? Is the first one an estimated plan and the second one the actual?
    I've searched trying to find an explanation for this, but haven't. Thanks for any help explaining this.

    I tired running SQL Tuning Advisor with DBMS_SQLTUNE package, I think the output will help you understand.
    Oracle 10g SQL Tuning
    Adith

  • Virtual column partitioning - explain plan takes lot of time.

    I have some problem with table with partitioning based on virtual column.
    Explain plan generates for some simple select 2-5 minutes,
    but the same select but without part of where clausule generate in secounds.
    In both query there is the same explain plan.
    Could someone explain why?
    Table:
    CREATE TABLE "SUBSCRIPTION"
    "CUSTOMER_ID" VARCHAR2(100 BYTE),
    "IDENT_SOURCE_ID" VARCHAR2(20 BYTE),
    "ACCOUNT_ID" VARCHAR2(100 BYTE),
    "MSISDN" VARCHAR2(500 BYTE),
    "IMSI" VARCHAR2(500 BYTE),
    "SIM" VARCHAR2(500 BYTE),
    "IMEI" VARCHAR2(500 BYTE),
    "MEID" VARCHAR2(15 BYTE),
    "EMAIL" VARCHAR2(100 BYTE),
    "TELCOOP" VARCHAR2(1000 BYTE),
    "MSISDN_TYPE" VARCHAR2(20 BYTE),
    "GSM" NUMBER(1,0),
    "CDMA" NUMBER(1,0),
    "VALID_FROM" DATE,
    "VALID_TO" DATE,
    "MSISDN_HASH" NUMBER(3,0) GENERATED ALWAYS AS (MOD(TO_NUMBER(NVL2(RTRIM(TRANSLATE(NVL(SUBSTR("MSISDN",-3),NVL("MSISDN",'err')),'123456789','000000000'),'0'),'-1',NVL(SUBSTR("MSISDN",-3),"MSISDN"))),125)) VIRTUAL VISIBLE, --generali mod from 3 last digits of msisdn
    ) PARTITION BY LIST ( "MSISDN_HASH" )
    PARTITION "PCHR" VALUES ( -1 )
    PARTITION "P000" VALUES ( 0 )
    PARTITION "P001" VALUES ( 1 )
    ... and so on till...
    PARTITION "P124" VALUES (124)
    PARALLEL 4;
    Slow select:
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from dbident2.subscription
    where MSISDN = '600489461'
    AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    Fast select:
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from dbident2.subscription
    where MSISDN = '600489461'
    AND MSISDN_HASH = 86

    --Slower select trace:
    Registered qb: SEL$1 0xf4ea2a20 (PARSER)
    QUERY BLOCK SIGNATURE
    signature (): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=4 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
    SPM: statement not found in SMB
    SPM: statement not a candidate for auto-capture
    Dynamic sampling level auto-adjusted from 6 to 6
    Automatic degree of parallelism (ADOP)
    Automatic degree of parallelism is disabled: Parameter.
    PM: Considering predicate move-around in query block SEL$1 (#0)
    Predicate Move-Around (PM)
    OPTIMIZER INFORMATION
    ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
    explain plan for
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    Legend
    The following abbreviations are used by optimizer trace.
    CBQT - cost-based query transformation
    JPPD - join predicate push-down
    OJPPD - old-style (non-cost-based) JPPD
    FPD - filter push-down
    PM - predicate move-around
    CVM - complex view merging
    SPJ - select-project-join
    SJC - set join conversion
    SU - subquery unnesting
    OBYE - order by elimination
    OST - old style star transformation
    ST - new (cbqt) star transformation
    CNT - count(col) to count(*) transformation
    JE - Join Elimination
    JF - join factorization
    SLP - select list pruning
    DP - distinct placement
    qb - query block
    LB - leaf blocks
    DK - distinct keys
    LB/K - average number of leaf blocks per key
    DB/K - average number of data blocks per key
    CLUF - clustering factor
    NDV - number of distinct values
    Resp - response cost
    Card - cardinality
    Resc - resource cost
    NL - nested loops (join)
    SM - sort merge (join)
    HA - hash (join)
    CPUSPEED - CPU Speed
    IOTFRSPEED - I/O transfer speed
    IOSEEKTIM - I/O seek time
    SREADTIM - average single block read time
    MREADTIM - average multiblock read time
    MBRC - average multiblock read count
    MAXTHR - maximum I/O system throughput
    SLAVETHR - average slave I/O throughput
    dmeth - distribution method
    1: no partitioning required
    2: value partitioned
    4: right is random (round-robin)
    128: left is random (round-robin)
    8: broadcast right and partition left
    16: broadcast left and partition right
    32: partition left using partitioning of right
    64: partition right using partitioning of left
    256: run the join in serial
    0: invalid distribution method
    sel - selectivity
    ptn - partition
    PARAMETERS USED BY THE OPTIMIZER
    PARAMETERS WITH ALTERED VALUES
    Compilation Environment Dump
    pgamax_size = 1258280 KB
    parallel_query_default_dop = 32
    db_file_multiblock_read_count = 16
    Bug Fix Control Environment
    PARAMETERS IN OPT_PARAM HINT
    Column Usage Monitoring is ON: tracking level = 1
    Considering Query Transformations on query block SEL$1 (#0)
    Query transformations (QT)
    JF: Checking validity of join factorization for query block SEL$1 (#0)
    JF: Bypassed: not a UNION or UNION-ALL query block.
    ST: not valid since star transformation parameter is FALSE
    TE: Checking validity of table expansion for query block SEL$1 (#0)
    TE: Bypassed: No relevant table found.
    CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
    CBQT: Validity checks failed for afjvvjmx6tqgr.
    CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
    Common Subexpression elimination (CSE)
    CSE: CSE not performed on query block SEL$1 (#0).
    OBYE: Considering Order-by Elimination from view SEL$1 (#0)
    Order-by elimination (OBYE)
    OBYE: OBYE bypassed: no order by to eliminate.
    CVM: Considering view merge in query block SEL$1 (#0)
    query block SEL$1 (#0) unchanged
    Considering Query Transformations on query block SEL$1 (#0)
    Query transformations (QT)
    JF: Checking validity of join factorization for query block SEL$1 (#0)
    JF: Bypassed: not a UNION or UNION-ALL query block.
    ST: not valid since star transformation parameter is FALSE
    TE: Checking validity of table expansion for query block SEL$1 (#0)
    TE: Bypassed: No relevant table found.
    CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
    CBQT: Validity checks failed for afjvvjmx6tqgr.
    CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
    Common Subexpression elimination (CSE)
    CSE: CSE not performed on query block SEL$1 (#0).
    SU: Considering subquery unnesting in query block SEL$1 (#0)
    Subquery Unnest (SU)
    SJC: Considering set-join conversion in query block SEL$1 (#0)
    Set-Join Conversion (SJC)
    SJC: not performed
    PM: Considering predicate move-around in query block SEL$1 (#0)
    Predicate Move-Around (PM)
    PM: PM bypassed: Outer query contains no views.
    PM: PM bypassed: Outer query contains no views.
    query block SEL$1 (#0) unchanged
    FPD: Considering simple filter push in query block SEL$1 (#0)
    "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
    try to generate transitive predicate from check constraints for query block SEL$1 (#0)
    finally: "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
    apadrv-start sqlid=12053738773107497463
    call(in-use=8176, alloc=32712), compile(in-use=114912, alloc=116848), execution(in-use=175432, alloc=178928)
    Peeked values of the binds in SQL statement
    Final query after transformations:******* UNPARSED QUERY IS *******
    SELECT "SUBSCRIPTION"."CUSTOMER_ID" "CUSTOMER_ID","SUBSCRIPTION"."IDENT_SOURCE_ID" "IDENT_SOURCE_ID","SUBSCRIPTION"."ACCOUNT_ID" "ACCOUNT_ID","SUBSCRIPTION"."MSISDN" "MSISDN","SUBSCRIPTION"."IMSI" "IMSI","SUBSCRIPTION"."SIM" "SIM","SUBSCRIPTION"."IMEI" "IMEI","SUBSCRIPTION"."MEID" "MEID","SUBSCRIPTION"."EMAIL" "EMAIL","SUBSCRIPTION"."TELCOOP" "TELCOOP" FROM "DBIDENT2"."SUBSCRIPTION" "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
    kkoqbc: optimizing query block SEL$1 (#0)
    call(in-use=8320, alloc=32712), compile(in-use=115880, alloc=116848), execution(in-use=175432, alloc=178928)
    kkoqbc-subheap (create addr=0x2b24ebece950)
    QUERY BLOCK TEXT
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    QUERY BLOCK SIGNATURE
    signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=0 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
    SYSTEM STATISTICS INFORMATION
    Using NOWORKLOAD Stats
    CPUSPEEDNW: 714 millions instructions/sec (default is 100)
    IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
    IOSEEKTIM: 10 milliseconds (default is 10)
    MBRC: -1 blocks (default is 16)
    BASE STATISTICAL INFORMATION
    Table Stats::
    Table: SUBSCRIPTION Alias: SUBSCRIPTION Partition [87]
    #Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
    #Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
    Index Stats::
    Index: SUBSCRIPTION_NDX_ACCID Col#: 3
    LVLS: 3 #LB: 121036 #DK: 9767936 LB/K: 1.00 DB/K: 1.00 CLUF: 13921256.00
    Index: SUBSCRIPTION_NDX_CUSID Col#: 1 2 18
    LVLS: 3 #LB: 142123 #DK: 24665396 LB/K: 1.00 DB/K: 1.00 CLUF: 24842146.00
    Index: SUBSCRIPTION_NDX_EMAIL Col#: 9
    LVLS: 2 #LB: 8365 #DK: 1361827 LB/K: 1.00 DB/K: 1.00 CLUF: 1361798.00
    Index: SUBSCRIPTION_NDX_EXT1 Col#: 19
    LVLS: 2 #LB: 65756 #DK: 67792 LB/K: 1.00 DB/K: 80.00 CLUF: 5446485.00
    Index: SUBSCRIPTION_NDX_IMEI Col#: 7
    LVLS: 2 #LB: 44539 #DK: 9199616 LB/K: 1.00 DB/K: 1.00 CLUF: 10413439.00
    Index: SUBSCRIPTION_NDX_IMSI Col#: 5
    LVLS: 3 #LB: 92914 #DK: 12846080 LB/K: 1.00 DB/K: 1.00 CLUF: 23472821.00
    Index: SUBSCRIPTION_NDX_MEID Col#: 8
    LVLS: 1 #LB: 132 #DK: 12585 LB/K: 1.00 DB/K: 1.00 CLUF: 18419.00
    Index: SUBSCRIPTION_NDX_MSISDN Col#: 4 PARTITION [87]
    LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
    LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
    Index: SUBSCRIPTION_NDX_SIM Col#: 6
    LVLS: 2 #LB: 88153 #DK: 13169664 LB/K: 1.00 DB/K: 1.00 CLUF: 24727298.00
    Index: SUBSCRIPTION_NDX_SRCID Col#: 2 17
    LVLS: 2 #LB: 81729 #DK: 4 LB/K: 20432.00 DB/K: 257314.00 CLUF: 1029257.00
    Access path analysis for SUBSCRIPTION
    SINGLE TABLE ACCESS PATH
    Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
    *** 2012-06-12 12:34:53.283
    ** Performing dynamic sampling initial checks. **
    Column (#14):
    NewDensity:0.000020, OldDensity:0.000366 BktCnt:254, PopBktCnt:22, PopValCnt:1, NDV:46252
    Column (#14):
    NewDensity:0.000163, OldDensity:0.000378 BktCnt:254, PopBktCnt:12, PopValCnt:1, NDV:5852
    Column (#14): VALID_FROM( Part#: 87
    AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
    Column (#14): VALID_FROM(
    AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
    Column (#4):
    NewDensity:0.000000, OldDensity:0.000000 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:9730048
    Column (#4):
    NewDensity:0.000013, OldDensity:0.000033 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:74848
    Column (#4): MSISDN( Part#: 87
    AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
    Column (#4): MSISDN(
    AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
    ** Dynamic sampling initial checks returning TRUE (level = 6).
    *** 2012-06-12 12:34:53.284
    ** Generated dynamic sampling query:
    query text :
    SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("SUBSCRIPTION") FULL("SUBSCRIPTION") NO_PARALLEL_INDEX("SUBSCRIPTION") */ 1 AS C1, CASE WHEN "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss') THEN 1 ELSE 0 END AS C2 FROM "DBIDENT2"."SUBSCRIPTION" SAMPLE BLOCK (1.153706 , 1) SEED (1) "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) SAMPLESUB
    *** 2012-06-12 12:36:44.452
    ** Executed dynamic sampling query:
    level : 6
    sample pct. : 1.153706
    total partitions : 1
    partitions for sampling : 1
    actual sample size : 342182
    filtered sample card. : 0
    orig. card. : 218104
    block cnt. table stat. : 11008
    block cnt. for sampling: 11008
    max. sample block cnt. : 128
    sample block cnt. : 127
    min. sel. est. : 0.00001260
    ** Not using dynamic sampling for single table sel. or cardinality.
    DS Failed for : ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
    explain plan for
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    Column (#21):
    NewDensity:0.002912, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:126, NDV:126
    Column (#21): MSISDN_HASH( Part#: 87
    AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
    Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
    Column (#21): MSISDN_HASH(
    AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
    Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
    Column (#1):
    NewDensity:0.000000, OldDensity:0.000241 BktCnt:254, PopBktCnt:31, PopValCnt:2, NDV:9768960
    Column (#1):
    NewDensity:0.000009, OldDensity:0.000250 BktCnt:254, PopBktCnt:36, PopValCnt:3, NDV:99208
    Column (#1): CUSTOMER_ID( Part#: 87
    AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
    Column (#1): CUSTOMER_ID(
    AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
    Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
    Column (#2):
    NewDensity:0.000639, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:3, NDV:3
    Column (#2):
    NewDensity:0.000786, OldDensity:0.000002 BktCnt:13365, PopBktCnt:13365, PopValCnt:3, NDV:3
    Column (#2): IDENT_SOURCE_ID( Part#: 87
    AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
    Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
    Column (#2): IDENT_SOURCE_ID(
    AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
    Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
    ColGroup (#1, Index) SUBSCRIPTION_NDX_CUSID
    Col#: 1 2 18 CorStregth: -1.00
    ColGroup (#2, Index) SUBSCRIPTION_NDX_SRCID
    Col#: 2 17 CorStregth: -1.00
    ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
    ***** Virtual column Adjustment ******
    Column name MSISDN_HASH
    cost_cpu 2300.00
    cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
    ***** End virtual column Adjustment ******
    Table: SUBSCRIPTION Alias: SUBSCRIPTION
    Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
    Access Path: TableScan
    Cost: 2420.71 Resp: 672.42 Degree: 0
    Cost_io: 2409.00 Cost_cpu: 100334308
    Resp_io: 669.17 Resp_cpu: 27870641
    kkofmx: index filter:"SUBSCRIPTION"."MSISDN_HASH"=86
    ***** Virtual column Adjustment ******
    Column name MSISDN_HASH
    cost_cpu 2300.00
    cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
    ***** End virtual column Adjustment ******
    Access Path: index (AllEqRange)
    Index: SUBSCRIPTION_NDX_MSISDN
    resc_io: 6.00 resc_cpu: 36840
    ix_sel: 0.000013 ix_sel_with_filters: 0.000013
    ***** Logdef predicate Adjustment ******
    Final IO cst 0.00 , CPU cst 2300.00
    ***** End Logdef Adjustment ******
    Cost: 6.01 Resp: 6.01 Degree: 1
    Best:: AccessPath: IndexRange
    Index: SUBSCRIPTION_NDX_MSISDN
    Cost: 6.01 Degree: 1 Resp: 6.01 Card: 2.75 Bytes: 0
    OPTIMIZER STATISTICS AND COMPUTATIONS
    GENERAL PLANS
    Considering cardinality-based initial join order.
    Permutations for Starting Table :0
    Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
    Best so far: Table#: 0 cost: 6.0051 card: 2.7487 bytes: 291
    ****** Recost for parallel table scan *******
    Access path analysis for SUBSCRIPTION
    SINGLE TABLE ACCESS PATH
    Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
    *** 2012-06-12 12:36:44.454
    ** Performing dynamic sampling initial checks. **
    ** TABLE SUBSCRIPTION Alias: SUBSCRIPTION : reused cached dynamic sampling result (failure).
    ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
    ***** Virtual column Adjustment ******
    Column name MSISDN_HASH
    cost_cpu 2300.00
    cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
    ***** End virtual column Adjustment ******
    Table: SUBSCRIPTION Alias: SUBSCRIPTION
    Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
    Access Path: TableScan
    Cost: 2420.71 Resp: 672.42 Degree: 0
    Cost_io: 2409.00 Cost_cpu: 100334308
    Resp_io: 669.17 Resp_cpu: 27870641
    Best:: AccessPath: TableScan
    Cost: 672.42 Degree: 4 Resp: 672.42 Card: 2.75 Bytes: 97
    Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
    Join order aborted: cost > best plan cost
    (newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:2000
    Number of join permutations tried: 1
    Enumerating distribution method (advanced)
    Trying or-Expansion on query block SEL$1 (#0)
    Transfer Optimizer annotations for query block SEL$1 (#0)
    id=0 frofkks[i] (index start key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
    id=0 frofkke[i] (index stop key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
    id=0 frofand predicate="SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
    Final cost for query block SEL$1 (#0) - All Rows Plan:
    Best join order: 1
    Cost: 6.0051 Degree: 1 Card: 3.0000 Bytes: 291
    Resc: 6.0051 Resc_io: 6.0000 Resc_cpu: 43740
    Resp: 6.0051 Resp_io: 6.0000 Resc_cpu: 43740
    kkoqbc-subheap (delete addr=0x2b24ebece950, in-use=21280, alloc=32840)
    kkoqbc-end:
    call(in-use=252920, alloc=343912), compile(in-use=129048, alloc=133000), execution(in-use=192248, alloc=195240)
    kkoqbc: finish optimizing query block SEL$1 (#0)
    apadrv-end
    call(in-use=252920, alloc=343912), compile(in-use=129960, alloc=133000), execution(in-use=192248, alloc=195240)
    Starting SQL statement dump
    user_id=115 user_name=xxx module=SQL*Plus action=
    sql_id=afjvvjmx6tqgr plan_hash_value=1672204165 problem_type=3
    ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
    explain plan for
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
    sql_text_length=266
    sql=explain plan for
    select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
    from subscription
    where MSISDN = '600600600' AND MSISDN_HASH = 86
    AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH2
    sql=4:MI:SS')
    ----- Explain Plan Dump -----
    ----- Plan Table -----
    ============
    Plan Table
    ============
    -----------------------------------------------------------------------------------------------------------------------+
    | Id | Operation | Name | Rows | Bytes | Cost | Time | Pstart| Pstop |
    -----------------------------------------------------------------------------------------------------------------------+
    | 0 | SELECT STATEMENT | | | | 6 | | | |
    | 1 | PARTITION LIST SINGLE | | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
    | 2 | TABLE ACCESS BY LOCAL INDEX ROWID | SUBSCRIPTION | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
    | 3 | INDEX RANGE SCAN | SUBSCRIPTION_NDX_MSISDN| 3 | | 3 | 00:00:01 | 88 | 88 |
    -----------------------------------------------------------------------------------------------------------------------+
    Predicate Information:
    2 - filter("VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
    3 - access("MSISDN"='600600600')
    Content of other_xml column
    ===========================
    nodeid/pflags: 1 1 db_version : 11.2.0.2
    parse_schema : xxx
    plan_hash : 1672204165
    plan_hash_2 : 1960934971
    Outline Data:
    /*+
    BEGIN_OUTLINE_DATA
    IGNORE_OPTIM_EMBEDDED_HINTS
    OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
    DB_VERSION('11.2.0.2')
    OPT_PARAM('optimizer_dynamic_sampling' 6)
    ALL_ROWS
    OUTLINE_LEAF(@"SEL$1")
    INDEX_RS_ASC(@"SEL$1" "SUBSCRIPTION"@"SEL$1" ("SUBSCRIPTION"."MSISDN"))
    END_OUTLINE_DATA
    Query Block Registry:
    SEL$1 0xf4ea2a20 (PARSER) [FINAL]
    call(in-use=259392, alloc=343912), compile(in-use=170344, alloc=270888), execution(in-use=344120, alloc=346656)
    End of Optimizer State Dump
    Dumping Hints
    =============
    ====================== END SQL Statement Dump ======================
    Edited by: user3754081 on 2012-06-12 08:07

Maybe you are looking for