Tuning of a view

Hi,
Below is the view used in cursor with order by clause. Its taking lot of time for teching rows.
Could anyone help to tune this view. so that performace can be improved.
If I remove rule based optimzer hint and checked explain plan for CBO. Its doing many full table scans and also its kaing more time then rule based.
CREATE OR REPLACE VIEW V_FIF AS
SELECT /*+ rule */
        ml_level_type                   fif_ml,
        ifs.if_ml_id                    fif_ml_id,
        ifs.if_id                       fif_if_id,
        ifs.if_type                     fif_if_type,
        ifs.if_min_stock_level          fif_min_stock_level,
        ifs.if_max_stock_level          fif_max_stock_level,
        ifs.if_mi_id                    fif_mi_id,
        ifs.if_std_produced_qty         fif_if_std_produced_qty,
        ifs.if_lotsize                  fif_if_lotsize,
        ifs.if_successor_qty            fif_successor_qty,
        ifs.if_successor_base_qty       fif_successor_base_qty,
        ifs.if_successor_uom            fif_successor_uom,
        ifs.if_if_id                    fif_if_if_id,
        ifs.if_valid_flag               fif_valid_flag,
        ifs.if_freeze_fence             fif_freeze_fence,
        ifs.if_freeze_fence_date        fif_freeze_fence_date,
        ifs.if_freeze_fence_date_old    fif_freeze_fence_date_old,
        ifs.if_facility_planning_flag   fif_facility_planning_flag,
        ifs.if_deletion_mark            fif_if_deletion_mark,
     ifs.if_allocation_fence_date     fif_allocation_fence_date,
        ifs.misr_id                     fif_misr_id,
        ifs.misr_me_id                  fif_me_id,
        ifs.item_mat_id                 fif_item_mat_id,
        ifs.item_prit_id                fif_item_prit_id,
        ifs.item_papl_id                fif_item_papl_id,
        ifs.item_repi_id                fif_item_repi_id,
        ifs.item_tnr                    fif_item_tnr,
        ifs.item_id                     fif_item_id,
        ifs.btyp_id                     fif_btyp_id,
        ifs.btyp_basic_type             fif_basic_type,
        sprd_sales_name                 fif_sprd_sales_name,
        bno_id                          fif_bno_id,
        bno_baunumber                   fif_bno,
        bno_deletion_mark               fif_bno_deletion_mark,
        bno_demand_level_code           fif_bno_demand_level_code,
        pg_id                           fif_pg_id,
        pl_process_line                 fif_pl_process_line,
        pl_id                           fif_pl_id,
        pcl_process_class               fif_pcl_process_class,
        pcl_id                          fif_pcl_id,
        pgp_id                          fif_pgp_id,
        DECODE(bs1.bs_id, NULL,DECODE(bs2.bs_id, NULL, bs3.bs_id, bs2.bs_id), bs1.bs_id)        fif_bs_id,
        DECODE(bs1.bs_business_segment, NULL,
                DECODE(bs2.bs_business_segment, NULL, bs3.bs_business_segment, bs2.bs_business_segment), bs1.bs_business_segment) fif_bs_business_segment,
        fac_id                          fif_fac_id,
        fac_facility_name               fif_fac_name,
        fac_facility_type               fif_fac_type,
        fac_usable_from                 fif_fac_usable_from,
        fac_usable_to                   fif_fac_usable_to,
        fac_loc_id                      fif_fac_loc_id,
        loc_location                    fif_fac_loc_location,
        si1.site_id                     fif_site_id,
        si1.site_site_name              fif_site_name,
        si2.site_id                     fif_site_id_fm,
        si2.site_site_name              fif_site_name_fm,
        sc1.sc_id                       fif_sc_id,
        sc1.sc_supply_chain_name        fif_sc_name,
        sc1.sc_type                     fif_sc_type,
        sc1.sc_eng_id                   fif_sc_eng_id,
        sc2.sc_id                       fif_sc_id_fm,
        sc2.sc_supply_chain_name        fif_sc_name_fm,
        sc2.sc_type                     fif_sc_type_fm,
        sc2.sc_eng_id                   fif_sc_eng_id_fm,
        pk_id                           fif_pk_id,
        pk_package_name                 fif_package_name,
        eng_ignore_key_wc               fif_eng_ignore_key_wc,
        dbi_id                          fif_dbi_id,
        bno_rias_user                   fif_bno_rias_user,
        bno_production_arranger         fif_bno_production_arranger
      , if_merchandise_flag             fif_merchandise_flag
FROM
        (SELECT
                ifsel.*,
                misr_id,
                misr_me_id,
                item_mat_id,
                item_prit_id,
                item_papl_id,
                item_repi_id,
                item_tnr,
                item_id,
                item_sisc_id,
                me_pk_id,
                decode (if_misr_id, null, nvl(btyp2.btyp_id,0), btyp1.btyp_id)                          btyp_id,
                decode (if_misr_id, null, nvl(btyp2.btyp_basic_type, 'UNDEF.'), btyp1.btyp_basic_type) btyp_basic_type,
                decode (if_misr_id, null, nvl(btyp2.btyp_pl_id, 0), btyp1.btyp_pl_id)                   btyp_pl_id
        FROM
                basic_types     btyp1,
                basic_types     btyp2,
                processed_items,
                items,
                mi_subroutes,
                mi_elements,
                item_facilities ifsel
        WHERE
                    ifsel.if_item_id = item_id
                AND ifsel.if_misr_id = misr_id(+)
                AND item_prit_id = prit_id (+)
                AND prit_btyp_id = btyp2.btyp_id (+)
                AND misr_me_id = me_id(+)
                AND me_btyp_id = btyp1.btyp_id(+)
                AND ifsel.if_type <> 'K'
                AND
                           (item_prit_id is not null
                        OR item_repi_id is not null
                        OR item_sisc_id is not null)) ifs,
        manufacturing_levels,
        start_item_scs,
        business_segments bs3,
        sites si1,
        supply_chains sc1,
        sites si2,
        supply_chains sc2,
        engines,
        database_instances,
        facilities,
        locations,
        packages,
        representative_items,
        business_segments bs2,
        process_lines,
        process_groups,
        process_classes,
        baunumbers,
        product_groups,
        business_segments bs1,
        sales_products
WHERE
            ifs.if_ml_id = ml_id
        AND ml_level_type <> 'UNDEF'
        AND ifs.item_sisc_id = sisc_id(+)
        AND sisc_bs_id = bs3.bs_id(+)
        AND ifs.if_site_id = si1.site_id(+)
        AND si1.site_sc_id = sc1.sc_id(+)
        AND si1.site_site_id = si2.site_id(+)
        AND si2.site_sc_id = sc2.sc_id(+)
        AND sc2.sc_eng_id = eng_id(+)
        AND eng_dbi_id = dbi_id(+)
        AND ifs.if_fac_id = fac_id
        AND fac_loc_id = loc_id
        AND ifs.me_pk_id = pk_id(+)
        AND ifs.item_repi_id = repi_id(+)
        AND repi_bs_id = bs2.bs_id(+)
        AND ifs.btyp_pl_id = pl_id(+)
        AND pl_pgp_id = pgp_id (+)
        AND pgp_pcl_id = pcl_id (+)
        AND ifs.if_bno_id = bno_id(+)
        AND bno_pg_id = pg_id(+)
        AND pg_bs_id = bs1.bs_id(+)
        AND ifs.if_bno_id = sprd_bno_id(+)
        AND (bs1.bs_id is not null OR bs2.bs_id is not null OR bs3.bs_id is not null)
        AND (bno_baunumber is not null OR ifs.item_tnr is not null)
        AND (bno_deletion_mark is null OR ml_level_type = 'VKL')
Explain plan for select * from v_fif order by fif_if_id;
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 62762906
| Id | Operation                                                 | Name
|   0 | SELECT STATEMENT                                          |
|   1 | SORT ORDER BY                                            |
|   2 |   NESTED LOOPS                                            |
|* 3 |    FILTER                                                 |
|   4 |     NESTED LOOPS OUTER                                    |
|   5 |      NESTED LOOPS OUTER                                   |
|   6 |       NESTED LOOPS OUTER                                  |
|   7 |        NESTED LOOPS OUTER                                 |
|   8 |         NESTED LOOPS OUTER                                |
|   9 |          NESTED LOOPS OUTER                               |
| 10 |           NESTED LOOPS OUTER                              |
| 11 |            NESTED LOOPS OUTER                             |
| 12 |             NESTED LOOPS                                  |
| 13 |              NESTED LOOPS                                 |
| 14 |               NESTED LOOPS OUTER                          |
PLAN_TABLE_OUTPUT
| 15 |                NESTED LOOPS OUTER                         |
| 16 |                 NESTED LOOPS OUTER                        |
| 17 |                  NESTED LOOPS OUTER                       |
| 18 |                   NESTED LOOPS OUTER                      |
| 19 |                    NESTED LOOPS OUTER                     |
| 20 |                     NESTED LOOPS OUTER                    |
| 21 |                      NESTED LOOPS OUTER                   |
| 22 |                       NESTED LOOPS OUTER                  |
| 23 |                        NESTED LOOPS OUTER                 |
| 24 |                         VIEW                              |
| 25 |                          NESTED LOOPS OUTER               |
| 26 |                           NESTED LOOPS OUTER              |
| 27 |                            NESTED LOOPS OUTER             |
| 28 |                             NESTED LOOPS                  |
| 29 |                              NESTED LOOPS OUTER           |
| 30 |                               NESTED LOOPS OUTER          |
|* 31 |                                TABLE ACCESS FULL          | ITEM_FACILIT
| 32 |                                TABLE ACCESS BY INDEX ROWID| MI_SUBROUTES
|* 33 |                                 INDEX UNIQUE SCAN         | MISR_PK
| 34 |                               TABLE ACCESS BY INDEX ROWID | MI_ELEMENTS
|* 35 |                                INDEX UNIQUE SCAN          | ME_PK
PLAN_TABLE_OUTPUT
|* 36 |                              TABLE ACCESS BY INDEX ROWID | ITEMS
|* 37 |                               INDEX UNIQUE SCAN           | ITEM_PK
| 38 |                             TABLE ACCESS BY INDEX ROWID   | PROCESSED_IT
|* 39 |                              INDEX UNIQUE SCAN            | PRIT_PK
| 40 |                            TABLE ACCESS BY INDEX ROWID    | BASIC_TYPES
|* 41 |                             INDEX UNIQUE SCAN             | BTYP_PK
| 42 |                           TABLE ACCESS BY INDEX ROWID     | BASIC_TYPES
|* 43 |                            INDEX UNIQUE SCAN              | BTYP_PK
| 44 |                         TABLE ACCESS BY INDEX ROWID       | SALES_PRODUC
|* 45 |                          INDEX UNIQUE SCAN                | SPRD_SPRD1_U
| 46 |                        TABLE ACCESS BY INDEX ROWID        | BAUNUMBERS
|* 47 |                         INDEX UNIQUE SCAN                 | BNO_PK
| 48 |                       TABLE ACCESS BY INDEX ROWID         | PRODUCT_GROU
|* 49 |                        INDEX UNIQUE SCAN                  | PG_PK
| 50 |                      TABLE ACCESS BY INDEX ROWID          | BUSINESS_SEG
|* 51 |                       INDEX UNIQUE SCAN                   | BS_PK
| 52 |                     TABLE ACCESS BY INDEX ROWID           | PROCESS_LINE
|* 53 |                      INDEX UNIQUE SCAN                    | PL_PK
| 54 |                    TABLE ACCESS BY INDEX ROWID            | PROCESS_GROU
|* 55 |                     INDEX UNIQUE SCAN                     | PGP_PK
| 56 |                   TABLE ACCESS BY INDEX ROWID             | PROCESS_CLAS
PLAN_TABLE_OUTPUT
|* 57 |                    INDEX UNIQUE SCAN                      | PCL_PK
| 58 |                  TABLE ACCESS BY INDEX ROWID              | REPRESENTATI
|* 59 |                   INDEX UNIQUE SCAN                       | REPI_PK
| 60 |                 TABLE ACCESS BY INDEX ROWID               | BUSINESS_SEG
|* 61 |                  INDEX UNIQUE SCAN                        | BS_PK
| 62 |                TABLE ACCESS BY INDEX ROWID                | PACKAGES
|* 63 |                 INDEX UNIQUE SCAN                         | PK_PK
| 64 |               TABLE ACCESS BY INDEX ROWID                 | FACILITIES
|* 65 |                INDEX UNIQUE SCAN                          | FAC_PK
| 66 |              TABLE ACCESS BY INDEX ROWID                  | LOCATIONS
|* 67 |               INDEX UNIQUE SCAN                           | LOC_PK
| 68 |             TABLE ACCESS BY INDEX ROWID                   | SITES
|* 69 |              INDEX UNIQUE SCAN                            | SITE_PK
| 70 |            TABLE ACCESS BY INDEX ROWID                    | SITES
|* 71 |             INDEX UNIQUE SCAN                             | SITE_PK
| 72 |           TABLE ACCESS BY INDEX ROWID                     | SUPPLY_CHAIN
|* 73 |            INDEX UNIQUE SCAN                              | SC_PK
| 74 |          TABLE ACCESS BY INDEX ROWID                      | ENGINES
|* 75 |           INDEX UNIQUE SCAN                               | ENG_PK
|* 76 |         INDEX UNIQUE SCAN                                 | DBI_PK
| 77 |        TABLE ACCESS BY INDEX ROWID                        | SUPPLY_CHAIN
PLAN_TABLE_OUTPUT
|* 78 |         INDEX UNIQUE SCAN                                 | SC_PK
| 79 |       TABLE ACCESS BY INDEX ROWID                         | START_ITEM_S
|* 80 |        INDEX UNIQUE SCAN                                  | SISC_PK
| 81 |      TABLE ACCESS BY INDEX ROWID                          | BUSINESS_SEG
|* 82 |       INDEX UNIQUE SCAN                                   | BS_PK
|* 83 |    TABLE ACCESS BY INDEX ROWID                            | MANUFACTURIN
|* 84 |     INDEX UNIQUE SCAN                                     | ML_PK
Predicate Information (identified by operation id):
   3 - filter("BS1"."BS_ID" IS NOT NULL OR "BS2"."BS_ID" IS NOT NULL OR
              "BS3"."BS_ID" IS NOT NULL)
31 - filter("IFSEL"."IF_TYPE"<>'K')
33 - access("IFSEL"."IF_MISR_ID"="MISR_ID"(+))
35 - access("MISR_ME_ID"="ME_ID"(+))
36 - filter("ITEM_PRIT_ID" IS NOT NULL OR "ITEM_REPI_ID" IS NOT NULL OR
              "ITEM_SISC_ID" IS NOT NULL)
37 - access("IFSEL"."IF_ITEM_ID"="ITEM_ID")
39 - access("ITEM_PRIT_ID"="PRIT_ID"(+))
PLAN_TABLE_OUTPUT
41 - access("PRIT_BTYP_ID"="BTYP2"."BTYP_ID"(+))
43 - access("ME_BTYP_ID"="BTYP1"."BTYP_ID"(+))
45 - access("IFS"."IF_BNO_ID"="SPRD_BNO_ID"(+))
47 - access("IFS"."IF_BNO_ID"="BNO_ID"(+))
49 - access("BNO_PG_ID"="PG_ID"(+))
51 - access("PG_BS_ID"="BS1"."BS_ID"(+))
53 - access("IFS"."BTYP_PL_ID"="PL_ID"(+))
55 - access("PL_PGP_ID"="PGP_ID"(+))
57 - access("PGP_PCL_ID"="PCL_ID"(+))
59 - access("IFS"."ITEM_REPI_ID"="REPI_ID"(+))
61 - access("REPI_BS_ID"="BS2"."BS_ID"(+))
63 - access("IFS"."ME_PK_ID"="PK_ID"(+))
65 - access("IFS"."IF_FAC_ID"="FAC_ID")
67 - access("FAC_LOC_ID"="LOC_ID")
69 - access("IFS"."IF_SITE_ID"="SI1"."SITE_ID"(+))
71 - access("SI1"."SITE_SITE_ID"="SI2"."SITE_ID"(+))
73 - access("SI2"."SITE_SC_ID"="SC2"."SC_ID"(+))
75 - access("SC2"."SC_ENG_ID"="ENG_ID"(+))
76 - access("ENG_DBI_ID"="DBI_ID"(+))
78 - access("SI1"."SITE_SC_ID"="SC1"."SC_ID"(+))
80 - access("IFS"."ITEM_SISC_ID"="SISC_ID"(+))
PLAN_TABLE_OUTPUT
82 - access("SISC_BS_ID"="BS3"."BS_ID"(+))
83 - filter(("BNO_DELETION_MARK" IS NULL OR "ML_LEVEL_TYPE"='VKL') AND
              "ML_LEVEL_TYPE"<>'UNDEF')
84 - access("IFS"."IF_ML_ID"="ML_ID")
Note
   - rule based optimizer used (consider using cbo)
133 rows selectedAny help really appreciated
Thanks in advance

I will suggest two things for your problem.
1. Try to remove all the decode operation with case .
2. If possible use CBO instead of RBO.
As you said that CBO is taking more time .. You must gather statistics about the objects.
and then use the CBO.
And a full table scan not always stands for the performance problems.It depends on the cardinality of
your SQL Statement.
Your explain plan output also shows a view operation is taking place, so try to rewrite the view in some other
possible way so that the view can become mergable with the main query.
It will defenitely help you.
Bi tc

Similar Messages

Fine tuning oracle inline view

Hi All,
i have a sql query (inline view) which is taking very long time (16 mins Approx) in our environment (Oracle 8.1.7 on Sun).
Can anyone have any idea to either fine tune the query OR convert it into PL/SQL.
Query:
SELECT DISTINCT ML.MFG_LEVEL,
SUBSTR(ML.PROCESS_DESC,
INSTR(ML.PROCESS_DESC, '_', 1, 2) + 1) AS FACILITY,
SUBSTR(ML.PROCESS_DESC, 1, INSTR(ML.PROCESS_DESC, '_') - 1) AS PACKAGE_NAME,
SUBSTR(ML.PROCESS_DESC,
INSTR(ML.PROCESS_DESC, '_') + 1,
INSTR(ML.PROCESS_DESC, '_', 1, 2) -
INSTR(ML.PROCESS_DESC, '_') - 1) AS BASIC_TYPE,
BT.BATCH_TIME_MEAN / BS.BATCH_SIZE AS RUNTIME_BASE,
ML.TASK_DESC,
ML.RESOURCE_DESC AS RESOURCE_NAME,
ML.PROCESS_DESC
FROM (SELECT DISTINCT RP.VALUE AS MFG_LEVEL,
TM.TASK_DESC,
RM.RESOURCE_DESC,
PC.PROCESS_DESC
FROM DWH_MCD.TASK_MASTER TM,
DWH_MCD.TASK_PARAMETER_MASTER TP,
DWH_MCD.RESOURCE_MASTER RM,
DWH_MCD.PROCESS_PLAN PP,
DWH_MCD.PROCESS PC,
DWH_MCD.RESOURCE_PARAMETER RP,
DWH_MCD.PARAMETER_TYPE PT
WHERE PC.PROCESS_ID = PP.PROCESS_ID AND PP.TASK_ID = TM.TASK_ID AND
TM.TASK_ID = TP.TASK_ID AND TP.RESOURCE_ID = RM.RESOURCE_ID AND
RP.RESOURCE_ID = RM.RESOURCE_ID AND
PT.PARAMETER_TYPE_ID = RP.PARAMETER_TYPE_ID AND
PT.PARAMETER_TYPE_ID = 220037 -- AREA i.e MFG_LEVEL
AND(TM.TASK_DESC NOT LIKE '%SUBCON%' OR
PC.PROCESS_DESC NOT LIKE '%VF%')) ML,
(SELECT DISTINCT TP.VALUE AS BATCH_TIME_MEAN,
TM.TASK_DESC,
RM.RESOURCE_DESC,
PC.PROCESS_DESC
FROM DWH_MCD.TASK_MASTER TM,
DWH_MCD.TASK_PARAMETER_MASTER TP,
DWH_MCD.RESOURCE_MASTER RM,
DWH_MCD.PROCESS_PLAN PP,
DWH_MCD.PROCESS PC,
DWH_MCD.RESOURCE_PARAMETER RP,
DWH_MCD.PARAMETER_TYPE PT
WHERE PC.PROCESS_ID = PP.PROCESS_ID AND PP.TASK_ID = TM.TASK_ID AND
TM.TASK_ID = TP.TASK_ID AND TP.RESOURCE_ID = RM.RESOURCE_ID AND
RP.RESOURCE_ID = RM.RESOURCE_ID AND
PT.PARAMETER_TYPE_ID = TP.PARAMETER_TYPE_ID AND
PT.PARAMETER_TYPE_ID = 220030 -- BATCH TIME MEAN
AND(TM.TASK_DESC NOT LIKE '%SUBCON%' OR
PC.PROCESS_DESC NOT LIKE '%VF%')) BT,
(SELECT DISTINCT TP.VALUE AS BATCH_SIZE,
TM.TASK_DESC,
RM.RESOURCE_DESC,
PC.PROCESS_DESC
FROM DWH_MCD.TASK_MASTER TM,
DWH_MCD.TASK_PARAMETER_MASTER TP,
DWH_MCD.RESOURCE_MASTER RM,
DWH_MCD.PROCESS_PLAN PP,
DWH_MCD.PROCESS PC,
DWH_MCD.RESOURCE_PARAMETER RP,
DWH_MCD.PARAMETER_TYPE PT
WHERE PC.PROCESS_ID = PP.PROCESS_ID AND PP.TASK_ID = TM.TASK_ID AND
TM.TASK_ID = TP.TASK_ID AND TP.RESOURCE_ID = RM.RESOURCE_ID AND
RP.RESOURCE_ID = RM.RESOURCE_ID AND
PT.PARAMETER_TYPE_ID = TP.PARAMETER_TYPE_ID AND
PT.PARAMETER_TYPE_ID = 220008 -- BATCH SIZE
AND(TM.TASK_DESC NOT LIKE '%SUBCON%' OR
PC.PROCESS_DESC NOT LIKE '%VF%')) BS
WHERE ML.TASK_DESC = BT.TASK_DESC AND ML.RESOURCE_DESC = BT.RESOURCE_DESC AND
ML.PROCESS_DESC = BT.PROCESS_DESC AND ML.TASK_DESC = BS.TASK_DESC AND
ML.RESOURCE_DESC = BS.RESOURCE_DESC AND
ML.PROCESS_DESC = BS.PROCESS_DESC;
Please feel free to ask me for more information if needed.
Thank You.
Best Regards,
Jawahar.

Jawahar,
Before you run this sql statement analyse those tables which you use in that query using dbms_utility.analyse_schema() then create one Mview for that query. Before you do all this use "Explain Plan for" this query and observe the statistics. See you need to create a table for Explain Plan. You can find that script in ORACLE_HOME/rdbms/admin/utlxplan.sql
Kamalesh JK
jkkstar inc

SQL tuning which uses View

I have used the below sql on a View .I will enter SEI_ACCT_NUMBER to get the respective ACCT_TRAN_ID.
It is taking longer time to run the query .ACCOUNT_TYPE_CD does not contain indexes.I do not have access rights to create indexes .
select
A.ACCT_TRAN_ID,
B.account_num as SEI_ACCT_NUMBER
from PACSAPP.TRAN_DETAIL_REPORT_VIEW A
INNER JOIN PACSAPP.TRAN_DETAIL_REPORT_VIEW B
          on A.REQUEST_ID = B.REQUEST_ID
          and A.ACCOUNT_TYPE_CD IN ('CHECKING','GL','SAVINGS')
          and B.ACCOUNT_TYPE_CD = 'TRUST'
The counts are below
select count(*) from PACSAPP.TRAN_DETAIL_REPORT_VIEW
2909725
select count(*) from PACSAPP.TRAN_DETAIL_REPORT_VIEW B
WHERE B.ACCOUNT_TYPE_CD = 'TRUST'
835354
select count(*) from PACSAPP.TRAN_DETAIL_REPORT_VIEW B
WHERE B.ACCOUNT_TYPE_CD = 'CHECKING'
320640
select count(*) from PACSAPP.TRAN_DETAIL_REPORT_VIEW B
WHERE B.ACCOUNT_TYPE_CD = 'GL'
16723
select count(*) from PACSAPP.TRAN_DETAIL_REPORT_VIEW B
WHERE B.ACCOUNT_TYPE_CD = 'SAVINGS'
530
Could you please help in improving the performance of this

I got the plan .DBA saying that it has a cartesian.How can we improve this?Could you Please suggest
Plan
SELECT STATEMENT ALL_ROWS Cost: 29,967 Bytes: 86,655,388 Cardinality: 646,682
      27 HASH JOIN RIGHT OUTER Cost: 29,967 Bytes: 86,655,388 Cardinality: 646,682
            1 INDEX FULL SCAN INDEX (UNIQUE) PACSAPP.ACCT_TRAN_TYPE_PK Cost: 1 Bytes: 8 Cardinality: 2
            26 HASH JOIN RIGHT OUTER Cost: 29,937 Bytes: 84,068,660 Cardinality: 646,682
                  2 INDEX FULL SCAN INDEX (UNIQUE) PACSAPP.ACCT_TRAN_STATUS_PK Cost: 1 Bytes: 44 Cardinality: 11
                  25 HASH JOIN RIGHT OUTER Cost: 29,907 Bytes: 81,481,932 Cardinality: 646,682
                        3 INDEX FULL SCAN INDEX (UNIQUE) PACSAPP.PAYMENT_TYPE_PK Cost: 1 Bytes: 15 Cardinality: 5
                        24 HASH JOIN RIGHT OUTER Cost: 29,877 Bytes: 79,541,886 Cardinality: 646,682
                              4 INDEX FAST FULL SCAN INDEX (UNIQUE) PACSAPP.PK_ACH_TRAN Cost: 312 Bytes: 3,515,106 Cardinality: 585,851
                              23 NESTED LOOPS OUTER Cost: 25,007 Bytes: 75,661,794 Cardinality: 646,682
                                    21 HASH JOIN RIGHT OUTER Cost: 24,466 Bytes: 71,781,702 Cardinality: 646,682
                                          5 INDEX FAST FULL SCAN INDEX (UNIQUE) PACSAPP.PK_TRUST_TRAN Cost: 183 Bytes: 2,074,164 Cardinality: 345,694
                                          20 HASH JOIN Cost: 20,315 Bytes: 67,901,610 Cardinality: 646,682
                                                18 HASH JOIN RIGHT OUTER Cost: 10,368 Bytes: 17,412,120 Cardinality: 241,835
                                                      6 INDEX FULL SCAN INDEX (UNIQUE) PACSAPP.ACCT_TRAN_TYPE_PK Cost: 1 Bytes: 8 Cardinality: 2
                                                      17 HASH JOIN RIGHT OUTER Cost: 10,356 Bytes: 16,444,780 Cardinality: 241,835
                                                            7 INDEX FULL SCAN INDEX (UNIQUE) PACSAPP.ACCT_TRAN_STATUS_PK Cost: 1 Bytes: 44 Cardinality: 11
                                                            16 HASH JOIN RIGHT OUTER Cost: 10,344 Bytes: 15,477,440 Cardinality: 241,835
                                                                  8 INDEX FULL SCAN INDEX (UNIQUE) PACSAPP.PAYMENT_TYPE_PK Cost: 1 Bytes: 15 Cardinality: 5
                                                                  15 HASH JOIN RIGHT OUTER Cost: 10,332 Bytes: 14,751,935 Cardinality: 241,835
                                                                        9 INDEX FAST FULL SCAN INDEX (UNIQUE) PACSAPP.PK_ACH_TRAN Cost: 312 Bytes: 3,515,106 Cardinality: 585,851
                                                                        14 NESTED LOOPS OUTER Cost: 8,688 Bytes: 13,300,925 Cardinality: 241,835
                                                                              12 HASH JOIN RIGHT OUTER Cost: 8,490 Bytes: 11,587,128 Cardinality: 236,472
                                                                                    10 INDEX FAST FULL SCAN INDEX (UNIQUE) PACSAPP.PK_TRUST_TRAN Cost: 183 Bytes: 2,074,164 Cardinality: 345,694
                                                                                    11 TABLE ACCESS FULL TABLE PACSAPP.TRAN Cost: 7,349 Bytes: 10,168,296 Cardinality: 236,472
                                                                              13 INDEX UNIQUE SCAN INDEX (UNIQUE) PACSAPP.PK_WIRE_TRAN Cost: 0 Bytes: 6 Cardinality: 1
                                                19 TABLE ACCESS FULL TABLE PACSAPP.TRAN Cost: 7,387 Bytes: 23,410,761 Cardinality: 709,417
                                    22 INDEX UNIQUE SCAN INDEX (UNIQUE) PACSAPP.PK_WIRE_TRAN Cost: 0 Bytes: 6 Cardinality: 1
Edited by: user2556087 on Feb 2, 2012 8:59 AM
Edited by: user2556087 on Feb 2, 2012 9:00 AM

Essbase tuning advisor / statistic viewer?

Hi,
Is there any tool that can help me fine tune my calculation scripts / business rules? I would like to know for instance, how many blocks are being affected with a couple of fixes, or the exact members where a fix calculation will have effect if I used a function like @Ancestors or @Children inside a fix.
It would be mostly to make some tests and check the time they take calculating.
Thank you

I would like to know for instance, how many blocks are being affected with a couple of fixes^^^SET MSG SUMMARY or SET MSG DETAIL and the application log will tell you that. It's sort of a pain to work with, but it's all there.
Regards,
Cameron Lackpour

Help for query tuning

hello all
my one of query is returning result in 1-2 mins only for 1 lakh record but i am not sure if it showed me complete rows or not because when I an trying to get count of result ..its taking lot of time .when I am using this query on plsql code ..code is running slow so just wanted to confirm on query tuning point of view if its fine or not ..please look onto it and let me know if query is fine or not by explain plan .my oracle version is 11g
this is my query
SELECT ROWNUM , TRUNC(rownum/5000) + 20000 ,'FOR_UPDATE', sku_org.NAME ,
acct_promo_sku.src_num , acct_promo_sku.sub_type ,
promo_actual.sku_actual_pos
FROM siebel.s_src acct_promo_hdr,
siebel.s_src acct_title_format,
siebel.s_src acct_promo_sku,
siebel.s_src_x acct_promo_hdrx,
siebel.s_src_x acct_promo_skux,
siebel.s_prod_int prod,
siebel.s_bu promo_hdr_org,
siebel.s_bu sku_org,
siebelwb.stg_sbl_acct_promo_actuals2 promo_actual
WHERE acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
AND acct_promo_hdr.row_id = acct_title_format.par_src_id
AND acct_title_format.sub_type = 'PLAN_ACCT_PROMOTION_CATEGORY'
AND acct_title_format.row_id = acct_promo_sku.par_src_id
AND acct_promo_sku.sub_type = 'PLAN_ACCOUNT_PROMOTION_PRODUCT'
AND acct_promo_hdr.row_id = acct_promo_hdrx.par_row_id
AND acct_promo_sku.row_id = acct_promo_skux.par_row_id(+)
AND acct_promo_sku.prod_id = prod.row_id
AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
AND acct_promo_sku.bu_id = sku_org.row_id
AND prod.x_prod_material_num = promo_actual.material_number
and prod.X_PROD_SALES_ORG=promo_actual.sales_org
AND acct_promo_hdr.row_id = promo_actual.acct_promo_id
and nvl(acct_promo_hdr.pr_accnt_id,0)=nvl(promo_actual.acct_siebel_rowid,0)
and nvl(acct_promo_hdr.x_indirect_id,0)=nvl(promo_actual.indirect_acct_siebel_rowid,0)
AND promo_actual.load_date >= TRUNC(SYSDATE)
AND promo_actual.load_date < TRUNC(SYSDATE + 1)
explain plan
PLAN_TABLE_OUTPUT
Plan hash value: 3864590768
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 298 | 2300 (1)| 00:00:28 |
| 1 | COUNT | | | | | |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1 | 298 | 2300 (1)| 00:00:28 |
| 5 | NESTED LOOPS OUTER | | 1 | 273 | 2298 (1)| 00:00:28 |
| 6 | NESTED LOOPS | | 1 | 263 | 2296 (1)| 00:00:28 |
| 7 | NESTED LOOPS | | 1 | 236 | 2295 (1)| 00:00:28 |
| 8 | NESTED LOOPS | | 1 | 165 | 2292 (1)| 00:00:28 |
| 9 | NESTED LOOPS | | 1 | 117 | 2289 (1)| 00:00:28 |
| 10 | NESTED LOOPS | | 1 | 109 | 2289 (1)| 00:00:28 |
| 11 | NESTED LOOPS | | 1 | 99 | 2287 (1)| 00:00:28 |
|* 12 | TABLE ACCESS FULL | STG_SBL_ACCT_PROMO_ACTUALS2 | 1 | 49 | 2285 (1)| 00:0
|* 13 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 50 | 2 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 | | 1 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | S_SRC_X_U1 | 1 | 10 | 2 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | S_BU_P1 | 1 | 8 | 0 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 48 | 3 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | S_SRC_F2 | 2 | | 2 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 71 | 3 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | S_SRC_F2 | 2 | | 2 (0)| 00:00:01 |
| 21 | TABLE ACCESS BY INDEX ROWID | S_BU | 1 | 27 | 1 (0)| 00:00:01 |
|* 22 | INDEX UNIQUE SCAN | S_BU_P1 | 1 | | 0 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | S_SRC_X_U1 | 1 | 10 | 2 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 25 | 2 (0)| 00:00:
Predicate Information (identified by operation id):
2 - filter(TRUNC(SYSDATE@!)<TRUNC(SYSDATE@!+1))
12 - filter("PROMO_ACTUAL"."LOAD_DATE">=TRUNC(SYSDATE@!) AND "PROMO_ACTUAL"."LOAD_DATE"<TRUNC(SYSD
13 - filter("ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION' AND
NVL("ACCT_PROMO_HDR"."PR_ACCNT_ID",'0')=NVL("PROMO_ACTUAL"."ACCT_SIEBEL_ROWID",'0') AND
NVL("ACCT_PROMO_HDR"."X_INDIRECT_ID",'0')=NVL("PROMO_ACTUAL"."INDIRECT_ACCT_SIEBEL_ROWID",'0'
14 - access("ACCT_PROMO_HDR"."ROW_ID"="PROMO_ACTUAL"."ACCT_PROMO_ID")
15 - access("ACCT_PROMO_HDR"."ROW_ID"="ACCT_PROMO_HDRX"."PAR_ROW_ID")
16 - access("ACCT_PROMO_HDR"."BU_ID"="PROMO_HDR_ORG"."ROW_ID")
17 - filter("ACCT_TITLE_FORMAT"."SUB_TYPE"='PLAN_ACCT_PROMOTION_CATEGORY')
18 - access("ACCT_PROMO_HDR"."ROW_ID"="ACCT_TITLE_FORMAT"."PAR_SRC_ID")
19 - filter("ACCT_PROMO_SKU"."PROD_ID" IS NOT NULL AND
"ACCT_PROMO_SKU"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION_PRODUCT')
20 - access("ACCT_TITLE_FORMAT"."ROW_ID"="ACCT_PROMO_SKU"."PAR_SRC_ID")
22 - access("ACCT_PROMO_SKU"."BU_ID"="SKU_ORG"."ROW_ID")
23 - access("ACCT_PROMO_SKU"."ROW_ID"="ACCT_PROMO_SKUX"."PAR_ROW_ID"(+))
24 - access("ACCT_PROMO_SKU"."PROD_ID"="PROD"."ROW_ID")
25 - filter("PROD"."X_PROD_MATERIAL_NUM" IS NOT NULL AND
"PROD"."X_PROD_MATERIAL_NUM"="PROMO_ACTUAL"."MATERIAL_NUMBER" AND
"PROD"."X_PROD_SALES_ORG"="PROMO_ACTUAL"."SALES_ORG")
55 rows selected.
thanks

Hi,
the plan you posted has the cost of 2300, i.e. 2300 single-block reads or equivalent number f multi-block reads. Even if none of the blocks is found in cache, 2300 reas shouldn't take more than a couple of minutes, beacause for most of the hard drives available today a disk read is typically within 5-10 ms.
This means that if there is a problem, we will never find out about it by looking in the plan. And it's quite likely that there is, in fact, a problem, because the plan contains a bunch of nested joins, and the cost of each nested join is directly proportional to the cardinality of the previous nested loop. I.e. it suffices to make one bad mistake in estimating the number of rows coming fom one of the nested rows to screw up the entire plan and get all remaining estimates (including the total cost of the query) completely wrong.
In order for us to be able to tell more, we need to see the plan with rowsource statistics, and please don't forget to use tags to preserve formatting (use the preview tab to make sure the posted plan is actually readable).
Best regards,
Nikolay

Changing the query on a view object

I have a view object right now, based on an entity. It is the default view object, so that means the query in the view object is straight forward, it grabs all of the attributes from the table. And there is no WHERE clause.
In reality I only want to show a finite set of rows from my table. Every time a record is changed/edited in this entity and committed, a new row in the database is created with the same information (I'm using CreateWithParams) except for a few columns.
I actually don't really have update on this table, just creation of new rows. But to the user, I want it to 'look' like they are editing something in the table.
Example:
12, 11:32,Thompson, 60 (the user edits this information in an adf table, and a new row is created in the db)
12, 11:55, Thompson, 75
I have a timestamp (see above) field in the database that is used as part of my primary key, so that I know which record is the latest.
When the VO query is run, I want the user to only see the latest row from the db.
12, 11:55, Thompson, 75
So...
I went to my VO, and I changed the WHERE query to add this:
where t1.TimeStamp = (Select MAX(t2.TimeStamp) FROM rcl.x t2 where t1.uid = t2.uid);
Now, this isn't a mysql/sql question. There's actually a better query that I'd rather run, but the VO editor doesn't allow me to change the query itself....
When I save the new WHERE to my VO, run my page again, I get the expected result (showing me only the latest records).
However, when I try and sort on the table in which my data is displayed, I am now getting ORDER BY errors.
I don't want my VO to be read-only sql based. I want to be able to update my table, so I have my VO running off of the entity.
Why doesn't the VO allow me to change the query itself? (Like do a subquery, instead of having my where clause do the work)
Why are order by errors being thrown when I sort on my adf table after changing the where clause in my view?
Hopefully I wasn't too convoluted in the explanation of my problem..
Thanks in advance,
Joel

HI Joe,
Regarding your problem you can do one of the following tasks:
1- easily to tuning on your view object, I mean in the tuning page of the view you can set that only return 1 record or 2-3 record fetch not all the record.
in the order by you will order by the timestamp field and descending.
2- you can order by the timestamp descending and in the where clause only set the rownum<2 (will return the last record) you can also set rownum<5 and get the 4 last record etc.
3-editing the view query in the expert mode is not advised at all because of many consequences that you will face.
4- maybe it is not bat that you add a readonly view for the table you mentioned and every time you unpdate the entity just re-execute the read-only view.( this method maybe is good maybe is not it depends on your business logic)
Regards.
Edited by: Amir Khanof on Sep 3, 2010 11:11 PM

Limit the number of Rows in View Obj

Hi,
I use jdeveloper 11.1.1.6.0
I have a View Obj with more than 100 rows, when I drag it as table in my page, I want to display only 10 first row. I know I can set it in the tuning part of View Obj but I can't use this way,
because I have more than one instance of this View Obj in Application Module and I want to do it only for one instance.
I tried to use FetchSize and RangeSize but none of them didn't work
Habib

You can setup MaxFetchSize=10 for a particular VO instance in the data model of the ApplicationModule. Go to "Data Model" page of the ApplicationModule definition, select the necessary VO instance and click the button "Edit ..." above the list of VO instances. "Edit View Instance" dialog will open. Go to "Tunning" page of the dialog and configure "Only up to row number" = 10. In this way you will setup MaxFetchSize=10 for this VO instance only. The other VO instances of the same VO definition will remain unaffected.
Dimitar

Partitioned views in Standard Edition

We have are SQL 2014 Standard edition, I have a situation where-in I plan to partition a table now since table partition is not supported in standard version I thought about Partitioned views however now I am stuck where I cant make the view writable because
of the identity column in the base table.
Do I have any other option in this case ?
Let me know your thoughts
Regards
Vishal
VG

Identity columns are problematic for a partitioned view. If any of the tables include an identity column, you can delete but not insert or update via the view. You could instead use a sequence to generate the surrogate key values, but that may require
significant application changes.
The real question is why you want to partition. There are specialized use cases where partitioning may improve performance (e.g. parallel scans) but you will generally get more benefit from index and query tuning. Partitioning (view
or table) can actually degrade performance depending on the queries and workload. That being said, partitioning always improves manageability.
Be aware that there is additional overhead of partitioned views compared to partitioned tables. Each table within the view may be indexed differently so there is considerable more work for the optimizer to do to generate an efficient plan.
This increases compilation time and can result in suboptimal plans, particularly if the view contains many tables. If your table is so large that partitioning is compelling, you might start making the business case for Enterprise Edition in order
to meet performance and availability SLAs.
I think the Database Engine forum is a better fit for this question so I'll move this thread there.
Dan Guzman, SQL Server MVP, http://www.dbdelta.com

Sizing the redo log files using optimal_logfile_size view.

Regards
I have a specific question regarding logfile size. I have deployed a test database and i was exploring certain aspects with regards to selecting optimal size of redo logs for performance tuning using optimal_logfile_size view from v$instance_recovery. My main goal is to reduce the redo bytes required for instance recovery. Currently i have not been able to optimize the redo log file size. Here are the steps i followed:-
In order to use the advisory from v$instance_recovery i had to set fast_start_mttr_target parameter which is by default not set so i did these steps:-
1)SQL> sho parameter fast_start_mttr_target;
NAME TYPE VALUE
fast_start_mttr_target integer 0
2) Setting the fast_start_mttr_target requires nullifying following deferred parameters :-
SQL> show parameter log_checkpoint;
NAME TYPE VALUE
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean FALSE
SQL> select ISSES_MODIFIABLE,ISSYS_MODIFIABLE,ISINSTANCE_MODIFIABLE,ISMODIFIED from v$parameter where name like'log_checkpoint_timeout';
ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
FALSE IMMEDIATE TRUE FALSE
SQL> alter system set log_checkpoint_timeout=0 scope=both;
System altered.
SQL> show parameter log_checkpoint_timeout;
NAME TYPE VALUE
log_checkpoint_timeout integer 0
3) Now setting fast_start_mttr_target
SQL> select ISSES_MODIFIABLE,ISSYS_MODIFIABLE,ISINSTANCE_MODIFIABLE,ISMODIFIED from v$parameter where name like'fast_start_mttr_target';
ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
FALSE IMMEDIATE TRUE FALSE
Setting the fast_mttr_target to 1200 = 20 minutes of checkpoint switching according to Oracle recommendation
Querying the v$instance_recovery view
4) SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
276 165888 *93* 59 361 16040
Here Target Mttr was 93 so i set the fast_mttr_target to 120
SQL> alter system set fast_start_mttr_target=120 scope=both;
System altered.
Now the logfile size suggested by v$instance_recovery is 290 Mb
SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
59 165888 93 59 290 16080
After altering the logfile size to 290 as show below by v$log view :-
SQL> select GROUP#,THREAD#,SEQUENCE#,BYTES from v$log;
GROUP# THREAD# SEQUENCE# BYTES
1 1 24 304087040
2 1 0 304087040
3 1 0 304087040
4 1 0 304087040
5 ) After altering the size i have observed the anomaly as redo log blocks to be applied for recovery has increased from *59 to 696* also now v$instance_recovery view is now suggesting the logfile size of *276 mb*. Have i misunderstood something
SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
*696* 646947 120 59 *276* 18474
Please clarify the above output i am unable to optimize the logfile size and have not been able to achieve the goal of reducing the redo log blocks to be applied for recovery, any help is appreciated in this regard.

sunny_123 wrote:
Sir oracle says that fast_start_mttr target can be set to 3600 = 1hour. As suggested by following oracle document
http://docs.oracle.com/cd/B10500_01/server.920/a96533/instreco.htm
I set mine value to 1200 = 20 minutes. Later i adjusted it to 120=2 minutes as Target_mttr suggested it to be around 100 (if fast_mttr_target value is too high or too low effective value is contained in target_mttr of v$instance_recovery)Just to add, you are reading the documentation of 9.2 and a lot has changed since then. For example, in 9.2 the parameter FSMTTR was introduced and explicitly required to be set and monitored by the DBA for teh additional checkpoint writes which might get caused by it. Since 10g onwards this parameter has been made automatically maintained by Oracle. Also it's been long that 9i has been desupported followed by 10g so it's better that you start reading the latest documentation of 11g and if not that, at least of 10.2.
Aman....

Performance Tuning DBA fix not Applications fix

Hi
I had an interview , which the DBA team leader was asking me about my performance tuning expereince
i was answering about my expereince in tuning the sqls and get a good statistics so the CBO choose the best plan, or even hint my sqls so i force the best plan
the interviwer was worried because this is an application tuning , not a DBA tuning
he mention that he want to hear that i changed a db parameter that enhance the performance , or chnage any thing in the DBA side that tune the performance
Anybody have an example of changing a parameter or something DBAish that help the performance?
Thanks for any contribution

You should read following sections of Performance Tuning Guide:
Performance Considerations for Initial Instance Configuration:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/build_db.htm#i20151
Memory Configuration and Use:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#i53187
Oracle Instance Tuning Using Dynamic Views:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#i35312

Performance of OBIEE report whereas SQL query behind it executed in 1-2 min

Facing lot of performance issues in OBIEE reports, whereas SQL query behind the report fetch data in 2-3 minutes. Reprot take around 1-2 hrs. Can anyone help to resolve this please?

(my 2c worth)... if the physical query runs for a reasonably short time but the report takes much longer to return it suggests the rendering process (ie. pivot view) is lagging.
To test this theory, go into Answers and remove all views from the request and leave a simple table view on the compound view. Run the report and the report should return around the same time the physical request takes to run because the table view is a very raw, un aggregated rendering process. Table views are nice and fast. If that works then you can focus on tuning your other views, ie. Pivot view. I've seen a simple pivot view take minutes to render what looks like a simple report because the underlying recordset is quite large.
I hope this helped. another quick trick you could try is applying aggregation in the formulas to aggregate things at the physical sql level so the returning result set isn't 5,000. depends what you're up to with the end report.
Edited by: user8300108 on 25-Feb-2010 04:40

CLOSED: MAPVIEWER LONG PREPARATION TIME AFTER LONG IDLE TIME

SR # 6896831.994
Customer: NEDGRAPHICS BV
Mapviewer Release: 9.0.4
This issue was posted to the Field Service Forum. They responded with
For Map, we do create the datasource and related maps, themes, styles to be used for Map. The exeuction part is done by Mapviewer and we don't have much control on the mapviewer code on performance tuning point of view.
Please post this question in mapviewer forum
Issue:
After MapViewer being idle for some time (+/- 60 minutes) it takes a long time to generate the first map image --> 5 minutes.
In the MapViewer logfile with log-level=finest, I see that there is a very long preparation time.
After producing the first map image the next (same!) image is produced very fast.
What could be the reason?
What does MapViewer do during "preparation"?
Customer statement:
I am a very experienced Oracle specialist and a very experienced MapViewer developer.
Could you please pass on my request to the MapViewer developers?
I have to know what is going on during preparation time.
Is there a possibility to get more detailed logging of the preparation time?
SEE log file at:
http://workbench.oraclecorp.com/cgi-bin/tools/its_reltar?tar=6896831.994
FILE: mapviewer_37.log
Additional customer info.
UPDATE from customer
================
The first time after long idle time it takes between 100 and 300 seconds.
After that it takes less than 2 seconds.
Can it be a dabase connection issue?
Will it make a difference if I use a database connection via data-sources.xml
instead of a direct data-source in mapviewerConfig.xml?
This is what I mean :
Method 1:
<map_data_source name="NBG"
jdbc_host="plutonium"
jdbc_sid="ods"
jdbc_port="1521"
jdbc_user="nbgex"
jdbc_password="ELvaJ7axzKQl0aKtjikuKT7JUFTjukU3"
jdbc_mode="thin"
number_of_mappers="3"
/>
Method 2:
<map_data_source name="NBG"
container_ds="jdbc/NBG"
number_of_mappers="3"
/>
data-sources.xml:
<data-source
class="oracle.jdbc.pool.OracleDataSource"
name="NBG"
location="jdbc/OracleCache"
ejb-location="jdbc/NBG"
xa-location="jdbc/xa/OracleXADS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="nbgex"
password="nbgex
url="jdbc:oracle:thin:@plutonium:1521:ods"
inactivity-timeout="30">
<property name="connectionCacheName" value="ICC"/>
<property name="connectionCachingEnabled" value="true"/>
<property name="fastConnectionFailoverEnabled" value="true"/>
</data-source>
Thanks
Message was edited by:
user639281

RESPONSE from customer
====================
The database is restarted once a day in the morning. That could explain the problems in the morning. But there are also problems during day time after some hours of idle time when the database in not restarted.
After testing we noticed that we don't have the problem if we use database connection through OC4J (data-sources.xml).
If we use that method every database connection is cleaned up if it is not used for 15 seconds or so.
If we use the other method (database connection in mapviewerconfig.xml) then the database connection is open for a long time and then we have the problem with the long preparation time.
This problem only occurs in a DMZ environment. MapViewer is installed on a DMZ server and connects through the firewall with a intranet database.
Is it possible that the firewall software prevents communication of an open database connection after a long period of idle time?
Thanls.

ABAP program flow.

Hi,
whenever i write abap program, i usually maintain following program flow. is it right from performance tuning point of view?
1) include statements
2) DATABASE TABLES
3) VARIABLE DECLARATIONS
4) SELECTION-SCREEN
5) FIELD SYMBOLS
6) INITIALIZATION
7) AT SELECTION SCREEN
8) TOP OF PAGE
9) END OF PAGE
10) START OF SELECTION
11) END OF SELECTION
Please advise
Regards,
Santosh

Hello,
Just to add to Kathick's explanation. ABAP is an event-driven programming language. The general flow of an ABAP program is controlled by events.
It is a good -practice to code event processing blocks in the order in which they will be triggered during execution. However, they do not have to be coded in a sequential order.
This is the first thing i learnt in ABAP basics class )
BR,
Suhas

RangeSize in ViewObject vs. RangeSize in iterator

Hi,
Jdev 11.1.1.2.0, ADFBC.
The tuning section of view object contains a property "Range Size". Default value is 1.
The iterator has a property "Range Size" too. Default value is 25.
As far I know the iterator’ s RangeSize attribute defines the number of records ADFm requests from the ADF BC layer simultaneously.
What's the purpose of RangeSize on view object level?
What's the recommended value for this property?
regards
Peter

Hi!
The iterator has a property "Range Size" too. Default value is 25.I believe that would be the iterator binding, not the iterator itself.
The iterator binding range size controls the range size of the (default) iterator of the VO. The VO implements the RowIterator interface but just forwards the calls to the default RSI of the default RowSet.
What's the purpose of RangeSize on view object level?That's the default range size of the default RSI of the VO. That value comes into play if it's not changed by a binding or if there's no binding at all.
Sascha

Preparemodel phase very slow

Is there a way to figure out why the prepareModel phase for my project is slow? It takes about 35 seconds from when the phase begins and the first invokeAction method is executed in the PageDef. Is this just a matter of tuning all the view objects? Is there a way to debug this? Any suggestions would be appreciated. I've added a snippit from my logs below to show where the delay is.
I'm using:
JDev 10.1.3.3.0.4157
ADF 10.1.3.41.57
Thanks,
Brent
Oct 2, 2007 8:13:03 AM edu.uiowa.healthcare.sched.DebugBean afterPhase
FINER: after ---------- RESTORE_VIEW 1----------
Oct 2, 2007 8:13:03 AM oracle.adf.controller.v2.context.LifecycleContext initControllerClass
FINE: [ADFc] Using a PagePhaseListener: edu.uiowa.healthcare.sched.MyADFPhaseListener
Oct 2, 2007 8:13:03 AM edu.uiowa.healthcare.sched.MyADFPhaseListener beforePhase
FINER: before ---------- INIT_CONTEXT----------
Oct 2, 2007 8:13:03 AM oracle.adf.controller.v2.lifecycle.Lifecycle executePhase
FINE: [ADFc] Execute:initContext
Oct 2, 2007 8:13:03 AM edu.uiowa.healthcare.sched.MyADFPhaseListener afterPhase
FINER: after ---------- INIT_CONTEXT----------
Oct 2, 2007 8:13:03 AM edu.uiowa.healthcare.sched.MyADFPhaseListener beforePhase
FINER: before ---------- PREPARE_MODEL----------
Oct 2, 2007 8:13:03 AM edu.uiowa.healthcare.sched.MyADFPhaseListener beforePhase
FINE: p_id: %%
Oct 2, 2007 8:13:03 AM oracle.adf.controller.v2.lifecycle.Lifecycle executePhase
FINE: [ADFc] Execute:prepareModel
Oct 2, 2007 8:13:40 AM oracle.adfinternal.view.faces.model.FacesExpressionEvaluator evaluate
FINEST: Expression:#{1==1} evaluated to:true class:java.lang.Boolean
Oct 2, 2007 8:13:40 AM edu.uiowa.healthcare.sched.view.UserBean <init>
FINE: UserBean created
Oct 2, 2007 8:13:40 AM edu.uiowa.healthcare.sched.view.UserBean setBindings

Changing the "create new data file" setting has provided a small improvement but we are still a long way from the performance level expected.
Right now I am looking for a bottle neck and coming up empty.
Checking task manager on both the dev(domain controller) and QAS I see nothing significant. My network team has verified we have plenty of bandwidth available.
With out the added burden of creating data files I at a loss as to where to look next.
Any and all suggestions would be appreciated

Tuning of a view

Similar Messages

Maybe you are looking for