Related
I have a view on which I apply some filters to retrieve data. This query to retrieve data is taking long time. Provided explain plan below with the query and it's access info. I have requirement to retrieve this data at a quick pace (within 30 seconds). But it is taking more than 15mins but not able to get data and timing out. Any idea how we can retrieve data quickly?
View definition as below:
CREATE VIEW DQ_DB.DQM_RESULT_VIEW
AS SELECT
res.ACTIVE_FL AS ACTIVE_FL,
res.VERSION as VERSION,
res.rule_constituents_tx,
nvl(ruletable.rule_desc,'N/A') AS rule_ds,
nvl(res.effective_dt, TO_DATE('31-dec-9999','dd-mon-yyyy')) AS effective_dt,
nvl(res.rule_id,'N/A') AS rule_id,
res.audit_update_ts AS rule_processed_at,
res.load_dt,
res.vendor_group_key,
nvl(res.vendor_entity_key,'N/A') AS vendor_entity_key,
res.vendor_entity_producer_nm,
(SELECT category_value_tx FROM dq_db.category_lookup_view WHERE category_nm = 'RESULT_STATUS_NB' AND category_value_cd = res.result_status_nb ) AS result,
--catlkp.category_value_tx as result,
res.entity_type,
nvl(rgrp.grp_nm,'N/A') AS rule_category,
nvl(ruletable.rule_nm,'N/A') AS rule_nm,
feedsumm.feed_run_nm AS file_nm,
res.application_id AS application,
res.data_source_id AS datasource,
res.entity_nm,
res.rule_entity_effective_dt,
res.result_id,
dim.dimension_nm,
dim.sub_dimension_nm,
ruletable.execution_env AS execution_env,
ruletable.ops_action AS ops_action,
rulefunctiontable.func_nm AS rule_func_nm,
-- nvl2(res.primary_dco_sid,dq_db.get_dco_name(res.primary_dco_sid),null) AS dco_primary,
-- nvl2(res.delegate_dco_sid,dq_db.get_dco_name(res.delegate_dco_sid),null) AS dco_delegate,
res.primary_dco_sid AS dco_primary,
res.delegate_dco_sid AS dco_delegate,
ruletable.data_concept_id AS data_concept_id,
res.latest_result_fl as latest_result_fl,
res.batch_execution_ts as batch_execution_ts
FROM
dq_db.dqm_result res
--LEFT OUTER JOIN dq_db.category_lookup_view catlkp on (catlkp.category_nm = 'RESULT_STATUS_NB' AND catlkp.category_value_cd = res.result_status_nb)
LEFT OUTER JOIN dq_db.feed_run_summary feedsumm ON res.vendor_group_key = feedsumm.batch_id
LEFT OUTER JOIN dq_db.dqm_rule ruletable ON res.rule_id = ruletable.rule_id
LEFT OUTER JOIN dq_db.dqm_rule_grp rgrp ON ruletable.rule_grp_id = rgrp.rule_grp_id
LEFT OUTER JOIN dq_db.dqm_rule_function rulefunctiontable ON ruletable.func_id = rulefunctiontable.func_id
LEFT OUTER JOIN dq_db.dq_dimension_view dim ON dim.dimension_id = ruletable.dimension_id
Explain plan of query used:
select * from ( select count(resultview0_.RULE_CATEGORY) as col_0_0_,
resultview0_.RULE_CATEGORY as col_1_0_ from DQ_DB.DQM_RESULT_VIEW
resultview0_ where (resultview0_.LATEST_RESULT_FL like :1 ) and
resultview0_.APPLICATION=:2 and (resultview0_.DATASOURCE in (:3 )) and
resultview0_.EFFECTIVE_DT>=:4 and resultview0_.EFFECTIVE_DT<=:5 and
resultview0_.LOAD_DT>=:6 and resultview0_.LOAD_DT<=:7 and
(resultview0_.RESULT in (:8 , :9 )) group by
resultview0_.RULE_CATEGORY ) where rownum <= :10
Plan hash value: 722164065
---------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 746K(100)| | | |
|* 1 | COUNT STOPKEY | | | | | | | |
| 2 | VIEW | | 592 | 155K| 746K (1)| 02:29:24 | | |
|* 3 | SORT GROUP BY STOPKEY | | 592 | 222K| 746K (1)| 02:29:24 | | |
| 4 | NESTED LOOPS | | 1 | 102 | 4 (0)| 00:00:01 | | |
| 5 | NESTED LOOPS | | 1 | 102 | 4 (0)| 00:00:01 | | |
|* 6 | TABLE ACCESS FULL | DATA_LOOKUP_VALUE | 1 | 51 | 3 (0)| 00:00:01 | | |
|* 7 | INDEX UNIQUE SCAN | PK_DATA_LOOKUP_CATEGORY | 1 | | 0 (0)| | | |
|* 8 | TABLE ACCESS BY INDEX ROWID | DATA_LOOKUP_CATEGORY | 1 | 51 | 1 (0)| 00:00:01 | | |
|* 9 | VIEW | DQM_RESULT_VIEW | 592 | 222K| 746K (1)| 02:29:24 | | |
|* 10 | FILTER | | | | | | | |
|* 11 | HASH JOIN OUTER | | 592 | 287K| 746K (1)| 02:29:24 | | |
|* 12 | HASH JOIN RIGHT OUTER | | 592 | 259K| 746K (1)| 02:29:16 | | |
| 13 | VIEW | index$_join$_009 | 39 | 3783 | 2 (0)| 00:00:01 | | |
|* 14 | HASH JOIN | | | | | | | |
| 15 | INDEX FAST FULL SCAN | PK_DQM_RULE_GRP | 39 | 3783 | 1 (0)| 00:00:01 | | |
| 16 | INDEX FAST FULL SCAN | UK_DQM_RULE_GRP | 39 | 3783 | 1 (0)| 00:00:01 | | |
|* 17 | HASH JOIN RIGHT OUTER | | 592 | 202K| 746K (1)| 02:29:16 | | |
| 18 | VIEW | DQ_DIMENSION_VIEW | 28 | 224 | 2 (0)| 00:00:01 | | |
| 19 | NESTED LOOPS OUTER | | 28 | 840 | 2 (0)| 00:00:01 | | |
|* 20 | HASH JOIN OUTER | | 28 | 616 | 2 (0)| 00:00:01 | | |
| 21 | INDEX FULL SCAN | PK_DQM_FW_DQ_DIM | 28 | 224 | 1 (0)| 00:00:01 | | |
| 22 | INDEX FULL SCAN | PK_DQM_FW_DQ_DIM_HRCHY | 21 | 294 | 1 (0)| 00:00:01 | | |
|* 23 | INDEX UNIQUE SCAN | PK_DQM_FW_DQ_DIM | 1 | 8 | 0 (0)| | | |
|* 24 | HASH JOIN RIGHT OUTER | | 592 | 198K| 746K (1)| 02:29:16 | | |
| 25 | TABLE ACCESS FULL | DQM_RULE | 451 | 37884 | 16 (0)| 00:00:01 | | |
| 26 | PARTITION RANGE ITERATOR | | 592 | 149K| 746K (1)| 02:29:16 | KEY | KEY |
|* 27 | TABLE ACCESS BY LOCAL INDEX ROWID| DQM_RESULT | 592 | 149K| 746K (1)| 02:29:16 | KEY | KEY |
|* 28 | INDEX SKIP SCAN | IDX_PK_DQM_RESULT | 379K| | 373K (1)| 01:14:42 | KEY | KEY |
|* 29 | INDEX FAST FULL SCAN | INDEX_BATCH_ID_RUN_SMRY | 149K| 7158K| 637 (1)| 00:00:08 | | |
---------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<=:10)
3 - filter(ROWNUM<=:10)
6 - filter(TO_NUMBER("VAL"."CATEGORY_VALUE_CD")=:B1)
7 - access("CAT"."CATEGORY_ID"="VAL"."CATEGORY_ID")
8 - filter("CAT"."CATEGORY_NM"='RESULT_STATUS_NB')
9 - filter(("RESULTVIEW0_"."RESULT"=:8 OR "RESULTVIEW0_"."RESULT"=:9))
10 - filter((:5>=:4 AND :7>=:6))
11 - access("RES"."VENDOR_GROUP_KEY"="FEEDSUMM"."BATCH_ID")
12 - access("RULETABLE"."RULE_GRP_ID"="RGRP"."RULE_GRP_ID")
14 - access(ROWID=ROWID)
17 - access("DIM"."DIMENSION_ID"="RULETABLE"."DIMENSION_ID")
20 - access("SUB_DIM"."SUB_DIMENSION_ID"="DIM"."DIMENSION_ID")
23 - access("DIM1"."DIMENSION_ID"="SUB_DIM"."DIMENSION_ID")
24 - access("RES"."RULE_ID"="RULETABLE"."RULE_ID")
27 - filter(NVL("RES"."LATEST_RESULT_FL",U'Y') LIKE SYS_OP_C2C(:1))
28 - access("RES"."LOAD_DT">=:6 AND "RES"."APPLICATION_ID"=SYS_OP_C2C(:2) AND "RES"."DATA_SOURCE_ID"=SYS_OP_C2C(:3) AND
"RES"."EFFECTIVE_DT">=:4 AND "RES"."LOAD_DT"<=:7 AND "RES"."EFFECTIVE_DT"<=:5)
filter(("RES"."EFFECTIVE_DT">=:4 AND "RES"."DATA_SOURCE_ID"=SYS_OP_C2C(:3) AND "RES"."APPLICATION_ID"=SYS_OP_C2C(:2)
AND "RES"."EFFECTIVE_DT"<=:5))
29 - filter("FEEDSUMM"."BATCH_ID" IS NOT NULL)
I have different indexes on DQM_RESULT table as below.
IDX_RULE_ID --> {RULE_ID}
IDX_PK_DQM_RESULT --> {LOAD_DT, APPLICATION_ID, DATA_SOURCE_ID, EFFECTIVE_DT, RESULT_ID}
IDX_EFF_DT_VENDOR_KEY --> {EFFECTIVE_DT, VENDOR_ENTITY_KEY}
INDEX_VENDOR_GROUP_KEY --> {VENDOR_GROUP_KEY}
IDX_EFFDT_APPDS_RUL_EID --> {LOAD_DT, APPLICATION_ID, DATA_SOURCE_ID, EFFECTIVE_DT, RULE_ID, VENDOR_ENTITY_KEY, LATEST_RESULT_FL, RESULT_ID}
DQM_RESULT Table is partitioned on LOAD_DT column and each load date contains around 15 data sources. Each data source loads around 1.5 million rows of data to each load date partition.
Change the order of the columns in this index to have the most selective columns first, or create another index with only the selective columns:
IDX_PK_DQM_RESULT --> {LOAD_DT, APPLICATION_ID, DATA_SOURCE_ID, EFFECTIVE_DT, RESULT_ID}
According to the execution plan, these operations are responsible for most of the time of the query:
|* 27 | TABLE ACCESS BY LOCAL INDEX ROWID| DQM_RESULT | 592 | 149K| 746K (1)| 02:29:16 | KEY | KEY |
|* 28 | INDEX SKIP SCAN | IDX_PK_DQM_RESULT | 379K| | 373K (1)| 01:14:42 | KEY | KEY |
Skip scans require an index access for each distinct value of the initial columns, which in this case is LOAD_DT. That column might be in some sort of anti-Goldilocks zone, where it's too distinct to be useful for a skip scan, but not distinct enough to be useful for a range scan.
If the above suggestion doesn't help, you should gather more data. The explain plan only shows the guesses about what the optimizer will do. Use the below code to generate an execution plan, which will show both the estimates and the actual values. Edit your question and post the results and you may get better answers.
--Run the query with this hint to generate extra statistics.
select /*+ gather_plan_statistics */ ... your query here ...;
--Find the SQL_ID for your statement.
select sql_id, sql_text from gv$sql where lower(sql_text) like '%gather_plan_statistics%';
--Generate execution plan.
select * from table(dbms_xplan.display_cursor(sql_id => 'SQL_ID from above', format => 'allstats last'));
I have a 118 line query similar to this:
select * from (The inner query with many joins) WHERE campus_code IN ('560','598')
The campus_code is getting generated by a function f_get_bookstore(SSBSECT_TERM_CODE,SSBSECT_CRN) AS SSBSECT_CAMP_CODE in the inner query. If I run the inner query alone its count is 18 & it is getting executed in 13 s. But if I add the WHERE campus_code IN ('560','598') then it is taking more than 2 min.
Another strange thing is, I have another query which is also like
select * from (The inner query with many joins) WHERE campus_code IN ('560','598'). Here the inner query slightly different than previous one. The inner query is fast & returning 92 rows. But here the campus_code IN filtering is fast even though it is working on 92 rows (unlike 18 rows for the previous query). Here also the campus_code is generated through the same function.
Can any body help to tune the query? Please tell what more info do you need.
This is the entire query:
SELECT *
FROM
(SELECT 'columbusstate' bk_institution_id,
'columbusstate.'
|| scbcrse_subj_code
|| '.'
|| scbcrse_crse_numb
||'.'
|| Ssbsect_Crn
|| '.'
|| ssbsect_term_code bk_section_id,
ssbsect_camp_code AS campus_code,
scbcrse_subj_code
|| '.'
|| scbcrse_crse_numb
||'.'
|| Ssbsect_Crn
|| '.'
|| ssbsect_term_code institution_section_id,
ssbsect_crn short_description,
scbcrse_title AS description,
ssbsect_crn sections_ssbsect_crn,
ssbsect_term_code sections_ssbsect_term_code,
'na' instructor_first_name,
'na' instructor_last_name,
scbcrse_subj_code
|| '.'
|| scbcrse_crse_numb rel_institution_course_id,
scbcrse_title AS rel_course_description,
scbcrse_title AS rel_course_name,
scbcrse_crse_numb AS course_short_desc,
scbcrse_crse_numb course_number,
stvterm_desc term_short_desc,
stvterm_code rel_institution_term_id,
section.ssbsect_crn,
ssbsect_ssts_code AS ssbsect_ssts_code,
'columbusstate.'
|| stvterm_code rel_bk_term_id,
'columbusstate.'
|| scbcrse_subj_code
|| '.'
|| scbcrse_crse_numb rel_bk_course_id,
ssbsect_seq_numb,
ssbsect_enrl ssbsect_enrl,
ssbsect_enrl estimated_enrl,
ssbsect_max_enrl ssbsect_max_enrl,
ssbsect_crn ssbsect_section_key,
ssbsect_crn ssbsect_section_number,
'parent' relationship,
course.scbcrse_subj_code institution_department_id ,
'DFLT' institution_division_id,
'DFLT' division_short_desc
FROM
(SELECT *
FROM
(SELECT SSBSECT_TERM_CODE,
SSBSECT_CRN,
SSBSECT_SUBJ_CODE,
SSBSECT_CRSE_NUMB,
SSBSECT_PTRM_CODE,
SSBSECT_SEQ_NUMB,
SSBSECT_SSTS_CODE,
SSBSECT_MAX_ENRL,
SSBSECT_ENRL,
SSBSECT_PRNT_IND,
f_get_bookstore(SSBSECT_TERM_CODE,SSBSECT_CRN) AS SSBSECT_CAMP_CODE
FROM SSBSECT
) sect
JOIN
(SELECT *
FROM
(SELECT * FROM saturn.stvterm WHERE STVTERM_CODE >= '201401'
)
) term
ON term.stvterm_code=sect.ssbsect_term_code
) section
JOIN
(SELECT C1.scbcrse_subj_code,
C1.scbcrse_dept_code,
C1.scbcrse_crse_numb,
C1.scbcrse_title
FROM saturn.scbcrse C1
LEFT JOIN saturn.scbcrse C2
ON (C1.scbcrse_subj_code = C2.scbcrse_subj_code
AND C1.scbcrse_crse_numb = C2.scbcrse_crse_numb
AND C1.scbcrse_eff_term < C2.scbcrse_eff_term)
WHERE c2.scbcrse_eff_term IS NULL
) Course ON Course.scbcrse_subj_code = Section.ssbsect_subj_code
AND scbcrse_crse_numb = section.ssbsect_crse_numb
AND ssbsect_ssts_code IN ('A','V','X')
LEFT JOIN
(SELECT sirasgn_term_code sirasgn_term_code,
sirasgn_crn,
MAX(spriden_pidm) spriden_pidm,
MAX(spriden_first_name) instructor_first_name,
MAX(spriden_last_name) instructor_last_name
FROM
(SELECT Pidm spriden_pidm,
Csu_Id SPRIDEN_ID,
First_Name spriden_first_name,
Last_Name spriden_last_name,
Mi spriden_mi,
External_User_Id login,
Email
FROM Csuapps.Wfollett_Person
) persons
JOIN
( SELECT * FROM saturn.sirasgn WHERE SIRASGN_PRIMARY_IND = 'Y'
) relations
ON persons.spriden_pidm=relations.sirasgn_pidm
GROUP BY sirasgn_crn,
sirasgn_term_code
) instr ON section.ssbsect_term_code=instr.sirasgn_term_code
AND section.ssbsect_crn =instr.sirasgn_crn
WHERE Course.scbcrse_subj_code = 'ACCT'
AND section.ssbsect_term_code = '201702'
)
WHERE campus_code IN ('560','1157')
Execution Plan:
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2063389120
-----------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 77 | 968K| | 4364 (3)| 00:00:01 |
| 1 | SORT ORDER BY | | 77 | 968K| 624K| 4364 (3)| 00:00:01 |
|* 2 | VIEW | | 77 | 968K| | 4155 (3)| 00:00:01 |
| 3 | COUNT | | | | | | |
| 4 | VIEW | | 77 | 967K| | 4155 (3)| 00:00:01 |
| 5 | SORT ORDER BY | | 77 | 774K| | 4155 (3)| 00:00:01 |
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 6 | FILTER | | | | | | |
|* 7 | HASH JOIN RIGHT OUTER | | 77 | 774K| | 4154 (3)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | SCBCRSE_KEY_INDEX | 83 | 1494 | | 1 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 77 | 772K| | 4153 (3)| 00:00:01 |
| 10 | NESTED LOOPS OUTER | | 23 | 229K| | 4139 (3)| 00:00:01 |
|* 11 | HASH JOIN OUTER | | 23 | 1656 | | 3783 (1)| 00:00:01 |
| 12 | NESTED LOOPS | | 23 | 1334 | | 7 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | STVTERM | 1 | 22 | | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | PK_STVTERM | 1 | | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID BATCHED| SSBSECT | 23 | 828 | | 6 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | SSBSECT_INDEX_SUBJ | 25 | | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 17 | VIEW | | 2172 | 30408 | | 3775 (1)| 00:00:01 |
| 18 | HASH GROUP BY | | 2172 | 8537K| 16M| 3775 (1)| 00:00:01 |
|* 19 | HASH JOIN | | 4166 | 15M| | 1364 (1)| 00:00:01 |
| 20 | VIEW | VW_GBF_14 | 2312 | 18496 | | 211 (1)| 00:00:01 |
| 21 | HASH GROUP BY | | 2312 | 48552 | | 211 (1)| 00:00:01 |
|* 22 | TABLE ACCESS FULL | SIRASGN | 2312 | 48552 | | 210 (1)| 00:00:01 |
| 23 | VIEW | WFOLLETT_PERSON | 3714 | 14M| | 1153 (1)| 00:00:01 |
| 24 | SORT UNIQUE | | 3714 | 342K| | 1153 (1)| 00:00:01 |
| 25 | UNION-ALL | | | | | | |
| 26 | NESTED LOOPS | | 1 | 59 | | 2 (0)| 00:00:01 |
| 27 | NESTED LOOPS | | 1 | 59 | | 2 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 28 | INDEX RANGE SCAN | PK_GLBEXTR | 1 | 38 | | 1 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | PK_GOBTPAC | 1 | | | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | GOBTPAC | 1 | 21 | | 1 (0)| 00:00:01 |
| 31 | NESTED LOOPS | | 1912 | 130K| | 605 (0)| 00:00:01 |
| 32 | NESTED LOOPS | | 1912 | 130K| | 605 (0)| 00:00:01 |
|* 33 | HASH JOIN | | 1912 | 93688 | | 31 (0)| 00:00:01 |
| 34 | VIEW | VW_SQ_2 | 3076 | 83052 | | 10 (0)| 00:00:01 |
| 35 | HASH GROUP BY | | 3076 | 39988 | | 10 (0)| 00:00:01 |
| 36 | INDEX FULL SCAN | PK_SIBINST | 6243 | 81159 | | 10 (0)| 00:00:01 |
|* 37 | TABLE ACCESS FULL | SIBINST | 3881 | 85382 | | 21 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | PK_GOBTPAC | 1 | | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 39 | TABLE ACCESS BY INDEX ROWID | GOBTPAC | 1 | 21 | | 1 (0)| 00:00:01 |
| 40 | NESTED LOOPS | | 1801 | 41423 | | 543 (1)| 00:00:01 |
| 41 | NESTED LOOPS | | 1801 | 41423 | | 543 (1)| 00:00:01 |
| 42 | VIEW | VW_DTP_6100A9C4 | 1801 | 3602 | | 3 (34)| 00:00:01 |
| 43 | HASH UNIQUE | | 1801 | 23413 | | 3 (34)| 00:00:01 |
|* 44 | INDEX RANGE SCAN | PK_SIRASGN | 4161 | 54093 | | 2 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | PK_GOBTPAC | 1 | | | 1 (0)| 00:00:01 |
| 46 | TABLE ACCESS BY INDEX ROWID | GOBTPAC | 1 | 21 | | 1 (0)| 00:00:01 |
| 47 | VIEW PUSHED PREDICATE | | 1 | 10165 | | 16 (25)| 00:00:01 |
|* 48 | FILTER | | | | | | |
| 49 | NESTED LOOPS | | 1 | 10164 | | 16 (25)| 00:00:01 |
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 50 | NESTED LOOPS | | 1 | 79 | | 4 (0)| 00:00:01 |
|* 51 | FILTER | | | | | | |
| 52 | NESTED LOOPS OUTER | | 1 | 60 | | 3 (0)| 00:00:01 |
| 53 | NESTED LOOPS | | 1 | 42 | | 2 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | SSBSECT | 1 | 24 | | 1 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | PK_SSBSECT | 1 | | | 1 (0)| 00:00:01 |
|* 56 | INDEX RANGE SCAN | SCBCRSE_KEY_INDEX | 1 | 18 | | 1 (0)| 00:00:01 |
|* 57 | INDEX RANGE SCAN | SCBCRSE_KEY_INDEX | 15046 | 264K| | 1 (0)| 00:00:01 |
|* 58 | INDEX RANGE SCAN | PK_SIRASGN | 1 | 19 | | 1 (0)| 00:00:01 |
| 59 | VIEW | WFOLLETT_PERSON | 1 | 10085 | | 12 (34)| 00:00:01 |
| 60 | SORT UNIQUE | | 3 | 304 | | 12 (34)| 00:00:01 |
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 61 | UNION ALL PUSHED PREDICATE | | | | | | |
| 62 | NESTED LOOPS | | 1 | 59 | | 2 (0)| 00:00:01 |
| 63 | TABLE ACCESS BY INDEX ROWID | GOBTPAC | 1 | 21 | | 1 (0)| 00:00:01 |
|* 64 | INDEX UNIQUE SCAN | PK_GOBTPAC | 1 | | | 1 (0)| 00:00:01 |
|* 65 | INDEX RANGE SCAN | PK_GLBEXTR | 1 | 38 | | 1 (0)| 00:00:01 |
| 66 | NESTED LOOPS | | 1 | 70 | | 3 (0)| 00:00:01 |
| 67 | NESTED LOOPS | | 1 | 70 | | 3 (0)| 00:00:01 |
| 68 | NESTED LOOPS | | 1 | 48 | | 2 (0)| 00:00:01 |
| 69 | TABLE ACCESS BY INDEX ROWID | GOBTPAC | 1 | 21 | | 1 (0)| 00:00:01 |
|* 70 | INDEX UNIQUE SCAN | PK_GOBTPAC | 1 | | | 1 (0)| 00:00:01 |
| 71 | VIEW | VW_SQ_1 | 1 | 27 | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 72 | SORT GROUP BY | | 1 | 13 | | 1 (0)| 00:00:01 |
|* 73 | INDEX RANGE SCAN | PK_SIBINST | 2 | 26 | | 1 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | PK_SIBINST | 1 | | | 1 (0)| 00:00:01 |
|* 75 | TABLE ACCESS BY INDEX ROWID | SIBINST | 1 | 22 | | 1 (0)| 00:00:01 |
| 76 | NESTED LOOPS | | 1 | 23 | | 4 (25)| 00:00:01 |
| 77 | TABLE ACCESS BY INDEX ROWID | GOBTPAC | 1 | 21 | | 1 (0)| 00:00:01 |
|* 78 | INDEX UNIQUE SCAN | PK_GOBTPAC | 1 | | | 1 (0)| 00:00:01 |
|* 79 | VIEW | VW_DTP_32C68FB6 | 1 | 2 | | 3 (34)| 00:00:01 |
| 80 | SORT UNIQUE | | 2 | 26 | | 3 (34)| 00:00:01 |
|* 81 | INDEX RANGE SCAN | PK_SIRASGN | 2 | 26 | | 2 (0)| 00:00:01 |
| 82 | TABLE ACCESS BY INDEX ROWID BATCHED | SCBCRSE | 3 | 126 | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 83 | INDEX RANGE SCAN | SCBCRSE_KEY_INDEX | 1 | | | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("from$_subquery$_002"."CAMPUS_CODE"='1157' OR "from$_subquery$_002"."CAMPUS_CODE"='560') AND "R">=1
AND "R"<=1500)
6 - filter("C2"."SCBCRSE_EFF_TERM" IS NULL)
7 - access("C1"."SCBCRSE_SUBJ_CODE"="C2"."SCBCRSE_SUBJ_CODE"(+) AND
"C1"."SCBCRSE_CRSE_NUMB"="C2"."SCBCRSE_CRSE_NUMB"(+))
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
filter("C1"."SCBCRSE_EFF_TERM"<"C2"."SCBCRSE_EFF_TERM"(+))
8 - access("C2"."SCBCRSE_SUBJ_CODE"(+)='ACCT')
11 - access("SSBSECT_TERM_CODE"="INSTR"."SIRASGN_TERM_CODE"(+) AND "SSBSECT_CRN"="INSTR"."SIRASGN_CRN"(+))
14 - access("STVTERM"."STVTERM_CODE"='201702')
15 - filter("SSBSECT_SSTS_CODE"='A' OR "SSBSECT_SSTS_CODE"='V' OR "SSBSECT_SSTS_CODE"='X')
16 - access("SSBSECT_SUBJ_CODE"='ACCT' AND "SSBSECT_TERM_CODE"='201702')
filter("SSBSECT_TERM_CODE"='201702')
19 - access("PIDM"="ITEM_1")
22 - filter("SIRASGN"."SIRASGN_TERM_CODE"='201702' AND "SIRASGN_PRIMARY_IND"='Y')
28 - access("GLBEXTR_APPLICATION"='STUDENT' AND "GLBEXTR_SELECTION"='CURR_ENRL' AND "GLBEXTR_CREATOR_ID"='GSHOUL')
29 - access("GOBTPAC_PIDM"=TO_NUMBER("GLBEXTR_KEY"))
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
33 - access("A"."SIBINST_TERM_CODE_EFF"="MAX(B.SIBINST_TERM_CODE_EFF)" AND "ITEM_2"="A"."SIBINST_PIDM")
37 - filter("A"."SIBINST_FCST_CODE"='AC' AND "A"."SIBINST_FCTG_CODE"<>'EMPL')
38 - access("A"."SIBINST_PIDM"="GOBTPAC_PIDM")
44 - access("SIRASGN_TERM_CODE">="TOOLS"."GETTERMCODE"(NULL,SYSDATE#!))
45 - access("ITEM_1"="GOBTPAC_PIDM")
48 - filter("SSBSECT_TERM_CODE">='201602' AND "SSBSECT_TERM_CODE"='201702')
51 - filter("C2"."SCBCRSE_EFF_TERM" IS NULL)
55 - access("SSBSECT_TERM_CODE"="SSBSECT_TERM_CODE" AND "SSBSECT_CRN"="SSBSECT_CRN")
filter("SSBSECT_TERM_CODE"='201702')
56 - access("SSBSECT_SUBJ_CODE"="C1"."SCBCRSE_SUBJ_CODE" AND "SSBSECT_CRSE_NUMB"="C1"."SCBCRSE_CRSE_NUMB")
57 - access("C1"."SCBCRSE_SUBJ_CODE"="C2"."SCBCRSE_SUBJ_CODE"(+) AND
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"C1"."SCBCRSE_CRSE_NUMB"="C2"."SCBCRSE_CRSE_NUMB"(+) AND "C1"."SCBCRSE_EFF_TERM"<"C2"."SCBCRSE_EFF_TERM"(+) AND
"C2"."SCBCRSE_EFF_TERM"(+) IS NOT NULL)
58 - access("REL"."SIRASGN_TERM_CODE"="SSBSECT_TERM_CODE" AND "REL"."SIRASGN_CRN"="SSBSECT_CRN")
filter("REL"."SIRASGN_TERM_CODE"="SSBSECT_TERM_CODE" AND "REL"."SIRASGN_TERM_CODE"='201702' AND
"REL"."SIRASGN_CRN"="SSBSECT_CRN")
64 - access("GOBTPAC_PIDM"="REL"."SIRASGN_PIDM")
65 - access("GLBEXTR_APPLICATION"='STUDENT' AND "GLBEXTR_SELECTION"='CURR_ENRL' AND "GLBEXTR_CREATOR_ID"='GSHOUL')
filter(TO_NUMBER("GLBEXTR_KEY")="REL"."SIRASGN_PIDM" AND "GOBTPAC_PIDM"=TO_NUMBER("GLBEXTR_KEY"))
70 - access("GOBTPAC_PIDM"="REL"."SIRASGN_PIDM")
73 - access("B"."SIBINST_PIDM"="REL"."SIRASGN_PIDM")
74 - access("A"."SIBINST_PIDM"="REL"."SIRASGN_PIDM" AND "A"."SIBINST_TERM_CODE_EFF"="MAX(B.SIBINST_TERM_CODE_EFF)")
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
filter("A"."SIBINST_PIDM"="GOBTPAC_PIDM" AND "ITEM_1"="A"."SIBINST_PIDM")
75 - filter("A"."SIBINST_FCST_CODE"='AC' AND "A"."SIBINST_FCTG_CODE"<>'EMPL')
78 - access("GOBTPAC_PIDM"="REL"."SIRASGN_PIDM")
79 - filter("ITEM_1"="GOBTPAC_PIDM")
81 - access("SIRASGN_TERM_CODE">="TOOLS"."GETTERMCODE"(NULL,SYSDATE#!) AND "SIRASGN_PIDM"="REL"."SIRASGN_PIDM")
filter("SIRASGN_PIDM"="REL"."SIRASGN_PIDM")
83 - access("C1"."SCBCRSE_SUBJ_CODE"='ACCT' AND "C1"."SCBCRSE_CRSE_NUMB"="SSBSECT_CRSE_NUMB")
139 rows selected.
The performance of your query depends on the details, that we don't know, and on the joins. In general, if the joins result in a huge set of rows, that will eat a lot of cpu and ram. So try to add where clauses that minimize the number of rows in the joins.
Said in an other way, just imagine you are the cpu. Go through your query and try to estimate the number of rows that you need to process, and how you could limit that number of rows.
Are you using an index on crucial tables to speed up selects? Are you modifying the search column used in an index, so that the index does not work? Stuff like this is very important.
Good luck!
update:
The plan shows to me that most cpu is burned for the outermost query, something that you already noticed in the timing measurements. My strategy would be to try to move the outermost where-clause towards the inner queries. If the database engine can apply the where-clause in an earlier phase, the query will need less memory and cpu.
Now it is not possible to see to which table each output field belongs. If I where you I would give EVERY table in each FROM an alias.
For the sake of testing performance, and for posting here, you could simplify the lists of output fields. Leave out fields that are not required by outer queries, or use asterisk. Also, try to present a perfectly pretty printed query.
Apart from the Plan, could you get some info on memory usage? With the outer query, perhaps it needs to get a lot of data in memory before outputting results. Just imagine if this results in exhausting ram and needs swap, that will cost a lot of time. Memory use may also come from holding a lock on possibly big tables, so do not get fooled by your 'just 18 rows' of output.
OK, I'm going to put this in a "answer", since comments seem to be ignored.
The only way to know what is going on and how to fix your problem is to get the execution plan. Otherwise every answer is a guess. You may get lucky that a guess works, but then you will never know why. So please help us to help you.
To get an execution plan (for both the queries with and without the WHERE clause), run this after your query...
set lines 500
set pages 10000
select * from table( dbms_xplan.display_cursor( null, null, 'TYPICAL' ));
Is campus_code an integer? If it is, try removing the apostrophes, like this:
WHERE campus_code IN (560,598)
Otherwise, each value gets converted before being compared, and that can take a lot of time.
Hope this helps.
What you observe is by 99% a merging predicates in an inline view.
This works typically fine and helps performance as illustrated on an example below.
Sample Data
create table T1 as
select 'xxxx'||rownum crampus_code from dual connect by level <= 100000;
create index idx1 on t1(crampus_code);
This query can take a substantial time on a large table as the whole table must be accessed.
select crampus_code, count(*) from T1 group by crampus_code;
A following query using the previous query as a subquery can be very effective. How?
The WHERE clause in MERGE in the subquery and only the data for the two keys are accessed (index) and aggregated.
with agg as
(
select
a.crampus_code, count(*)
from
T1 a
group by
crampus_code
)
select *
from agg
where crampus_code in ('xxxx42','xxxx399');
The proof is in the execution plan (that you don't provided)
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 48 | 3 (0)| 00:00:01 |
| 1 | SORT GROUP BY NOSORT| | 2 | 48 | 3 (0)| 00:00:01 |
| 2 | INLIST ITERATOR | | | | | |
|* 3 | INDEX RANGE SCAN | IDX1 | 2 | 48 | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("A"."CRAMPUS_CODE"='xxxx399' OR
"A"."CRAMPUS_CODE"='xxxx42')
You see the table is accesse via index for only the two keys.
Your Case
This is only speculation but IMO during the merge predicate phase you get a much worst execution plan that without it.
This explain the increase in elapsed time by addin the WHERE clause.
Only if you show both plans (subquery and the query with WHERE) you can be sure...
Workaround
So what can you do if the predicate merge destroys the performance?
Simple turn it off. Unfortunately you must use an undocumented hint MATERIALIZE, that set up the result of the query as temporary table
and the WHERE predicate will be applied on it.
This should work for your 18 rows. I'm not sure, but thing you must rewrite query using the subquery factoring (WITH).
with agg as
(select /*+ MATERIALIZE */ a.crampus_code, count(*) from T1 a group by crampus_code)
select * from agg
where crampus_code in ('xxxx42','xxxx399');
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 97325 | 3516K| 94 (5)| 00:00:02 |
| 1 | TEMP TABLE TRANSFORMATION | | | | | |
| 2 | LOAD AS SELECT | SYS_TEMP_0FD9D673A_CE046F62 | | | | |
| 3 | HASH GROUP BY | | 97325 | 2281K| 41 (10)| 00:00:01 |
| 4 | TABLE ACCESS FULL | T1 | 97325 | 2281K| 37 (0)| 00:00:01 |
|* 5 | VIEW | | 97325 | 3516K| 54 (2)| 00:00:01 |
| 6 | TABLE ACCESS FULL | SYS_TEMP_0FD9D673A_CE046F62 | 97325 | 2281K| 54 (2)| 00:00:01 |
----------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
5 - filter("CRAMPUS_CODE"='xxxx399' OR "CRAMPUS_CODE"='xxxx42')
This particular query was working fine till we were in 11i but as soon as we switched to 12c the query has been doing really bad.
I tried to remove the hint and it seems to be doing little better but our DBA wants us to remove all the multiple subqueries which cause serialization of the various sub-steps. I am at a loss on how to change it.
Any pointers on what I can do or start with?
WITH
-- Get all active accounts that have not been suspended and the suspension rules
-- apply for the account
TT1 AS (SELECT
pl.employer_id,
ma.employee_id,
ma.member_account_id,
pl.plan_id
FROM sa_plans pl,
sa_accounts ma
WHERE TRUNC(SYSDATE) BETWEEN pl.start_date AND NVL(pl.end_date, TRUNC(SYSDATE))
AND pl.employer_id = 23
AND pl.plan_type_id NOT IN (4
,1)
AND pl.plan_id = ma.plan_id
AND sa_mc_info.fn_ee_susp_exempt(ma.employee_id, DECODE(pl.plan_type_id, 1, 6 ,5 )) = 0
AND p_outstanding_threshold_perc > 0
AND NVL(ma.auto_suspension_flag, 0) = 0
AND TRUNC(SYSDATE) BETWEEN ma.account_effective_date AND NVL(ma.account_end_date, TRUNC(SYSDATE))
AND ma.account_effective_date != NVL(ma.account_end_date, ma.account_effective_date + 1)
),
-- Get all accounts that were active during the plan year for the current accounts
-- and the outstanding transactions
TT2 AS (SELECT /*+ MATERIALIZE */
ma1.member_account_id,
ma1.plan_id,
ma1.employee_id ,
wwsa.sa_mc_info.fn_acnt_unverified_txns(ma1.member_account_id) outstd_amount
FROM sa_accounts ma1,
TT1 ma
WHERE ma1.account_effective_date != NVL(ma1.account_end_date, ma1.account_effective_date + 1)
AND ma1.plan_id = ma.plan_id
AND ma1.employee_id = ma.employee_id
AND ma1.member_account_id = TT1.member_account_id),
-- Sum the outstanding transactions for the EE and plan
TT3 AS (SELECT /*+ MATERIALIZE ORDERED */
TT1.member_account_id,
SUM(TT2.outstd_amount) outstd_amount
FROM TT1,
TT2
WHERE TT1.employee_id = TT2.employee_id
AND TT1.plan_id = TT2.plan_id
GROUP BY TT1.member_account_id
HAVING SUM(TT2.outstd_amount) > 0),
-- Get the current account balance for accounts with outstanding transactions
TT4 AS (SELECT /*+ MATERIALIZE ORDERED */
TT1.*,
sa_bal_info.fn_account_balance(TT1.member_account_id) balance,
TT3.outstd_amount
FROM TT1,
TT3
WHERE TT1.member_account_id = TT3.member_account_id),
-- Get the list of accounts that need to be suspended
TT5 as (SELECT /*+ MATERIALIZE */
member_account_id,
employee_id
FROM TT4
WHERE outstd_amount > balance * p_outstanding_threshold_perc
AND outstd_amount > NVL(p_minimum_threshold_amount, 0) )
SELECT *
FROM TT5
ORDER BY employee_id;
This is the explain plan
-----------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 26 | 8622 (1)| 00:00:01 |
| 1 | TEMP TABLE TRANSFORMATION | | | | | |
| 2 | LOAD AS SELECT | SYS_TEMP_0FD9D666F_DCBC1560 | | | | |
| 3 | NESTED LOOPS | | 4 | 252 | 8600 (1)| 00:00:01 |
| 4 | NESTED LOOPS | | 1707 | 252 | 8600 (1)| 00:00:01 |
|* 5 | TABLE ACCESS BY INDEX ROWID BATCHED| SA_PLANS | 3 | 84 | 8452 (1)| 00:00:01 |
| 6 | INDEX FULL SCAN | SA_PLANS_PK | 19218 | | 75 (2)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | SA_ACCOUNTS_N03 | 569 | | 2 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID | SA_ACCOUNTS | 1 | 35 | 67 (0)| 00:00:01 |
| 9 | LOAD AS SELECT | SYS_TEMP_0FD9D6670_DCBC1560 | | | | |
| 10 | NESTED LOOPS | | 3 | 177 | 8 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 3 | 177 | 8 (0)| 00:00:01 |
| 12 | VIEW | | 1 | 26 | 2 (0)| 00:00:01 |
| 13 | TABLE ACCESS FULL | SYS_TEMP_0FD9D666F_DCBC1560 | 1 | 22 | 2 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | SA_ACCOUNTS_N01 | 3 | | 2 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | SA_ACCOUNTS | 3 | 99 | 6 (0)| 00:00:01 |
| 16 | LOAD AS SELECT | SYS_TEMP_0FD9D6671_DCBC1560 | | | | |
|* 17 | FILTER | | | | | |
| 18 | HASH GROUP BY | | 1 | 41 | 5 (20)| 00:00:01 |
|* 19 | HASH JOIN | | 1 | 41 | 4 (0)| 00:00:01 |
| 20 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
| 21 | TABLE ACCESS FULL | SYS_TEMP_0FD9D666F_DCBC1560 | 1 | 22 | 2 (0)| 00:00:01 |
| 22 | VIEW | | 1 | 24 | 2 (0)| 00:00:01 |
| 23 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6670_DCBC1560 | 1 | 30 | 2 (0)| 00:00:01 |
| 24 | LOAD AS SELECT | SYS_TEMP_0FD9D6672_DCBC1560 | | | | |
|* 25 | HASH JOIN | | 1 | 78 | 4 (0)| 00:00:01 |
| 26 | VIEW | | 1 | 52 | 2 (0)| 00:00:01 |
| 27 | TABLE ACCESS FULL | SYS_TEMP_0FD9D666F_DCBC1560 | 1 | 22 | 2 (0)| 00:00:01 |
| 28 | VIEW | | 1 | 26 | 2 (0)| 00:00:01 |
| 29 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6671_DCBC1560 | 1 | 19 | 2 (0)| 00:00:01 |
| 30 | LOAD AS SELECT | SYS_TEMP_0FD9D6673_DCBC1560 | | | | |
|* 31 | VIEW | | 1 | 52 | 2 (0)| 00:00:01 |
| 32 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6672_DCBC1560 | 1 | 48 | 2 (0)| 00:00:01 |
| 33 | SORT ORDER BY | | 1 | 26 | 3 (34)| 00:00:01 |
| 34 | VIEW | | 1 | 26 | 2 (0)| 00:00:01 |
| 35 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6673_DCBC1560 | 1 | 12 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------
Try to execute TT1 and evaluate execution time. If it's OK, then continue with TT1+TT2 and so on. You need to understand where problem is before truing to solve it.
I would assume your problem is directed related to a bad plan.
So, as you said, it performed just fine on 11g database so there basic two things you could do to try to solve your problem in a short term manner:
Check the optimizer_features_enable parameter on 12c version. If it is set to 12.* or an upper version, try to downgrade the session who is running the query to the 11.* version of your old database.
Assuming you have Tuning Pack (licensing issues - take care) enabled into your production environment, you could use SQL Profiles. How? You could manually copy your the plan from the 11g and import it to the 12c database. Take a look at dbms_sqltune.import_sql_profile.
https://oracle-randolf.blogspot.com.br/2009/03/plan-stability-in-10g-using-existing.html
As I said before, these are short term action. It would be better to evaluate your SQL.
I have two views, v_movimiento_no_duplicado and v_personas_no_duplicadas. Both queries removes duplicates from tables CLM020A and CLM010A respectively. When i execute each query individually i get fast return, when i join them is fast too. Problem is when i put some predicates, for example:
SELECT *
FROM v_movimiento_no_duplicado
INNER JOIN v_personas_no_duplicadas USING (cedula_rel)
WHERE LENGTH (nombres_010) <= 30
AND LENGTH (apellidos_010) <= 30
--AND LENGTH (cedula_rel) <= 15;
Without last predicate takes 125 ms(is ok),but if add third predicate takes 11 seconds. I haven't indexes at this moment, but i have tried indexes for each of three colums, composites indexes even function-based indexes, but result is the same or worst. This are the plans for both cases:
With two predicates (faster):
-------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 27 | 7371 | 253 (2)| 00:00:04 |
|* 1 | HASH JOIN | | 27 | 7371 | 253 (2)| 00:00:04 |
|* 2 | HASH JOIN | | 27 | 7047 | 149 (3)| 00:00:02 |
|* 3 | HASH JOIN SEMI | | 14 | 1596 | 46 (5)| 00:00:01 |
| 4 | JOIN FILTER CREATE | :BF0000 | 14 | 1148 | 22 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | CLM010A | 14 | 1148 | 22 (0)| 00:00:01 |
| 6 | VIEW | VW_NSO_1 | 56 | 1792 | 23 (5)| 00:00:01 |
|* 7 | FILTER | | | | | |
| 8 | HASH GROUP BY | | 1 | 672 | 23 (5)| 00:00:01 |
| 9 | JOIN FILTER USE | :BF0000 | 5532 | 66384 | 22 (0)| 00:00:01 |
|* 10 | TABLE ACCESS FULL| CLM010A | 5532 | 66384 | 22 (0)| 00:00:01 |
| 11 | TABLE ACCESS FULL | CLM020A | 10734 | 1540K| 102 (0)| 00:00:02 |
| 12 | VIEW | VW_NSO_2 | 10734 | 125K| 104 (2)| 00:00:02 |
| 13 | HASH GROUP BY | | 10734 | 461K| 104 (2)| 00:00:02 |
|* 14 | TABLE ACCESS FULL | CLM020A | 10734 | 461K| 102 (0)| 00:00:02 |
-------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("M".ROWID="FILA")
2 - access("CEDULA_REL"="CEDULA_REL")
3 - access("CEDULA_REL"="CEDULA_REL")
5 - filter(LENGTH("NOMBRES_010")<=30 AND LENGTH("APELLIDOS_010")<=30)
7 - filter(COUNT("CEDULA_REL")=1)
10 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"CEDULA_REL"))
14 - filter(("M"."TIPO_020"='E' OR "M"."TIPO_020"='S') AND
"M"."LUGARMOV_020" IS NOT NULL)
Now, with three predicates (slower):
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 229 | 252 (2)| 00:00:04 |
|* 1 | FILTER | | | | | |
|* 2 | HASH JOIN | | 1 | 229 | 125 (1)| 00:00:02 |
|* 3 | TABLE ACCESS FULL | CLM010A | 1 | 82 | 22 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL | CLM020A | 10734 | 1540K| 102 (0)| 00:00:02 |
|* 5 | FILTER | | | | | |
| 6 | HASH GROUP BY | | 1 | 12 | 23 (5)| 00:00:01 |
| 7 | TABLE ACCESS FULL| CLM010A | 5532 | 66384 | 22 (0)| 00:00:01 |
|* 8 | FILTER | | | | | |
| 9 | HASH GROUP BY | | 108 | 4752 | 104 (2)| 00:00:02 |
|* 10 | TABLE ACCESS FULL| CLM020A | 10734 | 461K| 102 (0)| 00:00:02 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( EXISTS (SELECT 0 FROM "LIMOV"."CLM010A" "P2" GROUP BY
"CEDULA_REL" HAVING "CEDULA_REL"=:B1 AND COUNT("CEDULA_REL")=1) AND
EXISTS (SELECT 0 FROM "LIMOV"."CLM020A" "M" WHERE ("M"."TIPO_020"='E'
OR "M"."TIPO_020"='S') AND "M"."LUGARMOV_020" IS NOT NULL GROUP BY
UPPER(TRIM("M"."LUGARMOV_020"))||UPPER("M"."TIPO_020")||TO_CHAR(INTERNAL
_FUNCTION("M"."FECHA_020"),'YYYYMMDDHH24MI')||"M"."CEDULA_REL" HAVING
MAX("M".ROWID)=:B2))
2 - access("CEDULA_REL"="CEDULA_REL")
3 - filter(LENGTH("NOMBRES_010")<=30 AND LENGTH("APELLIDOS_010")<=30
AND LENGTH("CEDULA_REL")<=15)
5 - filter("CEDULA_REL"=:B1 AND COUNT("CEDULA_REL")=1)
8 - filter(MAX("M".ROWID)=:B1)
10 - filter(("M"."TIPO_020"='E' OR "M"."TIPO_020"='S') AND
"M"."LUGARMOV_020" IS NOT NULL)
As you can see both plans are differents. I haven't much experience working with plans, any help will be appreciated.
--VIEWS
CREATE VIEW V_MOVIMIENTO_NO_DUPLICADO SELECT "CEDULA_REL",
"TIPO_020",
"FECHA_020",
"LUGARMOV_020",
"CLM_020",
"TRASLADO_020",
"RESPALDADO",
"ESTADIA",
"DIRECCION",
"FECHA_LETRA",
"HORA_SERVER",
"USUARIO"
FROM movimiento m
WHERE m.ROWID IN ( SELECT MAX (m.ROWID) fila
FROM movimiento m
WHERE M.lugarmov_020 IS NOT NULL
AND M.tipo_020 IN ('E', 'S')
GROUP BY UPPER (TRIM (M.lugarmov_020))
|| UPPER (M.tipo_020)
|| TO_CHAR (M.fecha_020, 'YYYYMMDDHH24MI')
|| M.CEDULA_REL)
CREATE VIEW V_PERSONAS_NO_DUPLICADAS SELECT CEDULA_REL,
NOMBRES_010,
APELLIDOS_010,
FECHANAC_010,
NACIONALIDAD_010,
TVIAJERO_010,
RESPALDADO,
RESIDENCIA,
SEXO,
FREGISTRO,
PC,
USUARIO,
USERUPDATE,
DATEUPDATE
FROM persona P1
WHERE cedula_rel IN ( SELECT cedula_rel
FROM persona P2
GROUP BY cedula_rel
HAVING COUNT (cedula_rel) = 1)
--Plans after indexes were added:
Fastest Query: (taking 12 secs more)
---------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 261 | 133 (4)| 00:00:02 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 1 | 261 | 29 (7)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 114 | 26 (8)| 00:00:01 |
| 4 | VIEW | VW_NSO_1 | 56 | 1792 | 23 (5)| 00:00:01 |
|* 5 | FILTER | | | | | |
| 6 | HASH GROUP BY | | 1 | 672 | 23 (5)| 00:00:01 |
| 7 | TABLE ACCESS FULL | CLM010A | 5532 | 66384 | 22 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID| CLM010A | 1 | 82 | 2 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | IDX_CEDULA_REL | 1 | | 1 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | IDX_CEDULA_REL_2 | 2 | | 1 (0)| 00:00:01 |
|* 11 | FILTER | | | | | |
| 12 | HASH GROUP BY | | 108 | 4752 | 104 (2)| 00:00:02 |
|* 13 | TABLE ACCESS FULL | CLM020A | 10734 | 461K| 102 (0)| 00:00:02 |
| 14 | TABLE ACCESS BY INDEX ROWID | CLM020A | 1 | 147 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
5 - filter(COUNT("CEDULA_REL")=1)
8 - filter(LENGTH("NOMBRES_010")<=30)
9 - access("CEDULA_REL"="CEDULA_REL")
filter(LENGTH("CEDULA_REL")<=15)
10 - access("CEDULA_REL"="CEDULA_REL")
filter( EXISTS (SELECT 0 FROM "LIMOV"."CLM020A" "M" WHERE ("M"."TIPO_020"='E' OR
"M"."TIPO_020"='S') AND "M"."LUGARMOV_020" IS NOT NULL GROUP BY
UPPER(TRIM("M"."LUGARMOV_020"))||UPPER("M"."TIPO_020")||TO_CHAR(INTERNAL_FUNCTION("M"."FECH
A_020"),'YYYYMMDDHH24MI')||"M"."CEDULA_REL" HAVING MAX("M".ROWID)=:B1))
11 - filter(MAX("M".ROWID)=:B1)
13 - filter(("M"."TIPO_020"='E' OR "M"."TIPO_020"='S') AND "M"."LUGARMOV_020" IS NOT
NULL)
Slowest Query:(canceled at 2 mins)
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 241 | 116 (3)| 00:00:02 |
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 1 | 241 | 116 (3)| 00:00:02 |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1 | 241 | 11 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 94 | 8 (0)| 00:00:01 |
|* 6 | TABLE ACCESS BY INDEX ROWID| CLM010A | 1 | 82 | 7 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | IDX_CEDULA_LEN | 50 | | 2 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | IDX_CEDULA_REL | 1 | 12 | 1 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | IDX_CEDULA_REL_2 | 2 | | 1 (0)| 00:00:01 |
|* 10 | FILTER | | | | | |
| 11 | HASH GROUP BY | | 108 | 4752 | 104 (2)| 00:00:02 |
|* 12 | TABLE ACCESS FULL | CLM020A | 10734 | 461K| 102 (0)| 00:00:02 |
| 13 | TABLE ACCESS BY INDEX ROWID | CLM020A | 1 | 147 | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(COUNT("CEDULA_REL")=1)
6 - filter(LENGTH("NOMBRES_010")<=30 AND LENGTH("APELLIDOS_010")<=30)
7 - access(LENGTH("CEDULA_REL")<=15)
8 - access("CEDULA_REL"="CEDULA_REL")
9 - access("CEDULA_REL"="CEDULA_REL")
filter( EXISTS (SELECT 0 FROM "LIMOV"."CLM020A" "M" WHERE ("M"."TIPO_020"='E' OR
"M"."TIPO_020"='S') AND "M"."LUGARMOV_020" IS NOT NULL GROUP BY
UPPER(TRIM("M"."LUGARMOV_020"))||UPPER("M"."TIPO_020")||TO_CHAR(INTERNAL_FUNCTION("M"."FECHA_
020"),'YYYYMMDDHH24MI')||"M"."CEDULA_REL" HAVING MAX("M".ROWID)=:B1))
10 - filter(MAX("M".ROWID)=:B1)
12 - filter(("M"."TIPO_020"='E' OR "M"."TIPO_020"='S') AND "M"."LUGARMOV_020" IS NOT NULL)
I solved the problem changing the order of the views in the join, then the execution plan changes, and filters changes drastically.
Slowest query:
SELECT *
FROM v_movimiento_no_duplicado
INNER JOIN v_personas_no_duplicadas USING (cedula_rel)
WHERE LENGTH (nombres_010) <= 30
AND LENGTH (apellidos_010) <= 30
AND LENGTH (cedula_rel) <= 15;
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 229 | 252 (2)| 00:00:04 |
|* 1 | FILTER | | | | | |
|* 2 | HASH JOIN | | 1 | 229 | 125 (1)| 00:00:02 |
|* 3 | TABLE ACCESS FULL | CLM010A | 1 | 82 | 22 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL | CLM020A | 10734 | 1540K| 102 (0)| 00:00:02 |
|* 5 | FILTER | | | | | |
| 6 | HASH GROUP BY | | 1 | 12 | 23 (5)| 00:00:01 |
| 7 | TABLE ACCESS FULL| CLM010A | 5532 | 66384 | 22 (0)| 00:00:01 |
|* 8 | FILTER | | | | | |
| 9 | HASH GROUP BY | | 108 | 4752 | 104 (2)| 00:00:02 |
|* 10 | TABLE ACCESS FULL| CLM020A | 10734 | 461K| 102 (0)| 00:00:02 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( EXISTS (SELECT 0 FROM "LIMOV"."CLM010A" "P2" GROUP BY
"CEDULA_REL" HAVING "CEDULA_REL"=:B1 AND COUNT("CEDULA_REL")=1) AND
EXISTS (SELECT 0 FROM "LIMOV"."CLM020A" "M" WHERE ("M"."TIPO_020"='E'
OR "M"."TIPO_020"='S') AND "M"."LUGARMOV_020" IS NOT NULL GROUP BY
UPPER(TRIM("M"."LUGARMOV_020"))||UPPER("M"."TIPO_020")||TO_CHAR(INTERNAL
_FUNCTION("M"."FECHA_020"),'YYYYMMDDHH24MI')||"M"."CEDULA_REL" HAVING
MAX("M".ROWID)=:B2))
2 - access("CEDULA_REL"="CEDULA_REL")
3 - filter(LENGTH("NOMBRES_010")<=30 AND LENGTH("APELLIDOS_010")<=30
AND LENGTH("CEDULA_REL")<=15)
5 - filter("CEDULA_REL"=:B1 AND COUNT("CEDULA_REL")=1)
8 - filter(MAX("M".ROWID)=:B1)
10 - filter(("M"."TIPO_020"='E' OR "M"."TIPO_020"='S') AND
"M"."LUGARMOV_020" IS NOT NULL)
Check that filter 1 looks to be a bit expensive. When i changed the order of views it just disappear.
SELECT *
FROM v_personas_no_duplicadas
INNER JOIN v_movimiento_no_duplicado USING (cedula_rel)
WHERE LENGTH (nombres_010) <= 30
AND LENGTH (apellidos_010) <= 30
AND LENGTH (cedula_rel) <= 15;
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 14 | 3822 | 253 (2)| 00:00:04 |
|* 1 | HASH JOIN SEMI | | 14 | 3822 | 253 (2)| 00:00:04 |
|* 2 | HASH JOIN | | 14 | 3374 | 229 (2)| 00:00:03 |
|* 3 | HASH JOIN | | 14 | 3206 | 125 (1)| 00:00:02 |
|* 4 | TABLE ACCESS FULL | CLM010A | 14 | 1148 | 22 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | CLM020A | 537 | 78939 | 102 (0)| 00:00:02 |
| 6 | VIEW | VW_NSO_1 | 10734 | 125K| 104 (2)| 00:00:02 |
| 7 | HASH GROUP BY | | 10734 | 461K| 104 (2)| 00:00:02 |
|* 8 | TABLE ACCESS FULL| CLM020A | 10734 | 461K| 102 (0)| 00:00:02 |
| 9 | VIEW | VW_NSO_2 | 56 | 1792 | 23 (5)| 00:00:01 |
|* 10 | FILTER | | | | | |
| 11 | HASH GROUP BY | | 1 | 672 | 23 (5)| 00:00:01 |
| 12 | TABLE ACCESS FULL| CLM010A | 5532 | 66384 | 22 (0)| 00:00:01 |
----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("CEDULA_REL"="CEDULA_REL")
2 - access("M".ROWID="FILA")
3 - access("CEDULA_REL"="CEDULA_REL")
4 - filter(LENGTH("NOMBRES_010")<=30 AND LENGTH("APELLIDOS_010")<=30)
5 - filter(LENGTH("CEDULA_REL")<=15)
8 - filter(("M"."TIPO_020"='E' OR "M"."TIPO_020"='S') AND
"M"."LUGARMOV_020" IS NOT NULL)
10 - filter(COUNT("CEDULA_REL")=1)
The scenerio
explain plan for
select l.etl_id , v.*
from v_load_base v, etl_log l
where l.is_active = 1
and v.ddate between trunc(l.load_from_date) and l.load_to_date
and v.starttime_full between l.load_from_date and l.load_to_date;
Produces this execution plan
--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 444 | | 31624 (4)| 00:06:20 |
| 1 | SORT ORDER BY | | 3 | 444 | | 31624 (4)| 00:06:20 |
|* 2 | HASH JOIN | | 3 | 444 | | 31623 (4)| 00:06:20 |
| 3 | NESTED LOOPS OUTER | | 3 | 378 | | 31413 (4)| 00:06:17 |
|* 4 | HASH JOIN | | 3 | 348 | | 31410 (4)| 00:06:17 |
|* 5 | HASH JOIN | | 1252 | 118K| 2144K| 23428 (4)| 00:04:42 |
|* 6 | HASH JOIN | | 27786 | 1818K| | 764 (7)| 00:00:10 |
| 7 | NESTED LOOPS | | 8 | 264 | | 7 (0)| 00:00:01 |
|* 8 | TABLE ACCESS FULL | ETL_LOG | 1 | 21 | | 3 (0)| 00:00:01 |
|* 9 | TABLE ACCESS FULL | MD | 8 | 96 | | 4 (0)| 00:00:01 |
| 10 | TABLE ACCESS FULL | DS | 479K| 15M| | 748 (6)| 00:00:09 |
| 11 | TABLE ACCESS FULL | MDS | 7280K| 208M| | 7823 (5)| 00:01:34 |
| 12 | TABLE ACCESS FULL | TASKS | 7760K| 140M| | 7844 (5)| 00:01:35 |
| 13 | TABLE ACCESS BY INDEX ROWID| ETL_GIS | 1 | 10 | | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | ETL_GIS_UK | 1 | | | 0 (0)| 00:00:01 |
| 15 | TABLE ACCESS FULL | DETAILS_TABLE | 292K| 6280K| | 204 (8)| 00:00:03 |
--------------------------------------------------------------------------------------------------------
The join predicate with the table etl_log was pushed down to the view v_load_base (line 8).
I created a view called v_load_base_active based on the same exact query as the one above.
Querying the new view produces the following plan
explain plan for select * from v_load_base_active;
----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 861 | | 63583 (8)| 00:12:43 |
| 1 | NESTED LOOPS | | 3 | 861 | | 63583 (8)| 00:12:43 |
|* 2 | TABLE ACCESS FULL | ETL_LOG | 1 | 21 | | 3 (0)| 00:00:01 |
|* 3 | VIEW | V_LOAD_BASE | 3 | 798 | | 63580 (8)| 00:12:43 |
| 4 | SORT ORDER BY | | 422K| 51M| 110M| 63580 (8)| 00:12:43 |
|* 5 | HASH JOIN RIGHT OUTER | | 422K| 51M| | 51513 (9)| 00:10:19 |
| 6 | TABLE ACCESS FULL | ETL_GIS | 5958 | 59580 | | 17 (0)| 00:00:01 |
|* 7 | HASH JOIN | | 422K| 47M| 9712K| 51488 (9)| 00:10:18 |
| 8 | TABLE ACCESS FULL | LINES_DETAILS | 292K| 6280K| | 204 (8)| 00:00:03 |
|* 9 | HASH JOIN | | 422K| 38M| 35M| 48647 (10)| 00:09:44 |
|* 10 | HASH JOIN | | 422K| 30M| | 27365 (14)| 00:05:29 |
| 11 | TABLE ACCESS FULL | MD | 3103 | 37236 | | 4 (0)| 00:00:01 |
|* 12 | HASH JOIN | | 7301K| 445M| 21M| 24366 (3)| 00:04:53 |
| 13 | TABLE ACCESS FULL| DS | 479K| 15M| | 748 (6)| 00:00:09 |
| 14 | TABLE ACCESS FULL| MSD | 7280K| 208M| | 7823 (5)| 00:01:34 |
| 15 | TABLE ACCESS FULL | TASKS | 7760K| 140M| | 7844 (5)| 00:01:35 |
----------------------------------------------------------------------------------------------------
The predicate is not pushed. This leads to a major decrease in performance.
I've tried setting a hint explicitly in the view /*+ PUSH_PRED(v) */ but the plan does not change.
How can i make the optimizer push the predicate also within a view ... ?
v_load_base does not contain analytic functions. The first query proves that the predicate can be pushed.
EDIT
notice that oracle does not state in the execution plan that a predicate was pushed with VIEW PUSHED PREDICATE. but, looking at the plan it's clear that oracle transformed the view's sql to include the etl_log predicate.
I doubt that it was pushing predicate in the first case, because it would be in the plan. More likely it was merging which is controlled by MERGE/NO_MERGE hints. See example below.
With NO_MERGE:
SQL> explain plan for
2 select /*+NO_MERGE(so)*/ *
3 from siebel.s_org_ext soe,
4 (select sx.attrib_08, s.*
5 from siebel.s_opty s
6 inner join siebel.s_opty_x sx on s.row_id = sx.row_id) so
7 where soe.row_id = so.pr_dept_ou_id
8 and soe.row_id like '1-8ZT%'
9 and so.db_last_upd between soe.db_last_upd and soe.db_last_upd - 365;
Explained
SQL> select * from table(dbms_xplan.display);
Plan hash value: 1802470607
---------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13258 | 55 (2)| 00:00:01 |
|* 1 | HASH JOIN | | 1 | 13258 | 55 (2)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| S_ORG_EXT | 1 | 1047 | 3 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | S_ORG_EXT_P1 | 1 | | 2 (0)| 00:00:01 |
| 4 | VIEW | | 1084 | 12M| 52 (2)| 00:00:01 |
|* 5 | HASH JOIN | | 1084 | 528K| 52 (2)| 00:00:01 |
| 6 | TABLE ACCESS FULL | S_OPTY_X | 1573 | 15730 | 17 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | S_OPTY | 1084 | 517K| 34 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
With MERGE:
SQL> explain plan for
2 select /*+MERGE(so)*/*
3 from siebel.s_org_ext soe,
4 (select sx.attrib_08, s.*
5 from siebel.s_opty s
6 inner join siebel.s_opty_x sx on s.row_id = sx.row_id) so
7 where soe.row_id = so.pr_dept_ou_id
8 and soe.row_id like '1-8ZT%'
9 and so.db_last_upd between soe.db_last_upd and soe.db_last_upd - 365;
Explained
SQL> select * from table(dbms_xplan.display);
Plan hash value: 4111959163
----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1546 | 6 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 1 | 1546 | 6 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 1 | 1536 | 5 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| S_ORG_EXT | 1 | 1047 | 3 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | S_ORG_EXT_P1 | 1 | | 2 (0)| 00:00:01 |
|* 5 | TABLE ACCESS BY INDEX ROWID| S_OPTY | 1 | 489 | 2 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | S_OPTY_M64_X | 1 | | 1 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | S_OPTY_X | 1 | 10 | 1 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | S_OPTY_X_P1 | 1 | | 0 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------
So try to force optimizer use merging with you view and see if plan changes.