How to force an MV to go through a FULL TABLE SCAN...

Hi all,
I'm trying to put a HINT in to this query to have the table MV_CLNT_SCDIM_MRGE go through a full table scan. However, for some reason, the view specification I'm using doesn't seem to work. Can anyone tell me what I should be doing to force the full table scan?
SELECT
DISTINCT 1 "c1",
t1."CALNDR_DT" "c2",
t2."OFFR_CD_ID" "c3",
t2."OFFR_COMM_CHNL_DESC" "c4",
t3."TCLNT_DIM_AGE_BASED_SGMNT_CD" "c5",
t3."TCLT_DM_CURR_CLNT_BUS_SGMNT_CD" "c6",
t2."OFFR_NM" "c7",
t2."CMPGN_NM" "c8",
t3."TCLNT_DIM_CLNT_DIM_KEY" "c9",
To_number(To_char(t1."CALNDR_DT", 'YYYY')) "c10", --only yyyy
DECODE(Substr(t2."OFFR_NM", 1, 3), 'MKT', 'MKT',
DECODE(Substr(t2."OFFR_NM", 1, 2), 'DP', 'DP',
DECODE(Substr(t2."OFFR_NM", 1, 2), 'AP', 'DP',
DECODE(Substr(t2."OFFR_NM", 1, 3), 'PRO','RRO',
DECODE(Substr(t2."OFFR_NM", 1, 5), 'SCPRO','PRO',
'NORPT'))))) "c11",
t4."PGE_NM_SRC_ID" "c12",
t4."WEB_PGE_NM" "c13",
To_number(To_char(t1."CALNDR_DT", 'YYYY')) "c14",
To_number(To_char(t1."CALNDR_DT", 'MM')) "c15",
To_number(To_char(t1."CALNDR_DT", 'WW')) "c16"
FROM "OCMADM"."VTRTMT_DIM" t2,
"OCMADM"."TDT_DIM" t1,
"OCMADM"."VR_OUTBND_CNTCT" t3,
"OCMADM"."TWEB_PGE_DIM" t4
WHERE t2."TRTMT_EFFTV_STRT_DT_DIM_KEY" = t1."DT_DIM_KEY"
AND t3."TRTMT_DIM_KEY" = t2."TRTMT_DIM_KEY"
AND t3."WEB_PGE_DIM_KEY" = t4."WEB_PGE_DIM_KEY"
AND t2."CMPGN_SYS_CD" IN ( 'INT' )
AND t2."TRTMT_STATUS_CD" = 'ACTV'
AND To_number(To_char(t1."CALNDR_DT", 'YYYY')) = 2010
and t3.outbnd_cntct_dt_dim_key > 12455197 --recommended by Brian
AND DECODE(Substr(t2."OFFR_NM", 1, 3), 'MKT', 'MKT',
DECODE(Substr(t2."OFFR_NM", 1, 2),'DP', 'DP',
DECODE(Substr(t2."OFFR_NM", 1, 2),'AP', 'DP',
DECODE(Substr(t2."OFFR_NM", 1, 3),'PRO','RRO',
DECODE(Substr(t2."OFFR_NM", 1, 5), 'SCPRO','PRO',
'NORPT'))))) IN ( 'MKT', 'DP', 'PRO' )
ORDER BY "c6" ASC,
"c5" ASC,
"c8" ASC,
"c7" ASC,
"c2" ASC,
"c11" ASC,
"c10" ASC,
"c4" ASC,
"c13" ASC,
"c12" ASC,
"c15" ASC,
"c16" ASC,
"c9" ASC,
"c3" ASC
Thanks, Pete

Here is the full query with the views and materialized views embedded. You can see the hints we gave this to work. I think it is one of two things... we just don't have the syntax correct or you cannot force the path of execution after a certain number of 'embedded' calls, for lack of a better term.
SELECT DISTINCT 1 "c1",
t1."CALNDR_DT" "c2",
t2."OFFR_CD_ID" "c3",
t2."OFFR_COMM_CHNL_DESC" "c4",
t3."TCLNT_DIM_AGE_BASED_SGMNT_CD" "c5",
t3."TCLT_DM_CURR_CLNT_BUS_SGMNT_CD" "c6",
t2."OFFR_NM" "c7",
t2."CMPGN_NM" "c8",
t3."TCLNT_DIM_CLNT_DIM_KEY" "c9",
To_number(To_char(t1."CALNDR_DT", 'YYYY')) "c10",
DECODE(Substr(t2."OFFR_NM", 1, 3), 'MKT', 'MKT',
DECODE(
Substr(t2."OFFR_NM", 1, 2), 'DP', 'DP'
DECODE(
Substr(t2."OFFR_NM", 1, 2), 'AP', 'DP'
DECODE(
Substr(t2."OFFR_NM", 1, 3), 'PRO',
'RRO',
DECODE(
Substr(t2."OFFR_NM", 1, 5), 'SCPRO',
'PRO',
'NORPT'))))) "c11",
t4."PGE_NM_SRC_ID" "c12",
t4."WEB_PGE_NM" "c13"
FROM "OCMADM"."VTRTMT_DIM" t2,
"OCMADM"."TDT_DIM" t1,
( SELECT /*+ FULL(mv_hhld_dim) FULL(clnt_scdim_mrge) */ tclnt_cmpgn_outbnd_cntct_fact.clnt_cmpgn_outbnd_cntct_key,
tclnt_cmpgn_outbnd_cntct_fact.outbnd_cntct_dt_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.trtmt_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.clnt_scdim_key,
tclnt_cmpgn_outbnd_cntct_fact.cmpgn_evnt_typ_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.web_pge_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.cmpgn_sys_cd,
tclnt_cmpgn_outbnd_cntct_fact.cntct_tm_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.etl_procs_key,
tclnt_cmpgn_outbnd_cntct_fact.etl_ld_ts,
mv_clnt_dim.tclnt_dim_clnt_dim_key,
mv_clnt_dim.tclnt_dim_po_id,
mv_clnt_dim.tclnt_dim_po_typ_cd,
mv_clnt_dim.tclnt_dim_best_age,
mv_clnt_dim.tclnt_dim_age_based_sgmnt_cd,
mv_clnt_dim.tclnt_dim_gendr_cd,
mv_clnt_dim.tclnt_dim_prspct_incpt_dt,
mv_clnt_dim.tclnt_dim_entry_dt,
mv_clnt_dim.tclnt_dim_brth_dt,
mv_clnt_dim.tclnt_dim_wealth_rnking_cd,
mv_clnt_dim.tclt_dm_curr_clnt_bus_sgmnt_cd,
mv_hhld_dim.hhld_dim_key,
mv_hhld_dim.hhld_id,
mv_hhld_dim.hhld_bus_sgmnt_cd
FROM OCMADM.tclnt_cmpgn_outbnd_cntct_fact tclnt_cmpgn_outbnd_cntct_fact
INNER JOIN OCMADM.mv_clnt_scdim_mrge clnt_scdim_mrge
ON clnt_scdim_mrge.tclnt_scdim_clnt_scdim_key =
tclnt_cmpgn_outbnd_cntct_fact.clnt_scdim_key
INNER JOIN OCMADM.mv_clnt_dim mv_clnt_dim
ON mv_clnt_dim.tclnt_dim_clnt_dim_key =
clnt_scdim_mrge.tclnt_mrge_mrged_to_clnt_key
INNER JOIN (SELECT /*+ FULL(mv) */ THHLD_CLNT_BRDG.HHLD_CLNT_BRDG_KEY AS THHLD_CLNT_BRDG_KEY,
THHLD_CLNT_BRDG.HHLD_DIM_KEY AS THHLD_CLNT_BRDG_HHLD_DIM_KEY,
THHLD_CLNT_BRDG.STRT_DT_DIM_KEY AS THHLD_CLT_BRDG_STRT_DT_DIM_KEY,
THHLD_CLNT_BRDG.END_DT_DIM_KEY AS THHLD_CLT_BRDG_END_DT_DIM_KEY,
MV.TCLNT_SCDIM_CLNT_SCDIM_KEY AS TCLNT_SCDIM_CLNT_SCDIM_KEY,
MV.TCLNT_SCDIM_CLNT_DIM_KEY AS TCLNT_SCDIM_CLNT_DIM_KEY,
MV.TCLNT_SCDIM_BUS_SGMNT_CD AS TCLNT_SCDIM_BUS_SGMNT_CD,
MV.TCLNT_SCDIM_SGMNTN_RNK_NO AS TCLNT_SCDIM_SGMNTN_RNK_NO,
MV.TCLNT_SCDIM_STRT_DT_DIM_KEY AS TCLNT_SCDIM_STRT_DT_DIM_KEY,
MV.TCLNT_SCDIM_END_DT_DIM_KEY AS TCLNT_SCDIM_END_DT_DIM_KEY,
MV.TCLNT_MRGE_MRGED_TO_CLNT_KEY AS TCLNT_MRGE_MRGED_TO_CLNT_KEY,
MV.TCLNT_MRGE_MRGED_FR_CLNT_KEY AS TCLNT_MRGE_MRGED_FR_CLNT_KEY,
MV.TCLNT_MRGE_STRT_DT_DIM_KEY AS TCLNT_MRGE_STRT_DT_DIM_KEY,
MV.TCLNT_MRGE_END_DT_DIM_KEY AS TCLNT_MRGE_END_DT_DIM_KEY
FROM OCMADM.MV_CLNT_SCDIM_MRGE MV,
OCMADM.THHLD_CLNT_BRDG THHLD_CLNT_BRDG
WHERE THHLD_CLNT_BRDG.CLNT_SCDIM_KEY = MV.TCLNT_SCDIM_CLNT_SCDIM_KEY
AND MV.TCLNT_SCDIM_END_DT_DIM_KEY = 15373484
AND MV.TCLNT_MRGE_END_DT_DIM_KEY = 15373484
AND THHLD_CLNT_BRDG.END_DT_DIM_KEY = 15373484) v_hhld_clnt_brdg
ON v_hhld_clnt_brdg.tclnt_mrge_mrged_to_clnt_key =
mv_clnt_dim.tclnt_dim_clnt_dim_key
INNER JOIN OCMADM.mv_hhld_dim mv_hhld_dim
ON mv_hhld_dim.hhld_dim_key =
v_hhld_clnt_brdg.thhld_clnt_brdg_hhld_dim_key
WHERE v_hhld_clnt_brdg.thhld_clt_brdg_end_dt_dim_key = 15373484) t3,
"OCMADM"."TWEB_PGE_DIM" t4
WHERE t2."TRTMT_EFFTV_STRT_DT_DIM_KEY" = t1."DT_DIM_KEY"
AND t3."TRTMT_DIM_KEY" = t2."TRTMT_DIM_KEY"
AND t3."WEB_PGE_DIM_KEY" = t4."WEB_PGE_DIM_KEY"
AND t2."CMPGN_SYS_CD" IN ( 'INT' )
AND t2."TRTMT_STATUS_CD" = 'ACTV'
AND To_number(To_char(t1."CALNDR_DT", 'YYYY')) = 2010
AND DECODE(Substr(t2."OFFR_NM", 1, 3), 'MKT', 'MKT',
DECODE(Substr(t2."OFFR_NM", 1, 2),
'DP',
'DP'
DECODE
Substr(t2."OFFR_NM", 1, 2), 'AP', 'DP'
DECODE(
Substr(t2."OFFR_NM", 1, 3), 'PRO',
'RRO',
DECODE(
Substr(t2."OFFR_NM", 1, 5), 'SCPRO',
'PRO',
'NORPT'))))) IN ( 'MKT', 'DP', 'PRO' )
ORDER BY "c6" ASC,
"c5" ASC,
"c8" ASC,
"c7" ASC,
"c2" ASC,
"c11" ASC,
"c10" ASC,
"c4" ASC,
"c12" ASC,
"c13" ASC,
"c9" ASC,
"c3" ASC

Similar Messages

  • How can i make the optimiser to skip this full table scan ??

    Hi,
    I am trying to tune the below query, I have checked up all the possibilities to skip the full table scan on vhd_calldesh_archive, But am unable to find the predicate in the where clause, which is letting the optimiser to choose the full table scan on vhd_calldesk_archive table, which is very large one. how can i make the optimiser to skip this full table scan.
    Please check the below sql script and explain plan ,
    SELECT a.call_id, a.entry_date,
    NVL (INITCAP (b.full_name), caller_name) AS caller_name,
    c.description AS org_desc, a.env_id, i.env_desc, a.appl_id,
    d.appl_desc, a.module_id, e.module_desc, a.call_type_id,
    f.call_type_desc, a.priority, a.upduserid,
    INITCAP (g.full_name) AS lastupdated_username, a.call_desc, h.mode_desc,
    a.received_time,a.assignment_team, a.status,
    ROUND (lcc.pkg_com.fn_datediff ('MI',
    a.entry_date,
    a.status_date
    ) AS elapsed_time,
    ROUND (lcc.pkg_com.fn_datediff ('MI',
    a.entry_date,
    a.status_date
    ) AS resolved_min,
    CASE
    WHEN a.orgid in (1,100,200) THEN a.orgid
    ELSE j.regionorgid
    END AS region
    ,(SELECT coalesce(MAX(upddate),a.upddate) FROM lcc.vhd_callstatus stat WHERE stat.call_id = a.call_id
    ) as stat_upddate
    ,(SELECT team_desc from lcc.vhd_teams t where t.team_id = a.assignment_team) as team_desc
    ,a.eta_date
    ,coalesce(a.caller_contact, b.telephone) AS caller_contact
    ,coalesce(a.caller_email, b.email) as email
    ,a.affected_users
    ,a.outage_time
    ,a.QA_DONE
    ,a.LAST_ACTION_TEAM
    ,a.LAST_ACTION_USER
    ,INITCAP (k.full_name) AS last_action_username
    ,a.last_action_date
    ,l.team_desc as last_action_teamdesc
    ,a.refid
    ,INITCAP (lu.full_name) AS logged_name
    ,a.pmreview
    ,a.status as main_status
    FROM lcc.vhd_calldesk_archive a
    LEFT OUTER JOIN lcc.lcc_userinfo_details b ON b.user_name = a.caller_id
    INNER JOIN lcc.com_organization c ON c.code = a.orgid
    INNER JOIN lcc.vhd_applications d ON d.appl_id = a.appl_id
    INNER JOIN lcc.vhd_modules e ON e.appl_id = a.appl_id AND e.module_id = a.module_id
    INNER JOIN lcc.vhd_calltypes f ON f.call_type_id = a.call_type_id
    INNER JOIN lcc.com_rptorganization j ON j.orgid = a.orgid AND j.tree = 'HLPDK'
    LEFT OUTER JOIN lcc.lcc_userinfo_details g ON g.user_name = a.upduserid
    LEFT OUTER JOIN lcc.vhd_callmode h ON h.mode_id = a.mode_id
    LEFT OUTER JOIN lcc.vhd_environment i ON i.appl_id = a.appl_id AND i.env_id = a.env_id
    LEFT OUTER JOIN lcc.lcc_userinfo_details k ON k.user_name = a.last_action_user
    LEFT OUTER JOIN lcc.vhd_teams l ON l.team_id = a.last_action_user
    LEFT OUTER JOIN (select CALL_ID,upduserid FROM lcc.VHD_CALLDESK_HISTORY P where upddate
    in ( select min(upddate) from lcc.VHD_CALLDESK_HISTORY Q WHERE Q.CALL_ID = P.CALL_ID
    group by call_id)) ku
    ON ku.call_id = a.call_id
    LEFT OUTER JOIN lcc.lcc_userinfo_details lu ON NVL(ku.upduserid,A.upduserid) = lu.user_name;
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 2104 | 3667K| 37696 |
    | 1 | UNION-ALL | | | | |
    | 2 | NESTED LOOPS OUTER | | 2103 | 3665K| 37683 |
    | 3 | VIEW | | 2103 | 3616K| 35580 |
    | 4 | NESTED LOOPS OUTER | | 2103 | 823K| 35580 |
    | 5 | NESTED LOOPS OUTER | | 2103 | 774K| 33477 |
    | 6 | NESTED LOOPS OUTER | | 2103 | 685K| 31374 |
    | 7 | NESTED LOOPS | | 2103 | 636K| 29271 |
    | 8 | NESTED LOOPS | | 2103 | 603K| 27168 |
    | 9 | NESTED LOOPS OUTER | | 2103 | 558K| 25065 |
    | 10 | NESTED LOOPS OUTER | | 2103 | 515K| 22962 |
    | 11 | NESTED LOOPS | | 2103 | 472K| 20859 |
    | 12 | NESTED LOOPS | | 2103 | 429K| 18756 |
    | 13 | NESTED LOOPS OUTER | | 4826 | 890K| 13930 |
    | 14 | NESTED LOOPS OUTER | | 4826 | 848K| 9104 |
    | 15 | NESTED LOOPS | | 4826 | 754K| 4278 |
    |* 16 | TABLE ACCESS FULL | COM_RPTORGANIZATION | 75 | 1050 | 3 |
    | 17 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK | 64 | 9344 | 57 |
    |* 18 | INDEX RANGE SCAN | VHD_CALLDSK_ORGID | 2476 | | 7 |
    | 19 | VIEW PUSHED PREDICATE | | 1 | 20 | 1 |
    |* 20 | FILTER | | | | |
    | 21 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 20 | 2 |
    |* 22 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
    |* 23 | FILTER | | | | |
    | 24 | SORT GROUP BY NOSORT | | 1 | 12 | 2 |
    | 25 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 12 | 2 |
    |* 26 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
    | 27 | TABLE ACCESS BY INDEX ROWID | VHD_CALLMODE | 1 | 9 | 1 |
    |* 28 | INDEX UNIQUE SCAN | VHD_CALLMOD_MODID_PK | 1 | | |
    | 29 | TABLE ACCESS BY INDEX ROWID | VHD_APPLICATIONS | 1 | 20 | 1 |
    |* 30 | INDEX UNIQUE SCAN | VHD_APPL_APPLID_PK | 1 | | |
    | 31 | TABLE ACCESS BY INDEX ROWID | VHD_CALLTYPES | 1 | 21 | 1 |
    |* 32 | INDEX UNIQUE SCAN | VHD_CALLTYP_ID_PK | 1 | | |
    | 33 | TABLE ACCESS BY INDEX ROWID | VHD_TEAMS | 1 | 21 | 1 |
    |* 34 | INDEX UNIQUE SCAN | VHD_TEAMID_PK | 1 | | |
    | 35 | TABLE ACCESS BY INDEX ROWID | VHD_ENVIRONMENT | 1 | 21 | 1 |
    |* 36 | INDEX UNIQUE SCAN | VHD_ENV_APLENVID_PK | 1 | | |
    | 37 | TABLE ACCESS BY INDEX ROWID | VHD_MODULES | 1 | 22 | 1 |
    |* 38 | INDEX UNIQUE SCAN | VHD_MOD_APLMOD_ID_PK | 1 | | |
    | 39 | TABLE ACCESS BY INDEX ROWID | COM_ORGANIZATION | 1 | 16 | 1 |
    |* 40 | INDEX UNIQUE SCAN | COM_ORG_PK | 1 | | |
    | 41 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 |
    |* 42 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
    | 43 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 43 |
    |* 44 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
    | 45 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
    |* 46 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
    | 47 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
    |* 48 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
    | 49 | NESTED LOOPS OUTER | | 1 | 1785 | 13 |
    | 50 | VIEW | | 1 | 1761 | 12 |
    | 51 | NESTED LOOPS OUTER | | 1 | 1656 | 12 |
    | 52 | NESTED LOOPS OUTER | | 1 | 1632 | 11 |
    | 53 | NESTED LOOPS OUTER | | 1 | 1608 | 10 |
    | 54 | NESTED LOOPS | | 1 | 1565 | 9 |
    | 55 | NESTED LOOPS | | 1 | 1549 | 9 |
    | 56 | NESTED LOOPS | | 1 | 1535 | 9 |
    | 57 | NESTED LOOPS OUTER | | 1 | 1513 | 8 |
    | 58 | NESTED LOOPS OUTER | | 1 | 1492 | 7 |
    | 59 | NESTED LOOPS | | 1 | 1471 | 6 |
    | 60 | NESTED LOOPS | | 1 | 1450 | 5 |
    | 61 | NESTED LOOPS OUTER | | 1 | 1430 | 4 |
    | 62 | NESTED LOOPS OUTER | | 1 | 1421 | 3 |
    | 63 | TABLE ACCESS FULL | VHD_CALLDESK_ARCHIVE | 1 | 1401 | 2 |
    | 64 | VIEW PUSHED PREDICATE | | 1 | 20 | 1 |
    |* 65 | FILTER | | | | |
    | 66 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 20 | 2 |
    |* 67 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
    |* 68 | FILTER | | | | |
    | 69 | SORT GROUP BY NOSORT | | 1 | 12 | 2 |
    | 70 | TABLE ACCESS BY INDEX ROWID| VHD_CALLDESK_HISTORY | 1 | 12 | 2 |
    |* 71 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
    | 72 | TABLE ACCESS BY INDEX ROWID | VHD_CALLMODE | 1 | 9 | 1 |
    |* 73 | INDEX UNIQUE SCAN | VHD_CALLMOD_MODID_PK | 1 | | |
    | 74 | TABLE ACCESS BY INDEX ROWID | VHD_APPLICATIONS | 1 | 20 | 1 |
    |* 75 | INDEX UNIQUE SCAN | VHD_APPL_APPLID_PK | 1 | | |
    | 76 | TABLE ACCESS BY INDEX ROWID | VHD_CALLTYPES | 1 | 21 | 1 |
    |* 77 | INDEX UNIQUE SCAN | VHD_CALLTYP_ID_PK | 1 | | |
    | 78 | TABLE ACCESS BY INDEX ROWID | VHD_TEAMS | 1 | 21 | 1 |
    |* 79 | INDEX UNIQUE SCAN | VHD_TEAMID_PK | 1 | | |
    | 80 | TABLE ACCESS BY INDEX ROWID | VHD_ENVIRONMENT | 1 | 21 | 1 |
    |* 81 | INDEX UNIQUE SCAN | VHD_ENV_APLENVID_PK | 1 | | |
    | 82 | TABLE ACCESS BY INDEX ROWID | VHD_MODULES | 1 | 22 | 1 |
    |* 83 | INDEX UNIQUE SCAN | VHD_MOD_APLMOD_ID_PK | 1 | | |
    | 84 | TABLE ACCESS BY INDEX ROWID | COM_RPTORGANIZATION | 1 | 14 | |
    |* 85 | INDEX UNIQUE SCAN | COM_RPTORG_PK | 1 | | |
    | 86 | TABLE ACCESS BY INDEX ROWID | COM_ORGANIZATION | 1 | 16 | |
    |* 87 | INDEX UNIQUE SCAN | COM_ORG_PK | 1 | | |
    | 88 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 43 |
    |* 89 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
    | 90 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 |
    |* 91 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
    | 92 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
    |* 93 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
    | 94 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
    |* 95 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
    Predicate Information (identified by operation id):
    16 - filter("J"."TREE"='HLPDK')
    18 - access("J"."ORGID"="A"."ORGID")
    20 - filter( EXISTS (SELECT /*+ */ 0 FROM "LCC"."VHD_CALLDESK_HISTORY" "Q" WHERE "Q"."CALL_ID"=:B1
    "Q"."CALL_ID" HAVING MIN("Q"."UPDDATE")=:B2))
    22 - access("SYS_ALIAS_2"."CALL_ID"="A"."CALL_ID")
    23 - filter(MIN("Q"."UPDDATE")=:B1)
    26 - access("Q"."CALL_ID"=:B1)
    28 - access("H"."MODE_ID"(+)="A"."MODE_ID")
    30 - access("D"."APPL_ID"="A"."APPL_ID")
    32 - access("F"."CALL_TYPE_ID"="A"."CALL_TYPE_ID")
    34 - access("L"."TEAM_ID"(+)="A"."LAST_ACTION_TEAM")
    36 - access("I"."APPL_ID"(+)="A"."APPL_ID" AND "I"."ENV_ID"(+)="A"."ENV_ID")
    38 - access("E"."APPL_ID"="A"."APPL_ID" AND "E"."MODULE_ID"="A"."MODULE_ID")
    40 - access("C"."CODE"="A"."ORGID")
    42 - access("K"."USER_NAME"(+)="A"."LAST_ACTION_USER")
    44 - access("B"."USER_NAME"(+)="A"."CALLER_ID")
    46 - access("G"."USER_NAME"(+)="A"."UPDUSERID")
    48 - access("LU"."USER_NAME"(+)=NVL("SYS_ALIAS_4"."UPDUSERID_162","SYS_ALIAS_4"."UPDUSERID_25"))
    65 - filter( EXISTS (SELECT /*+ */ 0 FROM "LCC"."VHD_CALLDESK_HISTORY" "Q" WHERE "Q"."CALL_ID"=:B1
    "Q"."CALL_ID" HAVING MIN("Q"."UPDDATE")=:B2))
    67 - access("SYS_ALIAS_2"."CALL_ID"="SYS_ALIAS_1"."CALL_ID")
    68 - filter(MIN("Q"."UPDDATE")=:B1)
    71 - access("Q"."CALL_ID"=:B1)
    73 - access("H"."MODE_ID"(+)="SYS_ALIAS_1"."MODE_ID")
    75 - access("D"."APPL_ID"="SYS_ALIAS_1"."APPL_ID")
    77 - access("F"."CALL_TYPE_ID"="SYS_ALIAS_1"."CALL_TYPE_ID")
    79 - access("L"."TEAM_ID"(+)=TO_NUMBER("SYS_ALIAS_1"."LAST_ACTION_USER"))
    81 - access("I"."APPL_ID"(+)="SYS_ALIAS_1"."APPL_ID" AND "I"."ENV_ID"(+)="SYS_ALIAS_1"."ENV_ID")
    83 - access("E"."APPL_ID"="SYS_ALIAS_1"."APPL_ID" AND "E"."MODULE_ID"="SYS_ALIAS_1"."MODULE_ID")
    85 - access("SYS_ALIAS_1"."ORGID"="J"."ORGID" AND "J"."TREE"='HLPDK')
    87 - access("C"."CODE"="SYS_ALIAS_1"."ORGID")
    89 - access("B"."USER_NAME"(+)="SYS_ALIAS_1"."CALLER_ID")
    91 - access("SYS_ALIAS_1"."UPDUSERID"="G"."USER_NAME"(+))
    93 - access("K"."USER_NAME"(+)="SYS_ALIAS_1"."LAST_ACTION_USER")
    95 - access("LU"."USER_NAME"(+)=NVL("SYS_ALIAS_3"."UPDUSERID_162","SYS_ALIAS_3"."UPDUSERID_25"))
    Note: cpu costing is off

    I've tried to look thru your sql and changed it a bit. Of course not testet :-)
    Your problem isn't the archive table! I tried to remove the 2 selects from the select-clause. Furthermore you have a lot of nested loops in your explain, which is a performance-killer. Try getting rid of them, perhaps use /*+ USE_HASH(?,?) */.
    SELECT a.call_id, a.entry_date,
           NVL (INITCAP (b.full_name), caller_name) AS caller_name, c.description AS org_desc, a.env_id, i.env_desc, a.appl_id,
           d.appl_desc, a.module_id, e.module_desc, a.call_type_id, f.call_type_desc, a.priority, a.upduserid,
           INITCAP (g.full_name) AS lastupdated_username, a.call_desc, h.mode_desc, a.received_time, a.assignment_team, a.status,
           ROUND (lcc.pkg_com.fn_datediff ('MI', a.entry_date, a.status_date)) AS elapsed_time,
           ROUND (lcc.pkg_com.fn_datediff ('MI', a.entry_date, a.status_date)) AS resolved_min,
           CASE
              WHEN a.orgid IN (1, 100, 200)
                 THEN a.orgid
              ELSE j.regionorgid
           END AS region,
           COALESCE (stat.upddate, a.upddate) AS stat_upddate,
           t.team_desc, a.eta_date,
           COALESCE (a.caller_contact, b.telephone) AS caller_contact,
           COALESCE (a.caller_email, b.email) AS email, a.affected_users,
           a.outage_time, a.qa_done, a.last_action_team, a.last_action_user,
           INITCAP (k.full_name) AS last_action_username, a.last_action_date,
           l.team_desc AS last_action_teamdesc, a.refid,
           INITCAP (lu.full_name) AS logged_name, a.pmreview,
           a.status AS main_status
      FROM lcc.vhd_calldesk_archive a, lcc.lcc_userinfo_details b, lcc.com_organization c,
           lcc.vhd_applications d, lcc.vhd_modules e, lcc.vhd_calltypes f, lcc.com_rptorganization j,
           lcc.lcc_userinfo_details g, lcc.vhd_callmode h, lcc.vhd_environment i, lcc.lcc_userinfo_details k,
           lcc.vhd_teams l,
          (SELECT call_id, upduserid
           FROM lcc.vhd_calldesk_history p
           WHERE upddate IN (SELECT   MIN (upddate)
                             FROM lcc.vhd_calldesk_history q
                             WHERE q.call_id = p.call_id
                             GROUP BY call_id)) ku,
           lcc.lcc_userinfo_details lu,
          (SELECT call_id, MAX (upddate)
           FROM lcc.vhd_callstatus
           GROUP BY call_id) stat,
           lcc.vhd_teams t
      WHERE a.caller_id        = b.user_name(+)
        AND a.orgid            = c.code
        AND a.appl_id          = d.appl_id
        AND a.appl_id          = e.appl_id
        AND a.module_id        = e.module_id
        AND a.call_type_id     = f.call_type_id
        AND a.orgid            = j.orgid
        AND j.tree             = 'HLPDK'
        AND a.upduserid        = g.user_name(+)
        AND a.mode_id          = h.mode_id(+)
        AND a.appl_id          = i.appl_id(+)
        AND a.env_id           = i.env_id(+)
        AND a.last_action_user = k.user_name(+)
        AND a.last_action_user = l.team_id(+)
        AND a.call_id          = ku.call_id(+)
        AND NVL (ku.upduserid, a.upduserid) = lu.user_name(+)
        AND a.call_id          = stat.call_id
        AND a.assignment_team  = t.team_id;

  • FASTER THROUGH PUT ON FULL TABLE SCAN

    제품 : ORACLE SERVER
    작성날짜 : 1995-04-10
    Subject: Faster through put on Full table scans
    db_file_multiblock_read only affects the performance of full table scans.
    Oracle has a maximum I/O size of 64KBytes hence db_blocksize *
    db_file_multiblock_read must be less than or equal to 64KBytes.
    If your query is really doing an index range scan then the performance
    of full scans is irrelevant. In order to improve the performance of this
    type of query it is important to reduce the number of blocks that
    the 'interesting' part of the index is contained within.
    Obviously the db_blocksize has the most impact here.
    Historically Informix has not been able to modify their database block size,
    and has had a fixed 2KB block.
    On most Unix platforms Oracle can use up to 8KBytes.
    (Some eg: Sequent allow 16KB).
    This means that for the same size of B-Tree index Oracle with
    an 8KB blocksize can read it's contents in 1/4 of the time that
    Informix with a 2KB block could do.
    You should also consider whether the PCTFREE value used for your index is
    appropriate. If it is too large then you will be wasting space
    in each index block. (It's too large IF you are not going to get any
    entry size extension OR you are not going to get any new rows for existing
    index values. NB: this is usually only a real consideration for large indexes - 10,000 entries is small.)
    db_file_simultaneous_writes has no direct relevance to index re-balancing.
    (PS: In the U.K. we benchmarked against Informix, Sybase, Unify and
    HP/Allbase for the database server application that HP uses internally to
    monitor and control it's Tape drive manufacturing lines. They chose
    Oracle because: We outperformed Informix.
                             Sybase was too slow AND too
    unreliable.
                             Unify was short on functionality
    and SLOW.
                             HP/Allbase couldn't match the
    availability
                             requirements and wasn't as
    functional.
    Informix had problems demonstrating the ability to do hot backups without
    severely affecting the system throughput.
    HP benchmarked all DB vendors on both 9000/800 and 9000/700 machines with
    different disks (ie: HP-IB and SCSI). Oracle came out ahead in all
    configurations.
    NNB: It's always worth throwing in a simulated system failure whilst the
    benchmark is in progress. Informix has a history of not coping gracefully.
    That is they usually need some manual intervention to perform the database
    recovery.)
    I have a perspective client who is running a stripped down souped version of
    informix with no catalytic converter. One of their queries boils down to an
    Index Range Scan on 10000 records. How can I achieve better throughput
    on a single drive single CPU machine (HP/UX) without using raw devices.
    I had heard rebuilding the database with a block size factor greater than
    the OS block size would yield better performance. Also I tried changing
    the db_file_multiblock_read_count to 32 without much improvement.
    Adjusting the db_writers to two did not help either.     
    Also will the adjustment of the db_file_simultaneous_writes help on
    the maintenance of a index during rebalancing operations.

    2)if cbo, how are the stats collected?
    daily(less than millions rows of table) and weekly(all tables)There's no need to collect stats so frequently unless it's absolute necessary like you have massive update on tables daily or weekly.
    It will help if you can post your sample explain plan and query.

  • How to find the count of tables going for fts(full table scan in oracle 10g

    HI
    how to find the count of tables going for fts(full table scan) in oracle 10g
    regards

    Hi,
    Why do you want to 'find' those tables?
    Do you want to 'avoid FTS' on those tables?
    You provide little information here. (Perhaps you just migrated from 9i and having problems with certain queries now?)
    FTS is sometimes the fastest way to retrieve data, and sometimes an index scan is.
    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:9422487749968
    There's no 'FTS view' available, if you want to know what happens on your DB you need, like Anand already said, to trace sessions that 'worry you'.

  • How can this query avoid full table scans?

    It is difficult to avoid full table scans in the following query because the values of column STATUS reiterant numbers. There are only 10 numbers values for the STATUS column (1..10)
    But the table is very large. there are more than 1 million rows in it. A full table scanning consumes too much time.
    How can this query avoid full table scans?
    Thank you
    SELECT SYNC,CUS_ID INTO V_SYNC,V_CUS_ID FROM CONSUMER_MSG_IDX
                      WHERE CUS_ID = V_TYPE_CUS_HEADER.CUS_ID AND
                            ADDRESS_ID = V_TYPE_CUS_HEADER.ADDRESS_ID AND
                            STATUS =! 8;Edited by: junez on Jul 23, 2009 7:30 PM

    Your code had an extra AND. I also replaced the "not equal" operator, which has display problems with the forum software
    SELECT SYNC,CUS_ID
       INTO V_SYNC,V_CUS_ID
      FROM CONSUMER_MSG_IDX
    WHERE CUS_ID = V_TYPE_CUS_HEADER.CUS_ID AND
           ADDRESS_ID = V_TYPE_CUS_HEADER.ADDRESS_ID AND
           STATUS != 8;Are you sure this query is doing a table scan? Is there an index on CUS_ID, ADDRESS_ID? I would think that would be mostly unique. So I'm not sure why you think the STATUS column is causing problems. It would seem to just be a non-selective additional filter.
    Justin

  • How to check small table scan full table scan if we  will use index  in where clause.

    How to check small table scan full table scan if i will use index column in where clause.
    Is there example link there i can  test small table scan full table  if index is used in where clause.

    Use explain plan on your statement or set autotrace traceonly in your SQL*Plus session followed by the SQL you are testing.
    For example
    SQL> set autotrace traceonly
    SQL> select *
      2  from XXX
      3  where id='fga';
    no rows selected
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=13 Card=1 Bytes=16
              5)
       1    0   PARTITION RANGE (ALL) (Cost=13 Card=1 Bytes=165)
       2    1     TABLE ACCESS (FULL) OF 'XXX' (TABLE) (Cost=13 Card
              =1 Bytes=165)
    Statistics
              1  recursive calls
              0  db block gets
           1561  consistent gets
            540  physical reads
              0  redo size
           1864  bytes sent via SQL*Net to client
            333  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed

  • How to Reduce cost of full table scan or remove full table scan while execu

    Dear Experts
    need your help.
    I execute a query and create a explain plan in that plan i found cost of a table is very high (2777) and it was full table scan.
    Please guide me How to Reduce cost of full table scan or remove full table scan while execute the query.
    Thanks

    Need your help to tune this query..
    SELECT DISTINCT ool.org_id, ool.header_id, ooh.order_number, ool.line_id,
    ool.line_number, ool.shipment_number,
    NVL (ool.option_number, -99) option_number, xcl.GROUP_ID,
    xcl.attribute3, xcl.attribute4
    FROM oe_order_headers ooh,
    xxcn_comp_header xch,
    xxcn_comp_lines xcl,
    fnd_lookup_values_vl fvl,
    oe_order_lines ool
    WHERE 1 = 1
    AND ooh.org_id = 1524
    AND xch.src_ref_no = TO_CHAR (ooh.order_number)
    AND xch.src_ref_id = ooh.header_id
    AND xch.org_id = 1524
    AND xcl.header_id = xch.header_id
    AND ool.line_id = xcl.oe_line_id
    AND ool.flow_status_code IN
    ('WWD_SHIPPED',
    'FULFILLED',
    'SHIPPED',
    'CLOSED',
    'RETURNED'
    AND ool.org_id = 1524
    AND ool.header_id = ooh.header_id
    AND xch.org_id = 1524
    AND fvl.lookup_type = 'EMR OIC SOURCE FOR OU'
    AND fvl.tag = '1524'
    AND fvl.description = xch.SOURCE
    AND EXISTS (
    SELECT 1
    FROM oe_order_lines oe
    WHERE oe.header_id = ool.header_id
    AND oe.org_id = 1524
    AND oe.line_number = ool.line_number
    AND oe.ordered_item = ool.ordered_item
    AND oe.shipment_number > ool.shipment_number
    AND NVL (oe.option_number, -99) =
    NVL (ool.option_number,
    -99)
    AND NOT EXISTS (
    SELECT 1
    FROM xxcn_comp_lines xcl2
    WHERE xcl.GROUP_ID = xcl2.GROUP_ID
    AND oe.line_id = oe_line_id))
    call count cpu elapsed disk query current rows
    Parse 1 0.07 0.12 12 25 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 2 103.03 852.42 176206 4997766 0 12
    total 4 103.10 852.55 176218 4997791 0 12
    In this LIO is very high...can u please help in resolving this performance issue

  • How to change font while displaying data through an ALV table in WDA?

    Hi all,
    I am displaying data through and ALV table. Now I want to change the FONT only for few rows. Is this possible?
    If so then do the needful to me..
    Thanks & Regards,
    Yugesh A.

    I believe as you have found 'LVC_FIELDCATALOG_MERGE' would only work with the classic dynpro (SAPGUI based) version of the ALV. 
    You won't be able to control the font the same way in the WDA version of the ALV.  You will need to create a custom cell editor for the column(s) in question.  You can then bind context attributes to the properties of the cell editor. You will need extra attributes in your bound context to control these settings on the row level.  Also you will be restricted by the changing the DESIGN property. This means only the values allowed for the DESIGN of the particluar UI element.  For a TextView that wouldn't be the font directly (the font of course comes from the Theme).
    DATA l_salv_wd_table TYPE REF TO iwci_salv_wd_table.
      l_salv_wd_table = wd_this->wd_cpifc_alv_adv( ).
      DATA l_table TYPE REF TO cl_salv_wd_config_table.
      l_table = l_salv_wd_table->get_model( ).
      data textview type ref to CL_SALV_WD_UIE_TEXT_VIEW.
      l_column = l_table->if_salv_wd_column_settings~get_column( 'ADD_PARTICIPANTS' ).
      create object textview.
      textview->SET_TEXT_FIELDNAME( 'ADD_PARTICIPANTS' ).
      textview->set_design_fieldname( 'ADD_DESIGN' ).
      textview->set_wrapping( abap_true ).
      l_column->set_cell_editor( textview ).
    DESIGN supports the following options:
    Value
    Visual Display
    Description
    emphasized
    Text is highlighted in default size
    groupTitle
    Header for forms
    This enumeration value is deprecated. Instead, use SectionHeader.
    header1
    Text is highlighted with font size +4 in relation to the default font size.
    header2
    Text is highlighted with font size +5.08 cm relation to the default font size.
    header3
    Text is highlighted in default size
    header4
    Text is highlighted in font size -1 (small) in relation to the default font size (like the legend but highlighted)
    label
    Text is display in the default font type. A space is always inserted after the text.
    label_small
    Text is displayed in default font type, as with label, onyl that font size is -1 (like the font size for header4).
    legend
    Text is displayed with default font type in size -1.
    reference
    Text is in italics and in default font size.
    standard
    Text is displayed in default font size. No text attributes are defined for this value.
    monospace
    Text is displayed in no-proportional font type. Each letter takes up the same space.

  • How to avoid this full table scan (and index FFS) ?

    Hi All,
    Oracle 11.2 on Linux.
    See this query and its plan below
    SQL> DELETE
      2  FROM  TABLEA APE
      3        WHERE   NOT EXISTS
      4                   (SELECT   1
      5                      FROM   TABLEB AP
      6                     WHERE       AP.col1 = APE.col1
      7                             AND AP.col2 = APE.col2
      8                             AND AP.col3 = APE.col3)
      9  AND ROWNUM < 51 ;
    50 rows deleted.
    Elapsed: 00:12:01.07
    Execution Plan
    Plan hash value: 1740911877
    | Id  | Operation               | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time  |
    |   0 | DELETE STATEMENT        |                       |    50 |  2650 |       |   573K  (1)| 01:54:40 |
    |   1 |  DELETE                 | TABLEA                |       |       |       |            |       |
    |*  2 |   COUNT STOPKEY         |                       |       |       |       |            |       |
    |*  3 |    HASH JOIN RIGHT ANTI |                       |    80M|  4059M|  1775M|   573K  (1)| 01:54:40 |
    |   4 |     INDEX FAST FULL SCAN| TABLEB_UK             |    47M|  1228M|       | 96480   (1)| 00:19:18 |
    |   5 |     TABLE ACCESS FULL   | TABLEA                |    80M|  1991M|       |   243K  (1)| 00:48:42 |
    ---------------------------------------------------------------------------------------------------------In both tables, TABLEA and TABLEB, there is index on columns col1-col2-col3 as leading columns (TABLEB has few more columns in the index, but after these 3 columns).
    Requirement is, I want to delete first 50 records in TABLEA, which does not exist in TABLEB.
    I tried with various hints, but Oracle is always doing a full scan on one of the tables and index FFS on other. In some cases, Oracle did full scan on both tables and then deleted 50 records. Stats is up-to-date. Doing a full scan on tables with 80 million and 47 million rows is a bit too much for deleting 50 rows.
    How I can make Oracle do
    1) Read TABLEA row-by-row
    2) for each row, check if it exists in TABLEB
    3) If not exists, then delete row from TABLEA, else continue
    4) Stop reading TABLEA after we have deleted 50 records
    Thanks in advance

    >
    >
    Oracle 11.2 on Linux.
    SQL> DELETE
    2  FROM  TABLEA APE
    3        WHERE   NOT EXISTS
    4                   (SELECT   1
    5                      FROM   TABLEB AP
    6                     WHERE       AP.col1 = APE.col1
    7                             AND AP.col2 = APE.col2
    8                             AND AP.col3 = APE.col3)
    9  AND ROWNUM < 51 ;
    50 rows deleted.
    Elapsed: 00:12:01.07
    Execution Plan
    Plan hash value: 1740911877
    | Id  | Operation               | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time  |
    |   0 | DELETE STATEMENT        |                       |    50 |  2650 |       |   573K  (1)| 01:54:40 |
    |   1 |  DELETE                 | TABLEA                |       |       |       |            |       |
    |*  2 |   COUNT STOPKEY         |                       |       |       |       |            |       |
    |*  3 |    HASH JOIN RIGHT ANTI |                       |    80M|  4059M|  1775M|   573K  (1)| 01:54:40 |
    |   4 |     INDEX FAST FULL SCAN| TABLEB_UK             |    47M|  1228M|       | 96480   (1)| 00:19:18 |
    |   5 |     TABLE ACCESS FULL   | TABLEA                |    80M|  1991M|       |   243K  (1)| 00:48:42 |
    ---------------------------------------------------------------------------------------------------------Requirement is, I want to delete first 50 records in TABLEA, which does not exist in TABLEB.
    Such requirements usually make me curious - what's special about a randomly selected 50 rows ?
    Is this trying to delete the data in batches of 50 rows at a time.
    How I can make Oracle do
    1) Read TABLEA row-by-row
    2) for each row, check if it exists in TABLEB
    3) If not exists, then delete row from TABLEA, else continue
    4) Stop reading TABLEA after we have deleted 50 records
    It look's as if a 'no_unnest' hint in the subquery should do what you want. It should make Oracle run the quey with a FILTER subquery. You could then choose to drive the delete through a tablescan of tableA or an index range scan of the index on tableA. Have you considered the effect of (and requirements relating to) nulls in the three columns of either table ?
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    Author: <b><em>Oracle Core</em></b>

  • How to force BI Server to pick from the Agg table and not the Fact table?

    Hi All,
    I have 3 tables as the Sources in the Key measures. 2 are fact tables and the other one is the agg table.
    E.g.
    Fact 1 at A,B,C,D and E level
    Fact 2 at A,B,C level
    Agg at A,B,C level which contains the measures from the Fact1 and Fact2
    So when I select the measures from the Agg which are coming from Fact1 the Agg table get fired and when I select measures from Agg which are coming from Fact2, the Fact2 table gets fired in the SQL Query.
    Now my question here is there anyway to tell BI Server that when I select Fact2 measures fire the Agg table and not the Fact2 table. The reason being the Agg and Fact2 tables are at the same level.
    But I need to keep the Agg table as it is one level higher than the Fact1 tables.
    Any pointers would be helpful.

    hi,
    you explain us your situation really good.but you forgot to tell us the most import,the measures in aggregate table and the aggregated dimensions.
    meaning,you have 7 measures aggregated in some levels of your dimensions tables?if yes,there is no possibility Bi goes anywhere else..(by choosing only these measures and the defined levels at your dimensions..)
    One more thing,if you choose a combination of your 2 fact data sources,bi goes?where???
    hope i helped...
    http://greekoraclebi.blogspot.com/

  • How to avoid full Table scan when using Rule based optimizer (Oracle817)

    1. We have a Oracle 8.1.7 DB, and the optimizer_mode is set to "RULE"
    2. There are three indexes on table cm_contract_supply, which is a large table having 28732830 Rows, and average row length 149 Bytes
    COLUMN_NAME INDEX_NAME
    PROGRESS_RECID XAK11CM_CONTRACT_SUPPLY
    COMPANY_CODE XIE1CM_CONTRACT_SUPPLY
    CONTRACT_NUMBER XIE1CM_CONTRACT_SUPPLY
    COUNTRY_CODE XIE1CM_CONTRACT_SUPPLY
    SUPPLY_TYPE_CODE XIE1CM_CONTRACT_SUPPLY
    VERSION_NUMBER XIE1CM_CONTRACT_SUPPLY
    CAMPAIGN_CODE XIF1290CM_CONTRACT_SUPPLY
    COMPANY_CODE XIF1290CM_CONTRACT_SUPPLY
    COUNTRY_CODE XIF1290CM_CONTRACT_SUPPLY
    SUPPLIER_BP_ID XIF801CONTRACT_SUPPLY
    COMMISSION_LETTER_CODE XIF803CONTRACT_SUPPLY
    COMPANY_CODE XIF803CONTRACT_SUPPLY
    COUNTRY_CODE XIF803CONTRACT_SUPPLY
    COMPANY_CODE XPKCM_CONTRACT_SUPPLY
    CONTRACT_NUMBER XPKCM_CONTRACT_SUPPLY
    COUNTRY_CODE XPKCM_CONTRACT_SUPPLY
    SUPPLY_SEQUENCE_NUMBER XPKCM_CONTRACT_SUPPLY
    VERSION_NUMBER XPKCM_CONTRACT_SUPPLY
    3. We are querying the table for a particular contract_number and version_number. We want to avoid full table scan.
    SELECT /*+ INDEX(XAK11CM_CONTRACT_SUPPLY) */
    rowid, pms.cm_contract_supply.*
    FROM pms.cm_contract_supply
    WHERE
    contract_number = '0000000000131710'
    AND version_number = 3;
    However despite of giving hint, query results are fetched after full table scan.
    Execution Plan
    0 SELECT STATEMENT Optimizer=RULE (Cost=1182 Card=1 Bytes=742)
    1 0 TABLE ACCESS (FULL) OF 'CM_CONTRACT_SUPPLY' (Cost=1182 Card=1 Bytes=742)
    4. I have tried giving
    SELECT /*+ FIRST_ROWS + INDEX(XAK11CM_CONTRACT_SUPPLY) */
    rowid, pms.cm_contract_supply.*
    FROM pms.cm_contract_supply
    WHERE
    contract_number = '0000000000131710'
    AND version_number = 3;
    and
    SELECT /*+ CHOOSE + INDEX(XAK11CM_CONTRACT_SUPPLY) */
    rowid, pms.cm_contract_supply.*
    FROM pms.cm_contract_supply
    WHERE
    contract_number = '0000000000131710'
    AND version_number = 3;
    But it does not work.
    Is there some way without changing optimizer mode and without creating an additional index, we can use the index instead of full table scan?

    David,
    Here is my test on a Oracle 10g database.
    SQL> create table mytable as select * from all_tables;
    Table created.
    SQL> set autot traceonly
    SQL> alter session set optimizer_mode = choose;
    Session altered.
    SQL> select count(*) from mytable;
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE
       1    0   SORT (AGGREGATE)
       2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (TABLE)
    Statistics
              1  recursive calls
              0  db block gets
             29  consistent gets
              0  physical reads
              0  redo size
            223  bytes sent via SQL*Net to client
            276  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> analyze table mytable compute statistics;
    Table analyzed.
    SQL>  select count(*) from mytable
      2  ;
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1)
       1    0   SORT (AGGREGATE)
       2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (TABLE) (Cost=11 Card=1
              788)
    Statistics
              1  recursive calls
              0  db block gets
             29  consistent gets
              0  physical reads
              0  redo size
            222  bytes sent via SQL*Net to client
            276  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> disconnect
    Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
    With the Partitioning, Oracle Label Security, OLAP and Data Mining options

  • Prompt on DATE forces FULL TABLE SCAN

    When using a prompt on a datetime field OBIEE sends a SQL to the Database with the TIMESTAMP COMMAND.
    Due to Timestamp the Oracle database does a Full Table Scan. The field ATIST is a date with time on the physical database.
    By Default ATIST was configured as TIMESTAMP in the rpd physical layer. The SQL request is sent to a Oracle 10 Database.
    That is the query sent to the database:
    -------------------- Sending query to database named PlantControl1 (id: <<10167>>):
    select distinct T1471.ATIST as c1,
    T1471.GUTMENGEMELD2 as c2
    from
    AGRUECK T1471 /* Fact_ARBEITSGANGMELDUNGEN */
    where ( T1471.ATIST = TIMESTAMP '2005-04-01 13:48:05' )
    order by c1, c2
    The result takes more than half a minute to appear.
    Because BIEE is using "TIMESTAMP" , the database performs a full table scan instead of using the index.
    By using TO_DATE instead of timestamp the result appears after a second.
    select distinct T1471.ATIST, T1471.GUTMENGEMELD2 as c2
    from
    AGRUECK T1471 /* Fact_ARBEITSGANGMELDUNGEN */
    where ( T1471.ATIST = to_date('2005.04.01 13:48:05', 'yyyy.mm.dd hh24:mi:ss') );
    Is there any way resolving the issue?
    PS:When the field ATIST is configured as date at the physical layer the SQL performs well is it uses the command "to_date" instead of "timestamp". But this cuts the time of the date, When it is configured as DATETIME, OBIEE uses TIMESTAMP again.
    What I need is a working date + time field.
    Anybody has encountered a similiar problem?

    To be honest I haven't come across many scenarios where the Time has been important. Most of our reporting stops at Day level.
    What is the real world business question being asked here that requires DayTime?
    Incidentally if you change your datatype on the base table you will see it works fine.
    CREATE TABLE daytime( daytime TIMESTAMP );
    CREATE UNIQUE INDEX dt ON daytime  (daytime)
    SQL> set autotrace traceonly
    SQL> SELECT * FROM daytime
      2  WHERE daytime = TIMESTAMP '2007-04-01 13:00:45';
    no rows selected
    Execution Plan
    Plan hash value: 3985400340
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |     1 |    13 |     1   (0)| 00:00:01 |
    |*  1 |  INDEX UNIQUE SCAN| DT   |     1 |    13 |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access("DAYTIME"=TIMESTAMP' 2007-04-01 13:00:45.000000000')
    Statistics
              1  recursive calls
              0  db block gets
              1  consistent gets
              0  physical reads
              0  redo size
            242  bytes sent via SQL*Net to client
            362  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    SQL>However if its a date it would appear to do some internal function call which I guess is the source of the problem ...
    | Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |         |     1 |     9 |     2   (0)| 00:00:01 |
    |*  1 |  TABLE ACCESS FULL| DAYTIME |     1 |     9 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter(INTERNAL_FUNCTION("DAYTIME")=TIMESTAMP' 2007-04-01
                  13:00:45.000000000')

  • Full table scan and how to avoid it

    Hello,
    I have two tables, one with 425,000 records, and the other with 5,200,000 records in it. The smaller table has an index on its unique primary key, and the bigger table has an index on the foreign key of the smaller table.
    When joining these two tables, I keep getting full table scans on both of these tables, and I would like to understand the philosophy behind it as well as ways to avoid this.
    Thanks

    Are you manipulating the join columns in any fashion? Such as applying a function to them like in
    to_char(column_a) = to_char(column_b)Because any manipulation like that will obviate your index (assuming you don't have function based indexes).
    Really though, without your tables, indexes and query, we're left with voodoo, which is cool, but not really that effective.
    *note to any and all practicing witch doctors, i really do think voodoo is cool and effective, please don't persecute me for my speakings.
    Message was edited by:
    Tubby

  • Query tuning and how to force  table to use index?

    Dear Experts,
    i have two (2) question regarding performance during DRL.
    Question # 1
    There is a column name co_id in every transaction table. DBA suggest me to add [co_id='KPG'] in every clause which forces query to use index, resulting immediate processing. As an index was created for each table on the co_id column.
    Please note that co_id has constant value 'KPG' through out the table. is it make sense to add that column in where caluse like
    select a,b,c from tab1
    where a='89' and co_id='KPG'
    Question # 2
    if i am using a column name in where clause having index on it and that column is not in my column list does it restrict query for full table scan. like
    select a,b,c,d from tabletemp
    where e='ABC';
    Thanks in advance
    Edited by: Fiz Dosani on Mar 27, 2009 12:00 PM

    Fiz Dosani wrote:
    Dear Experts,
    i have two (2) question regarding performance during DRL.
    Question # 1
    There is a column name co_id in every transaction table. DBA suggest me to add [co_id='KPG'] in every clause which forces query to use index, resulting immediate processing. As an index was created for each table on the co_id column.
    Please note that co_id has constant value 'KPG' through out the table. is it make sense to add that column in where caluse like
    select a,b,c from tab1
    where a='89' and co_id='KPG'If co_id is always 'KPG' it is not needed to add this condition to the table. It would be very stupid to add an (normal) index on that column. An index is used to reduce the resultset of a query by storing the values and the rowids in a specified order. When all the values are equal and index justs makes all dml operations slower without makeing any select faster.
    And of cause the CBO is clever enough not to use such a index.
    >
    Question # 2
    if i am using a column name in where clause having index on it and that column is not in my column list does it restrict query for full table scan. like
    select a,b,c,d from tabletemp
    where e='ABC';
    Yes this is possible. However it depends from a few things.
    1) How selective this condition is. In general an index will be used when selectivity is less than 5%. This factor depends a bit on the database version. it means that when less then 5% of your rows have the value 'ABC' then an index access will be faster than the full table scan.
    2) Are the statistics up to date. The cost based optimizer (CBO) needs to know how many values are in that table, in the columns, in that index to make a good decision bout using an index access or a full table scan. Often one forgets to create statistics for freshly created data as in temptables.
    Edited by: Sven W. on Mar 27, 2009 8:53 AM

  • Rm ${datafile}; how to force 10g to find out about it?

    Hey;
    I have a small oracle 10g test instance with which I'm hoping to become familiar with backup and recovery - my first topic of study.
    I have a list of backups both copy and backupset. After getting those, I identified the files in the database:
    2 from dba_data_files
    3* order by tablespace_name
    SQL> /
    FILE_NAME FILE_ID STATUS TABLESPACE
    /oracle/oradata/oci1/example01.dbf 5 AVAILABLE EXAMPLE
    /oracle/oradata/oci1/sysaux01.dbf 3 AVAILABLE SYSAUX
    /oracle/oradata/oci1/system01.dbf 1 AVAILABLE SYSTEM
    /oracle/oradata/oci1/undotbs01.dbf 2 AVAILABLE UNDOTBS1
    /oracle/oradata/oci1/users01.dbf 4 AVAILABLE USERS
    then blasted example.dbf;
    $ ls -ld /oracle/oradata/oci1/example01.dbf
    ls: /oracle/oradata/oci1/example01.dbf: No such file or directory
    I was thinking that would start screaming immediately in the alert log... so far, nothing. I then tried a query of the hr schema and that worked. That obviously means the hr schema is in the sga which is curious by itself because I've never queried that table before.
    Finally a report from the v$datafile_header is also showing everything is still there:
    SQL> select file#, status, error, recover, tablespace_name, name
    2 from v$datafile_header;
    FILE# STATUS ERROR REC TABLESPACE NAME
    1 ONLINE NO SYSTEM /oracle/oradata/oci1/system01.dbf
    2 ONLINE NO UNDOTBS1 /oracle/oradata/oci1/undotbs01.dbf
    3 ONLINE NO SYSAUX /oracle/oradata/oci1/sysaux01.dbf
    4 ONLINE NO USERS /oracle/oradata/oci1/users01.dbf
    5 ONLINE NO EXAMPLE /oracle/oradata/oci1/example01.dbf
    I also forced a check point with alter system checkpoint and still nothing in the alert log or v$datafile_header query.
    How long will it be before oracle does the 'holy crap!' thing and/or how can I force it to find out about the missing datafile?
    Thanks for any info..
    Doug O'Leary

    Actually, if, after removing the file from the O/S, you login to the database w/ a new session, this will give you a new server process (assuming you're not running shared server), and that server process would not be able to open that file. If you now do a select and force a full table scan on a table that has extents in the file that you deleted, your process should catch an error.
    -Mark
    Edited by: mbobak on Jul 22, 2009 11:30 AM

Maybe you are looking for