Running long time- need help

Question

Following Query running more than 4 hrs. could somone please suggest me to tune this query.
SELECT fi_contract_id, a.cust_id, a.product_id, a.currency_cd,
ROUND (DECODE (SUBSTR (a.ACCOUNT, 1, 4), '4992', posted_tran_amt, 0),
2
) ftp_amt,
ROUND (DECODE (SUBSTR (a.ACCOUNT, 1, 4), '4992', posted_base_amt, 0),
2
) ftp_base_amt,
ROUND (DECODE (SUBSTR (a.ACCOUNT, 1, 4),
'4994', posted_tran_amt,
'4995', posted_tran_amt,
0
2
) col_amt,
ROUND (DECODE (SUBSTR (a.ACCOUNT, 1, 4),
'4994', posted_base_amt,
'4995', posted_base_amt,
0
2
) col_base_amt,
ROUND (DECODE (SUBSTR (a.ACCOUNT, 1, 3), '499', 0, posted_tran_amt),
2
) closing_bal,
a.ACCOUNT, a.deptid, a.business_unit,
CASE
WHEN a.ACCOUNT LIKE '499%'
THEN '990'
ELSE a.operating_unit
END operating_unit,
a.base_currency, NVL (TRIM (pf_system_code), a.SOURCE) pf_system_code,
b.setid, a.channel_id, scb_arm_code, scb_tp_product, scb_tranche_id,
CASE
WHEN pf_system_code = 'CLS'
THEN scb_bncpr_flg
ELSE NULL
END tranche_purpose,
CASE
WHEN pf_system_code = 'IMX'
AND SUBSTR (scb_bncpr_flg, 1, 1) IN ('Y', 'N')
THEN SUBSTR (scb_bncpr_flg, 1, 1)
ELSE NULL
END lc_ind,
CASE
WHEN pf_system_code = 'IMX'
AND SUBSTR (scb_bncpr_flg, 1, 1) IN ('Y', 'N')
THEN SUBSTR (scb_bncpr_flg, 2, 3)
WHEN pf_system_code = 'IMX'
AND SUBSTR (scb_bncpr_flg, 1, 1) NOT IN ('Y', 'N')
THEN SUBSTR (scb_bncpr_flg, 1, 3)
ELSE NULL
END bill_branch_id,
CASE
WHEN pf_system_code = 'IMX'
AND SUBSTR (scb_bncpr_flg, 1, 1) IN ('Y', 'N')
THEN SUBSTR (scb_bncpr_flg, 5, 1)
WHEN pf_system_code = 'IMX'
AND SUBSTR (scb_bncpr_flg, 1, 1) NOT IN ('Y', 'N')
THEN SUBSTR (scb_bncpr_flg, 4, 1)
ELSE NULL
END section_id,
CASE
WHEN pf_system_code = 'IFS'
THEN SUBSTR (scb_bncpr_flg, 1, 1)
ELSE NULL
END recourse_ind,
CASE
WHEN pf_system_code = 'IFS'
THEN SUBSTR (scb_bncpr_flg, 2, 1)
ELSE NULL
END disclosure_ind,
TO_CHAR (LAST_DAY (upload_date), 'DDMMYYYY')
FROM ps_fi_ildgr_f00 a,
(SELECT c.business_unit, c.fi_instrument_id, c.scb_arm_code,
c.scb_tp_product, c.scb_tranche_id, c.scb_bncpr_flg
FROM ps_fi_iother_r00 c, ps_scb_bus_unit b1
WHERE c.business_unit = b1.business_unit
AND b1.setid = 'PKSTN'
AND c.asof_dt =
(SELECT MAX (c1.asof_dt)
FROM ps_fi_iother_r00 c1
WHERE c.business_unit = c1.business_unit
AND c1.fi_instrument_id = c.fi_instrument_id)) c,
ps_scb_bus_unit b,
(SELECT upload_date - 15 upload_date
FROM stg_ftp_trans_bal_tb
WHERE setid = 'PKSTN' AND ROWNUM < 2),
(SELECT i.business_unit, i.fi_instrument_id, i.pf_system_code,
i.fi_contract_id
FROM ps_fi_instr_f00 i, ps_scb_bus_unit b1
WHERE i.business_unit = b1.business_unit
AND b1.setid = 'PKSTN'
AND (i.asof_dt) =
(SELECT MAX (i1.asof_dt)
FROM ps_fi_instr_f00 i1
WHERE i.business_unit = i1.business_unit
AND i1.fi_instrument_id = i.fi_instrument_id)) d
WHERE a.business_unit = b.business_unit
AND a.business_unit = c.business_unit
AND a.business_unit = d.business_unit
AND a.fi_instrument_id = c.fi_instrument_id(+)
AND a.fi_instrument_id = d.fi_instrument_id(+)
AND fiscal_year = TO_CHAR (upload_date, 'YYYY')
AND a.ACCOUNT != '191801'
AND a.pf_scenario_id LIKE '%M_'
AND accounting_period = TO_CHAR (upload_date, 'MM')
AND b.setid = 'PKSTN'
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 225 | | 14059 (2)| | | | | |
|* 1 | FILTER | | | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10006 | 962 | 211K| | 13578 (2)| | | Q1,06 | P->S | QC (RAND) |
|* 4 | HASH JOIN | | 962 | 211K| | 13578 (2)| | | Q1,06 | PCWP | |
| 5 | PX RECEIVE | | 977 | 190K| | 4273 (2)| | | Q1,06 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10004 | 977 | 190K| | 4273 (2)| | | Q1,04 | P->P | BROADCAST |
PLAN_TABLE_OUTPUT
|* 7 | HASH JOIN | | 977 | 190K| | 4273 (2)| | | Q1,04 | PCWP | |
| 8 | BUFFER SORT | | | | | | | | Q1,04 | PCWC | |
| 9 | PX RECEIVE | | 1 | 10 | | 2 (0)| | | Q1,04 | PCWP | |
| 10 | PX SEND BROADCAST | :TQ10000 | 1 | 10 | | 2 (0)| | | | S->P | BROADCAST |
|* 11 | TABLE ACCESS FULL | PS_SCB_BUS_UNIT | 1 | 10 | | 2 (0)| | | | | |
| 12 | TABLE ACCESS BY LOCAL INDEX ROWID| PS_FI_INSTR_F00 | 1 | 42 | | 1 (0)| | | Q1,04 | PCWC | |
| 13 | NESTED LOOPS | | 1954 | 362K| | 4271 (2)| | | Q1,04 | PCWP | |
|* 14 | HASH JOIN | | 1954 | 282K| | 3999 (2)| | | Q1,04 | PCWP | |
| 15 | BUFFER SORT | | | | | | | | Q1,04 | PCWC | |
| 16 | PX RECEIVE | | 1 | 10 | | 2 (0)| | | Q1,04 | PCWP | |
| 17 | PX SEND BROADCAST | :TQ10001 | 1 | 10 | | 2 (0)| | | | S->P | BROADCAST |
PLAN_TABLE_OUTPUT
|* 18 | TABLE ACCESS FULL | PS_SCB_BUS_UNIT | 1 | 10 | | 2 (0)| | | | | |
|* 19 | HASH JOIN | | 3907 | 526K| | 3997 (2)| | | Q1,04 | PCWP | |
| 20 | PX RECEIVE | | 54702 | 4700K| | 616 (1)| | | Q1,04 | PCWP | |
| 21 | PX SEND HASH | :TQ10003 | 54702 | 4700K| | 616 (1)| | | Q1,03 | P->P | HASH |
| 22 | PX BLOCK ITERATOR | | 54702 | 4700K| | 616 (1)| 1 | 6119 | Q1,03 | PCWC | |
|* 23 | TABLE ACCESS FULL | PS_FI_ILDGR_F00 | 54702 | 4700K| | 616 (1)| 1 | 6119 | Q1,03 | PCWP | |
| 24 | BUFFER SORT | | | | | | | | Q1,04 | PCWC | |
| 25 | PX RECEIVE | | 221K| 10M| | 3380 (3)| | | Q1,04 | PCWP | |
| 26 | PX SEND HASH | :TQ10002 | 221K| 10M| | 3380 (3)| | | | S->P | HASH |
| 27 | NESTED LOOPS | | 221K| 10M| | 3380 (3)| | | | | |
| 28 | NESTED LOOPS | | 1 | 16 | | 2351 (2)| | | | | |
PLAN_TABLE_OUTPUT
| 29 | VIEW | | 1 | 6 | | 2349 (2)| | | | | |
|* 30 | COUNT STOPKEY | | | | | | | | | | |
| 31 | PARTITION LIST SINGLE | | 661K| 7755K| | 2349 (2)| KEY | KEY | | | |
| 32 | TABLE ACCESS FULL | STG_FTP_TRANS_BAL_TB | 661K| 7755K| | 2349 (2)| 2 | 2 | | | |
|* 33 | TABLE ACCESS FULL | PS_SCB_BUS_UNIT | 1 | 10 | | 2 (0)| | | | | |
| 34 | PARTITION LIST ITERATOR | | 442K| 14M| | 1029 (3)| KEY | KEY | | | |
|* 35 | TABLE ACCESS FULL | PS_FI_IOTHER_R00 | 442K| 14M| | 1029 (3)| KEY | KEY | | | |
| 36 | PARTITION LIST ITERATOR | | 1 | | | 1 (0)| KEY | KEY | Q1,04 | PCWP | |
|* 37 | INDEX RANGE SCAN | PS_FI_INSTR_F00 | 1 | | | 1 (0)| KEY | KEY | Q1,04 | PCWP | |
| 38 | VIEW | VW_SQ_1 | 5220K| 124M| | 9296 (1)| | | Q1,06 | PCWP | |
| 39 | SORT GROUP BY | | 5220K| 169M| 479M| 9296 (1)| | | Q1,06 | PCWP | |
PLAN_TABLE_OUTPUT
| 40 | PX RECEIVE | | 5220K| 169M| | 9220 (1)| | | Q1,06 | PCWP | |
| 41 | PX SEND HASH | :TQ10005 | 5220K| 169M| | 9220 (1)| | | Q1,05 | P->P | HASH |
| 42 | PX BLOCK ITERATOR | | 5220K| 169M| | 9220 (1)| 1 | 7 | Q1,05 | PCWC | |
| 43 | TABLE ACCESS FULL | PS_FI_INSTR_F00 | 5220K| 169M| | 9220 (1)| 1 | 7 | Q1,05 | PCWP | |
| 44 | SORT AGGREGATE | | 1 | 20 | | | | | | | |
| 45 | PARTITION LIST SINGLE | | 1 | 20 | | 1 (0)| KEY | KEY | | | |
|* 46 | INDEX RANGE SCAN | PS_FI_IOTHER_R00 | 1 | 20 | | 1 (0)| KEY | KEY | | | |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
1 - filter("C"."ASOF_DT"= (SELECT /*+ */ MAX("C1"."ASOF_DT") FROM "PS_FI_IOTHER_R00" "C1" WHERE "C1"."FI_INSTRUMENT_ID"=:B1 AND
"C1"."BUSINESS_UNIT"=:B2))
4 - access("I"."ASOF_DT"="VW_COL_1" AND "I"."BUSINESS_UNIT"="BUSINESS_UNIT" AND "FI_INSTRUMENT_ID"="I"."FI_INSTRUMENT_ID")
7 - access("I"."BUSINESS_UNIT"="B1"."BUSINESS_UNIT")
11 - filter("B1"."SETID"='PKSTN')
14 - access("A"."BUSINESS_UNIT"="B"."BUSINESS_UNIT")
18 - filter("B"."SETID"='PKSTN')
19 - access("A"."BUSINESS_UNIT"="C"."BUSINESS_UNIT" AND "A"."FI_INSTRUMENT_ID"="C"."FI_INSTRUMENT_ID" AND
"FISCAL_YEAR"=TO_NUMBER(TO_CHAR("UPLOAD_DATE",'YYYY')) AND "ACCOUNTING_PERIOD"=TO_NUMBER(TO_CHAR("UPLOAD_DATE",'MM')))
23 - filter("A"."PF_SCENARIO_ID" LIKE '%M_' AND "A"."ACCOUNT"<>'191801')
PLAN_TABLE_OUTPUT
30 - filter(ROWNUM<2)
33 - filter("B1"."SETID"='PKSTN')
35 - filter("C"."BUSINESS_UNIT"="B1"."BUSINESS_UNIT")
37 - access("A"."BUSINESS_UNIT"="I"."BUSINESS_UNIT" AND "A"."FI_INSTRUMENT_ID"="I"."FI_INSTRUMENT_ID")
46 - access("C1"."BUSINESS_UNIT"=:B1 AND "C1"."FI_INSTRUMENT_ID"=:B2)
Note
- 'PLAN_TABLE' is old version
75 rows selected.

Answer 1

[email protected] wrote:
Following Query running more than 4 hrs. could somone please suggest me to tune this query.1. You can try to avoid self-joins or FILTER operations in the C and D inline views if you change below queries to use analytic functions instead:
(SELECT c.business_unit, c.fi_instrument_id, c.scb_arm_code,
c.scb_tp_product, c.scb_tranche_id, c.scb_bncpr_flg
FROM ps_fi_iother_r00 c, ps_scb_bus_unit b1
WHERE c.business_unit = b1.business_unit
AND b1.setid = 'PKSTN'
AND c.asof_dt =
(SELECT MAX (c1.asof_dt)
FROM ps_fi_iother_r00 c1
WHERE c.business_unit = c1.business_unit
AND c1.fi_instrument_id = c.fi_instrument_id)) c,
(SELECT upload_date - 15 upload_date
FROM stg_ftp_trans_bal_tb
WHERE setid = 'PKSTN' AND ROWNUM < 2),
(SELECT i.business_unit, i.fi_instrument_id, i.pf_system_code,
i.fi_contract_id
FROM ps_fi_instr_f00 i, ps_scb_bus_unit b1
WHERE i.business_unit = b1.business_unit
AND b1.setid = 'PKSTN'
AND (i.asof_dt) =
(SELECT MAX (i1.asof_dt)
FROM ps_fi_instr_f00 i1
WHERE i.business_unit = i1.business_unit
AND i1.fi_instrument_id = i.fi_instrument_id)) d
...Try to use something like this instead:
(select * from
(SELECT c.business_unit, c.fi_instrument_id, c.scb_arm_code,
        c.scb_tp_product, c.scb_tranche_id, c.scb_bncpr_flg,
        rank() over (order by c.asof_dt desc partition by c.business_unit, c.fi_instrument_id) rnk
   FROM ps_fi_iother_r00 c, ps_scb_bus_unit b1
  WHERE c.business_unit = b1.business_unit
    AND b1.setid = 'PKSTN')
where rnk = 1) c,
...2. This piece seems to be questionable since it seems to pick the "UPLOAD_DATE" from an arbitrary row where SETID = 'PKSTN'. I assume that the UPLOAD_DATE is then the same for all these rows, otherwise this would potentially return a different UPLOAD_DATE for each execution of the query. Still it's a questionable approach and seems to be de-normalized data.
(SELECT upload_date - 15 upload_date
FROM stg_ftp_trans_bal_tb
WHERE setid = 'PKSTN' AND ROWNUM < 2),3. Your execution plan contains some parts that are questionable and might lead to inappropriate work performed by the database if the estimates of optimizer are wrong:
a. Are you sure that the filter predicate "SETID"='PKSTN' on PS_SCB_BUS_UNIT returns only a single row? If not, below NESTED LOOP operation could scan the PS_FI_IOTHER_R00 table more than once making this rather inefficient
|  27 |                NESTED LOOPS              |                      |   221K|    10M|       |  3380   (3)|       |       |        |      |            |
|  28 |                 NESTED LOOPS             |                      |     1 |    16 |       |  2351   (2)|       |       |        |      |            |
|  29 |                  VIEW                    |                      |     1 |     6 |       |  2349   (2)|       |       |        |      |            |
|* 30 |                   COUNT STOPKEY          |                      |       |       |       |            |       |       |        |      |            |
|  31 |                    PARTITION LIST SINGLE |                      |   661K|  7755K|       |  2349   (2)|   KEY |   KEY |        |      |            |
|  32 |                     TABLE ACCESS FULL    | STG_FTP_TRANS_BAL_TB |   661K|  7755K|       |  2349   (2)|     2 |     2 |        |      |            |
|* 33 |                  TABLE ACCESS FULL       | PS_SCB_BUS_UNIT      |     1 |    10 |       |     2   (0)|       |       |        |      |            |
|  34 |                 PARTITION LIST ITERATOR  |                      |   442K|    14M|       |  1029   (3)|   KEY |   KEY |        |      |            |
|* 35 |                  TABLE ACCESS FULL       | PS_FI_IOTHER_R00     |   442K|    14M|       |  1029   (3)|   KEY |   KEY |        |      |            |b. The optimizer assumes that below join returns only 3907 rows out of the 54k and 221k source sets. This could be wrong, because the join expression contains multiple function calls and an implicit TO_NUMBER conversion you haven't mentioned in your SQL which is bad practice in general:
19 - access("A"."BUSINESS_UNIT"="C"."BUSINESS_UNIT" AND "A"."FI_INSTRUMENT_ID"="C"."FI_INSTRUMENT_ID" AND
"FISCAL_YEAR"=TO_NUMBER(TO_CHAR("UPLOAD_DATE",'YYYY')) AND "ACCOUNTING_PERIOD"=TO_NUMBER(TO_CHAR("UPLOAD_DATE",'MM')))The conversion functions might hide from the optimizer that the join returns many more rows than estimated, because the optimizer uses default selectivities or guesses for function expressions. If you can't fix the data model to use appropriate join expressions you could try to create function based indexes on the expressions TO_NUMBER(TO_CHAR("UPLOAD_DATE",'YYYY')) and TO_NUMBER(TO_CHAR("UPLOAD_DATE",'MM')) and gather statistics on the corresponding hidden columns (method_opt parameter of DBMS_STATS.GATHER_TABLE_STATS call set to "FOR ALL HIDDEN COLUMNS"). If you're already on 11g you can achieve the same by using virtual columns.
|* 19 |            HASH JOIN                     |                      |  3907 |   526K|       |  3997   (2)|       |       |  Q1,04 | PCWP |            |
|  20 |             PX RECEIVE                   |                      | 54702 |  4700K|       |   616   (1)|       |       |  Q1,04 | PCWP |            |
|  21 |              PX SEND HASH                | :TQ10003             | 54702 |  4700K|       |   616   (1)|       |       |  Q1,03 | P->P | HASH       |
|  22 |               PX BLOCK ITERATOR          |                      | 54702 |  4700K|       |   616   (1)|     1 |  6119 |  Q1,03 | PCWC |            |
|* 23 |                TABLE ACCESS FULL         | PS_FI_ILDGR_F00      | 54702 |  4700K|       |   616   (1)|     1 |  6119 |  Q1,03 | PCWP |            |
|  24 |             BUFFER SORT                  |                      |       |       |       |            |       |       |  Q1,04 | PCWC |            |
|  25 |              PX RECEIVE                  |                      |   221K|    10M|       |  3380   (3)|       |       |  Q1,04 | PCWP |            |
|  26 |               PX SEND HASH               | :TQ10002             |   221K|    10M|       |  3380   (3)|       |       |        | S->P | HASH       |
|  27 |                NESTED LOOPS              |                      |   221K|    10M|       |  3380   (3)|       |       |        |      |            |
|  28 |                 NESTED LOOPS             |                      |     1 |    16 |       |  2351   (2)|       |       |        |      |            |
|  29 |                  VIEW                    |                      |     1 |     6 |       |  2349   (2)|       |       |        |      |            |
|* 30 |                   COUNT STOPKEY          |                      |       |       |       |            |       |       |        |      |            |
|  31 |                    PARTITION LIST SINGLE |                      |   661K|  7755K|       |  2349   (2)|   KEY |   KEY |        |      |            |
|  32 |                     TABLE ACCESS FULL    | STG_FTP_TRANS_BAL_TB |   661K|  7755K|       |  2349   (2)|     2 |     2 |        |      |            |
|* 33 |                  TABLE ACCESS FULL       | PS_SCB_BUS_UNIT      |     1 |    10 |       |     2   (0)|       |       |        |      |            |
|  34 |                 PARTITION LIST ITERATOR  |                      |   442K|    14M|       |  1029   (3)|   KEY |   KEY |        |      |            |
|* 35 |                  TABLE ACCESS FULL       | PS_FI_IOTHER_R00     |   442K|    14M|       |  1029   (3)|   KEY |   KEY |        |      |            |c. Due to the small number of rows estimated, mainly caused by b. above, the result of the joins is broadcasted to all parallel slaves when performing the final join. This might be quite inefficient if the result is much larger than expected.
|   6 |       PX SEND BROADCAST                  | :TQ10004             |   977 |   190K|       |  4273   (2)|       |       |  Q1,04 | P->P | BROADCAST  |Note that this join is not necessary any longer / obsolete if you introduce above analytic functions as suggested.
4. Your PLAN_TABLE does not match your Oracle version. If you're already on 10g or later, simply drop all PLAN_TABLEs in non-SYS schemas since there is already one provided as part of the data dictionary. Otherwise re-create them using $ORACLE_HOME/rdbms/admin/utlxplan.sql
Note
- 'PLAN_TABLE' is old versionIf you want to understand where the majority of the time is spent you need to trace the execution. Note that your statement introduces an increased complexity because it uses parallel execution, therefore you'll end up with multiple trace files per parallel slave and query coordinator process, which makes the analysis not that straightforward.
Please read this HOW TO: Post a SQL statement tuning request - template posting that explains how you can enable the statement trace and what you should provide if you have SQL statement tuning question and how to format it here so that the posted information is readable by others.
This accompanying blog post shows step-by-step instructions how to obtain that information.
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/