SQL Tuning - Explain plan analysis
Dear Experts,
In my 11.1.0.7 DB, I'm trying to figure out why one of my NEW ETL job (INSERT statement) in UAT is taking longer. I see same job in UNIT envt runs fairly quicker.
UAT run time > 5Hrs to insert 1.1 million records, UNIT run time < 10 mins to insert 750K records
I ran tuning advisor and have accepted the only recommendation, SQL profile that was shown to have 99% benefit and still see run time is over 5 hours (with or without SQLprofile). I have compared the explain plans in UAT and UNIT envt which are similar and also have same plan_hash_value. Explain plans are shared below:
It's obvious from UAT plan that NESTED LOOPS OUTER, HASH JOIN RIGHT OUTER are the one taking lot of CPU and time for operation execution.
Please share your inputs as to how this can be diagnosed. Thanks a lot..
UNIT ENVT
==========
PLAN_TABLE_OUTPUT
Plan hash value: 891903485
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | 4739K| 646M| | 85917 (1)| 00:19:12 |
| 1 | LOAD TABLE CONVENTIONAL | F_DRV_FUEL_W | | | | | |
| 2 | HASH UNIQUE | | 4739K| 646M| 726M| 85917 (1)| 00:19:12 |
|* 3 | HASH JOIN RIGHT OUTER | | 4739K| 646M| | 7881 (3)| 00:01:46 |
| 4 | VIEW | | 20936 | 756K| | 1456 (1)| 00:00:20 |
|* 5 | HASH JOIN RIGHT OUTER | | 10468 | 572K| | 594K (5)| 02:12:51 |
| 6 | TABLE ACCESS FULL | X_SNI_TRK_STP_P | 2754 | 33048 | | 5 (0)| 00:00:01 |
| 7 | NESTED LOOPS OUTER | | 10468 | 449K| | 594K (5)| 02:12:51 |
| 8 | TABLE ACCESS FULL | X_SNI_FUEL_CMPLY_DTL_P | 10468 | 184K| | 14 (0)| 00:00:01 |
| 9 | VIEW | | 1 | 26 | | 57 (6)| 00:00:01 |
|* 10 | FILTER | | | | | | |
|* 11 | HASH JOIN | | 1 | 59 | | 57 (6)| 00:00:01 |
|* 12 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 1 | 28 | | 27 (0)| 00:00:01 |
|* 13 | VIEW | | 17659 | 534K| | 29 (7)| 00:00:01 |
|* 14 | WINDOW SORT PUSHED RANK| | 17659 | 448K| | 29 (7)| 00:00:01 |
| 15 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 17659 | 448K| | 27 (0)| 00:00:01 |
|* 16 | HASH JOIN RIGHT OUTER | | 4739K| 479M| 14M| 6404 (3)| 00:01:26 |
|* 17 | TABLE ACCESS FULL | XO_E_PER_ASSIGNMENT_P | 276K| 11M| | 2616 (2)| 00:00:36 |
|* 18 | HASH JOIN | | 699K| 42M| 20M| 2704 (3)| 00:00:37 |
|* 19 | TABLE ACCESS FULL | X_SNI_FUEL_PUR_TXN_PRD_P | 702K| 12M| | 536 (3)| 00:00:08 |
|* 20 | TABLE ACCESS FULL | X_SNI_FUEL_PUR_TXN_P | 695K| 30M| | 1202 (3)| 00:00:17 |
Predicate Information (identified by operation id):
3 - access("X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_CMPLY_DTL_P"."FUEL_PUR_TXN_ID"(+))
5 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PRVD_TRK_STP_CD"="X_SNI_TRK_STP_P"."CMDTA_CD"(+))
10 - filter("X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" IS NOT NULL)
11 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_STP_DTL_ID"="PLN_STP_DTL_ID" AND
"X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="PWR_NUM" AND "X_SNI_FUEL_PLN_STP_DTL_P"."PLN_GAL_QTY"="PLN_GAL_QTY")
12 - filter("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_DTTM"="X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" AND
"X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="X_SNI_FUEL_CMPLY_DTL_P"."PWR_NUM")
13 - filter("R1"=1)
14 - filter(ROW_NUMBER() OVER ( PARTITION BY "PWR_NUM","PLN_DTTM" ORDER BY
INTERNAL_FUNCTION("PLN_STP_DTL_ID") DESC )<=1)
16 - access("X_SNI_FUEL_PUR_TXN_P"."DRV_NUM"="XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+))
filter("X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM"<="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_END_DT"(+) AND
"X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM">="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_STRT_DT"(+))
17 - filter("XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+) IS NOT NULL AND "XO_E_PER_ASSIGNMENT_P"."PS_CURR_IND"(+)=1
AND "XO_E_PER_ASSIGNMENT_P"."ACTV_EMP_IND"(+)=1 AND "XO_E_PER_ASSIGNMENT_P"."PRSN_TYP_RNK_NUM"(+)=1)
18 - access("X_SNI_FUEL_PUR_TXN_PRD_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID")
19 - filter("X_SNI_FUEL_PUR_TXN_PRD_P"."PS_CURR_IND"=1)
20 - filter("X_SNI_FUEL_PUR_TXN_P"."PS_CURR_IND"=1)
49 rows selected.
UAT ENVT
=========
PLAN_TABLE_OUTPUT
Plan hash value: 891903485
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | 998K| 139M| | 34826 (1)| 00:07:47 |
| 1 | LOAD TABLE CONVENTIONAL | F_DRV_FUEL_W | | | | | |
| 2 | HASH UNIQUE | | 998K| 139M| 157M| 34826 (1)| 00:07:47 |
|* 3 | HASH JOIN RIGHT OUTER | | 998K| 139M| 44M| 18001 (2)| 00:04:02 |
| 4 | VIEW | | 931K| 33M| | 4250 (1)| 00:00:57 |
|* 5 | HASH JOIN RIGHT OUTER | | 62082 | 3576K| | 25M (2)| 96:08:31 |
| 6 | TABLE ACCESS FULL | X_SNI_TRK_STP_P | 5603 | 61633 | | 10 (0)| 00:00:01 |
| 7 | NESTED LOOPS OUTER | | 30548 | 1431K| | 25M (2)| 96:08:31 |
| 8 | TABLE ACCESS FULL | X_SNI_FUEL_CMPLY_DTL_P | 30548 | 715K| | 46 (3)| 00:00:01 |
| 9 | VIEW | | 1 | 24 | | 845 (2)| 00:00:12 |
|* 10 | FILTER | | | | | | |
|* 11 | HASH JOIN | | 1 | 57 | | 845 (2)| 00:00:12 |
|* 12 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 1 | 29 | | 150 (2)| 00:00:03 |
|* 13 | VIEW | | 151K| 4155K| | 694 (2)| 00:00:10 |
|* 14 | WINDOW SORT PUSHED RANK| | 151K| 3413K| 5376K| 694 (2)| 00:00:10 |
| 15 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 151K| 3413K| | 150 (2)| 00:00:03 |
|* 16 | HASH JOIN RIGHT OUTER | | 998K| 103M| 15M| 11138 (2)| 00:02:30 |
|* 17 | TABLE ACCESS FULL | XO_E_PER_ASSIGNMENT_P | 296K| 11M| | 5060 (2)| 00:01:08 |
|* 18 | HASH JOIN | | 1028K| 65M| 31M| 4555 (3)| 00:01:02 |
|* 19 | TABLE ACCESS FULL | X_SNI_FUEL_PUR_TXN_PRD_P | 1037K| 19M| | 1000 (2)| 00:00:14 |
|* 20 | TABLE ACCESS FULL | X_SNI_FUEL_PUR_TXN_P | 1020K| 45M| | 2088 (3)| 00:00:28 |
Predicate Information (identified by operation id):
3 - access("X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_CMPLY_DTL_P"."FUEL_PUR_TXN_ID"(+))
5 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PRVD_TRK_STP_CD"="X_SNI_TRK_STP_P"."CMDTA_CD"(+))
10 - filter("X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" IS NOT NULL)
11 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_STP_DTL_ID"="PLN_STP_DTL_ID" AND
"X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="PWR_NUM" AND "X_SNI_FUEL_PLN_STP_DTL_P"."PLN_GAL_QTY"="PLN_GAL_QTY")
12 - filter("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_DTTM"="X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" AND
"X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="X_SNI_FUEL_CMPLY_DTL_P"."PWR_NUM")
13 - filter("R1"=1)
14 - filter(ROW_NUMBER() OVER ( PARTITION BY "PWR_NUM","PLN_DTTM" ORDER BY
INTERNAL_FUNCTION("PLN_STP_DTL_ID") DESC )<=1)
16 - access("X_SNI_FUEL_PUR_TXN_P"."DRV_NUM"="XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+))
filter("X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM"<="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_END_DT"(+) AND
"X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM">="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_STRT_DT"(+))
17 - filter("XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+) IS NOT NULL AND
"XO_E_PER_ASSIGNMENT_P"."ACTV_EMP_IND"(+)=1 AND "XO_E_PER_ASSIGNMENT_P"."PS_CURR_IND"(+)=1 AND
"XO_E_PER_ASSIGNMENT_P"."PRSN_TYP_RNK_NUM"(+)=1)
18 - access("X_SNI_FUEL_PUR_TXN_PRD_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID")
19 - filter("X_SNI_FUEL_PUR_TXN_PRD_P"."PS_CURR_IND"=1)
20 - filter("X_SNI_FUEL_PUR_TXN_P"."PS_CURR_IND"=1)
Note
- SQL profile "SYS_SQLPROF_0139a0175fb30006" used for this statement
Ora DBA wrote:
Dear Experts,
In my 11.1.0.7 DB, I'm trying to figure out why one of my NEW ETL job (INSERT statement) in UAT is taking longer. I see same job in UNIT envt runs fairly quicker.
UAT run time > 5Hrs to insert 1.1 million records, UNIT run time < 10 mins to insert 750K records
I ran tuning advisor and have accepted the only recommendation, SQL profile that was shown to have 99% benefit and still see run time is over 5 hours (with or without SQLprofile). I have compared the explain plans in UAT and UNIT envt which are similar and also have same plan_hash_value. Explain plans are shared below:
It's obvious from UAT plan that NESTED LOOPS OUTER, HASH JOIN RIGHT OUTER are the one taking lot of CPU and time for operation execution.
Please share your inputs as to how this can be diagnosed. Thanks a lot..As a first step towards diagnosis, I would check following:
1) First step would be to isolate the problem. So you may want to verify if the SELECT part or the INSERT part is contributing more to run-time (It looks like the SELECT part but always good to confirm). That way, you can concentrate on, for e.g., tuning only SELECT part.
2) When trying to compare the runtime from 2 environments, ensure that you are using almost similar (if not same) data volumes and same tables/index structures
3) As both environments produce same plan, presumably the tables involved have similar pattern of statistics. But the actual data volume may be quite different. So check whether statistics are representative of actual data
4) Fortunately, your plan uses all FULL TABLE ACCESS and HASH JOIN (except one NESTED LOOP). So for a query that runs for more than 5 hours, you should be able to monitor individual steps using v$session_longops. As you are on 11G, you may also make use of Real-time SQL monitoring.
5) While it is not possible to decisively conclude anything based on EXPLAIN PLAN output, you may want to compare the PGA settings and TEMP file disk I/O capabilities of both environments. For e.g. in UNIT env, all the HASH JOINS that spill to disk are expected to be completed quicker than the corresponding HASH JOINS on UAT env. (Again, same volume of data would benefit the comparison here).
6) You may want to get rid of any HINTs used to check how CBO decides to process the query when left on its own.
7) Last but not the least, you may want to check the table design, especially as this query appears to involve lots of outer joins and analytical functions. Difficult to say anything conclusive without knowing the query but the following part of the plan suggests that there might be an opportunity to validate the logic used.
| 9 | VIEW | | 1 | 26 | | 57 (6)| 00:00:01 |
|* 10 | FILTER | | | | | | |
|* 11 | HASH JOIN | | 1 | 59 | | 57 (6)| 00:00:01 |
|* 12 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 1 | 28 | | 27 (0)| 00:00:01 |
|* 13 | VIEW | | 17659 | 534K| | 29 (7)| 00:00:01 |
|* 14 | WINDOW SORT PUSHED RANK| | 17659 | 448K| | 29 (7)| 00:00:01 |
| 15 | TABLE ACCESS FULL | X_SNI_FUEL_PLN_STP_DTL_P | 17659 | 448K| | 27 (0)| 00:00:01 |This looks like a self-join of a table with itself, combined with usage of analytic function. Both might not be necessary and may be re-written to either avoid self-join or the analytic function part or replace them with a simpler query, which, in turn may impact the CBO's choice of subsequent NESTED LOOP join.
Hope this helps.
Similar Messages
-
Query needs tuning; Explain plan attached
DB version:10gR2
Currently, the below query is taking more than 28 secs to complete. The table stats are up-to-date.
Is there a way to rewrite/tune this query?
SELECT DISTINCT TASK_HDR.TASK_ID,
TASK_HDR.WHSE,
TASK_HDR.TASK_DESC,
TASK_HDR.INVN_TYPE,
TASK_HDR.INVN_NEED_TYPE,
TASK_HDR.DFLT_TASK_PRTY,
TASK_HDR.CURR_TASK_PRTY,
TASK_HDR.XPECTD_DURTN,
TASK_HDR.ACTL_DURTN,
TASK_HDR.ERLST_START_DATE_TIME,
TASK_HDR.LTST_START_DATE_TIME,
TASK_HDR.LTST_CMPL_DATE_TIME,
TASK_HDR.BEGIN_AREA,
TASK_HDR.BEGIN_ZONE,
TASK_HDR.BEGIN_AISLE,
TASK_HDR.END_AREA,
TASK_HDR.END_ZONE,
TASK_HDR.END_AISLE,
TASK_HDR.START_CURR_WORK_GRP,
TASK_HDR.START_CURR_WORK_AREA,
TASK_HDR.END_CURR_WORK_GRP,
TASK_HDR.END_CURR_WORK_AREA,
TASK_HDR.START_DEST_WORK_GRP,
TASK_HDR.START_DEST_WORK_AREA,
TASK_HDR.END_DEST_WORK_GRP,
TASK_HDR.END_DEST_WORK_AREA,
TASK_HDR.TASK_TYPE,
TASK_HDR.TASK_GENRTN_REF_CODE,
TASK_HDR.TASK_GENRTN_REF_NBR,
TASK_HDR.NEED_ID,
TASK_HDR.TASK_BATCH,
TASK_HDR.STAT_CODE,
TASK_HDR.CREATE_DATE_TIME,
TASK_HDR.MOD_DATE_TIME,
TASK_HDR.USER_ID,
TASK_HDR.RLS_DATE_TIME,
TASK_HDR.SKU_ID,
TASK_HDR.TASK_CMPL_REF_CODE,
TASK_HDR.TASK_CMPL_REF_NBR,
TASK_HDR.OWNER_USER_ID,
TASK_HDR.ONE_USER_PER_GRP,
TASK_HDR.NEXT_TASK_ID,
TASK_HDR.EXCEPTION_CODE,
TASK_HDR.CURR_LOCN_ID,
TASK_HDR.TASK_PARM_ID,
TASK_HDR.RULE_ID,
TASK_HDR.VOCOLLECT_ASSIGN_ID,
TASK_HDR.CURR_USER_ID,
TASK_HDR.MHE_FLAG,
TASK_HDR.PICK_TO_TOTE_FLAG,
TASK_HDR.MHE_ORD_STATE,
TASK_HDR.PRT_TASK_LIST_FLAG,
TASK_HDR.RPT_PRTR_REQSTR,
TASK_HDR.ORIG_TASK_ID
FROM INVN_NEED_TYPE, TASK_DTL, TASK_HDR
WHERE (TASK_HDR.TASK_ID = TASK_DTL.TASK_ID(+))
AND TASK_HDR.WHSE = '01' AND TASK_HDR.STAT_CODE >= 99 AND
TASK_HDR.INVN_NEED_TYPE = INVN_NEED_TYPE.INVN_NEED_TYPE AND
INVN_NEED_TYPE.WHSE = TASK_HDR.WHSE AND
(INVN_NEED_TYPE.CO = '88') AND (INVN_NEED_TYPE.DIV = '51') AND
(TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1) AND
TASK_HDR.MOD_DATE_TIME <= sysdate-85
ORDER BY TASK_HDR.CREATE_DATE_TIME DESC
The explain plan:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 10032 | 1969K| | 3143 (2)|
| 1 | SORT ORDER BY | | 10032 | 1969K| 4232K| 3143 (2)|
| 2 | HASH UNIQUE | | 10032 | 1969K| 4232K| 2689 (2)|
| 3 | FILTER | | | | | |
| 4 | NESTED LOOPS OUTER | | 10032 | 1969K| | 2235 (1)|
| 5 | NESTED LOOPS | | 3226 | 570K| | 284 (3)|
| 6 | TABLE ACCESS BY INDEX ROWID| TASK_HDR | 3412 | 559K| | 282 (2)|
| 7 | INDEX RANGE SCAN | TASK_HDR_IND_3 | 9042 | | | 8 (13)|
| 8 | INDEX UNIQUE SCAN | PK_INVN_NEED_TYPE | 1 | 13 | | 1 (0)|
| 9 | TABLE ACCESS BY INDEX ROWID | TASK_DTL | 3 | 60 | | 1 (0)|
| 10 | INDEX RANGE SCAN | PK_TASK_DTL | 3 | | | 1 (0)|
---------------------------------------------------------------------------------------------------My apologies, yes, it is:
SELECT TASK_HDR.TASK_ID,
TASK_HDR.WHSE,
TASK_HDR.TASK_DESC,
TASK_HDR.INVN_TYPE,
TASK_HDR.INVN_NEED_TYPE,
TASK_HDR.DFLT_TASK_PRTY,
TASK_HDR.CURR_TASK_PRTY,
TASK_HDR.XPECTD_DURTN,
TASK_HDR.ACTL_DURTN,
TASK_HDR.ERLST_START_DATE_TIME,
TASK_HDR.LTST_START_DATE_TIME,
TASK_HDR.LTST_CMPL_DATE_TIME,
TASK_HDR.BEGIN_AREA,
TASK_HDR.BEGIN_ZONE,
TASK_HDR.BEGIN_AISLE,
TASK_HDR.END_AREA,
TASK_HDR.END_ZONE,
TASK_HDR.END_AISLE,
TASK_HDR.START_CURR_WORK_GRP,
TASK_HDR.START_CURR_WORK_AREA,
TASK_HDR.END_CURR_WORK_GRP,
TASK_HDR.END_CURR_WORK_AREA,
TASK_HDR.START_DEST_WORK_GRP,
TASK_HDR.START_DEST_WORK_AREA,
TASK_HDR.END_DEST_WORK_GRP,
TASK_HDR.END_DEST_WORK_AREA,
TASK_HDR.TASK_TYPE,
TASK_HDR.TASK_GENRTN_REF_CODE,
TASK_HDR.TASK_GENRTN_REF_NBR,
TASK_HDR.NEED_ID,
TASK_HDR.TASK_BATCH,
TASK_HDR.STAT_CODE,
TASK_HDR.CREATE_DATE_TIME,
TASK_HDR.MOD_DATE_TIME,
TASK_HDR.USER_ID,
TASK_HDR.RLS_DATE_TIME,
TASK_HDR.SKU_ID,
TASK_HDR.TASK_CMPL_REF_CODE,
TASK_HDR.TASK_CMPL_REF_NBR,
TASK_HDR.OWNER_USER_ID,
TASK_HDR.ONE_USER_PER_GRP,
TASK_HDR.NEXT_TASK_ID,
TASK_HDR.EXCEPTION_CODE,
TASK_HDR.CURR_LOCN_ID,
TASK_HDR.TASK_PARM_ID,
TASK_HDR.RULE_ID,
TASK_HDR.VOCOLLECT_ASSIGN_ID,
TASK_HDR.CURR_USER_ID,
TASK_HDR.MHE_FLAG,
TASK_HDR.PICK_TO_TOTE_FLAG,
TASK_HDR.MHE_ORD_STATE,
TASK_HDR.PRT_TASK_LIST_FLAG,
TASK_HDR.RPT_PRTR_REQSTR,
TASK_HDR.ORIG_TASK_ID
FROM INVN_NEED_TYPE,TASK_HDR
WHERE TASK_HDR.WHSE = '01' AND TASK_HDR.STAT_CODE >= 99 AND
TASK_HDR.INVN_NEED_TYPE = INVN_NEED_TYPE.INVN_NEED_TYPE AND
INVN_NEED_TYPE.WHSE = TASK_HDR.WHSE AND
(INVN_NEED_TYPE.CO = '88') AND (INVN_NEED_TYPE.DIV = '51') AND
TASK_HDR.MOD_DATE_TIME <= sysdate-85
AND EXISTS (SELECT 1
FROM TASK_DTL
WHERE TASK_HDR.TASK_ID = TASK_DTL.TASK_ID
AND (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1))
ORDER BY TASK_HDR.CREATE_DATE_TIME DESCAlthough you have an OUTER JOIN on TASK_DTL.TASK_ID, this is converted to an INNER JOIN with (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1), which is the equivalent of the 'EXISTS' version above.
I haven't been able to test this. -
Hii all,
I have tuned one query by using SQL Tuning Advisor in SQL Developer Tool. I have seen much improvement in Explain plan in advisor .. After tuning finished i executed following script.
{code}
select dbms_sqltune.report_tuning_task('staName47421') as Rems
from dual;
{code}
I seen an explain plan but i am not able to see recommended changes in query .. Is it possible to get the query directly from any view ..
I tried and checked in many dynamic views by keeping plan_hash_value as reference .. I found records in some dynamic views like dba_sqltune_plans and dba_advisor_sqlstats but i am unable to find exact sqltext .. Kindly advice if possible to get that query .. My query was taking 17 mins but it got reduced to 2 mins by seeing sql tuned explain plan so i want to see as what are the changes been done .
Regards,
Nitesh.I would rather accept what is in the documentation:
"If a SQL profile is recommended, the database tests the new profile by executing the SQL statement both with and without the profile. If the performance improvement improves at least threefold, then the database accepts the SQL profile, but only if the ACCEPT_SQL_PROFILES task parameter is set to TRUE. Otherwise, the automatic SQL tuning reports merely report the recommendation to create a SQL profile." Automatic SQL Tuning
"If automatic implementation of SQL profiles is enabled (the default is disabled), then the database implements any SQL profiles that promise a great performance benefit. The implementation occurs at tuning time so that the database can immediately benefit from the new plan. You can enable or disable automatic implementation by using the SET_AUTO_TUNING_TASK_PARAMETER API to set the ACCEPT_SQL_PROFILES parameter." DBMS_AUTO_SQLTUNE -
Explain plan results are different in SQL Developer than SQL Plus
My Environment:
SQL Developer 1.0.0.15.27
Platform where SQL Developer is running: Windows XP 2002 SP2
Oracle Database and Client 9.2.0.7
Optimizer_mode: FIRST_ROWS
I have the following SQL statement:
SELECT a1.comp_id
FROM temp_au_company a0, au_company a1
WHERE :b2 = a0.temp_emp_code
AND a0.comp_id = a1.comp_id
AND a0.sls_terr_code != a1.sls_terr_code
AND a1.last_mdfy_date > :b1
When I run an Explain in SQL Developer I get the following access path (which is the one I really want):
SELECT STATEMENT TABLE ACCESS(BY INDEX ROWID) FEDLINK.AU_COMPANY NESTED LOOPS INDEX(RANGE SCAN)
FEDLINK.UX2_TEMP_AU_COMPANY
INDEX(RANGE SCAN) FEDLINK.PX1_COMPANY
However, when I execute the statement with sql_trace turned on and use tkprof to generate the actual access path, the statement executes as follows (which is WAY more expensive):
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 3.58 6.68 28136 29232 0 0
total 3 3.58 6.69 28136 29232 0 0
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 979 (FEDLINK) (recursive depth: 1)
Rows Row Source Operation
0 NESTED LOOPS
0 TABLE ACCESS FULL AU_COMPANY
0 INDEX RANGE SCAN UX2_TEMP_AU_COMPANY (object id 49783)
Notice the FULL access of au_company.
I understand that SQL Developer has nothing to do with why the statement executed the way it did, but why is the Explain in SQL Developer different than the actual execution plan?
Added note....when I run the explain in SQL Plus it is the same as the actual execution. Here is the explain from SQL Plus:
explain plan for SELECT a1.comp_id
FROM temp_au_company a0, au_company a1
WHERE '1' = a0.temp_emp_code
AND a0.comp_id = a1.comp_id
AND a0.sls_terr_code != a1.sls_terr_code
AND a1.last_mdfy_date > '01-MAY-2006';
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 76 | 2597 |
| 1 | NESTED LOOPS | | 2 | 76 | 2597 |
| 2 | TABLE ACCESS FULL | AU_COMPANY | 2 | 42 | 2595 |
| 3 | INDEX RANGE SCAN | UX2_TEMP_AU_COMPANY | 1 | 17 | 2
Thanks,
BrendaThe explain is different (full scan of au_company in SQL Plus / index access in SQL Developer) even when I use variables in SQL Plus. Here is the output for SQL Plus using variables instead of literals:
SQL> variable b1 varchar2
SQL> variable b2 char
SQL> explain plan for SELECT a1.comp_id
2 FROM temp_au_company a0, au_company a1
3 WHERE :b2 = a0.temp_emp_code
4 AND a0.comp_id = a1.comp_id
5 AND a0.sls_terr_code != a1.sls_terr_code
6 AND a1.last_mdfy_date > :b1
7 /
Explained.
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 3184 | 118K| 2995 |
| 1 | HASH JOIN | | 3184 | 118K| 2995 |
| 2 | INDEX RANGE SCAN | UX2_TEMP_AU_COMPANY | 3187 | 54179 | 3 |
| 3 | TABLE ACCESS FULL | AU_COMPANY | 24009 | 492K| 2983 |
Any other ideas? They should be the same.
Brenda -
Weird explain plan on multi-level structured XmlType column
Hello,
am running an explain on the follwing query on 11.2.0.2:
SELECT
T1.EVENT_ID,
ACTION_SUB_ID,
PARAM_KEY,
PARAM_VALUE,
TO_DATE('2013-12-10', 'YYYY-MM-DD')
FROM T_C_RMP_MNTRNG_XML_FULL_IL ,
XMLTABLE('/monitoring' PASSING XML_CONTENT COLUMNS
EVENT_ID VARCHAR2(4000) PATH 'eventId',
ACTIONS XMLTYPE PATH 'action'
) T1,
XMLTABLE('/action' PASSING T1.ACTIONS COLUMNS
ACTION_SUB_ID NUMBER(10,0) PATH 'actionSubId',
PARAMS xmltype PATH 'param'
) T2,
XMLTABLE('/param' PASSING T2.params columns
PARAM_KEY VARCHAR2(4000) PATH 'key',
PARAM_VALUE VARCHAR2(1000) PATH 'value'
) T3
WHERE MESSAGE_ID = 4972102 ;
Although MESSAGE_ID is the primary key of T_C_RMP_MNTRNG_XML_FULL_IL and thus there is only one record matching the condition, I get an explain plan with huge costs, 500MB of data and an estimated 10 hour runtime:
PLAN_TABLE_OUTPUT
Plan hash value: 4011854835
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 223K| 489M| 3111K (1)| 10:22:17 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 223K| 489M| 3111K (1)| 10:22:17 |
| 3 | NESTED LOOPS | | 140K| 11M| 1678 (1)| 00:00:21 |
|* 4 | INDEX RANGE SCAN | X1B | 1 | 53 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| T_OR_MON_ACTION | 140K| 4542K| 1675 (1)| 00:00:21 |
PLAN_TABLE_OUTPUT
|* 6 | INDEX RANGE SCAN | X3 | 140K| | 4 (25)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | X4G | 4083 | | 22 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | T_OR_MON_ACTION_PARAM | 2 | 4428 | 52 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - access("MESSAGE_ID"=4972102)
6 - access("SYS_ALIAS_0"."NESTED_TABLE_ID"="T_C_RMP_MNTRNG_XML_FULL_IL"."SYS_NC0001200013$")
7 - access("NESTED_TABLE_ID"="SYS_ALIAS_0"."SYS_NC0000500006$")
PLAN_TABLE_OUTPUT
Note
- dynamic sampling used for this statement (level=2)
When I run the query, the result comes back within 0.3 seconds.
Why is the explain plan off like that?
Is this just the way it is, or is there something going wrong here?This is my table create statement:
CREATE TABLE QQRCSBI0.T_C_RMP_MNTRNG_XML_FULL_IL (
MESSAGE_ID NUMBER(22,0) NOT NULL ENABLE,
XML_EVAL_ID NUMBER(22,0),
VIN7 VARCHAR2(7 BYTE),
FLEET_ID VARCHAR2(50 BYTE),
CSC_SW_VERSION VARCHAR2(100 BYTE),
RECEIVED DATE,
XML_CONTENT SYS.XMLTYPE ,
DWH_LM_TS_UTC DATE NOT NULL ENABLE,
CONSTRAINT PK_C_RMP_MNTRNG_XML_FULL_IL5 PRIMARY KEY (MESSAGE_ID)
) NOLOGGING TABLESPACE CATALOG
VARRAY "XML_CONTENT"."XMLDATA"."ACTION" STORE AS TABLE "T_OR_MON_ACTION" (
NOLOGGING TABLESPACE "CATALOG"
VARRAY "PARAM" STORE AS TABLE "T_OR_MON_ACTION_PARAM" (
NOLOGGING TABLESPACE "CATALOG"
) RETURN AS LOCATOR
) RETURN AS LOCATOR
XMLTYPE XML_CONTENT STORE AS OBJECT RELATIONAL XMLSCHEMA "http://mydomain.com/csc_monitoring_session.xsd" ELEMENT "monitoring";
I set all default table names in the schema to blank and registered the schema with genTables=false.
I am still running into problems retrieving the 3rd level T_OR_MON_ACTION_PARAM data. The query just crashes after a while because it is running out of either TEMP space or UNDO space (it keeps changing). I'll take a step back to re-evaluate and post another thread about that in a bit I guess...
You said "SQL*Plus explain plan, goes most of the time bananas" - is there a difference in what client (SqlPlus or SqlDeveloper) I use to get the explain plan? I thought the plan was generated by the DB and the clients just display the result, and the only difference is the way the clients display the plan?! -
Tuning needed for sql:EXPLAIN PLAN attached
DB Version:10gR2
The below sql was running slow, so i took an explain plan
SQL> explain plan for
2 SELECT COUNT(1) FROM SHIP_DTL WHERE
3 SHIP_DTL.PLT_ID = 'AM834'
4 AND SHIP_DTL.WHSE = '34' AND
5 SHIP_DTL.STAT_CODE != '845'
6 ORDER BY SHIP_DTL.LOAD_SEQ ASC;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 18 | 5 (20)|
| 1 | SORT AGGREGATE | | 1 | 18 | |
|* 2 | TABLE ACCESS BY INDEX ROWID| SHIP_DTL | 200 | 3600 | 5 (20)|
|* 3 | INDEX RANGE SCAN | SHIP_DTL_IND_4 | 203 | | 3 (0)|
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - filter("SHIP_DTL"."WHSE"='34' AND "SHIP_DTL"."STAT_CODE"<>845)
3 - access("SHIP_DTL"."PLT_ID"='AM834')Why is there an INDEX RANGE scan where there is no BETWEEN operator in the query? What are various options(indexes, rewriting query) in tuning this query?james_p wrote:
DB Version:10gR2
The below sql was running slow, so i took an explain planCheck your plan, the optimizer estimates that the following query:
select count(*)
from SHIP_DTL
where "SHIP_DTL"."PLT_ID"='AM834';only returns 200 records. Is this correct? Please post the result of above query.
It probably isn't the case, because retrieving 200 records per index range scan and single row random table access shouldn't take long, at maximum a couple of seconds if you need to read each block actually from disk rather than from the cache.
If the estimate is wrong you need to check the statistics on the table and index that were used by the optimizer to come to that conclusion.
Are you sure that this plan is the actual plan used at execution time? You can check for the actual plans used to execute by using the DBMS_XPLAN.DISPLAY_CURSOR function in 10g if the SQL is still cached in the Shared Pool. You need to pass the SQL_ID and SQL_CHILD_NUMBER which you can retrieve from V$SESSION while the statement is executing.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
OEM explain plan sown on SQL Details vs Tuning Advisor
In OEM, if I go to "Top SQL" and then get the "SQL Details" for a specific SQL Id there is a tab which shows the execution plan.
For the SQL I'm interested in, this plan shows very low values for cost, number of rows, etc. It also shows all table access being through indexes. It shows no values in the Time column.
Now on this page, if I click the button "Run SQL Tuning Advisor" and run an advisor it comes back with a recommendation that I'll ignore for now. Here's my real question. On the recommendations page there is a button "Original Explain Plan". If I click this the execution plan I get is similar but not exactly the same as the one I mentioned above on the SQL Details page. This one has very high values for cost, number of rows, etc. Some of the tables show as not using indexes.
What are the differences between these 2 pages? Is the first one an estimated plan and the second one the actual?
I've searched trying to find an explanation for this, but haven't. Thanks for any help explaining this.I tired running SQL Tuning Advisor with DBMS_SQLTUNE package, I think the output will help you understand.
Oracle 10g SQL Tuning
Adith -
SQL Tuning- slow query on GL_BALANCES- Explain plan provided
Hi- I really need some help here.
The following SQL statement has been identified to perform poorly.
It currently takes from 2-3 minutes to execute. I see it is because GL_BALANCES has so many rows.
Is there any way around this? Explain and info below. Thanks gurus!
This is the SQL statement:
SELECT DISTINCT GLB.CODE_COMBINATION_ID CCID
FROM gl_balances GLB, gl_code_combinations GCC
WHERE GLB.ACTUAL_FLAG = 'A'
AND GLB.Last_Update_Date > to_date('11-JAN-2010','DD-MON-YYYY')
AND GLB.code_combination_id = GCC.code_combination_id
AND EXISTS (
SELECT 1
FROM fnd_flex_value_sets A, fnd_flex_values B
WHERE A.flex_value_set_name = 'XXX_XXX'
AND UPPER(B.ATTRIBUTE3) = 'APPORTIONMENT'
AND A.flex_value_set_id = b.flex_value_set_id
AND GCC.segment11 = b.flex_value
);The version of the database is 11.1.0.7.
These are the parameters relevant to the optimizer:
NAME TYPE VALUE
optimizerautostats_job boolean FALSE
optimizerextended_cursor_sharing_r string NONE
el
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.7
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean FALSE
optimizer_use_invisible_indexes boolean FALSE
NAME TYPE VALUE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
optimizerextended_cursor_sharing_r string NONE
el
cursor_sharing string EXACT
select
2 sname
3 , pname
4 , pval1
5 , pval2
6 from
7 sys.aux_stats$;
SNAME PNAME PVAL1
PVAL2
SYSSTATS_INFO STATUS
COMPLETED
SYSSTATS_INFO DSTART
09-02-2006 14:35
SYSSTATS_INFO DSTOP
09-02-2006 14:35
SNAME PNAME PVAL1
PVAL2
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 451.262136
SYSSTATS_MAIN IOSEEKTIM 10
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN SLAVETHR
13 rows selected.
SQL> explain plan for
2 SELECT DISTINCT GLB.CODE_COMBINATION_ID CCID
3 FROM gl_balances GLB, gl_code_combinations GCC
4 WHERE GLB.code_combination_id = GCC.code_combination_id
5 AND GLB.ACTUAL_FLAG = 'A'
6 AND GLB.Last_Update_Date > '11-JAN-2010'
7 AND EXISTS (SELECT 1
8 FROM fnd_flex_value_sets A, fnd_flex_values B
9 WHERE A.flex_value_set_id = b.flex_value_set_id
10 AND A.flex_value_set_name = 'XXX_XXX'
11 AND UPPER(B.ATTRIBUTE3) = 'APPORTIONMENT'
12 AND GCC.segment11 = b.flex_value);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1839014065
| Id | Operation | Name | Rows | By
tes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 4102 |
296K| 955K (3)| 03:11:03 |
| 1 | HASH UNIQUE | | 4102 |
296K| 955K (3)| 03:11:03 |
|* 2 | HASH JOIN | | 4102 |
296K| 955K (3)| 03:11:03 |
| 3 | NESTED LOOPS | | |
| | |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | | 23907 | 1
354K| 2598 (1)| 00:00:32 |
| 5 | NESTED LOOPS | | 1 |
45 | 5 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUE_SETS | 1 |
28 | 2 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | FND_FLEX_VALUE_SETS_U2 | 1 |
PLAN_TABLE_OUTPUT
| 1 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUES | 1 |
17 | 3 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | FND_FLEX_VALUES_N2 | 53 |
| 1 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | GL_CODE_COMBINATIONS_N11 | 25427 |
| 106 (1)| 00:00:02 |
PLAN_TABLE_OUTPUT
| 11 | TABLE ACCESS BY INDEX ROWID | GL_CODE_COMBINATIONS | 18664 |
236K| 2593 (1)| 00:00:32 |
|* 12 | TABLE ACCESS FULL | GL_BALANCES | 1022K|
15M| 952K (3)| 03:10:32 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - access("GLB"."CODE_COMBINATION_ID"="GCC"."CODE_COMBINATION_ID")
7 - access("A"."FLEX_VALUE_SET_NAME"='SSA_SGL')
8 - filter(UPPER("B"."ATTRIBUTE3")='APPORTIONMENT')
9 - access("A"."FLEX_VALUE_SET_ID"="B"."FLEX_VALUE_SET_ID")
10 - access("GCC"."SEGMENT11"="B"."FLEX_VALUE")
12 - filter("GLB"."LAST_UPDATE_DATE">TO_DATE(' 2010-01-11 00:00:00', 'syyyy-mm
-dd hh24:mi:ss') AND
"GLB"."ACTUAL_FLAG"='A')
30 rows selected.As per the other replies, you've not really given enough information to go on - what are you trying to achieve, versions, etc.
On my old apps 11.5.8 system, the explain plan for your query uses GL_CODE_COMBINATIONS_U1 rather than a full scan of gl_code_combinations.
Check your stats are up to date (select table_name, num_rows, last_analyzed from dba_tables where ...)
See if you can also use period_name and/or period_set_name (or period_num) from GL_Periods rather than period_year (i.e. use P_YEAR to lookup the period_name/period_set_name/period_num from gl_periods). It might be faster to do per period and then consolidate for the whole year, as there are indexes on gl_balances for columns period_name, period_set_name, period_num.
regards, Ivan -
SQL Tuning Advisor Recommends New Explain Plan
Hi:
I have to believe this has been asked before but didn't see it in a forum search so I'll ask here. I had SQL Tuning Advisor look at a query and it is recommending a new plan for a 50+% improvement (hazah!). The trouble is, I don't want Oracle to re-write the plan to execute the query better, I want to know how I can re-write the query to generate that more optimal plan in the first place because I have similar systems in the field that I would like to also be optimized. What are my options?
Thanks.Sorry Gaff I know where you are talking about but I don't have your answer, but it may be a good start going over the 19g reference guide for these dictionary views -
SQL> select view_name from dba_views where view_name like 'DBA%ADVISOR%' ;
VIEW_NAME
DBA_ADVISOR_DEFINITIONS
DBA_ADVISOR_COMMANDS
DBA_ADVISOR_OBJECT_TYPES
DBA_ADVISOR_USAGE
DBA_ADVISOR_TASKS
DBA_ADVISOR_TEMPLATES
DBA_ADVISOR_LOG
...Best regards. -
Reg:Tkprof, awr, explain plan, autotrace analysis
hi friends.
can any one give description about below subject..........
Tkprof,
awr,
explain plan,
autotrace analysis
if possible kindly mentioned some example for each OR provide some to read.
regards,
RajnishThey're all described in the Oracle Documentation, example:
http://www.oracle.com/pls/db112/search?remark=quick_search&word=AWR&partno=
Look in the [Performance Tuning Guide|http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/toc.htm] for examples/exaplanations.
Randolf Geist sums it all up very nice here: http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
More examples can be found on http://asktom.oracle.com
and on this forum by simply doing a search. -
Hi,
I was trying to get an explain plan for below query. (Refer - A)
BILL_DETAIL table have index of ZONECODE,MRNO,AREACODE,WCNO but still it's
showing 'TABLE ACCESS FULL in BILL_DETAIL'
If i select only first 4 column, it is going by index. (REFER - B)
As per my knowledge index will consider only where clause conditions
but here I couldn't understand why this considering select output columns.
First time I am trying sql explain plan statement, Please help me to correct
this query.
REFER - A
EXPLAIN PLAN FOR
SELECT B.ZONECODE ZONECODE, B.MRNO MRNO, B.AREACODE AREACODE, B.WCNO WCNO,
B.BILLNO BILLNO,B.BILLDT BILLDT,B.FROMDT FROMDT,B.TODT TODT,B.TOBEPAID TOBEPAID,
B.PREVUNPAID PREVUNPAID,B.DUEDT DUEDT
FROM BILL_DETAIL B, CONSUMER_MASTER C
WHERE B.ZONECODE = C.ZONECODE
AND B.MRNO = C.MRNO
AND B.AREACODE = C.AREACODE
AND B.WCNO = C.WCNO
AND UPPER(B.ZONECODE)=UPPER('SZ-4')
AND UPPER(B.MRNO)=UPPER('347')
AND UPPER(B.AREACODE)=UPPER('18')
AND UPPER(B.WCNO)=UPPER('30910')
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 71 | 9 (0)|
| 1 | NESTED LOOPS | | 1 | 71 | 9 (0)|
|* 2 | TABLE ACCESS FULL| BILL_DETAIL | 1 | 52 | 9 (0)|
|* 3 | INDEX UNIQUE SCAN| SYS_C008803 | 1 | 19 | 0 (0)|
Predicate Information (identified by operation id):
2 - filter(UPPER("B"."ZONECODE")='SZ-4' AND UPPER("B"."MRNO")='347'
AND UPPER("B"."AREACODE")='18' AND UPPER("B"."WCNO")='30910')
3 - access("B"."ZONECODE"="C"."ZONECODE" AND "B"."MRNO"="C"."MRNO"
AND "B"."AREACODE"="C"."AREACODE" AND "B"."WCNO"="C"."WCNO")
REFER - B
EXPLAIN PLAN FOR
SELECT B.ZONECODE ZONECODE, B.MRNO MRNO, B.AREACODE AREACODE, B.WCNO WCNO
FROM BILL_DETAIL B, CONSUMER_MASTER C
WHERE B.ZONECODE = C.ZONECODE
AND B.MRNO = C.MRNO
AND B.AREACODE = C.AREACODE
AND B.WCNO = C.WCNO
AND UPPER(B.ZONECODE)=UPPER('SZ-4')
AND UPPER(B.MRNO)=UPPER('347')
AND UPPER(B.AREACODE)=UPPER('18')
AND UPPER(B.WCNO)=UPPER('30910')
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 34 | 4 (0)|
| 1 | NESTED LOOPS | | 1 | 34 | 4 (0)|
|* 2 | INDEX FAST FULL SCAN| SYS_C008798 | 1 | 15 | 4 (0)|
|* 3 | INDEX UNIQUE SCAN | SYS_C008803 | 1 | 19 | 0 (0)|
Predicate Information (identified by operation id):
2 - filter(UPPER("B"."ZONECODE")='SZ-4' AND UPPER("B"."MRNO")='347'
AND UPPER("B"."AREACODE")='18' AND UPPER("B"."WCNO")='30910')
3 - access("B"."ZONECODE"="C"."ZONECODE" AND "B"."MRNO"="C"."MRNO"
AND "B"."AREACODE"="C"."AREACODE" AND "B"."WCNO"="C"."WCNO")
Note
- 'PLAN_TABLE' is old versionWelcome to the forums!
user13295080 wrote:
I was trying to get an explain plan for below query. (Refer - A)
BILL_DETAIL table have index of ZONECODE,MRNO,AREACODE,WCNO but still it's
showing 'TABLE ACCESS FULL in BILL_DETAIL'
If i select only first 4 column, it is going by index. (REFER - B)
As per my knowledge index will consider only where clause conditions
but here I couldn't understand why this considering select output columns.This is because Oracle is smart enough to know that the entire query can be satisfied by using the index without hitting the table. However, once you add a column that doesn't exist in the index Oracle has decided it is more efficient to use the full table scan.
I also noticed that all the row estimates are 1 in the execution plans. Is this expected? If not, have statistics on the relevant objects been gathered?
Generally speaking, when you have a query tuning question providing information in these threads is extremely helpful:
{message:id=1812597}
{thread:id=863295}
Additionally, when posting query plans, queries, or any code please use \ tags to preserve formatting.
Your code here!\ -
Hi ,
I got a sql tuning result for one query , and i need to understand the below fileds in the explain plan
operation lineid object object_type order rows bytes cost time cpucost iocost
any document to understand will be appreciated
and in recomendation i got Consider accepting the recommended SQL profile. suppose if it was not feasible after accepting the SQL profile can i revert back.
Thanksuser12266475 wrote:
Hi ,
I got a sql tuning result for one query , and i need to understand the below fileds in the explain plan
operation lineid object object_type order rows bytes cost time cpucost iocost
any document to understand will be appreciated
and in recomendation i got Consider accepting the recommended SQL profile. suppose if it was not feasible after accepting the SQL profile can i revert back.
Thankshttp://docs.oracle.com/cd/E11882_01/server.112/e16638/toc.htm
Thread: HOW TO: Post a SQL statement tuning request - template posting
HOW TO: Post a SQL statement tuning request - template posting -
Does bigger explain plan in TKPROF output indicate something wrong with SQL
We were tracing some database sessions.
Using TKPROF we were able to read the trace file.
we have noticed that some of the SQL ( 1-2 lines SQL statements) were showing up atleast
150 lines of explain plan.
So we realized that the sql statements are badly written.
Based on that above can we come into the following conclusion:
- for 1-2 lines of SQL Statement if there is 100+ lines of explain plan in TKPROF report, it indicates the SQL statement
is wrongly written ?johnpau2013 wrote:
We were tracing some database sessions.
Using TKPROF we were able to read the trace file.
we have noticed that some of the SQL ( 1-2 lines SQL statements) were showing up atleast
150 lines of explain plan.
So we realized that the sql statements are badly written.
Based on that above can we come into the following conclusion:
- for 1-2 lines of SQL Statement if there is 100+ lines of explain plan in TKPROF report, it indicates the SQL statement
is wrongly written ?The only rule that is always true for tuning SQL, is that NO rule is ALWAYS true for every SQL statement &
every data distribution.
it depends
post actual example, so we can see what you see. -
Hi Guys
I am new to SQL Tuning and i wanna know what exactly are the tables involved in finding the explain plan of sql's and what all the views that needs to be queried to find the explain lan of a query. Kindly help me .
Thanks
Ramplan_table is used to get execution plan of any query. this table can be created with the script utlxplan.sql. You can find the script under ORACLE_HOME/rdbms/admin folder.
The process for getting the execution plan is
SQL> explain plan for
2 select * from emp where employee_id=12 ;
Explained.
SQL> select plan_table_output from table(dbms_xplan.display('plan_table',null,'serial'));
you can run the utlxpls.sql script also to get formated output and which can be found in ORACLE_HOME/rdbms/admin folder.
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) |
| 0 | SELECT STATEMENT | | 1 | 42 | 3 (0)|
|* 1 | TABLE ACCESS FULL | EMP | 1 | 42 | 3 (0)|
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
1 - filter("EMPLOYEE_ID"=12) -
Tuning : Inconsistent result between Explain plan VS Execution Time
Dear Experts,
Need your suggestions belongs to contrary result between Explain plan VS Execution Time
Environment :_
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
Red Hat Enterprise Linux 5.4
There's same query but : 1st query access Loan_Account, 2nd query access Loan_Account_Han
*1st.*
Query Access Via : Loan_account (Partition Type : Hash (5) with column Contract_Number)
Explain Plan : cost: 4,432, bytes: 716, cardinality: 2
Execution Time : 13 seconds
*2nd.*
Query Access Via : Loan_Account_Han (Partition Type : List(5) with column Loan_Status)
Explain Plan : cost:188,447 bytes: 1,661,088, cardinality: 4,719
Execution Time : 10 seconds
Note :_
all tables and all indexes belong to the table which included in query has been analyzed.
my question :
1. why it could become like this ? I even confusing with Jonathan Lewis Theory : Cost-Based Fundamental Book.
with this result, I even not believed with the result from Explain Plan anymore.
2. If analyze tables and indexes to update statistics which help CBO to choose the best path as part of Daily Performance Tuning,
is there a way that could do in enviroment 24x7 ?
Note : if original query is needed, I'll posting it here.
Any help is very appreciated and thanks very much.
Regards,
SigcleThe DBMS_XPLAN.DISPLAY_CURSOR output
Query no 1
PLAN_TABLE_OUTPUT
SQL_ID bq7avs72xvmkv, child number 0
SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id, la.contract_number, mc.customer_name,
dco.os_principal_on_schedule AS os_principal_on_schedule, f_get_param_value (la.financing_type, 'FinancingType'
) AS financing_type, CASE la.financing_type WHEN 11 -- Asset Purchase THEN NVL (tp.os_principal_cust,
la.os_principal_cust ) WHEN 12 -- JF Channelling THEN
NVL (tp.os_principal_mf, la.os_principal) END AS os_principal_actual, CASE WHEN dco.bi_collectibility_with_gp >= 3 THEN 0
ELSE CASE WHEN la.financing_type = '12' THEN NVL (ia.accrue_interest_pl, 0) + NVL (ia.accrue_interest_npl, 0)
ELSE NVL (ia.accrue_
Plan hash value: 4011856754
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem |
| 1 | TABLE ACCESS BY INDEX ROWID | COLLECTIBILITY_CODE | 3 | 1 | 3 |00:00:00.01 | 9 | 2 | | | |
|* 2 | INDEX SKIP SCAN | UNQ_COLLECTIBILITY_CODE | 3 | 1 | 3 |00:00:00.01 | 6 | 1 | | | |
| 3 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 501 | 1 | 501 |00:00:00.03 | 2004 | 796 | | | |
|* 4 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 501 | 1 | 501 |00:00:00.02 | 1503 | 377 | | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 333 | 1 | 333 |00:00:00.10 | 3220 | 1074 | | | |
|* 6 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 333 | 1 | 333 |00:00:00.09 | 2887 | 1074 | | | |
| 7 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 168 | 1 | 167 |00:00:00.05 | 1464 | 495 | | | |
|* 8 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 168 | 1 | 167 |00:00:00.05 | 1297 | 495 | | | |
| 9 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 333 | 1 | 333 |00:00:00.06 | 3167 | 0 | | | |
|* 10 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 333 | 1 | 333 |00:00:00.06 | 2834 | 0 | | | |
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 168 | 1 | 167 |00:00:00.03 | 1447 | 0 | | | |
|* 12 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 168 | 1 | 167 |00:00:00.03 | 1280 | 0 | | | |
| 13 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 333 | 1 | 333 |00:00:00.06 | 3167 | 0 | | | |
|* 14 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 333 | 1 | 333 |00:00:00.06 | 2834 | 0 | | | |
| 15 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 168 | 1 | 167 |00:00:00.03 | 1447 | 0 | | | |
|* 16 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 168 | 1 | 167 |00:00:00.03 | 1280 | 0 | | | |
| 17 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 333 | 1 | 333 |00:00:00.06 | 3167 | 0 | | | |
|* 18 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 333 | 1 | 333 |00:00:00.06 | 2834 | 0 | | | |
| 19 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 168 | 1 | 167 |00:00:00.03 | 1447 | 0 | | | |
|* 20 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 168 | 1 | 167 |00:00:00.03 | 1280 | 0 | | | |
|* 21 | TABLE ACCESS FULL | COLLECTIBILITY_CODE | 3 | 1 | 3 |00:00:00.01 | 12 | 1 | | | |
| 22 | NESTED LOOPS OUTER | | 1 | 2 | 501 |00:00:01.02 | 96112 | 20091 | | | |
| 23 | NESTED LOOPS | | 1 | 2 | 501 |00:00:00.28 | 13445 | 5358 | | | |
| 24 | NESTED LOOPS | | 1 | 2 | 501 |00:00:00.26 | 11441 | 5071 | | | |
| 25 | NESTED LOOPS OUTER | | 1 | 2 | 501 |00:00:00.24 | 9433 | 5014 | | | |
|* 26 | HASH JOIN | | 1 | 2 | 501 |00:00:00.03 | 329 | 325 | 1206K| 1206K| 341K (0)|
|* 27 | TABLE ACCESS FULL | CURRENCY | 1 | 1 | 1 |00:00:00.01 | 3 | 2 | | | |
|* 28 | HASH JOIN | | 1 | 61 | 501 |00:00:00.02 | 326 | 323 | 868K| 868K| 947K (0)|
|* 29 | HASH JOIN | | 1 | 10 | 13 |00:00:00.01 | 7 | 6 | 947K| 947K| 1030K (0)|
| 30 | TABLE ACCESS BY INDEX ROWID | MULTIFINANCE | 1 | 5 | 9 |00:00:00.01 | 2 | 2 | | | |
|* 31 | INDEX RANGE SCAN | IDX_STATUS_MF | 1 | 5 | 9 |00:00:00.01 | 1 | 1 | | | |
|* 32 | TABLE ACCESS FULL | AGREEMENT | 1 | 18 | 13 |00:00:00.01 | 5 | 4 | | | |
| 33 | VIEW | | 1 | 110 | 501 |00:00:00.02 | 319 | 317 | | | |
|* 34 | HASH JOIN RIGHT OUTER | | 1 | 110 | 501 |00:00:00.02 | 319 | 317 | 1011K| 1011K| 317K (0)|
| 35 | TABLE ACCESS BY INDEX ROWID | TENANT_PARAMETER | 1 | 1 | 1 |00:00:00.01 | 2 | 2 | | | |
|* 36 | INDEX UNIQUE SCAN | PK_TENANT_PARAMETER | 1 | 1 | 1 |00:00:00.01 | 1 | 1 | | | |
|* 37 | TABLE ACCESS BY GLOBAL INDEX ROWID| LOAN_ACCOUNT | 1 | 110 | 501 |00:00:00.02 | 317 | 315 | | | |
|* 38 | INDEX RANGE SCAN | IDX_STATUS_LA1 | 1 | 4394 | 3025 |00:00:00.01 | 15 | 14 | | | |
|* 39 | TABLE ACCESS BY INDEX ROWID | TX_PAYMENT | 501 | 1 | 0 |00:00:00.16 | 9104 | 4689 | | | |
|* 40 | INDEX RANGE SCAN | FK_TX_PAY_LOAN_ACCT | 501 | 12 | 8799 |00:00:00.02 | 1038 | 207 | | | |
| 41 | TABLE ACCESS BY INDEX ROWID | DL_CL_OUTSTANDING | 501 | 1 | 501 |00:00:00.02 | 2008 | 57 | | | |
|* 42 | INDEX RANGE SCAN | IDXLO_CNUM | 501 | 1 | 501 |00:00:00.01 | 1507 | 37 | | | |
|* 43 | TABLE ACCESS BY INDEX ROWID | MF_CUSTOMER | 501 | 1 | 501 |00:00:00.02 | 2004 | 287 | | | |
|* 44 | INDEX UNIQUE SCAN | MF_CUSTOMER_PK | 501 | 1 | 501 |00:00:00.01 | 1503 | 24 | | | |
|* 45 | TABLE ACCESS BY INDEX ROWID | TX_INTEREST_ACCRUE | 501 | 1 | 0 |00:00:00.73 | 82667 | 14733 | | | |
|* 46 | INDEX RANGE SCAN | FK_TX_INTEREST_ACCRUE_LOAN_ACC | 501 | 67 | 40581 |00:00:00.14 | 42084 | 451 | | | |
Predicate Information (identified by operation id):
2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
filter("XX"."COLLECTIBILITY_CODE"=:B1)
4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
26 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
27 - filter(UPPER("CURR"."STATUS")='A')
28 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
29 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
31 - access("MF"."SYS_NC00052$"='A')
32 - filter(UPPER("A"."STATUS")='A')
34 - access("LA"."TENANT_ID"="TENANT_ID")
36 - access("TENANT_PARAMETER_ID"=23)
37 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR ("LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
UPPER("LA"."LOAN_STATUS")='CN')))
38 - access("LA"."SYS_NC00118$"='A')
39 - filter(("TP"."APPROVAL_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"=152 AND UPPER("TP"."APPROVAL_STATUS")='A'))
40 - access("TP"."LOAN_ACCOUNT_ID"="from$_subquery$_016"."LOAN_ACCOUNT_ID")
42 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
43 - filter(UPPER("MC"."STATUS")='A')
44 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")
45 - filter("IA"."ACCRUE_DATE"="XX"."PREV_DATE")
46 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID")
The DBMS_XPLAN.DISPLAY_CURSOR output after : alter system flush buffer_cache; alter system flush shared_pool;
Query no 2
PLAN_TABLE_OUTPUT
SQL_ID cxmg4jfvr9pz0, child number 0
SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id, la.contract_number, mc.customer_name,
dco.os_principal_on_schedule AS os_principal_on_schedule, f_get_param_value (la.financing_type, 'FinancingType'
) AS financing_type, CASE la.financing_type WHEN 11 -- Asset Purchase THEN NVL (tp.os_principal_cust,
la.os_principal_cust ) WHEN 12 -- JF Channelling THEN
NVL (tp.os_principal_mf, la.os_principal) END AS os_principal_actual, CASE WHEN dco.bi_collectibility_with_gp >= 3 THEN 0
ELSE CASE WHEN la.financing_type = '12' THEN NVL (ia.accrue_interest_pl, 0) + NVL (ia.accrue_interest_npl, 0)
ELSE NVL (ia.accrue_
Plan hash value: 2072372033
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 4719 | 1622K| 188K (32)| 00:37:42 | | |
| 1 | TABLE ACCESS BY INDEX ROWID | COLLECTIBILITY_CODE | 1 | 12 | 3 (0)| 00:00:01 | | |
|* 2 | INDEX SKIP SCAN | UNQ_COLLECTIBILITY_CODE | 1 | | 2 (0)| 00:00:01 | | |
| 3 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 4 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 15 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 6 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 7 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 1 | 15 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 8 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 9 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 15 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 10 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 1 | 15 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 12 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 13 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 14 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 15 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 16 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 17 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 18 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 19 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 20 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
|* 21 | TABLE ACCESS FULL | COLLECTIBILITY_CODE | 1 | 12 | 3 (0)| 00:00:01 | | |
| 22 | NESTED LOOPS | | 4719 | 1622K| 188K (32)| 00:37:42 | | |
| 23 | NESTED LOOPS | | 4719 | 1460K| 183K (33)| 00:36:45 | | |
| 24 | NESTED LOOPS OUTER | | 4719 | 1354K| 180K (33)| 00:36:07 | | |
| 25 | NESTED LOOPS OUTER | | 4719 | 1225K| 130K (46)| 00:26:01 | | |
|* 26 | HASH JOIN | | 4719 | 1106K| 23591 (2)| 00:04:44 | | |
| 27 | TABLE ACCESS BY INDEX ROWID | MULTIFINANCE | 5 | 130 | 2 (0)| 00:00:01 | | |
|* 28 | INDEX RANGE SCAN | IDX_STATUS_MF | 5 | | 1 (0)| 00:00:01 | | |
|* 29 | HASH JOIN | | 8494 | 1775K| 23589 (2)| 00:04:44 | | |
|* 30 | TABLE ACCESS FULL | AGREEMENT | 18 | 360 | 3 (0)| 00:00:01 | | |
|* 31 | HASH JOIN | | 8494 | 1609K| 23585 (2)| 00:04:44 | | |
|* 32 | TABLE ACCESS FULL | CURRENCY | 1 | 4 | 3 (0)| 00:00:01 | | |
| 33 | VIEW | | 212K| 38M| 23579 (2)| 00:04:43 | | |
|* 34 | HASH JOIN RIGHT OUTER | | 212K| 32M| 23579 (2)| 00:04:43 | | |
| 35 | TABLE ACCESS BY INDEX ROWID| TENANT_PARAMETER | 1 | 74 | 1 (0)| 00:00:01 | | |
|* 36 | INDEX UNIQUE SCAN | PK_TENANT_PARAMETER | 1 | | 0 (0)| 00:00:01 | | |
| 37 | PARTITION LIST ALL | | 212K| 17M| 23575 (2)| 00:04:43 | 1 | 5 |
|* 38 | TABLE ACCESS FULL | LOAN_ACCOUNT_HAN | 212K| 17M| 23575 (2)| 00:04:43 | 1 | 5 |
| 39 | TABLE ACCESS BY INDEX ROWID | TX_INTEREST_ACCRUE | 1 | 26 | 130K (46)| 00:26:01 | | |
| 40 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
| 41 | BITMAP AND | | | | | | | |
| 42 | BITMAP CONVERSION FROM ROWIDS| | | | | | | |
|* 43 | INDEX RANGE SCAN | FK_TX_INTEREST_ACCRUE_LOAN_ACC | 67 | | 0 (0)| 00:00:01 | | |
| 44 | BITMAP CONVERSION FROM ROWIDS| | | | | | | |
|* 45 | INDEX RANGE SCAN | IDX_TX_INTEREST_ACCRUE | 67 | | 12 (100)| 00:00:01 | | |
|* 46 | TABLE ACCESS BY INDEX ROWID | TX_PAYMENT | 1 | 28 | 11 (0)| 00:00:01 | | |
|* 47 | INDEX RANGE SCAN | FK_TX_PAY_LOAN_ACCT | 12 | | 0 (0)| 00:00:01 | | |
| 48 | TABLE ACCESS BY INDEX ROWID | DL_CL_OUTSTANDING | 1 | 23 | 1 (0)| 00:00:01 | | |
|* 49 | INDEX RANGE SCAN | IDXLO_CNUM | 1 | | 0 (0)| 00:00:01 | | |
|* 50 | TABLE ACCESS BY INDEX ROWID | MF_CUSTOMER | 1 | 35 | 1 (0)| 00:00:01 | | |
|* 51 | INDEX UNIQUE SCAN | MF_CUSTOMER_PK | 1 | | 0 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
filter("XX"."COLLECTIBILITY_CODE"=:B1)
4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
26 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
28 - access(UPPER("STATUS")='A')
29 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
30 - filter(UPPER("A"."STATUS")='A')
31 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
32 - filter(UPPER("CURR"."STATUS")='A')
34 - access("LA"."TENANT_ID"="TENANT_ID"(+))
36 - access("TENANT_PARAMETER_ID"(+)=23)
38 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR "LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
AND UPPER("LA"."LOAN_STATUS")='CN') AND UPPER("LA"."STATUS")='A')
43 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID"(+))
45 - access("IA"."ACCRUE_DATE"(+)="XX"."PREV_DATE")
46 - filter("TP"."APPROVAL_DATE"(+)=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"(+)=152
AND UPPER("TP"."APPROVAL_STATUS"(+))='A')
47 - access("TP"."LOAN_ACCOUNT_ID"(+)="from$_subquery$_016"."LOAN_ACCOUNT_ID")
49 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
50 - filter(UPPER("MC"."STATUS")='A')
51 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")Typically both query running on 10-12 seconds (or same execution time).
And I can't provide autotrace and tkprof output cause I cannot access via sqlplus.
Thanks very much for the link HOW TO: Post a SQL statement tuning request - template posting
Regards,
Sigcle
Edited by: SigCle on Feb 25, 2013 4:22 AM
Maybe you are looking for
-
Is there a way to open looong Word documents in Illustrator?
Hi, I absolutely DO NOT want to install some office progs on my machine (I have another one for that kind of boring stuff but that's still on its way across the ocean) and need to open a .doc document consiting on more than 1 page. Is there a way to
-
What's up with Adobe Application Manager CS6?
If I select within Pr (CS6): Help > Updates... here is the resulting update check (as expected): But... if I directly run Application Manager either from the Start Menu shortcut, or by running the executable file (PDapp.exe) in this location: C:\Prog
-
Workaround good/bad practice or does it not matter...??
Hi, I have a project that requires other shared actions to hide./show something and was wanting a quick workaround for Hide 1 show 9 so I did as follows..(bear in mind I am using CP7 not 8) I copied my hide1 show 20 slide from another project, which
-
Callable Statement throws exception..pls help
When I use Callable Statement calling my function which returns Y if person is employee or nothing if not I get this error.. Procedure not createdORA-06550: line 1, column 22: PLS-00103: Encountered the symbol "CHCK_EMP_STATUS" when expecting one of
-
Cant get contacts and calendars to sync to ipod nano
when I sync my nano to my macbook itunes, all music and photos copy, but my contacts and calendars (selected) look like they copy, but when done, the nano does not have any contacts or calendars. this happened occasionally for a while, but now it nev