Good Explain plan long execution.

Hi,
on 11.2.0.3 for a query I have following explain plan which sounds good but when executed by an application it does not finish.
It waits on db file scattered read. Thanks for your ideas.
| Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT              |                   |     1 |   427 |     2   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL      | PS_PC_RT_RUN_TA24 |       |       |            |          |
|*  2 |   FILTER                      |                   |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID| PS_PRT_PRICE4     |     1 |   427 |     0   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | PSAPRT_PRICE4     |     1 |       |     0   (0)| 00:00:01 |
|*  5 |    TABLE ACCESS FULL          | PS_PC_RT_RUN_TA24 |     1 |    57 |     2   (0)| 00:00:01 |
Query Block Name / Object Alias (identified by operation id):
   1 - SEL$1
   3 - SEL$1 / PRT@SEL$1
   4 - SEL$1 / PRT@SEL$1
   5 - SEL$2 / A@SEL$2
Predicate Information (identified by operation id):
   2 - filter( NOT EXISTS (SELECT 0 FROM "PS_PC_RT_RUN_TA24" "A" WHERE
              "A"."BUSINESS_UNIT"=:B1 AND "A"."PROJECT_ID"=:B2 AND "A"."ACTIVITY_ID"=:B3 AND
              "A"."RESOURCE_ID"=:B4 AND "A"."PROCESS_INSTANCE"=2690469))
   4 - access("PRT"."PROCESS_INSTANCE"=2690469)
   5 - filter("A"."BUSINESS_UNIT"=:B1 AND "A"."PROJECT_ID"=:B2 AND "A"."ACTIVITY_ID"=:B3
              AND "A"."RESOURCE_ID"=:B4 AND "A"."PROCESS_INSTANCE"=2690469)
SQL> show parameter optimizer
NAME                                 TYPE        VALUE
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      11.2.0.3
optimizer_index_caching              integer 0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
optimizer_use_invisible_indexes      boolean     FALSE
optimizer_use_pending_statistics     boolean FALSE
  optimizer_use_sql_plan_baselines     boolean TRUE

many thanks Nicolas,
yes it is the famous standard PC_Pricing on step PC_PRICING.COPYTA2.Step01.S.
The query is :
INSERT INTO PS_PC_RT_RUN_TA24 (PROCESS_INSTANCE, BUSINESS_UNIT, PROJECT_ID, ACTIVITY_ID, RESOURCE_ID, LINE_NO, SEQ_NUM, RESOURCE_ID_FROM, ANALYSIS_TYPE, RESOURCE_TYPE, RESOURCE_CATEGORY, RESOURCE_SUB_CAT, CONTRACT_NUM, CONTRACT_LINE_NUM, RESOURCE_QUANTITY, FOREIGN_AMOUNT, RATE_OPTION, RATE_AMT, AMOUNT, TRANS_DT, ACCOUNTING_DT, INFO_FLD1, INFO_FLD2, EMPLID, TIME_RPTG_CD, JOBCODE, UOM_BILL, UNIT_OF_MEASURE, UNIT_AMT, FOREIGN_CURRENCY, RT_TYPE, OPRID, OVERRIDE_SRC, SRC_AN_TYPE, SRC_RES_CATEGORY, SRC_RES_SUB_CAT, SRC_RES_TYPE, TO_CUR, BUSINESS_UNIT_GL, ACCOUNT, ALTACCT, DEPTID, OPERATING_UNIT, PRODUCT, FUND_CODE, CLASS_FLD, PROGRAM_CODE, BUDGET_REF, AFFILIATE, AFFILIATE_INTRA1, AFFILIATE_INTRA2, CHARTFIELD1, CHARTFIELD2, CHARTFIELD3, SYSTEM_SOURCE, PROCESS_STATUS, BI_DISTRIB_STATUS, RATE_PLAN, DESCR, DESCR1, PROJ_ROLE, TIER_PRICE_SW, PRICED_RATE, RATE_MULT, RATE_DIV, CST_DISTRIB_STATUS, REV_DISTRIB_STATUS, RATE_DEF_TYPE, BUSINESS_UNIT_WO, WO_ID, WO_TASK_ID, RSRC_TYPE, RES_LN_NBR, PC_TEMPLATE_ID, COMBO_STATUS, COST_RATE, BILL_RATE, TEMPLATE_TYPE, RATE_PLAN_TYPE, RATE_DEF_BIL, RATE_DEF_COST, RATE_DEF_REV) SELECT PRT.PROCESS_INSTANCE, PRT.BUSINESS_UNIT, PRT.PROJECT_ID, PRT.ACTIVITY_ID, PRT.RESOURCE_ID, 1, 0, PRT.RESOURCE_ID, PRT.ANALYSIS_TYPE, PRT.RESOURCE_TYPE, PRT.RESOURCE_CATEGORY, PRT.RESOURCE_SUB_CAT, PRT.CONTRACT_NUM, PRT.CONTRACT_LINE_NUM, PRT.RESOURCE_QUANTITY, PRT.FOREIGN_AMOUNT, ' ', 0, 0, PRT.TRANS_DT, PRT.ACCOUNTING_DT, ' ', ' ', PRT.EMPLID, PRT.TIME_RPTG_CD, PRT.JOBCODE, ' ', PRT.UNIT_OF_MEASURE, 0, PRT.FOREIGN_CURRENCY, PRT.RT_TYPE, PRT.OPRID, 'N', ' ', ' ', ' ', ' ', ' ', PRT.BUSINESS_UNIT_GL, PRT.ACCOUNT, PRT.ALTACCT, PRT.DEPTID, PRT.OPERATING_UNIT, PRT.PRODUCT, PRT.FUND_CODE, PRT.CLASS_FLD, PRT.PROGRAM_CODE, PRT.BUDGET_REF, PRT.AFFILIATE, PRT.AFFILIATE_INTRA1, PRT.AFFILIATE_INTRA2, PRT.CHARTFIELD1, PRT.CHARTFIELD2, PRT.CHARTFIELD3, PRT.SYSTEM_SOURCE, PRT.PROCESS_STATUS, PRT.BI_DISTRIB_STATUS, PRT.RATE_PLAN, PRT.DESCR, ' ', PRT.PROJ_ROLE, PRT.TIER_PRICE_SW, PRT.PRICED_RATE, PRT.RATE_MULT, PRT.RATE_DIV, PRT.CST_DISTRIB_STATUS, PRT.REV_DISTRIB_STATUS, PRT.RATE_DEF_TYPE, PRT.BUSINESS_UNIT_WO, PRT.WO_ID, PRT.WO_TASK_ID, PRT.RSRC_TYPE, PRT.RES_LN_NBR, PRT.PC_TEMPLATE_ID, ' ', 0, 0, PRT.TEMPLATE_TYPE, PRT.RATE_PLAN_TYPE, PRT.RATE_DEF_BIL, PRT.RATE_DEF_COST, PRT.RATE_DEF_REV FROM PS_PRT_PRICE4 PRT WHERE PRT.PROCESS_INSTANCE = 2690469 AND NOT EXISTS ( SELECT 'X' FROM PS_PC_RT_RUN_TA24 A
WHERE A.BUSINESS_UNIT = PRT.BUSINESS_UNIT AND A.PROJECT_ID = PRT.PROJECT_ID AND A.ACTIVITY_ID = PRT.ACTIVITY_ID AND A.RESOURCE_ID = PRT.RESOURCE_ID AND A.PROCESS_INSTANCE = 2690469)
====================End of query=================================
Best regards.

Similar Messages

  • Tuning : Inconsistent result between Explain plan VS Execution Time

    Dear Experts,
    Need your suggestions belongs to contrary result between Explain plan VS Execution Time
    Environment :_
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit
    PL/SQL Release 10.2.0.4.0 - Production
    CORE     10.2.0.4.0     Production
    TNS for Linux: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production
    Red Hat Enterprise Linux 5.4
    There's same query but : 1st query access Loan_Account, 2nd query access Loan_Account_Han
    *1st.*
    Query Access Via : Loan_account (Partition Type : Hash (5) with column Contract_Number)
    Explain Plan : cost: 4,432, bytes: 716, cardinality: 2
    Execution Time : 13 seconds
    *2nd.*
    Query Access Via : Loan_Account_Han (Partition Type : List(5) with column Loan_Status)
    Explain Plan : cost:188,447 bytes: 1,661,088, cardinality: 4,719
    Execution Time : 10 seconds
    Note :_
    all tables and all indexes belong to the table which included in query has been analyzed.
    my question :
    1. why it could become like this ? I even confusing with Jonathan Lewis Theory : Cost-Based Fundamental Book.
    with this result, I even not believed with the result from Explain Plan anymore.
    2. If analyze tables and indexes to update statistics which help CBO to choose the best path as part of Daily Performance Tuning,
    is there a way that could do in enviroment 24x7 ?
    Note : if original query is needed, I'll posting it here.
    Any help is very appreciated and thanks very much.
    Regards,
    Sigcle

    The DBMS_XPLAN.DISPLAY_CURSOR output
    Query no 1
    PLAN_TABLE_OUTPUT
    SQL_ID  bq7avs72xvmkv, child number 0
    SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id,        la.contract_number, mc.customer_name,       
    dco.os_principal_on_schedule AS os_principal_on_schedule,        f_get_param_value (la.financing_type,                           'FinancingType'                  
           ) AS financing_type,        CASE la.financing_type           WHEN 11                    -- Asset Purchase              THEN NVL (tp.os_principal_cust,     
                      la.os_principal_cust                       )           WHEN 12                                            -- JF Channelling              THEN
    NVL (tp.os_principal_mf, la.os_principal)        END AS os_principal_actual,        CASE           WHEN dco.bi_collectibility_with_gp >= 3              THEN 0    
          ELSE CASE           WHEN la.financing_type = '12'              THEN   NVL (ia.accrue_interest_pl, 0)                   + NVL (ia.accrue_interest_npl, 0)    
          ELSE   NVL (ia.accrue_
    Plan hash value: 4011856754
    | Id  | Operation                                  | Name                           | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    |   1 |  TABLE ACCESS BY INDEX ROWID               | COLLECTIBILITY_CODE            |      3 |      1 |      3 |00:00:00.01 |       9 |      2 |       |       |          |
    |*  2 |   INDEX SKIP SCAN                          | UNQ_COLLECTIBILITY_CODE        |      3 |      1 |      3 |00:00:00.01 |       6 |      1 |       |       |          |
    |   3 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    501 |      1 |    501 |00:00:00.03 |    2004 |    796 |       |       |          |
    |*  4 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    501 |      1 |    501 |00:00:00.02 |    1503 |    377 |       |       |          |
    |   5 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.10 |    3220 |   1074 |       |       |          |
    |*  6 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.09 |    2887 |   1074 |       |       |          |
    |   7 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.05 |    1464 |    495 |       |       |          |
    |*  8 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.05 |    1297 |    495 |       |       |          |
    |   9 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 10 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  11 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 12 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |  13 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 14 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  15 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 16 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |  17 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 18 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  19 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 20 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |* 21 |  TABLE ACCESS FULL                         | COLLECTIBILITY_CODE            |      3 |      1 |      3 |00:00:00.01 |      12 |      1 |       |       |          |
    |  22 |  NESTED LOOPS OUTER                        |                                |      1 |      2 |    501 |00:00:01.02 |   96112 |  20091 |       |       |          |
    |  23 |   NESTED LOOPS                             |                                |      1 |      2 |    501 |00:00:00.28 |   13445 |   5358 |       |       |          |
    |  24 |    NESTED LOOPS                            |                                |      1 |      2 |    501 |00:00:00.26 |   11441 |   5071 |       |       |          |
    |  25 |     NESTED LOOPS OUTER                     |                                |      1 |      2 |    501 |00:00:00.24 |    9433 |   5014 |       |       |          |
    |* 26 |      HASH JOIN                             |                                |      1 |      2 |    501 |00:00:00.03 |     329 |    325 |  1206K|  1206K|  341K (0)|
    |* 27 |       TABLE ACCESS FULL                    | CURRENCY                       |      1 |      1 |      1 |00:00:00.01 |       3 |      2 |       |       |          |
    |* 28 |       HASH JOIN                            |                                |      1 |     61 |    501 |00:00:00.02 |     326 |    323 |   868K|   868K|  947K (0)|
    |* 29 |        HASH JOIN                           |                                |      1 |     10 |     13 |00:00:00.01 |       7 |      6 |   947K|   947K| 1030K (0)|
    |  30 |         TABLE ACCESS BY INDEX ROWID        | MULTIFINANCE                   |      1 |      5 |      9 |00:00:00.01 |       2 |      2 |       |       |          |
    |* 31 |          INDEX RANGE SCAN                  | IDX_STATUS_MF                  |      1 |      5 |      9 |00:00:00.01 |       1 |      1 |       |       |          |
    |* 32 |         TABLE ACCESS FULL                  | AGREEMENT                      |      1 |     18 |     13 |00:00:00.01 |       5 |      4 |       |       |          |
    |  33 |        VIEW                                |                                |      1 |    110 |    501 |00:00:00.02 |     319 |    317 |       |       |          |
    |* 34 |         HASH JOIN RIGHT OUTER              |                                |      1 |    110 |    501 |00:00:00.02 |     319 |    317 |  1011K|  1011K|  317K (0)|
    |  35 |          TABLE ACCESS BY INDEX ROWID       | TENANT_PARAMETER               |      1 |      1 |      1 |00:00:00.01 |       2 |      2 |       |       |          |
    |* 36 |           INDEX UNIQUE SCAN                | PK_TENANT_PARAMETER            |      1 |      1 |      1 |00:00:00.01 |       1 |      1 |       |       |          |
    |* 37 |          TABLE ACCESS BY GLOBAL INDEX ROWID| LOAN_ACCOUNT                   |      1 |    110 |    501 |00:00:00.02 |     317 |    315 |       |       |          |
    |* 38 |           INDEX RANGE SCAN                 | IDX_STATUS_LA1                 |      1 |   4394 |   3025 |00:00:00.01 |      15 |     14 |       |       |          |
    |* 39 |      TABLE ACCESS BY INDEX ROWID           | TX_PAYMENT                     |    501 |      1 |      0 |00:00:00.16 |    9104 |   4689 |       |       |          |
    |* 40 |       INDEX RANGE SCAN                     | FK_TX_PAY_LOAN_ACCT            |    501 |     12 |   8799 |00:00:00.02 |    1038 |    207 |       |       |          |
    |  41 |     TABLE ACCESS BY INDEX ROWID            | DL_CL_OUTSTANDING              |    501 |      1 |    501 |00:00:00.02 |    2008 |     57 |       |       |          |
    |* 42 |      INDEX RANGE SCAN                      | IDXLO_CNUM                     |    501 |      1 |    501 |00:00:00.01 |    1507 |     37 |       |       |          |
    |* 43 |    TABLE ACCESS BY INDEX ROWID             | MF_CUSTOMER                    |    501 |      1 |    501 |00:00:00.02 |    2004 |    287 |       |       |          |
    |* 44 |     INDEX UNIQUE SCAN                      | MF_CUSTOMER_PK                 |    501 |      1 |    501 |00:00:00.01 |    1503 |     24 |       |       |          |
    |* 45 |   TABLE ACCESS BY INDEX ROWID              | TX_INTEREST_ACCRUE             |    501 |      1 |      0 |00:00:00.73 |   82667 |  14733 |       |       |          |
    |* 46 |    INDEX RANGE SCAN                        | FK_TX_INTEREST_ACCRUE_LOAN_ACC |    501 |     67 |  40581 |00:00:00.14 |   42084 |    451 |       |       |          |
    Predicate Information (identified by operation id):
       2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
           filter("XX"."COLLECTIBILITY_CODE"=:B1)
       4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
       6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
       8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
      26 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
      27 - filter(UPPER("CURR"."STATUS")='A')
      28 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
      29 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
      31 - access("MF"."SYS_NC00052$"='A')
      32 - filter(UPPER("A"."STATUS")='A')
      34 - access("LA"."TENANT_ID"="TENANT_ID")
      36 - access("TENANT_PARAMETER_ID"=23)
      37 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR ("LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  UPPER("LA"."LOAN_STATUS")='CN')))
      38 - access("LA"."SYS_NC00118$"='A')
      39 - filter(("TP"."APPROVAL_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"=152 AND UPPER("TP"."APPROVAL_STATUS")='A'))
      40 - access("TP"."LOAN_ACCOUNT_ID"="from$_subquery$_016"."LOAN_ACCOUNT_ID")
      42 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
      43 - filter(UPPER("MC"."STATUS")='A')
      44 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")
      45 - filter("IA"."ACCRUE_DATE"="XX"."PREV_DATE")
      46 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID")
    The DBMS_XPLAN.DISPLAY_CURSOR output after : alter system flush buffer_cache; alter system flush shared_pool;
    Query no 2
    PLAN_TABLE_OUTPUT
    SQL_ID  cxmg4jfvr9pz0, child number 0
    SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id,        la.contract_number, mc.customer_name,       
    dco.os_principal_on_schedule AS os_principal_on_schedule,        f_get_param_value (la.financing_type,                           'FinancingType'                  
           ) AS financing_type,        CASE la.financing_type           WHEN 11                    -- Asset Purchase              THEN NVL (tp.os_principal_cust,     
                      la.os_principal_cust                       )           WHEN 12                                            -- JF Channelling              THEN
    NVL (tp.os_principal_mf, la.os_principal)        END AS os_principal_actual,        CASE           WHEN dco.bi_collectibility_with_gp >= 3              THEN 0    
          ELSE CASE           WHEN la.financing_type = '12'              THEN   NVL (ia.accrue_interest_pl, 0)                   + NVL (ia.accrue_interest_npl, 0)    
          ELSE   NVL (ia.accrue_
    Plan hash value: 2072372033
    | Id  | Operation                            | Name                           | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT                     |                                |  4719 |  1622K|   188K (32)| 00:37:42 |       |       |
    |   1 |  TABLE ACCESS BY INDEX ROWID         | COLLECTIBILITY_CODE            |     1 |    12 |     3   (0)| 00:00:01 |       |       |
    |*  2 |   INDEX SKIP SCAN                    | UNQ_COLLECTIBILITY_CODE        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   3 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  4 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   5 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  6 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   7 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  8 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   9 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 10 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  11 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 12 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  13 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 14 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  15 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 16 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  17 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 18 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  19 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 20 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |* 21 |  TABLE ACCESS FULL                   | COLLECTIBILITY_CODE            |     1 |    12 |     3   (0)| 00:00:01 |       |       |
    |  22 |  NESTED LOOPS                        |                                |  4719 |  1622K|   188K (32)| 00:37:42 |       |       |
    |  23 |   NESTED LOOPS                       |                                |  4719 |  1460K|   183K (33)| 00:36:45 |       |       |
    |  24 |    NESTED LOOPS OUTER                |                                |  4719 |  1354K|   180K (33)| 00:36:07 |       |       |
    |  25 |     NESTED LOOPS OUTER               |                                |  4719 |  1225K|   130K (46)| 00:26:01 |       |       |
    |* 26 |      HASH JOIN                       |                                |  4719 |  1106K| 23591   (2)| 00:04:44 |       |       |
    |  27 |       TABLE ACCESS BY INDEX ROWID    | MULTIFINANCE                   |     5 |   130 |     2   (0)| 00:00:01 |       |       |
    |* 28 |        INDEX RANGE SCAN              | IDX_STATUS_MF                  |     5 |       |     1   (0)| 00:00:01 |       |       |
    |* 29 |       HASH JOIN                      |                                |  8494 |  1775K| 23589   (2)| 00:04:44 |       |       |
    |* 30 |        TABLE ACCESS FULL             | AGREEMENT                      |    18 |   360 |     3   (0)| 00:00:01 |       |       |
    |* 31 |        HASH JOIN                     |                                |  8494 |  1609K| 23585   (2)| 00:04:44 |       |       |
    |* 32 |         TABLE ACCESS FULL            | CURRENCY                       |     1 |     4 |     3   (0)| 00:00:01 |       |       |
    |  33 |         VIEW                         |                                |   212K|    38M| 23579   (2)| 00:04:43 |       |       |
    |* 34 |          HASH JOIN RIGHT OUTER       |                                |   212K|    32M| 23579   (2)| 00:04:43 |       |       |
    |  35 |           TABLE ACCESS BY INDEX ROWID| TENANT_PARAMETER               |     1 |    74 |     1   (0)| 00:00:01 |       |       |
    |* 36 |            INDEX UNIQUE SCAN         | PK_TENANT_PARAMETER            |     1 |       |     0   (0)| 00:00:01 |       |       |
    |  37 |           PARTITION LIST ALL         |                                |   212K|    17M| 23575   (2)| 00:04:43 |     1 |     5 |
    |* 38 |            TABLE ACCESS FULL         | LOAN_ACCOUNT_HAN               |   212K|    17M| 23575   (2)| 00:04:43 |     1 |     5 |
    |  39 |      TABLE ACCESS BY INDEX ROWID     | TX_INTEREST_ACCRUE             |     1 |    26 |   130K (46)| 00:26:01 |       |       |
    |  40 |       BITMAP CONVERSION TO ROWIDS    |                                |       |       |            |          |       |       |
    |  41 |        BITMAP AND                    |                                |       |       |            |          |       |       |
    |  42 |         BITMAP CONVERSION FROM ROWIDS|                                |       |       |            |          |       |       |
    |* 43 |          INDEX RANGE SCAN            | FK_TX_INTEREST_ACCRUE_LOAN_ACC |    67 |       |     0   (0)| 00:00:01 |       |       |
    |  44 |         BITMAP CONVERSION FROM ROWIDS|                                |       |       |            |          |       |       |
    |* 45 |          INDEX RANGE SCAN            | IDX_TX_INTEREST_ACCRUE         |    67 |       |    12 (100)| 00:00:01 |       |       |
    |* 46 |     TABLE ACCESS BY INDEX ROWID      | TX_PAYMENT                     |     1 |    28 |    11   (0)| 00:00:01 |       |       |
    |* 47 |      INDEX RANGE SCAN                | FK_TX_PAY_LOAN_ACCT            |    12 |       |     0   (0)| 00:00:01 |       |       |
    |  48 |    TABLE ACCESS BY INDEX ROWID       | DL_CL_OUTSTANDING              |     1 |    23 |     1   (0)| 00:00:01 |       |       |
    |* 49 |     INDEX RANGE SCAN                 | IDXLO_CNUM                     |     1 |       |     0   (0)| 00:00:01 |       |       |
    |* 50 |   TABLE ACCESS BY INDEX ROWID        | MF_CUSTOMER                    |     1 |    35 |     1   (0)| 00:00:01 |       |       |
    |* 51 |    INDEX UNIQUE SCAN                 | MF_CUSTOMER_PK                 |     1 |       |     0   (0)| 00:00:01 |       |       |
    Predicate Information (identified by operation id):
       2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
           filter("XX"."COLLECTIBILITY_CODE"=:B1)
       4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
       6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
       8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
      26 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
      28 - access(UPPER("STATUS")='A')
      29 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
      30 - filter(UPPER("A"."STATUS")='A')
      31 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
      32 - filter(UPPER("CURR"."STATUS")='A')
      34 - access("LA"."TENANT_ID"="TENANT_ID"(+))
      36 - access("TENANT_PARAMETER_ID"(+)=23)
      38 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR "LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
                  AND UPPER("LA"."LOAN_STATUS")='CN') AND UPPER("LA"."STATUS")='A')
      43 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID"(+))
      45 - access("IA"."ACCRUE_DATE"(+)="XX"."PREV_DATE")
      46 - filter("TP"."APPROVAL_DATE"(+)=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"(+)=152
                  AND UPPER("TP"."APPROVAL_STATUS"(+))='A')
      47 - access("TP"."LOAN_ACCOUNT_ID"(+)="from$_subquery$_016"."LOAN_ACCOUNT_ID")
      49 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
      50 - filter(UPPER("MC"."STATUS")='A')
      51 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")Typically both query running on 10-12 seconds (or same execution time).
    And I can't provide autotrace and tkprof output cause I cannot access via sqlplus.
    Thanks very much for the link HOW TO: Post a SQL statement tuning request - template posting
    Regards,
    Sigcle
    Edited by: SigCle on Feb 25, 2013 4:22 AM

  • Explain Plan and Execution Plan in 10gR2.

    Hi,
    Version 10.2.0.1.0.
    I have two questions:
    1) If the explain plan differs from the execution path in this version, then, is it safe to assume that the statistics are stale (or not gathered at all) on the underlying tables?
    2) Can you in any way make a query use RBO instead of CBO? (I know it doesn't make any sense since CBO is lot smarter, but, for purely academic reasons).
    Thank you,
    Rahul.

    The rule based optimizer is most definitely present in 10gR2. It might not be in the documentation, but it is still there.
    C:\sql>sqlplus test/test
    SQL*Plus: Release 10.2.0.2.0 - Production on Tue Oct 10 15:43:34 2006
    Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
    With the Partitioning, OLAP and Data Mining options
    test@SVTEST> set autotrace traceonly
    test@SVTEST> alter session set optimizer_mode=rule;
    Session altered.
    Elapsed: 00:00:00.01
    test@SVTEST> select * from dual;
    Elapsed: 00:00:00.03
    Execution Plan
    Plan hash value: 272002086
    | Id | Operation | Name |
    | 0 | SELECT STATEMENT | |
    | 1 | TABLE ACCESS FULL| DUAL |
    Note
    - rule based optimizer used (consider using cbo)
    Statistics
    1 recursive calls
    0 db block gets
    3 consistent gets
    2 physical reads
    0 redo size
    407 bytes sent via SQL*Net to client
    381 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed
    test@SVTEST>

  • Why two different explain plan for same objects?

    Believe or not there are two different databases, one for processing and one for reporting, plan is show different for same query. Table structure and indexes are same. It's 11G
    Thanks
    Good explain plan .. works fine..
    Plan
    SELECT STATEMENT  ALL_ROWSCost: 12,775  Bytes: 184  Cardinality: 1                                                                        
         27 SORT UNIQUE  Cost: 12,775  Bytes: 184  Cardinality: 1                                                                   
              26 NESTED LOOPS                                                              
                   24 NESTED LOOPS  Cost: 12,774  Bytes: 184  Cardinality: 1                                                         
                        22 HASH JOIN  Cost: 12,772  Bytes: 178  Cardinality: 1                                                    
                             20 NESTED LOOPS SEMI  Cost: 30  Bytes: 166  Cardinality: 1                                               
                                  17 NESTED LOOPS  Cost: 19  Bytes: 140  Cardinality: 1                                          
                                       14 NESTED LOOPS OUTER  Cost: 16  Bytes: 84  Cardinality: 1                                     
                                            11 VIEW DSSADM. Cost: 14  Bytes: 37  Cardinality: 1                                
                                                 10 NESTED LOOPS                           
                                                      8 NESTED LOOPS  Cost: 14  Bytes: 103  Cardinality: 1                      
                                                           6 NESTED LOOPS  Cost: 13  Bytes: 87  Cardinality: 1                 
                                                                3 INLIST ITERATOR            
                                                                     2 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOB_FAMILY_TBL Cost: 10  Bytes: 51  Cardinality: 1       
                                                                          1 INDEX RANGE SCAN INDEX DSSODS.DRV_PS_JOB_FAMILY_TBL_CL_SETID Cost: 9  Cardinality: 1 
                                                                5 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_JOBCODE Cost: 3  Bytes: 36  Cardinality: 1            
                                                                     4 INDEX RANGE SCAN INDEX DSSADM.STAN_JB_FN_IDX Cost: 2  Cardinality: 1       
                                                           7 INDEX UNIQUE SCAN INDEX (UNIQUE) DSSODS.DRV_PS_JOBCODE_TBL_SEQ_KEY_RPT Cost: 0  Cardinality: 1                 
                                                      9 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOBCODE_TBL_RPT Cost: 1  Bytes: 16  Cardinality: 1                      
                                            13 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PSXLATITEM_RPT Cost: 2  Bytes: 47  Cardinality: 1                                
                                                 12 INDEX RANGE SCAN INDEX DSSODS.PK_DRV_RIXLATITEM_RPT Cost: 1  Cardinality: 1                           
                                       16 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_JOBCODE Cost: 3  Bytes: 56  Cardinality: 1                                     
                                            15 INDEX RANGE SCAN INDEX DSSADM.DIM_JOBCODE_EXPDT1 Cost: 2  Cardinality: 1                                
                                  19 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOB_RPT Cost: 11  Bytes: 438,906  Cardinality: 16,881                                          
                                       18 INDEX RANGE SCAN INDEX DSSODS.DRV_PS_JOB_JOBCODE_RPT Cost: 2  Cardinality: 8                                     
                             21 INDEX FAST FULL SCAN INDEX (UNIQUE) DSSADM.Z_PK_JOBCODE_PROMPT_TBL Cost: 12,699  Bytes: 66,790,236  Cardinality: 5,565,853                                               
                        23 INDEX RANGE SCAN INDEX DSSADM.DIM_PERSON_EMPL_RCD_SEQ_KEY Cost: 1  Cardinality: 1                                                    
                   25 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_PERSON_EMPL_RCD Cost: 2  Bytes: 6  Cardinality: 1                                                         This bad plan ... show merge join cartesian and full table ..
    Plan
    SELECT STATEMENT  ALL_ROWSCost: 3,585  Bytes: 237  Cardinality: 1                                                              
         26 SORT UNIQUE  Cost: 3,585  Bytes: 237  Cardinality: 1                                                         
              25 NESTED LOOPS SEMI  Cost: 3,584  Bytes: 237  Cardinality: 1                                                    
                   22 NESTED LOOPS  Cost: 3,573  Bytes: 211  Cardinality: 1                                               
                        20 MERGE JOIN CARTESIAN  Cost: 2,864  Bytes: 70,446  Cardinality: 354                                          
                             17 NESTED LOOPS                                     
                                  15 NESTED LOOPS  Cost: 51  Bytes: 191  Cardinality: 1                                
                                       13 NESTED LOOPS OUTER  Cost: 50  Bytes: 180  Cardinality: 1                           
                                            10 HASH JOIN  Cost: 48  Bytes: 133  Cardinality: 1                      
                                                 6 NESTED LOOPS                 
                                                      4 NESTED LOOPS  Cost: 38  Bytes: 656  Cardinality: 8            
                                                           2 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DIM_JOBCODE Cost: 14  Bytes: 448  Cardinality: 8       
                                                                1 INDEX RANGE SCAN INDEX REPORT2.STAN_PROM_JB_IDX Cost: 6  Cardinality: 95 
                                                           3 INDEX RANGE SCAN INDEX REPORT2.SETID_JC_IDX Cost: 2  Cardinality: 1       
                                                      5 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DIM_JOBCODE Cost: 3  Bytes: 26  Cardinality: 1            
                                                 9 INLIST ITERATOR                 
                                                      8 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOB_FAMILY_TBL Cost: 10  Bytes: 51  Cardinality: 1            
                                                           7 INDEX RANGE SCAN INDEX REPORT2.DRV_PS_JOB_FAMILY_TBL_CL_SETID Cost: 9  Cardinality: 1       
                                            12 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PSXLATITEM_RPT Cost: 2  Bytes: 47  Cardinality: 1                      
                                                 11 INDEX RANGE SCAN INDEX REPORT2.PK_DRV_RIXLATITEM_RPT Cost: 1  Cardinality: 1                 
                                       14 INDEX UNIQUE SCAN INDEX (UNIQUE) REPORT2.DRV_PS_JOBCODE_TBL_SEQ_KEY_RPT Cost: 0  Cardinality: 1                           
                                  16 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOBCODE_TBL_RPT Cost: 1  Bytes: 11  Cardinality: 1                                
                             19 BUFFER SORT  Cost: 2,863  Bytes: 4,295,552  Cardinality: 536,944                                     
                                  18 TABLE ACCESS FULL TABLE REPORT2.DIM_PERSON_EMPL_RCD Cost: 2,813  Bytes: 4,295,552  Cardinality: 536,944                                
                        21 INDEX RANGE SCAN INDEX (UNIQUE) REPORT2.Z_PK_JOBCODE_PROMPT_TBL Cost: 2  Bytes: 12  Cardinality: 1                                          
                   24 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOB_RPT Cost: 11  Bytes: 1,349,920  Cardinality: 51,920                                               
                        23 INDEX RANGE SCAN INDEX REPORT2.DRV_PS_JOB_JOBCODE_RPT Cost: 2  Cardinality: 8                                          

    user550024 wrote:
    I am really surprise that the stat for good sql are little old. I just computed the states of bad sql so they are uptodate..
    There is something terribly wrong..Not necessarily. Just using the default stats collection I've seen a few cases of things suddenly going wrong. As the data increases, it gets closer to an edge case where the inadequacy of the statistics convinces the optimizer to do a wrong plan. To fix, I could just go into dbconsole, set the stats back to a time when they worked, and locked them. In most cases it's definitely better to figure out what is really going on, though, to give the optimizer better information to work with. Aside from the value of learning how to do it, for some cases it's not so simple. Also, many think the default settings of the database statistic collection may be wrong in general (in 10.2.x, at least). So much depends on your application and data that you can't make too many generalizations. You have to look at the evidence and figure it out. There is still a steep learning curve for the tools to look at the evidence. People are here to help with that.
    Most of the time it works better than a dumb rule based optimizer, but at the cost of a few situations where people are smarter than computers. It's taken a lot of years to get to this point.

  • Real explain plan differs from one in v$sqlarea

    I have some more or less complex queries which I catch on runtime by reading v$sqlarea table to find sql with high cost..
    but..
    I found some highly costed sql, but when I run it through client ti see it's explain plan and execution time, it's much faster with very little cost
    why?
    am I wrong when I read v$sqlarea?
    I'm using Oracle 11g R2

    This is not at all surprising. Jonathan Lewis and many other have discussed this numerous times both in these forums, in books, in white papers, and in conference presentations.
    That said ... you should be looking in gv$sql_plan.

  • Autotrace explain plan

    Hi
    i like to know how can i understand the output of the autotrace ..
    my current sql explain plan is
    Execution Plan
    Plan hash value: 2038802176
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 9 | 1026 | 332 (3)| 00:00:04 |
    | 1 | SORT ORDER BY | | 9 | 1026 | 332 (3)| 00:00:04 |
    | 2 | HASH UNIQUE | | 9 | 1026 | 331 (3)| 00:00:04 |
    | 3 | NESTED LOOPS | | | | | |
    | 4 | NESTED LOOPS | | 9 | 1026 | 330 (2)| 00:00:04 |
    |* 5 | TABLE ACCESS FULL | EATTEND_STUDENT_ATTENDANCE | 9 | 144 | 294 (3)|
    |* 6 | INDEX RANGE SCAN | PERF_EATTEND_STUDENT_INFO_N99 | 7 | | 2 (0)| 0
    |* 7 | TABLE ACCESS BY INDEX ROWID| EATTEND_STUDENT_INFO | 1 | 98 | 4 (0)| 0
    how will i decide where is the performance issue ???
    thanks

    Don't think you have any issues here, given the small number of rows you're query returns.
    You can find useful information regariding interpreting execution plans by exploring these links:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i16971
    http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:111012348061
    http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:231814117467
    and do some searches on those sites yourself
    Also, post your execution plan between the {noformat}{noformat} tag, so it'll stay formatted.
    For example, when you type:
    {noformat}select *
    from dual{noformat}
    it will appear as:select *
    from dualwhen you post it on this forum.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • How to provide tuning solution from explain plan only

    Dear all,
    If I do not have any kind of access to the database and only have explain plan with me,how I can provideperformance or query  tuning solutions from that??
    Regards
    Anirban

    958657,
    If I do not have any kind of access to the database and only have explain plan with me,how I can provide performance or query  tuning solutions from that??
    This is contradictory as you said you don't have access but you have explain plan. You wont get any explain plan until you connect to the database and run "Explain plan for" statement for the query. How do you get the "explain plan"? If it is provided by someone to you, you might request to get the "Execution Plan" for the query.
    Keep in mind that "explain plan" and  "execution plan "  - these two are not same.
    Explain plan  is not enough for predicting elapsed/response time of a query as Explain plan is static Whereas Execution plan is dynamic and talks about query in execution.
    Oracle provides following things for a query to diagnose its performance :
    1. Static - Explain plan  - Not enough
    2. Dynamic:  Execution plan - Run time Plan
    3. awr/ statspack execution plan --Run time from the past - this is again dynamic execution plan of query runs in the past
    Tuning recommendation is possible by comparing run time of the same query in the past and today's run time and based on further analysis.
    Tuning Recommendation is not possible if you have only Explain plan.

  • Explain plan result for a long-running query used in data-warehousing. Tuni

    I have executed an explain plan for a query that is used in a data-warehousing application.
    This sql is taking too long to execute as it is visiting 24 partitions.
    Where each partition contains data for 1 month month, so it fetches last 2 year data.
    And each partition has a million or so rows.
    All this is kept in table prescrip_retail. So this table has 24 partitions.
    abc@def>explain plan set statement_id='dwh_query'
    2 for
    3 SELECT r.pier_account_id,
    4 p.presc_num,
    5 spm.product_id,
    6 p.month,
    7 t.best_call_state,
    8 sum(p.trx_count)
    9 FROM rlup_assigned_account r,
    10 temp_presc_num_TEST t,
    11 retail.prescrip_retail p,
    12 sherlock.sherlock_product_mapping spm
    13 WHERE spm.product_id like '056%'
    14 and t.CLIENT_ID='934759'
    15 and p.month >= add_months(sysdate,-24)
    16 and spm.mds6 = p.product_id
    17 and t.CLIENT_ID = p.presc_num
    18 and r.ndc_pyr_id = p.payer_plan
    19 and t.best_call_state = r.ST
    20 GROUP BY r.pier_account_id,
    21 p.presc_num,
    22 spm.product_id,
    23 p.month,
    24 t.best_call_state;
    Explained.
    abc@def>ed
    Wrote file afiedt.buf
    1 select operation,options,optimizer,cost,cardinality,partition_start,partition_stop
    2 from plan_table
    3* where statement_id='dwh_query'
    abc@def>/
    OPERATION OPTIONS OPTIMIZER COST CARDINALITY
    PARTITION_START
    PARTITION_STOP
    SELECT STATEMENT CHOOSE 850 1
    SORT GROUP BY 850 1
    NESTED LOOPS 848 1
    HASH JOIN 845 3
    HASH JOIN 842 6
    TABLE ACCESS FULL ANALYZED 1 6
    PARTITION RANGE ITERATOR
    KEY
    36
    TABLE ACCESS BY LOCAL INDEX ROWID ANALYZED 839 166
    KEY
    36
    BITMAP CONVERSION TO ROWIDS
    BITMAP INDEX SINGLE VALUE
    KEY
    36
    TABLE ACCESS FULL 2 50
    TABLE ACCESS BY INDEX ROWID ANALYZED 1 149501
    INDEX UNIQUE SCAN ANALYZED 149501
    13 rows selected.

    Here is the create statement for PRESCRIP_RETAIL table:
    I have observed 2 things:
    1. In the query the following joins are present.
    13 WHERE spm.product_id like '056%'
    14 and t.CLIENT_ID='934759'
    15 and p.month >= add_months(sysdate,-24)
    16 and spm.mds6 = p.product_id
    17 and t.CLIENT_ID = p.presc_num
    18 and r.ndc_pyr_id = p.payer_plan
    19 and t.best_call_state = r.ST
    Index exist for p.product_id,p.presc_num,p.payer_plan as you can see below.
    However, the index does not exist for month.
    I am also doing search for month.
    I feel if I create a "partitioned index" on month, query performance should improve.
    Q Can you provide me the syntax for creating a partitioned index on month?
    2.The following tables are used in the query:
    9 FROM rlup_assigned_account r,
    10 temp_presc_num_TEST t,
    11 retail.prescrip_retail p,
    12 sherlock.sherlock_product_mapping spm
    In these tables, apart from sherlock.sherlock_product_mapping table the statistics that exist is old.
    I need to analyse on table level as well as column level.
    For example:
    Table prescrip_retail is analyzed in 2002,
    table temp_presc_num_TEST is not analysed at all.
    table rlup_assigned_account is analysed in Feb 2007.
    sherlock_product_mapping is the only table that has updated statistics, analysed on Oct. 2007
    Here is the table creation statement of PRESCRIP_RETAIL and index on it.
    Prompt Table PRESCRIP_RETAIL;
    -- PRESCRIP_RETAIL (Table)
    -- Row count:2806673860
    CREATE TABLE RETAIL.PRESCRIP_RETAIL
    PRESC_NUM NUMBER,
    PIER_NUM CHAR(8),
    RELID CHAR(9) NOT NULL,
    ME_NUM CHAR(10) NOT NULL,
    PRODUCT_ID CHAR(6) NOT NULL,
    PRODUCT_FRMSTR CHAR(1) NOT NULL,
    PAYER_PLAN CHAR(6) NOT NULL,
    MONTH DATE NOT NULL,
    PYMT_CODE CHAR(1) NOT NULL,
    NRX_COUNT NUMBER(7) NOT NULL,
    NRX_QUANTITY NUMBER(9) NOT NULL,
    NRX_DOLLARS NUMBER(13,2) NOT NULL,
    TRX_COUNT NUMBER(7) NOT NULL,
    TRX_QUANTITY NUMBER(9) NOT NULL,
    TRX_DOLLARS NUMBER(13,2) NOT NULL
    TABLESPACE PRESC_PARTITION_29
    NOLOGGING
    PARTITION BY RANGE (MONTH)
    PARTITION PRESC200406 VALUES LESS THAN (TO_DATE(' 2004-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407 VALUES LESS THAN (TO_DATE(' 2004-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408 VALUES LESS THAN (TO_DATE(' 2004-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409 VALUES LESS THAN (TO_DATE(' 2004-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410 VALUES LESS THAN (TO_DATE(' 2004-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411 VALUES LESS THAN (TO_DATE(' 2004-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412 VALUES LESS THAN (TO_DATE(' 2005-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501 VALUES LESS THAN (TO_DATE(' 2005-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502 VALUES LESS THAN (TO_DATE(' 2005-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503 VALUES LESS THAN (TO_DATE(' 2005-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504 VALUES LESS THAN (TO_DATE(' 2005-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505 VALUES LESS THAN (TO_DATE(' 2005-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506 VALUES LESS THAN (TO_DATE(' 2005-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507 VALUES LESS THAN (TO_DATE(' 2005-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508 VALUES LESS THAN (TO_DATE(' 2005-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509 VALUES LESS THAN (TO_DATE(' 2005-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510 VALUES LESS THAN (TO_DATE(' 2005-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511 VALUES LESS THAN (TO_DATE(' 2005-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512 VALUES LESS THAN (TO_DATE(' 2006-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601 VALUES LESS THAN (TO_DATE(' 2006-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602 VALUES LESS THAN (TO_DATE(' 2006-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603 VALUES LESS THAN (TO_DATE(' 2006-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604 VALUES LESS THAN (TO_DATE(' 2006-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605 VALUES LESS THAN (TO_DATE(' 2006-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606 VALUES LESS THAN (TO_DATE(' 2006-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607 VALUES LESS THAN (TO_DATE(' 2006-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608 VALUES LESS THAN (TO_DATE(' 2006-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609 VALUES LESS THAN (TO_DATE(' 2006-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610 VALUES LESS THAN (TO_DATE(' 2006-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611 VALUES LESS THAN (TO_DATE(' 2006-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612 VALUES LESS THAN (TO_DATE(' 2007-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701 VALUES LESS THAN (TO_DATE(' 2007-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702 VALUES LESS THAN (TO_DATE(' 2007-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703 VALUES LESS THAN (TO_DATE(' 2007-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704 VALUES LESS THAN (TO_DATE(' 2007-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705 VALUES LESS THAN (TO_DATE(' 2007-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_29
    NOCACHE
    NOPARALLEL;
    Prompt Index BX2_PRESC_PAYER;
    -- BX2_PRESC_PAYER (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX2_PRESC_PAYER ON RETAIL.PRESCRIP_RETAIL
    (PAYER_PLAN)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX3_PRESC_PAYERCD;
    -- BX3_PRESC_PAYERCD (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX3_PRESC_PAYERCD ON RETAIL.PRESCRIP_RETAIL
    (PYMT_CODE)
    TABLESPACE PRESC_PARTITION_29
    NOLOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX4_PRESC_PRESC;
    -- BX4_PRESC_PRESC (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX4_PRESC_PRESC ON RETAIL.PRESCRIP_RETAIL
    (PRESC_NUM)
    TABLESPACE PRESC_PARTITION_29
    NOLOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX5_PRESC_PIER;
    -- BX5_PRESC_PIER (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX5_PRESC_PIER ON RETAIL.PRESCRIP_RETAIL
    (PIZR_NUM)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX6_PRESC_RELID;
    -- BX6_PRESC_RELID (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX6_PRESC_RELID ON RETAIL.PRESCRIP_RETAIL
    (RELID)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX7_PRESC_ME;
    -- BX7_PRESC_ME (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX7_PRESC_ME ON RETAIL.PRESCRIP_RETAIL
    (ME_NUM)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX1_PRESC_PROD;
    -- BX1_PRESC_PROD (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX1_PRESC_PROD ON RETAIL.PRESCRIP_RETAIL
    (PRODUCT_ID, PRODUCT_FRMSTR)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;

  • Execution time from explain plan

    Hi
    How can i get the execution time of a query from explain plan (not tkprof). I don't see the execution time in the plan table output.
    Thanks

    Explain plan won't give execution time of a query because:
    - it does not execute the query
    - it only evaluates the execution plan and gives estimated costs
    I dont't know if it is possible to deduce execution time from estimated cost.
    Message was edited by:
    Pierre Forstmann

  • Execution Time & Explain Plan Variations

    I have a scenario here. I have 2 schemas; schema1 & schema2. I executed a lengthy SELECT statement of 5 TABLE JOIN in these 2 schemas. I am getting totally different execution time (one runs at 0.3 seconds & the other at 4 seconds) and a different Explain Plan. I assume that, since its the same SELECT statement in these schema, I should get the same Explain Plan. What could be the reason for these dissimilarities? Oracle Version: 9.2.0.8.0. I am ready to share the Explain Plan of these 2 schemas. But they are of length around 300 lines.
    Thank you.

    There are many factors come in to play here.
    1.) Size of all tables involved are same
    2.) structures are also same
    3.) Also indexes are same
    4.) Also stats are up to date on both
    5.) Constraints and other factors are also same.
    regards
    PravinAnd a few more.
    6) session environments are the same
    7) bind variable values are the same - or were at first execution
    I'd change 4 to read Optimizer statistics are the same. (not up to date which is a bit vague).
    In short if you are using the CBO and feed in the exact same inputs you will get the exact same plan, however typically you won't get the exact same inputs and so may get a different plan. If your query has a time element and the two queries are hard parsed at different times it may actually be impossible to get the same input - for example the percentage of a table that is returned by a predicate like
    timestamp_col > sysdate - 1 will be estimated differently depending on the time of parsing for the same data.
    That all said looking at the plans might reveal some obvious differences, though perhaps it might be better to point at a URL that holds the plans given the length you say they are.
    Niall Litchfield
    http://www.orawin.info/
    null

  • Explain plan generating it self taking very long time !!! What to do ?

    Hi,
    I am trying to generate explain plan for a query which is running more than 2 hours. I am trying to generate explain plan for query by "explin plan for select ..." but it self is taking very long time.
    Kindly suggest me how to reduce time for explain plan ? Secondly why explain plan itself taking very long time ?
    thanks & regards
    PKP

    Just guessing here, but I've experienced this behaviour when I did two explain's within a second. This is because a plan is identified by a statement_id or, if you don't provide a statement_id, by the timestamp (of DATE datatype). So if you execute two explain plans within the second (using a script), it has two sets of data with the same primary key. The hierarchical query that needs to be executed to provide you the nicely indented text, will exponentially expand in this case.
    Maybe time to clean up your plan_table ?
    Hope this helps.
    Regards,
    Rob.

  • Explain Plan shows Nested Loops, Is it good or bad?

    Hi All,
    I have a doubt in the explain plan, I would like to know if the Nested Loops , will it degrade the query performance?
    Note: I have pasted only few output that I had taken from the expalin plan.
    Do let me know if there is any article I could read to get clear understanding about the same.
    17 NESTED LOOPS ANTI Cost: 125 Bytes: 186 Cardinality: 1                                                                  
    15 NESTED LOOPS ANTI Cost: 124 Bytes: 166 Cardinality: 1                                                             
    12 NESTED LOOPS Cost: 122 Bytes: 140 Cardinality: 1                                                        
         9 NESTED LOOPS Cost: 121 Bytes: 117 Cardinality: 1           
    Thanks

    Hi,
    there is absolutely nothing wrong about nested loops (NL). It's a very efficient way of combining data from two rowsources. It works pretty much like a regular loop: it takes all rows from one rowsource (the "outer" one) and for each of them it looks up a row matching the join condition in the other rowsource (the "inner" one).
    Note that there are not so many alternatives in Oracle: there are only 3 ways to join data in Oracle, and one of them is used in rather special circumstances (merge join). So normally the choice is between a NL and a hash join. Hash join (HJ) takes the smaller dataset and builds an in-memory lookup table using a hash function on join column(s). Then it goes through the other dataset and as it goes, it applies the hashing function to join column(s) and picks the matching rows from the smaller dataset.
    Actually, hash joins and nested loops are not all that different. The basic mechanism is same: you go through one datasource and as you go, you pick matching rows from the other and do the join. The main difference is that a HJ requires some preparation work (it costs resources to build the in-memory table) and thus HJ are typically associated with less-selective queries and full table scans.
    In your particular case it's nor possible to tell whether or not NL is in order based on just a few rows from the explain plan. We need to know the structure of your tables (the DDL), what kind of data they hold (optimizer stats) and what query you are running to be able to tell.
    Best regards,
    Nikolay

  • How to improve the query performance or tune query from Explain Plan

    Hi
    The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
    SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204                                         
         8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1                                    
              5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1                               
                   2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1                          
                        1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                     
                   4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1                          
                        3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1                     
              7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1                               
                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1                          
         10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1                                    
              9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                               
         15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1                                    
              12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1                               
                   11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                          
              14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1                               
                   13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1                          
         21 FILTER                                    
              16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49                               
              20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1                               
                   18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1                          
                        17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                     
                   19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1                          
         23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1                                    
              22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                               
         45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204                                    
              42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204                               
                   38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204                          
                        34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925                     
                             30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699                
                                  26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18          
                                       25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18     
                                            24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
                                  29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32           
                                       28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32      
                                            27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
                             33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35                
                                  32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35           
                                       31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35      
                        37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38                     
                             36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2               
                                  35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2          
                   41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41                          
                        40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2                    
                             39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2               
              44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1                               
                   43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1

    damorgan wrote:
    Tuning is NOT about reducing the cost of i/o.
    i/o is only one of many contributors to cost and only one of many contributors to waits.
    Any time you would like to explore this further run this code:
    SELECT 1 FROM dual
    WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
    And when I say "extreme" I mean "EXTREME!"
    You've been warned.I think you just need a faster server.
    SQL> set autotrace traceonly statistics
    SQL> set timing on
    SQL> select 1 from dual
      2  where
      3  regexp_like   (' ','^*[ ]*a');
    no rows selected
    Elapsed: 00:00:00.00
    Statistics
              1  recursive calls
              0  db block gets
              0  consistent gets
              0  physical reads
              0  redo size
            243  bytes sent via SQL*Net to client
            349  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processedRepeated from an Oracle 10.2.0.x instance:
    SQL> SELECT DISTINCT SID FROM V$MYSTAT;
           SID
           310
    SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    Session altered.
    SQL> select 1 from dual
      2  where
      3  regexp_like   (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
    COLUMN STAT_NAME FORMAT A35 TRU
    SET PAGESIZE 200
    SELECT
      STAT_NAME,
      VALUE
    FROM
      V$SESS_TIME_MODEL
    WHERE
      SID=310;
    STAT_NAME                                VALUE
    DB time                                   9247
    DB CPU                                    9247
    background elapsed time                      0
    background cpu time                          0
    sequence load elapsed time                   0
    parse time elapsed                        6374
    hard parse elapsed time                   5997
    sql execute elapsed time                  2939
    connection management call elapsed        1660
    failed parse elapsed time                    0
    failed parse (out of shared memory)          0
    hard parse (sharing criteria) elaps          0
    hard parse (bind mismatch) elapsed           0
    PL/SQL execution elapsed time               95
    inbound PL/SQL rpc elapsed time              0
    PL/SQL compilation elapsed time              0
    Java execution elapsed time                  0
    repeated bind elapsed time                  48
    RMAN cpu time (backup/restore)               0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
    STAT_NAME                                VALUE
    DB time                                   9247
    DB CPU                                    9247
    background elapsed time                      0
    background cpu time                          0
    sequence load elapsed time                   0
    parse time elapsed                        6374
    hard parse elapsed time                   5997
    sql execute elapsed time                  2939
    connection management call elapsed        1660
    failed parse elapsed time                    0
    failed parse (out of shared memory)          0
    hard parse (sharing criteria) elaps          0
    hard parse (bind mismatch) elapsed           0
    PL/SQL execution elapsed time               95
    inbound PL/SQL rpc elapsed time              0
    PL/SQL compilation elapsed time              0
    Java execution elapsed time                  0
    repeated bind elapsed time                  48
    RMAN cpu time (backup/restore)               0The session is not reporting additional CPU usage or parse time.
    Let's check one of the session's statistics:
    SELECT
      SS.VALUE
    FROM
      V$SESSTAT SS,
      V$STATNAME SN
    WHERE
      SN.NAME='consistent gets'
      AND SN.STATISTIC#=SS.STATISTIC#
      AND SS.SID=310;
         VALUE
           163Not many consistent gets after 20+ minutes.
    Let's take a look at the plan:
    SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
    al%';
    SQL_ID        CHILD_NUMBER
    04mpgrzhsv72w            0
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
    select 1 from dual where regexp_like   (' ','^*[ ]*a')
    NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
          Please verify value of SQL_ID and CHILD_NUMBER;
          It could also be that the plan is no longer in cursor cache (check v$sql_p
    lan)No plan...
    Let's take a look at the 10053 trace file:
    Registered qb: SEL$1 0x19157f38 (PARSER)
      signature (): qb_name=SEL$1 nbfros=1 flg=0
        fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
    Predicate Move-Around (PM)
    PM: Considering predicate move-around in SEL$1 (#0).
    PM:   Checking validity of predicate move-around in SEL$1 (#0).
    CBQT: Validity checks failed for 7uqx4guu04x3g.
    CVM: Considering view merge in query block SEL$1 (#0)
    CBQT: Validity checks failed for 7uqx4guu04x3g.
    Subquery Unnest
    SU: Considering subquery unnesting in query block SEL$1 (#0)
    Set-Join Conversion (SJC)
    SJC: Considering set-join conversion in SEL$1 (#0).
    Predicate Move-Around (PM)
    PM: Considering predicate move-around in SEL$1 (#0).
    PM:   Checking validity of predicate move-around in SEL$1 (#0).
    PM:     PM bypassed: Outer query contains no views.
    FPD: Considering simple filter push in SEL$1 (#0)
    FPD:   Current where clause predicates in SEL$1 (#0) :
              REGEXP_LIKE (' ','^*[ ]*a')
    kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
    predicates with check contraints:  REGEXP_LIKE (' ','^*[ ]*a')
    after transitive predicate generation:  REGEXP_LIKE (' ','^*[ ]*a')
    finally:  REGEXP_LIKE (' ','^*[ ]*a')
    apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
    kkoqbc-start
                : call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
    kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
    I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

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

  • Explain plan changing for the same sql

    Hi All,
    In a E Business suite application, we have the 10.2.0.4 Database.
    One of the program is running a select stmt which is using different explain plan one in a month which is causing issue in the program running for longer time.
    Ex : When it uses the index A, it is running fine. When it uses the index B, it is running for longer time.
    Can you please advice on the possible reasons for the same sql to choose index B instead of index A some times.
    Thanks,
    Rakesh

    It could be that the SQL is question got aged out of the shared pool and when it came to be reparsed - the values in the bind variables were such that access via index b was more attractive than access via index a.
    Could you please send the query and the good and bad plans and all other information that might help diagnose the problem..
    Note: we had a similiar case where plans suddenly changed for no apperant reason (on 10.2.0.2) - we found that under certain circumstances the optimizer would not peek into the bind varaibles to derive the execution path.

Maybe you are looking for