Help me in reading/understanding Explain Plan

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
SELECT SRC2.PGM_MSTR_NBR,
                                              SRC2.PGM_TRK_NBR,
                                              SRC2.CNTL_LOCN,
                                              SRC2.PGM_NAME,
                                              SRC2.PGM_STS,
                                              SRC2.SIS_PGM_START_DATE,
                                              SRC2.SIS_PGM_END_DATE,
                                              SRC2.AWARD_TRGT,
                                              SRC2.AWARD_MAX,
                                              SRC2.COMPLNC_TYPE,
                                              SRC2.CMPNY_VNDR_LOCN,
                                              SRC2.CMPNY_VNDR_NBR,
                                              LKP3.ADDR_NAME,
                                              SRC2.INV_IND,
                                              SRC2.LAST_INV_THRU_DATE,
                                              SRC2.INV_RPT_DAY,
                                              SRC2.INV_RPT_CYCLE,
                                              SRC2.BEG_COLL_DATE,
                                              SRC2.END_COLL_DATE,
                                              SRC2.SLS_CONT_DIST,
                                              SRC2.SLS_CONT_NBR,
                                              SRC2.ORD_INV_START_DATE,
                                              SRC2.ORD_INV_END_DATE,
                                              SRC2.CMPLNC_RPT_IND,
                                              SRC2.PROD_ENTRY_LVL,
                                              SRC2.DIST_ENTRY_LVL,
                                              SRC2.CUST_ENTRY_LVL,
                                              SRC2.VNDR_ENTRY_LVL,
                                              SRC2.VNDR_CONT,
                                              SRC2.SIS_CMPNY_VNDR_NBR
                                              FROM CASADM.SBA_REB_PGM SRC2
                                              INNER JOIN(SELECT PGM_MSTR_NBR,PGM_TRK_NBR,CNTL_LOCN  FROM CASADM.ACCR_SIS_PURCH_DTL
                                                         UNION SELECT PGM_MSTR_NBR,PGM_TRK_NBR,CNTL_LOCN  FROM CASADM.ACCR_SIS_EXCL_DTL)ACCR2
                                                    ON  (SRC2.PGM_MSTR_NBR=ACCR2.PGM_MSTR_NBR AND SRC2.PGM_TRK_NBR=ACCR2.PGM_TRK_NBR AND SRC2.CNTL_LOCN=ACCR2.CNTL_LOCN)
                                              LEFT OUTER JOIN
                                                        CASADM.MT_CMPNY_VNDR LKP3
                                                    ON (LKP3.CMPNY_VNDR_NBR=SRC2.CMPNY_VNDR_NBR);
Record Count in each table:
select count(*) from casadm.accr_sis_purch_dtl --375,968
select count(*) from casadm.accr_sis_excl_dtl --1,988,867
select count(*) from casadm.sba_reb_pgm --526,133
select count(*) from casadm.mt_cmpny_vndr --20743
Execution Plan
Plan hash value: 1465316812
| Id  | Operation                    | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time|
|   0 | SELECT STATEMENT             |                       |     9 |  1908 | | 26988   (2)| 00:06:18 |
|   1 |  NESTED LOOPS OUTER          |                       |     9 |  1908 | | 26988   (2)| 00:06:18 |
|*  2 |   HASH JOIN                  |                       |     9 |  1656 |83M| 26979   (2)| 00:06:18|
|   3 |    TABLE ACCESS FULL         | SBA_REB_PGM           |   536K|    77M| |  2624   (2)| 00:00:37 |
|   4 |    VIEW                      |                       |  2364K|    74M| | 16424   (2)| 00:03:50 |
|   5 |     SORT UNIQUE              |                       |  2364K|    49M|72M| 16424  (86)| 00:03:50|
|   6 |      UNION-ALL               |                       |       |       ||            |          |
|   7 |       INDEX FAST FULL SCAN   | ACCR_SIS_PURCH_DTL_PK |   375K|  8077K||   871   (1)| 00:00:13 |
|   8 |       TABLE ACCESS FULL      | ACCR_SIS_EXCL_DTL     |  1988K|    41M||  5634   (1)| 00:01:19 |
|   9 |   TABLE ACCESS BY INDEX ROWID| MT_CMPNY_VNDR         |     1 |    28 | |     1   (0)| 00:00:01 |
|* 10 |    INDEX UNIQUE SCAN         | MT_CMPNY_VNDR_PK      |     1 |       | |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("SRC2"."PGM_MSTR_NBR"="ACCR2"."PGM_MSTR_NBR" AND
              "SRC2"."PGM_TRK_NBR"="ACCR2"."PGM_TRK_NBR" AND "SRC2"."CNTL_LOCN"=
"ACCR2"."CNTL_LOCN")
  10 - access("LKP3"."CMPNY_VNDR_NBR"(+)="SRC2"."CMPNY_VNDR_NBR")
Statistics
        102  recursive calls
          0  db block gets
      34558  consistent gets
      23241  physical reads
         88  redo size
     531258  bytes sent via SQL*Net to client
       2760  bytes received via SQL*Net from client
        361  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
       5392  rows processed

With respect to HASH JOIN it has two operands a TABLE ACCESS FULL and VIEW. Oracle joins these results together based on the following access predicate:
2 - access("SRC2"."PGM_MSTR_NBR"="ACCR2"."PGM_MSTR_NBR" AND
              "SRC2"."PGM_TRK_NBR"="ACCR2"."PGM_TRK_NBR" AND "SRC2"."CNTL_LOCN"="ACCR2"."CNTL_LOCN")The VIEW is the result of the union between the CASADM.ACCR_SIS_PURCH_DTL and CASADM.ACCR_SIS_EXCL_DTL where instead of accessing the table CASADM.ACCR_SIS_PURCH_DTL Oracle was able to acquire all the data from the index ACCR_SIS_PURCH_DTL_PK .
The TABLE ACCESS FULL is exactly what says a full table access of SBA_REB_PGM.
The NESTED LOOPS OUTER has two operands like the HASH JOIN. The way this works is that for each result returned by the HASH JOIN operation it accesses the index MT_CMPNY_VNDR_PK and then the table MT_CMPNY_VNDR based on the following access predicate:
10 - access("LKP3"."CMPNY_VNDR_NBR"(+)="SRC2"."CMPNY_VNDR_NBR")It'd probably be worthwhile for you to review the following paper by Christian Antognini Interpreting Execution Plans as well.

Similar Messages

  • I want to understand Explain Plan

    Dear Gurus,
    I want learn/understand Explain Plan for query so as to tune the query.
    OR I want to tune query by understanding their plan but how it help to tune query.
    Could anybody give me link or material on above.
    Thanking in advance
    Sanjeev

    If you don't want to read the Oracle documentation, then this book is excellent: Troubleshooting Oracle Performance - Christian Antognini
    It does a great job of explaining execution plans.

  • Understanding explain plan

    Oracle Gurus,
    I am trying to understand the below explain plan which I generated using DBMS_XPLAN. This explain plan shows 380M cost, what do "M" and "K" mean here? If anyone has any good documentation to understand explain plan, please pass on.
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
    | 0 | INSERT STATEMENT | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
    | 1 | HASH UNIQUE | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
    |* 2 | FILTER | | | | | | | | | | |
    | 3 | PX COORDINATOR | | | | | | | | | | |
    | 4 | PX SEND QC (RANDOM) | :TQ10002 | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | P->S | QC (RAND) |
    |* 5 | HASH JOIN BUFFERED | | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | PCWP | |
    | 6 | PX RECEIVE | | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,02 | PCWP | |
    | 7 | PX SEND HASH | :TQ10000 | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,00 | P->P | HASH |
    | 8 | PX BLOCK ITERATOR | | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWC | |
    |* 9 | TABLE ACCESS FULL | TOP10_UL_SECTOR_LUCENT | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWP | |
    | 10 | PX RECEIVE | | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,02 | PCWP | |
    | 11 | PX SEND HASH | :TQ10001 | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,01 | P->P | HASH |
    | 12 | PX BLOCK ITERATOR | | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWC | |
    |* 13 | TABLE ACCESS FULL | BH_UL_SECTOR_LUCENT | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWP | |
    | 14 | SORT AGGREGATE | | 1 | 14 | | | | | | | |
    | 15 | PARTITION RANGE ITERATOR| | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
    |* 16 | INDEX SKIP SCAN | IDX2_BH_UL_SECTOR_LUCENT | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
    -----------------------------------------------------------------------------------------------------------------------------------------------------

    Hello,
    Once again K is number of (1000) rows fetched and M is for bytes repsentation. Check this oracle doc for reading xplan
    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
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i16971
    Regards

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

  • Help reading an explain plan

    Here is an except from an explain plan.
    what does index$_join_002 mean?
    | Id  | Operation                         | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                  |                             |     1 |    74 |   133K  (1)| 00:31:04 |
    |*  1 |  FILTER                           |                             |       |       |            |          |
    |*  2 |   HASH JOIN RIGHT SEMI            |                             | 26855 |  1940K| 10561   (1)| 00:02:28 |
    |*  3 |    VIEW                           | index$_join$_002            | 66364 |   907K|   851   (2)| 00:00:12

    I am having trouble forcing a good plan. I have 2 databases with comparable data sets and the indexes are the same. One has a good plan and one a bad plan. When I analyze the tables in the database with the good plan, it changes to the bad plan.
    Definiton of good plan: returns in 3 seconds
    definition of bad plan: returns in 6 minutes.
    Note that as soon as i analyzed the tables, I started getting the bad plan. I am at a loss on how to force the plan to change.
    BAD PLAN
    | Id  | Operation                         | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                  |                             |     1 |    70 | 62008   (1)| 00:14:29 |
    |*  1 |  FILTER                           |                             |       |       |            |          |
    |*  2 |   HASH JOIN SEMI                  |                             | 29528 |  2018K|  1501   (1)| 00:00:22 |
    |*  3 |    TABLE ACCESS BY INDEX ROWID    | EXT_T                       | 29528 |  1614K|  1344   (0)| 00:00:19 |
    |   4 |     DOMAIN INDEX                  | EXT_TEXT_IND                      |       |       | 13441   (0)| 00:03:09 |
    |   5 |    MAT_VIEW ACCESS BY INDEX ROWID | KM_MV                    |   107K|  1464K|   155   (0)| 00:00:03 |
    |*  6 |     INDEX RANGE SCAN              | KAP_IND                            |   107K|         |   136   (1)| 00:00:02 |good plan. I dont get this when I analyze my tables.
    | Id  | Operation                         | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                  |                             |     1 |    74 |   133K  (1)| 00:31:04 |
    |*  1 |  FILTER                           |                             |       |       |            |          |
    |*  2 |   HASH JOIN RIGHT SEMI            |                             | 26855 |  1940K| 10561   (1)| 00:02:28 |
    |*  3 |    VIEW                           | index$_join$_002            | 66364 |   907K|   851   (2)| 00:00:12 |
    |*  4 |     HASH JOIN                     |                             |       |       |            |          |
    |*  5 |      INDEX RANGE SCAN             | KAP_IND | 66364 |   907K|   105   (1)| 00:00:02 |
    |   6 |      INDEX FAST FULL SCAN         | KAP_PK                      | 66364 |   907K|   742   (1)| 00:00:11 |
    |*  7 |    TABLE ACCESS BY INDEX ROWID    | EXT_T      | 26855 |  1573K|  9709   (0)| 00:02:16 |
    |   8 |     DOMAIN INDEX                  | EXT_TEXT_IND     |       |       |  9709   (0)| 00:02:16 |Edited by: Guess2 on Jul 1, 2009 9:06 AM
    Edited by: Guess2 on Jul 1, 2009 9:07 AM
    Edited by: Guess2 on Jul 1, 2009 9:07 AM
    Edited by: Guess2 on Jul 1, 2009 9:08 AM

  • Query Performance and reading an Explain Plan

    Hi,
    Below I have posted a query that is running slowly for me - upwards of 10 minutes which I would not expect. I have also supplied the explain plan. I'm fairly new to explain plans and not sure what the danger signs are that I should be looking out for.
    I have added indexes to these tables, a lot of which are used in the JOIN and so I expected this to be quicker.
    Any help or pointers in the right direction would be very much appreciated -
    SELECT a.lot_id, a.route, a.route_rev
    FROM wlos_owner.tbl_current_lot_status_dim a, wlos_owner.tbl_last_seq_num b, wlos_owner.tbl_hist_metrics_at_op_lkp c
    WHERE a.fw_ver = '2'
    AND a.route = b.route
    AND a.route_rev = b.route_rev
    AND a.fw_ver = b.fw_ver
    AND a.route = c.route
    AND a.route_rev = c.route_rev
    AND a.fw_ver = c.fw_ver
    AND a.prod = c.prod
    AND a.lot_type = c.lot_type
    AND c.step_seq_num >= a.step_seq_num
    PLAN_TABLE_OUTPUT
    Plan hash value: 2447083104
    | Id  | Operation           | Name                       | Rows  | Bytes | Cost
    (%CPU)| Time     |
    PLAN_TABLE_OUTPUT
    |   0 | SELECT STATEMENT    |                            |   333 | 33633 |  1347
       (8)| 00:00:17 |
    |*  1 |  HASH JOIN          |                            |   333 | 33633 |  1347
       (8)| 00:00:17 |
    |*  2 |   HASH JOIN         |                            |   561 | 46002 |  1333
       (7)| 00:00:17 |
    |*  3 |    TABLE ACCESS FULL| TBL_CURRENT_LOT_STATUS_DIM | 11782 |   517K|   203
       (5)| 00:00:03 |
    PLAN_TABLE_OUTPUT
    |*  4 |    TABLE ACCESS FULL| TBL_HIST_METRICS_AT_OP_LKP |   178K|  6455K|  1120
       (7)| 00:00:14 |
    |*  5 |   TABLE ACCESS FULL | TBL_LAST_SEQ_NUM           |  8301 |   154K|    13
      (16)| 00:00:01 |
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
       1 - access("A"."ROUTE"="B"."ROUTE" AND "A"."ROUTE_REV"="B"."ROUTE_REV" AND
                  "A"."FW_VER"=TO_NUMBER("B"."FW_VER"))
       2 - access("A"."ROUTE"="C"."ROUTE" AND "A"."ROUTE_REV"="C"."ROUTE_REV" AND
                  "A"."FW_VER"="C"."FW_VER" AND "A"."PROD"="C"."PROD" AND "A"."LOT_T
    YPE"="C"."LOT_TYPE")
           filter("C"."STEP_SEQ_NUM">="A"."STEP_SEQ_NUM")
       3 - filter("A"."FW_VER"=2)
    PLAN_TABLE_OUTPUT
       4 - filter("C"."FW_VER"=2)
       5 - filter(TO_NUMBER("B"."FW_VER")=2)
    24 rows selected.

    Guys thank you for your help.
    I changed the type of the offending column and the plan looks a lot better and results seem a lot quicker.
    However I have added to my SELECT, quite substantially, and have a new explain plan.
    There are two sections in particular that have a high cost and I was wondering if you seen anything inherently wrong or can explain more fully what the PLAN_TABLE_OUTPUT descriptions are telling me - in particular
    INDEX FULL SCAN
    PLAN_TABLE_OUTPUT
    Plan hash value: 3665357134
    | Id  | Operation                        | Name                           | Rows
      | Bytes | Cost (%CPU)| Time     |
    PLAN_TABLE_OUTPUT
    |   0 | SELECT STATEMENT                 |                                |
    4 |   316 |    52   (2)| 00:00:01 |
    |*  1 |  VIEW                            |                                |
    4 |   316 |    52   (2)| 00:00:01 |
    |   2 |   WINDOW SORT                    |                                |
    4 |   600 |    52   (2)| 00:00:01 |
    |*  3 |    TABLE ACCESS BY INDEX ROWID   | TBL_HIST_METRICS_AT_OP_LKP     |
    1 |    71 |     1   (0)| 00:00:01 |
    PLAN_TABLE_OUTPUT
    |   4 |     NESTED LOOPS                 |                                |
    4 |   600 |    51   (0)| 00:00:01 |
    |   5 |      NESTED LOOPS                |                                |    7
    5 |  5925 |    32   (0)| 00:00:01 |
    |*  6 |       INDEX FULL SCAN            | UNIQUE_LAST_SEQ                |    8
    9 |  2492 |    10   (0)| 00:00:01 |
    |   7 |       TABLE ACCESS BY INDEX ROWID| TBL_CURRENT_LOT_STATUS_DIM     |
    PLAN_TABLE_OUTPUT
    1 |    51 |     1   (0)| 00:00:01 |
    |*  8 |        INDEX RANGE SCAN          | TBL_CUR_LOT_STATUS_DIM_IDX1    |
    1 |       |     1   (0)| 00:00:01 |
    |*  9 |      INDEX RANGE SCAN            | TBL_HIST_METRIC_AT_OP_LKP_IDX1 |    2
    9 |       |     1   (0)| 00:00:01 |
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
       1 - filter("SEQ"=1)
       3 - filter("C"."FW_VER"=2 AND "A"."PROD"="C"."PROD" AND "A"."LOT_TYPE"="C"."L
    OT_TYPE" AND
                  "C"."STEP_SEQ_NUM">="A"."STEP_SEQ_NUM")
       6 - access("B"."FW_VER"=2)
           filter("B"."FW_VER"=2)
    PLAN_TABLE_OUTPUT
       8 - access("A"."ROUTE"="B"."ROUTE" AND "A"."ROUTE_REV"="B"."ROUTE_REV" AND "A
    "."FW_VER"=2)
       9 - access("A"."ROUTE"="C"."ROUTE" AND "A"."ROUTE_REV"="C"."ROUTE_REV")

  • Understanding explain plan output

    Hi,
    Version 11202.
    Bellow is the output of tkprof against a statment which has cpu time = elapsed time =~3000 sec.
    The statment is related to oracle EBS , but the question bellow is regarding the execution plan.
    As you can see in the plan bellow most of the time is spend on the following step :
             0          0          0      TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
    2059303280 2059303280 2059303280       INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)What i am trying to understand is why 2 billions rows (2059303280) has been accessed by the index IBY_PMT_INSTR_USES_ALL_N2
    SQL> select table_name,num_rows,sample_size,last_analyzed from dba_tables where table_name='IBY_PMT_INSTR_USES_ALL';
    TABLE_NAME NUM_ROWS SAMPLE_SIZE LAST_ANAL
    IBY_PMT_INSTR_USES_ALL 2414470 241447 28-JAN-13
    SQL> select table_name,distinct_keys,clustering_factor,num_rows,sample_size,last_analyzed from dba_indexes where index_name='IBY_PMT_INSTR_USES_ALL_N2';
    TABLE_NAME DISTINCT_KEYS CLUSTERING_FACTOR NUM_ROWS SAMPLE_SIZE LAST_ANAL
    IBY_PMT_INSTR_USES_ALL 304515 267170 2407170 240717 28-JAN-13The whole statment and is plan is as followed :
    insert into iby_pmt_instr_uses_all (instrument_payment_use_id,payment_flow,
      ext_pmt_party_id,instrument_type,instrument_id,payment_function,
      order_of_preference,created_by,creation_date,last_updated_by,
      last_update_date,last_update_login,object_version_number,start_date,
      end_date,debit_auth_flag,debit_auth_method,debit_auth_reference,
      debit_auth_begin,debit_auth_end)select iby_pmt_instr_uses_all_s.nextval  ,
      'FUNDS_CAPTURE' ,iep.ext_payer_id ,'BANKACCOUNT' ,eba.ext_bank_account_id ,
      'CUSTOMER_PAYMENT' ,DECODE(cbi.primary_flag,'Y',1,10) ,:b0 ,SYSDATE ,:b0 ,
      SYSDATE ,:b2 ,1 ,cbi.start_date ,cbi.end_date ,'' ,'' ,'' ,'' ,''  from
      iby_external_payers_all iep ,hz_cust_accounts hca ,hz_cust_site_uses_all
      csu ,hz_cust_acct_sites_all cas ,hz_parties hzba ,hz_relationships hzr ,
      hz_code_assignments hcba ,hz_parties hzbb ,hz_organization_profiles hop ,
      hz_code_assignments hcbb ,iby_ext_bank_accounts eba ,
      ra_customer_banks_int_all cbi where
      (((((((((((((((((((((((((((((((((((((((cbi.interface_status is null  and
      cbi.request_id=:b3) and UPPER(cbi.bank_name)=UPPER(hzba.party_name)) and
      hzba.party_id=hop.party_id) and SYSDATE between
      TRUNC(hop.effective_start_date) and NVL(TRUNC(hop.effective_end_date),
      (SYSDATE+1))) and hcba.class_category='BANK_INSTITUTION_TYPE') and
      hcba.class_code='BANK') and hcba.owner_table_name='HZ_PARTIES') and
      hcba.owner_table_id=hzba.party_id) and cbi.bank_home_country=
      hop.home_country) and hzbb.party_id=hcbb.owner_table_id) and
      hcbb.owner_table_name='HZ_PARTIES') and hcbb.class_category=
      'BANK_INSTITUTION_TYPE') and hcbb.class_code='BANK_BRANCH') and
      nvl(hcbb.status,'A')='A') and hzbb.party_id=hzr.subject_id) and
      hzba.party_id=hzr.object_id) and hzr.relationship_type='BANK_AND_BRANCH')
      and hzr.relationship_code='BRANCH_OF') and hzr.status='A') and
      hzr.subject_table_name='HZ_PARTIES') and hzr.subject_type='ORGANIZATION')
      and hzr.object_table_name='HZ_PARTIES') and hzr.object_type='ORGANIZATION')
      and UPPER(cbi.bank_branch_name)=UPPER(hzbb.party_name)) and hzbb.party_id=
      eba.branch_id) and hzba.party_id=eba.bank_id) and eba.bank_account_num=
      cbi.bank_account_num) and eba.currency_code=cbi.bank_account_currency_code)
      and cbi.orig_system_customer_ref=hca.orig_system_reference) and
      iep.cust_account_id=hca.cust_account_id) and iep.party_id=hca.party_id) and
      ((cbi.orig_system_address_ref is null  and iep.org_id is null ) or
      iep.org_id=cbi.org_id)) and ((cbi.orig_system_address_ref is null  and
      iep.org_type is null ) or iep.org_type='OPERATING_UNIT')) and cbi.org_id=
      cas.org_id(+)) and nvl(iep.acct_site_use_id,(-1))=
      decode(cbi.orig_system_address_ref,null ,(-1),csu.site_use_id)) and
      cbi.orig_system_address_ref=cas.orig_system_reference(+)) and
      (csu.site_use_id=(select min(site_use_id)  from hz_cust_site_uses_all hcsua
      where ((hcsua.cust_acct_site_id=cas.cust_acct_site_id and
      hcsua.site_use_code='BILL_TO') and hcsua.status='A')) or csu.site_use_id is
      null )) and cas.cust_acct_site_id=csu.cust_acct_site_id(+)) and  not exists
      (select 'x'  from iby_pmt_instr_uses_all ipi where (((ipi.ext_pmt_party_id=
      iep.ext_payer_id and ipi.instrument_type='BANKACCOUNT') and
      ipi.instrument_id=eba.ext_bank_account_id) and ipi.payment_function=
      'CUSTOMER_PAYMENT')))
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1   3049.58    3080.23      31827   44696023       1587        1175
    Fetch        0      0.00       0.00          0          0          0           0
    total        2   3049.58    3080.23      31827   44696023       1587        1175
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 57  (APPS)
    Number of plan statistics captured: 1
    Rows (1st) Rows (avg) Rows (max)  Row Source Operation
             0          0          0  LOAD TABLE CONVENTIONAL  (cr=44696030 pr=31827 pw=0 time=2870820188 us)
          1175       1175       1175   SEQUENCE  IBY_PMT_INSTR_USES_ALL_S (cr=44695967 pr=31774 pw=0 time=3270855802 us)
          1175       1175       1175    FILTER  (cr=44695960 pr=31774 pw=0 time=3270803657 us)
          1175       1175       1175     NESTED LOOPS ANTI (cr=44695844 pr=31774 pw=0 time=3270739008 us cost=251 size=497 card=1)
          1175       1175       1175      NESTED LOOPS  (cr=64952 pr=217 pw=0 time=2991575 us cost=248 size=457 card=1)
          1175       1175       1175       NESTED LOOPS  (cr=64827 pr=205 pw=0 time=2949382 us cost=245 size=423 card=1)
          1175       1175       1175        NESTED LOOPS OUTER (cr=63494 pr=205 pw=0 time=2921176 us cost=243 size=403 card=1)
          1175       1175       1175         NESTED LOOPS  (cr=63377 pr=205 pw=0 time=2893312 us cost=240 size=391 card=1)
          1175       1175       1175          NESTED LOOPS  (cr=61415 pr=205 pw=0 time=2850064 us cost=236 size=348 card=1)
         47434      47434      47434           NESTED LOOPS  (cr=57058 pr=205 pw=0 time=2565056 us cost=234 size=328 card=1)
         41203      41203      41203            NESTED LOOPS OUTER (cr=42422 pr=0 pw=0 time=581594 us cost=230 size=296 card=1)
         41203      41203      41203             HASH JOIN  (cr=1049 pr=0 pw=0 time=173751 us cost=229 size=277 card=1)
          2333       2333       2333              NESTED LOOPS  (cr=1013 pr=0 pw=0 time=32850 us)
          2333       2333       2333               NESTED LOOPS  (cr=825 pr=0 pw=0 time=22036 us cost=208 size=172 card=1)
           514        514        514                NESTED LOOPS  (cr=691 pr=0 pw=0 time=16378 us cost=206 size=88 card=1)
           514        514        514                 NESTED LOOPS  (cr=588 pr=0 pw=0 time=7190 us cost=95 size=2501 card=41)
           514        514        514                  TABLE ACCESS BY INDEX ROWID HZ_CODE_ASSIGNMENTS (cr=20 pr=0 pw=0 time=1716 us cost=10 size=1681 card=41)
           514        514        514                   INDEX RANGE SCAN HZ_CODE_ASSIGNMENTS_N1 (cr=7 pr=0 pw=0 time=464 us cost=4 size=0 card=164)(object id 464630)
           514        514        514                  TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=568 pr=0 pw=0 time=2797 us cost=2 size=20 card=1)
           514        514        514                   INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=54 pr=0 pw=0 time=1059 us cost=1 size=0 card=1)(object id 421661)
           514        514        514                 TABLE ACCESS BY INDEX ROWID HZ_ORGANIZATION_PROFILES (cr=103 pr=0 pw=0 time=5913 us cost=3 size=27 card=1)
           514        514        514                  INDEX RANGE SCAN BZ_HZ_ORGANIZATION_PROFILE_N1 (cr=76 pr=0 pw=0 time=2873 us cost=2 size=0 card=1)(object id 9378840)
          2333       2333       2333                INDEX RANGE SCAN HZ_RELATIONSHIPS_N2 (cr=134 pr=0 pw=0 time=3962 us cost=1 size=0 card=1)(object id 11581198)
          2333       2333       2333               TABLE ACCESS BY INDEX ROWID HZ_RELATIONSHIPS (cr=188 pr=0 pw=0 time=7476 us cost=2 size=84 card=1)
          1175       1175       1175              TABLE ACCESS FULL RA_CUSTOMER_BANKS_INT_ALL (cr=36 pr=0 pw=0 time=9479 us cost=21 size=123375 card=1175)
         41203      41203      41203             TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL (cr=41373 pr=0 pw=0 time=304952 us cost=1 size=19 card=1)
         41203      41203      41203              INDEX UNIQUE SCAN HZ_CUST_ACCT_SITES_U2 (cr=170 pr=0 pw=0 time=93830 us cost=1 size=0 card=1)(object id 421730)
         47434      47434      47434            TABLE ACCESS BY INDEX ROWID IBY_EXT_BANK_ACCOUNTS (cr=14636 pr=205 pw=0 time=2375333 us cost=4 size=32 card=1)
         47434      47434      47434             INDEX RANGE SCAN IBY_EXT_BANK_ACCOUNTS_N6 (cr=3548 pr=94 pw=0 time=1112297 us cost=2 size=0 card=1)(object id 14313177)
          1175       1175       1175           TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=4357 pr=0 pw=0 time=171450 us cost=2 size=20 card=1)
          1203       1203       1203            INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=3154 pr=0 pw=0 time=107886 us cost=1 size=0 card=1)(object id 421661)
          1175       1175       1175          TABLE ACCESS BY INDEX ROWID HZ_CODE_ASSIGNMENTS (cr=1962 pr=0 pw=0 time=41107 us cost=3 size=43 card=1)
          1175       1175       1175           INDEX RANGE SCAN HZ_CODE_ASSIGNMENTS_U2 (cr=1611 pr=0 pw=0 time=25716 us cost=2 size=0 card=1)(object id 14355645)
          1175       1175       1175         TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=117 pr=0 pw=0 time=14875 us cost=3 size=12 card=1)
          1175       1175       1175          INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=86 pr=0 pw=0 time=10600 us cost=2 size=0 card=1)(object id 464289)
          1175       1175       1175        TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS (cr=1333 pr=0 pw=0 time=22634 us cost=2 size=20 card=1)
          1175       1175       1175         INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U3 (cr=158 pr=0 pw=0 time=9307 us cost=1 size=0 card=1)(object id 9438627)
          1175       1175       1175       TABLE ACCESS BY INDEX ROWID IBY_EXTERNAL_PAYERS_ALL (cr=125 pr=12 pw=0 time=131366 us cost=3 size=34 card=1)
          1175       1175       1175        INDEX RANGE SCAN IBY_EXTERNAL_PAYERS_ALL_U2 (cr=109 pr=4 pw=0 time=51266 us cost=2 size=0 card=1)(object id 14313089)
             0          0          0      TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
    2059303280 2059303280 2059303280       INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)
          1000       1000       1000     SORT AGGREGATE (cr=116 pr=0 pw=0 time=39211 us)
          1000       1000       1000      TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=116 pr=0 pw=0 time=27041 us cost=4 size=22 card=1)
          1000       1000       1000       INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=85 pr=0 pw=0 time=19027 us cost=3 size=0 card=1)(object id 464289)

    Yoav wrote:
    and  not exists
    (select 'x'  from iby_pmt_instr_uses_all ipi where (((ipi.ext_pmt_party_id=
    iep.ext_payer_id and ipi.instrument_type='BANKACCOUNT') and
    ipi.instrument_id=eba.ext_bank_account_id) and ipi.payment_function=
    'CUSTOMER_PAYMENT')))
    Number of plan statistics captured: 1
    Rows (1st) Rows (avg) Rows (max)  Row Source Operation
    0          0          0  LOAD TABLE CONVENTIONAL  (cr=44696030 pr=31827 pw=0 time=2870820188 us)
    1175       1175       1175   SEQUENCE  IBY_PMT_INSTR_USES_ALL_S (cr=44695967 pr=31774 pw=0 time=3270855802 us)
    1175       1175       1175    FILTER  (cr=44695960 pr=31774 pw=0 time=3270803657 us)
    1175       1175       1175     NESTED LOOPS ANTI (cr=44695844 pr=31774 pw=0 time=3270739008 us cost=251 size=497 card=1)
    1175       1175       1175      NESTED LOOPS  (cr=64952 pr=217 pw=0 time=2991575 us cost=248 size=457 card=1)
    0          0          0      TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
    2059303280 2059303280 2059303280       INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)
    1000       1000       1000     SORT AGGREGATE (cr=116 pr=0 pw=0 time=39211 us)
    1000       1000       1000      TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=116 pr=0 pw=0 time=27041 us cost=4 size=22 card=1)
    1000       1000       1000       INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=85 pr=0 pw=0 time=19027 us cost=3 size=0 card=1)(object id 464289)
    You have a "not exists" subquery that the optimizer has turned into a nested loop anti join.
    For each of the 1175 rows returned by the previous step Oracle does a range scan of what it thinks is the most appropriate index - the figures for cost (2) and card (8) at that line show that something has gone wrong with the optimizer's estimates, and for each of the 1175 prior rows it has acquired an average 1.7M index entries based on the index predicates, then visited the table and discarded resulting row.
    It looks as if the index is a bad choice of index - you need to check the index predicates for the plan - use dbms_xplan to pull it from memory; and check your indexes to see if there is a better one that the optimizer should have chosen
    Regards
    Jonathan Lewis

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

  • Understanding of Explain plan

    Hi all,
    Could you please provide me any article on how to read and understand the complete explain plan by step by step?
    I am not much familiar with expalin paln.
    Wolud be appreciated your help !!
    Regards,
    Vissu...
    Edited by: vissu on Aug 10, 2010 2:13 AM

    [ | http://www.lmgtfy.com/?q=Understanding+explain+plans+in+oracle+10g]
    [| http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm]

  • Query regarding Partition table Explain plan

    Hello,
    We are amidst a tuning activity, wherein a large table has been partitioned for better administration. During testing, I was analyzing the explain plans for long running sql's and found a piece that I was unable to understand. The PSTART and PSTOP columns show ROWID as its value, which in normal partition pruning scenario be the Partition number or the KEY. I tried to look around for this issue but did not get enough information. Can anybody help me of what it means? Also, if there is a good explanation of the same, it will be extremely helpful.
    The snippet from explain plan looks like:
    | Id  | Operation                                | Name                          | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    7 |        TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXXXXXXXX             | 43874 |  9083K|       |  1386   (1)| 00:00:17 | ROWID | ROWID |
    On another similar query it looks like:
    | Id  | Operation                             | Name                         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    |   6 |     TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXX               | 22455 |  4648K|       |   456   (1)| 00:00:06 |     9 |     9 |
    I have another query with regards to the Partition tables. Does it, require/benefit if, the Indexes to be in partitioned mode? I tried to read about it but did not get a conclusive evidence. I am trying to test it and post here the outcome, but if anybody has experience of working with it, it would be great to have some advice.
    Oracle Version:- 10.2.0.4
    Regards,
    Purvesh.

    Hi Purvesh.
    Great explanation and example on this this topic...
    Ask Tom &amp;quot;explain plan on range-partitioned table&amp;quot;
    Hope this help.

  • Question regarding using of Explain Plan

    Hi. I'm new with Oracle Queries so I have a little obstacles about understanding. I want to learn how to use Explain Plan feature from Oracle
    I am using Oracle 9i as back end .
    Please tell me how can i use feature of Explain Plan Feature for the below query.
    SELECT * FROM emp WHERE empno = 7369
    Thanks in advance.

    [email protected] wrote:
    Hi. I'm new with Oracle Queries so I have a little obstacles about understanding. I want to learn how to use Explain Plan feature from Oracle
    I am using Oracle 9i as back end .
    Please tell me how can i use feature of Explain Plan Feature for the below query.
    SELECT * FROM emp WHERE empno = 7369
    Kiran,
    Firstly , before anything else, I would suggest to change your handle to anything else and remove the email id from it. Its not good to have the id displayed in any public forum.
    About the question, unfortunately, its not that easy to answer. To understand explain plan and how to use it, you need to understand that algorithm/mechanism, whatever you feel like saying, that generates it. Because, explain plan is just the outcome of that mechanism, a final product, its the result of some inputs given by you in the form of your query, predicates, joins and their types and that all bring up the explain plan. Explain plan is basically the constitution of some steps which are used /fixed by optimizer to run the query. I would suggest that you read this page from cover to cover to understand some of the steps and their meanings which are shown to you in the plan. I am giving 10g link as this is a more better version of optimizer than the previous ones and I would suggest you to do experiments on 10g only.
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#i21299
    And I would suggest that you collect these following books and start reading them. I haven't yet found any thing better than these books.
    [Cost Based Oracle Fundamentals (Jonathan Lewis)|http://www.amazon.com/Cost-Based-Oracle-Fundamentals-Experts-Voice/dp/1590596366]
    [Troubleshooting Oracle Performance(Christian Antognini )|http://www.amazon.com/Troubleshooting-Oracle-Performance-Christian-Antognini/dp/1590599179/ref=sr_1_1?ie=UTF8&s=books&qid=1240078634&sr=1-1]
    [Effectuve Oracle By Design(Tom Kyte)|http://www.amazon.com/Effective-Oracle-Design-Osborne-ORACLE/dp/0072230657/ref=sr_1_1?ie=UTF8&s=books&qid=1240078698&sr=1-1]
    It would be real long journey before the mazes of optimizer and explain would be clear so make sure you have patience as well.
    HTH
    Aman....

  • Simple Explain Plan

    Oracle 11g R2,
    Windows 7 OS.
    I would like to know, how oracle is using the view in the below explain plan and is it possible to skip using of view in below explain plan(but i don't want to go for NO_INDEX or FULL hints).I purpose fully didn't pasted the time,bytes,rows parameters.Only thing is view is used, and upon this i want clarity
    select e.employee_id,e.first_name from employees e;
    OPERATION                 OPTIONS              OBJECT_NAME           COST      
    SELECT STATEMENT                                                        3      
    VIEW                                           index$_join$_00          3      
                                                   1                               
    HASH JOIN                                                                      
    INDEX                     FAST FULL SCAN       EMP_EMP_ID_PK            1      
    INDEX                     FAST FULL SCAN       EMP_NAME_IX              1       One more thing i would like to add, this is just sample HR schema(default schema) in oracle.View "EMP_DETAILS_VIEW" is already present in this schema, which selects first_name,last_name etc.. from employee table.
    Thanks.
    Edited by: 902629 on Dec 15, 2011 10:40 AM

    Execute alter session set "_INDEX_JOIN_ENABLED"=FALSE; and execute the query.
    help reading an explain plan
    Thanks

  • 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 to enable Explain plan in TOAD

    Hi,
    I am using toad version 8.6.1.Whenever i login as my userid and run a sql stmnt i am trying to get explain plan from toad explain plan button.But it's not showing anything some times it says insuffcient privileges.I created synonym called plan_table which is based on actual plan_table.But no luck.Can you pls help me how to enable explain plan in toad
    Thanks
    Anand

    Anand,
    in earlier versions of Toad you could use the notoad.sql or toadprep.sql to create the required tables.
    In your version it is probably already has been replaced by menu option Tools->Server Side Object Wizard.
    Toad does not use the plan_table - it creates it's own set of tables including the table for the explain plan.
    Mike

  • About explain plan

    Hello ALL,
    I have the following explain plan, can any body explain the meaning of this explain plan
    SELECT * FROM
    2 TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE','111'));
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
    | 0 | SELECT STATEMENT | | 401 | 25263 | | 751K|
    | 1 | MERGE JOIN SEMI | | 401 | 25263 | | 751K|
    | 2 | SORT JOIN | | 17M| 820M| 2108M| 75297 |
    | 3 | TABLE ACCESS FULL | TABLE1 | 17M| 820M| | 3520 |
    |* 4 | SORT UNIQUE | | 275M| 3412M| 10G| 676K|
    | 5 | VIEW | VW_NSO_1 | 275M| 3412M| | 3538 |
    |* 6 | HASH JOIN | | 275M| 7874M| | 3538 |
    |* 7 | TABLE ACCESS FULL| TABLE2 | 16 | 128 | | 2 |
    |* 8 | TABLE ACCESS FULL| TABLE1 | 17M| 360M| | 3520 |
    Predicate Information (identified by operation id):
    4 - access("TABLE1"."POSITION"="VW_NSO_1"."$nso_col_1")
    filter("TABLE1"."POSITION"="VW_NSO_1"."$nso_col_1")
    6 - access("TABLE2"."VERSION_NO"="TABLE1"."VERSION_NO")
    7 - filter("TABLE2"."STATIC_UPD_FLAG"='N')
    8 - filter("TABLE1"."DATETIME_INSERTED">TO_DATE('0004-01-01 00:00:00',
    'yyyy-mm-dd hh24:mi:ss'))
    Note: cpu costing is off
    26 rows selected.
    SQL>

    There is a section in the manual on interpreting the output of explain plan http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/ex_plan.htm#16972 Tom Kyte also discusses interpreting the plan http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:231814117467#7344298017927 (page down about halfway where he starts his book excerpt).
    Rows, bytes, and temp space are the cost-based optimizer's guess about the number of rows, bytes, and temp space that will be touched (or consumed) by the operation. The cost is an internal number that has no significance to you when you're reading an explain plan-- it does have some significance when you are examining an event 10046 trace.
    Justin
    Distributed Database Consulting, Inc.
    http://www.ddbcinc.com/askDDBC

Maybe you are looking for

  • Incorrect display of HTML document in UWL

    Hi experts, we are using SRM 5.0 with UWL integration. If a workitem is rejected the requestor gets a notification in his SAP Business Workplace (SBWP). This notification contains a link to the SRM shopping cart. The notification is also available in

  • HT204380 Through face time can i 3G video call to any one who does not use iphone

    hi im a Apple fane.i love iphone very much..i want to buy iphone 5 so i need some information..use face time can i 3g video call any one. Thnks Faruk

  • Adding Disk to Physical Exchange Servers

    Greetings, I have Exchange Server 2007 setup. Having 2 Mailbox Server and 2 CAS Servers. The Mailbox Server (Database drive) is running Low disk space on both the Mailbox servers. Now i want to add Physical Disks to both the servers. I have already b

  • Post System Refresh

    Hi Guru's, I needed to know what are important BI steps to go through (for system check up) after the system refresh. In this case, the testing box has been refreshed from the production. Thanks, Akash

  • Type tool problem

    Somehow the type tool in CS6 has set itself to vertical. I have to change it to horizontal every time I use it, which takes a lot of time when I'm making a document with dozens of type layers. I've tried right-clicking on the "T" in the tool bar and