A sql tuning issue
Hi,
In a data warehousing env, version 11.1.0.7.0 on Redhat linux.
run a query like below,select sum(case when T495255.PAYMENT_TYPE_ID = 3 then T495255.PAYMENT_ADJUSTMENT_AMOUNT end ) as c1,
max(T494961.DATE_VALUE) as c2,
sum(T495343.CURRENT_BALANCE_AMOUNT) as c3,
sum(T495343.FINAL_BILL_AMOUNT) as c4,
T495414.RECORDSTATUSIND_DESC as c5,
T495272.DATE_DESC as c6,
T495414.BTN as c7,
T495414.FINAL_RECEIVED_AMOUNT as c8,
T495414.ACCOUNT_NUMBER as c9,
T495414.DISCONNECT_REASON_DESC as c10,
T495414.LIQUIDITY_SCORE as c11,
T495414.STATE as c12,
T495414.REGION_DESCRIPTION as c13,
T495323.LIQUIDITY_SCORE_DESCRIPTION as c14,
T495360.BATCH_STATUS as c15
from
D_DATE T495294 /* D_DATE_CREATED */ ,
F_BATCH T495360 /* F_BATCH_Lscore */ ,
D_LIQUIDITY_SCORE_REASON T495323 /* D_LIQUIDITY_SCORE_REASON_DETAIL */ ,
F_LIQUIDITY_SCORE T495343 /* F_LIQUIDITY_SCORE_DETAIL */ left outer join (
F_PAYMENT_ADJUSTMENT_FINALS T495255 /* F_PAYMENT_ADJUSTMENT_FINALS_LSCORE */ left outer join D_DATE T494961 /* D_DATE_PAYMENT_ADJUSTMENT */ On T494961.DATE_ID = T495255.PAYMENT_ADJUSTMENT_DATE) On T495255.ACCOUNT_ID = T495343.ACCOUNT_ID,
D_DATE T495272 /* D_DATE_BILL_DATE */ ,
T_ACCOUNT_FINALS_DTL T495414 /* T_ACCOUNT_FINALS_DTL_LSCORE */
where ( T495294.DATE_ID = T495360.START_DATE and T495272.DATE_ID = T495414.FINAL_BILL_DATE and T495323.LIQUIDITY_SCORE_ID = T495343.LIQUIDITY_SCORE_REASON_ID and T495343.ACCOUNT_ID = T495414.ACCOUNT_ID and T495294.YEAR_DESC = 'Year 2010' and T495343.LIQUIDITY_SCORE_IMP_BATCH_ID = T495360.SOURCE_BATCH_ID and T495414.REGION_DESCRIPTION = '8-FinalsRM' )
group by T495272.DATE_DESC, T495323.LIQUIDITY_SCORE_DESCRIPTION, T495360.BATCH_STATUS, T495414.ACCOUNT_NUMBER, T495414.BTN, T495414.DISCONNECT_REASON_DESC, T495414.FINAL_RECEIVED_AMOUNT, T495414.LIQUIDITY_SCORE, T495414.RECORDSTATUSIND_DESC, T495414.REGION_DESCRIPTION, T495414.STATE;
explain is like below,
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 26M| 5784M| | 45903 (1)| 00:09:11 | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10010 | 26M| 5784M| | 45903 (1)| 00:09:11 | Q1,10 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 26M| 5784M| 6243M| 45903 (1)| 00:09:11 | Q1,10 | PCWP | |
| 4 | PX RECEIVE | | 26M| 5784M| | 45903 (1)| 00:09:11 | Q1,10 | PCWP | |
| 5 | PX SEND HASH | :TQ10009 | 26M| 5784M| | 45903 (1)| 00:09:11 | Q1,09 | P->P | HASH |
| 6 | HASH GROUP BY | | 26M| 5784M| 6243M| 45903 (1)| 00:09:11 | Q1,09 | PCWP | |
|* 7 | HASH JOIN OUTER | | 26M| 5784M| | 25403 (1)| 00:05:05 | Q1,09 | PCWP | |
| 8 | PX RECEIVE | | 3648K| 657M| | 20227 (1)| 00:04:03 | Q1,09 | PCWP | |
| 9 | PX SEND HASH | :TQ10007 | 3648K| 657M| | 20227 (1)| 00:04:03 | Q1,07 | P->P | HASH |
|* 10 | HASH JOIN BUFFERED | | 3648K| 657M| | 20227 (1)| 00:04:03 | Q1,07 | PCWP | |
| 11 | PX RECEIVE | | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,07 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10003 | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | P->P | BROADCAST |
| 13 | PX BLOCK ITERATOR | | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | PCWC | |
| 14 | TABLE ACCESS FULL | D_DATE | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 15 | HASH JOIN | | 3648K| 577M| | 20224 (1)| 00:04:03 | Q1,07 | PCWP | |
| 16 | BUFFER SORT | | | | | | | Q1,07 | PCWC | |
| 17 | PX RECEIVE | | 10 | 200 | | 3 (0)| 00:00:01 | Q1,07 | PCWP | |
| 18 | PX SEND BROADCAST | :TQ10001 | 10 | 200 | | 3 (0)| 00:00:01 | | S->P | BROADCAST |
| 19 | TABLE ACCESS FULL | D_LIQUIDITY_SCORE_REASON | 10 | 200 | | 3 (0)| 00:00:01 | | | |
|* 20 | HASH JOIN | | 3648K| 507M| | 20220 (1)| 00:04:03 | Q1,07 | PCWP | |
| 21 | PX RECEIVE | | 3649K| 180M| | 337 (3)| 00:00:05 | Q1,07 | PCWP | |
| 22 | PX SEND HASH | :TQ10004 | 3649K| 180M| | 337 (3)| 00:00:05 | Q1,04 | P->P | HASH |
|* 23 | HASH JOIN | | 3649K| 180M| | 337 (3)| 00:00:05 | Q1,04 | PCWP | |
| 24 | PX RECEIVE | | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,04 | PCWP | |
| 25 | PX SEND BROADCAST | :TQ10002 | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,02 | P->P | BROADCAST |
| 26 | PX BLOCK ITERATOR | | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,02 | PCWC | |
|* 27 | TABLE ACCESS FULL | D_DATE | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,02 | PCWP | |
|* 28 | HASH JOIN | | 9431K| 323M| | 334 (2)| 00:00:05 | Q1,04 | PCWP | |
| 29 | BUFFER SORT | | | | | | | Q1,04 | PCWC | |
| 30 | PX RECEIVE | | 1975 | 25675 | | 8 (0)| 00:00:01 | Q1,04 | PCWP | |
| 31 | PX SEND BROADCAST | :TQ10000 | 1975 | 25675 | | 8 (0)| 00:00:01 | | S->P | BROADCAST |
| 32 | TABLE ACCESS FULL| F_BATCH | 1975 | 25675 | | 8 (0)| 00:00:01 | | | |
| 33 | PX BLOCK ITERATOR | | 9431K| 206M| | 324 (2)| 00:00:04 | Q1,04 | PCWC | |
| 34 | TABLE ACCESS FULL | F_LIQUIDITY_SCORE | 9431K| 206M| | 324 (2)| 00:00:04 | Q1,04 | PCWP | |
| 35 | PX RECEIVE | | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,07 | PCWP | |
| 36 | PX SEND HASH | :TQ10005 | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | P->P | HASH |
| 37 | PX BLOCK ITERATOR | | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | PCWC | |
|* 38 | TABLE ACCESS FULL | T_ACCOUNT_FINALS_DTL | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | PCWP | |
| 39 | PX RECEIVE | | 113M| 4448M| | 5165 (1)| 00:01:02 | Q1,09 | PCWP | |
| 40 | PX SEND HASH | :TQ10008 | 113M| 4448M| | 5165 (1)| 00:01:02 | Q1,08 | P->P | HASH |
| 41 | VIEW | | 113M| 4448M| | 5165 (1)| 00:01:02 | Q1,08 | PCWP | |
|* 42 | HASH JOIN RIGHT OUTER | | 113M| 3472M| | 5165 (1)| 00:01:02 | Q1,08 | PCWP | |
| 43 | PX RECEIVE | | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,08 | PCWP | |
| 44 | PX SEND BROADCAST | :TQ10006 | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | P->P | BROADCAST |
| 45 | PX BLOCK ITERATOR | | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | PCWC | |
| 46 | TABLE ACCESS FULL | D_DATE | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | PCWP | |
| 47 | PX BLOCK ITERATOR | | 113M| 1953M| | 5151 (1)| 00:01:02 | Q1,08 | PCWC | |
| 48 | TABLE ACCESS FULL | F_PAYMENT_ADJUSTMENT_FINALS | 113M| 1953M| | 5151 (1)| 00:01:02 | Q1,08 | PCWP | |
Predicate Information (identified by operation id):
7 - access("T495255"."ACCOUNT_ID"(+)="T495343"."ACCOUNT_ID")
10 - access("T495272"."DATE_ID"="T495414"."FINAL_BILL_DATE")
15 - access("T495323"."LIQUIDITY_SCORE_ID"="T495343"."LIQUIDITY_SCORE_REASON_ID")
20 - access("T495343"."ACCOUNT_ID"="T495414"."ACCOUNT_ID")
23 - access("T495294"."DATE_ID"="T495360"."START_DATE")
27 - filter("T495294"."YEAR_DESC"='Year 2010')
28 - access("T495343"."LIQUIDITY_SCORE_IMP_BATCH_ID"="T495360"."SOURCE_BATCH_ID")
38 - filter("T495414"."REGION_DESCRIPTION"='8-FinalsRM')
42 - access("T494961"."DATE_ID"(+)="T495255"."PAYMENT_ADJUSTMENT_DATE")
Put hint into query, like
select /*+ star_transformation CACHE(T495294) PARALLEL(T495414 32,2) PARALLEL(T495255 32,2) PARALLEL(T495343 32,2) PARALLEL(T495272 32,2) PARALLEL(T495360 32,2) */ sum(case when T495255.PAYMENT_TYPE_ID = 3 then T495255.PAYMENT_ADJUSTMENT_AMOUNT end ) as c1,
max(T494961.DATE_VALUE) as c2,
sum(T495343.CURRENT_BALANCE_AMOUNT) as c3,
sum(T495343.FINAL_BILL_AMOUNT) as c4,
T495414.RECORDSTATUSIND_DESC as c5,
T495272.DATE_DESC as c6,
T495414.BTN as c7,
T495414.FINAL_RECEIVED_AMOUNT as c8,
T495414.ACCOUNT_NUMBER as c9,
T495414.DISCONNECT_REASON_DESC as c10,
T495414.LIQUIDITY_SCORE as c11,
T495414.STATE as c12,
T495414.REGION_DESCRIPTION as c13,
T495323.LIQUIDITY_SCORE_DESCRIPTION as c14,
T495360.BATCH_STATUS as c15
from
D_DATE T495294 /* D_DATE_CREATED */ ,
F_BATCH T495360 /* F_BATCH_Lscore */ ,
D_LIQUIDITY_SCORE_REASON T495323 /* D_LIQUIDITY_SCORE_REASON_DETAIL */ ,
F_LIQUIDITY_SCORE T495343 /* F_LIQUIDITY_SCORE_DETAIL */ left outer join (
F_PAYMENT_ADJUSTMENT_FINALS T495255 /* F_PAYMENT_ADJUSTMENT_FINALS_LSCORE */ left outer join D_DATE T494961 /* D_DATE_PAYMENT_ADJUSTMENT */ On T494961.DATE_ID = T495255.PAYMENT_ADJUSTMENT_DATE) On T495255.ACCOUNT_ID = T495343.ACCOUNT_ID,
D_DATE T495272 /* D_DATE_BILL_DATE */ ,
T_ACCOUNT_FINALS_DTL T495414 /* T_ACCOUNT_FINALS_DTL_LSCORE */
where ( T495294.DATE_ID = T495360.START_DATE and T495272.DATE_ID = T495414.FINAL_BILL_DATE and T495323.LIQUIDITY_SCORE_ID = T495343.LIQUIDITY_SCORE_REASON_ID and T495343.ACCOUNT_ID = T495414.ACCOUNT_ID and T495294.YEAR_DESC = 'Year 2010' and T495343.LIQUIDITY_SCORE_IMP_BATCH_ID = T495360.SOURCE_BATCH_ID and T495414.REGION_DESCRIPTION = '8-FinalsRM' )
group by T495272.DATE_DESC, T495323.LIQUIDITY_SCORE_DESCRIPTION, T495360.BATCH_STATUS, T495414.ACCOUNT_NUMBER, T495414.BTN, T495414.DISCONNECT_REASON_DESC, T495414.FINAL_RECEIVED_AMOUNT, T495414.LIQUIDITY_SCORE, T495414.RECORDSTATUSIND_DESC, T495414.REGION_DESCRIPTION, T495414.STATE;
explain plan is
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 69M| 14G| | 76473 (1)| 00:15:18 | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10010 | 69M| 14G| | 76473 (1)| 00:15:18 | Q1,10 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 69M| 14G| 15G| 76473 (1)| 00:15:18 | Q1,10 | PCWP | |
| 4 | PX RECEIVE | | 69M| 14G| | 25397 (1)| 00:05:05 | Q1,10 | PCWP | |
| 5 | PX SEND HASH | :TQ10009 | 69M| 14G| | 25397 (1)| 00:05:05 | Q1,09 | P->P | HASH |
|* 6 | HASH JOIN OUTER BUFFERED | | 69M| 14G| | 25397 (1)| 00:05:05 | Q1,09 | PCWP | |
| 7 | PX RECEIVE | | 3648K| 657M| | 20221 (1)| 00:04:03 | Q1,09 | PCWP | |
| 8 | PX SEND HASH | :TQ10007 | 3648K| 657M| | 20221 (1)| 00:04:03 | Q1,07 | P->P | HASH |
|* 9 | HASH JOIN BUFFERED | | 3648K| 657M| | 20221 (1)| 00:04:03 | Q1,07 | PCWP | |
| 10 | PX RECEIVE | | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,07 | PCWP | |
| 11 | PX SEND BROADCAST | :TQ10003 | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | P->P | BROADCAST |
| 12 | PX BLOCK ITERATOR | | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | PCWC | |
| 13 | TABLE ACCESS FULL | D_DATE | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 14 | HASH JOIN | | 3648K| 577M| | 20218 (1)| 00:04:03 | Q1,07 | PCWP | |
| 15 | BUFFER SORT | | | | | | | Q1,07 | PCWC | |
| 16 | PX RECEIVE | | 10 | 200 | | 3 (0)| 00:00:01 | Q1,07 | PCWP | |
| 17 | PX SEND BROADCAST | :TQ10000 | 10 | 200 | | 3 (0)| 00:00:01 | | S->P | BROADCAST |
| 18 | TABLE ACCESS FULL | D_LIQUIDITY_SCORE_REASON | 10 | 200 | | 3 (0)| 00:00:01 | | | |
|* 19 | HASH JOIN | | 3648K| 507M| | 20214 (1)| 00:04:03 | Q1,07 | PCWP | |
| 20 | PX RECEIVE | | 3649K| 180M| | 331 (3)| 00:00:04 | Q1,07 | PCWP | |
| 21 | PX SEND HASH | :TQ10004 | 3649K| 180M| | 331 (3)| 00:00:04 | Q1,04 | P->P | HASH |
|* 22 | HASH JOIN | | 3649K| 180M| | 331 (3)| 00:00:04 | Q1,04 | PCWP | |
| 23 | PX RECEIVE | | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,04 | PCWP | |
| 24 | PX SEND BROADCAST | :TQ10001 | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,01 | P->P | BROADCAST |
| 25 | PX BLOCK ITERATOR | | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,01 | PCWC | |
|* 26 | TABLE ACCESS FULL | D_DATE | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,01 | PCWP | |
|* 27 | HASH JOIN | | 9431K| 323M| | 328 (2)| 00:00:04 | Q1,04 | PCWP | |
| 28 | PX RECEIVE | | 1975 | 25675 | | 2 (0)| 00:00:01 | Q1,04 | PCWP | |
| 29 | PX SEND BROADCAST | :TQ10002 | 1975 | 25675 | | 2 (0)| 00:00:01 | Q1,02 | P->P | BROADCAST |
| 30 | PX BLOCK ITERATOR | | 1975 | 25675 | | 2 (0)| 00:00:01 | Q1,02 | PCWC | |
| 31 | TABLE ACCESS FULL| F_BATCH | 1975 | 25675 | | 2 (0)| 00:00:01 | Q1,02 | PCWP | |
| 32 | PX BLOCK ITERATOR | | 9431K| 206M| | 324 (2)| 00:00:04 | Q1,04 | PCWC | |
| 33 | TABLE ACCESS FULL | F_LIQUIDITY_SCORE | 9431K| 206M| | 324 (2)| 00:00:04 | Q1,04 | PCWP | |
| 34 | PX RECEIVE | | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,07 | PCWP | |
| 35 | PX SEND HASH | :TQ10005 | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | P->P | HASH |
| 36 | PX BLOCK ITERATOR | | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | PCWC | |
|* 37 | TABLE ACCESS FULL | T_ACCOUNT_FINALS_DTL | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | PCWP | |
| 38 | PX RECEIVE | | 113M| 3038M| | 5165 (1)| 00:01:02 | Q1,09 | PCWP | |
| 39 | PX SEND HASH | :TQ10008 | 113M| 3038M| | 5165 (1)| 00:01:02 | Q1,08 | P->P | HASH |
| 40 | VIEW | | 113M| 3038M| | 5165 (1)| 00:01:02 | Q1,08 | PCWP | |
|* 41 | HASH JOIN OUTER | | 113M| 3472M| | 5182 (2)| 00:01:03 | Q1,08 | PCWP | |
| 42 | PX BLOCK ITERATOR | | 113M| 1953M| | 5151 (1)| 00:01:02 | Q1,08 | PCWC | |
| 43 | TABLE ACCESS FULL | F_PAYMENT_ADJUSTMENT_FINALS | 113M| 1953M| | 5151 (1)| 00:01:02 | Q1,08 | PCWP | |
| 44 | BUFFER SORT | | | | | | | Q1,08 | PCWC | |
| 45 | PX RECEIVE | | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,08 | PCWP | |
| 46 | PX SEND BROADCAST | :TQ10006 | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | P->P | BROADCAST |
| 47 | PX BLOCK ITERATOR | | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | PCWC | |
| 48 | TABLE ACCESS FULL | D_DATE | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | PCWP | |
it return 19000 row with elapse time 2 mins (before tuning, its 3 minutes and more)
(T_ACCOUNT_FINALS_DTL (51G) AND F_PAYMENT_ADJUSTMENT_FINALS (13G) ARE TWO HUGE TALBES HERE)
Is there better way to tune it??
thanks a lot
Jerry
Edited by: jerrygreat on Jul 13, 2010 2:19 PM
Edited by: jerrygreat on Jul 13, 2010 2:57 PM
Can you please (after 414 posts you should know)
a) use the templates to post a tuning question
b) format your code
c) use the tags to make sure identation is preserved.
Other than that: why are you not using the templates and using the tag?
It is minimal effort on your part, and it would take others hours to format the JUNK you are posting everytime!
Sybrand Bakker
Senior Oracle DBA
Similar Messages
-
A SQL tuning issue-sql runs much slower in test than in production?
Hi Buddies,
I am working on a sql tuning issue. A sql runs much slower in test than in production.
I compared the two explain plans in test and production
seems in test, CBO refuses to use index SUBLEDGER_ENTRY_I2.
we rebuile it and re-gether that index statistcs. run, still slow..
I compared the init.ora parameters like hash_area_size, sort_area_size in test, they are same as production.
I wonder if any expert friend can show some light.
in production,
SQL> set autotrace traceonly
SQL> SELECT rpt_horizon_subledger_entry_vw.onst_offst_cd,
2 rpt_horizon_subledger_entry_vw.bkng_prd,
3 rpt_horizon_subledger_entry_vw.systm_afflt_cd,
4 rpt_horizon_subledger_entry_vw.jrnl_id,
5 rpt_horizon_subledger_entry_vw.ntrl_accnt_cd,
6 rpt_horizon_subledger_entry_vw.gnrl_ldgr_chrt_of_accnt_nm,
7 rpt_horizon_subledger_entry_vw.lgl_entty_brnch_cd,
8 rpt_horizon_subledger_entry_vw.crprt_melob_cd AS corp_mlb_cd,
rpt_horizon_subledger_entry_vw.onst_offst_cd, SUM (amt) AS amount
9 10 FROM rpt_horizon_subledger_entry_vw
11 WHERE rpt_horizon_subledger_entry_vw.bkng_prd = '092008'
12 AND rpt_horizon_subledger_entry_vw.jrnl_id = 'RCS0002100'
13 AND rpt_horizon_subledger_entry_vw.systm_afflt_cd = 'SAFF01'
14 GROUP BY rpt_horizon_subledger_entry_vw.onst_offst_cd,
15 rpt_horizon_subledger_entry_vw.bkng_prd,
16 rpt_horizon_subledger_entry_vw.systm_afflt_cd,
17 rpt_horizon_subledger_entry_vw.jrnl_id,
18 rpt_horizon_subledger_entry_vw.ntrl_accnt_cd,
19 rpt_horizon_subledger_entry_vw.gnrl_ldgr_chrt_of_accnt_nm,
20 rpt_horizon_subledger_entry_vw.lgl_entty_brnch_cd,
21 rpt_horizon_subledger_entry_vw.crprt_melob_cd,
22 rpt_horizon_subledger_entry_vw.onst_offst_cd;
491 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=130605 Card=218764 B
ytes=16407300)
1 0 SORT (GROUP BY) (Cost=130605 Card=218764 Bytes=16407300)
2 1 VIEW OF 'RPT_HORIZON_SUBLEDGER_ENTRY_VW' (Cost=129217 Ca
rd=218764 Bytes=16407300)
3 2 SORT (UNIQUE) (Cost=129217 Card=218764 Bytes=35877296)
4 3 UNION-ALL
5 4 HASH JOIN (Cost=61901 Card=109382 Bytes=17719884)
6 5 TABLE ACCESS (FULL) OF 'GNRL_LDGR_CHRT_OF_ACCNT'
(Cost=2 Card=111 Bytes=3774)
7 5 HASH JOIN (Cost=61897 Card=109382 Bytes=14000896
8 7 TABLE ACCESS (FULL) OF 'SUBLEDGER_CHART_OF_ACC
OUNT' (Cost=2 Card=57 Bytes=1881)
9 7 HASH JOIN (Cost=61893 Card=109382 Bytes=103912
90)
10 9 TABLE ACCESS (FULL) OF 'HORIZON_LINE' (Cost=
34 Card=4282 Bytes=132742)
11 9 HASH JOIN (Cost=61833 Card=109390 Bytes=7000
960)
12 11 TABLE ACCESS (BY INDEX ROWID) OF 'SUBLEDGE
R_ENTRY' (Cost=42958 Card=82076 Bytes=3611344)
13 12 INDEX (RANGE SCAN) OF 'SUBLEDGER_ENTRY_I
2' (NON-UNIQUE) (Cost=1069 Card=328303)
14 11 TABLE ACCESS (FULL) OF 'HORIZON_SUBLEDGER_
LINK' (Cost=14314 Card=9235474 Bytes=184709480)
15 4 HASH JOIN (Cost=61907 Card=109382 Bytes=18157412)
16 15 TABLE ACCESS (FULL) OF 'GNRL_LDGR_CHRT_OF_ACCNT'
(Cost=2 Card=111 Bytes=3774)
17 15 HASH JOIN (Cost=61903 Card=109382 Bytes=14438424
18 17 TABLE ACCESS (FULL) OF 'SUBLEDGER_CHART_OF_ACC
OUNT' (Cost=2 Card=57 Bytes=1881)
19 17 HASH JOIN (Cost=61899 Card=109382 Bytes=108288
18)
20 19 TABLE ACCESS (FULL) OF 'HORIZON_LINE' (Cost=
34 Card=4282 Bytes=132742)
21 19 HASH JOIN (Cost=61838 Card=109390 Bytes=7438
520)
22 21 TABLE ACCESS (BY INDEX ROWID) OF 'SUBLEDGE
R_ENTRY' (Cost=42958 Card=82076 Bytes=3939648)
23 22 INDEX (RANGE SCAN) OF 'SUBLEDGER_ENTRY_I
2' (NON-UNIQUE) (Cost=1069 Card=328303)
24 21 TABLE ACCESS (FULL) OF 'HORIZON_SUBLEDGER_
LINK' (Cost=14314 Card=9235474 Bytes=184709480)
Statistics
25 recursive calls
18 db block gets
343266 consistent gets
370353 physical reads
0 redo size
15051 bytes sent via SQL*Net to client
1007 bytes received via SQL*Net from client
34 SQL*Net roundtrips to/from client
1 sorts (memory)
1 sorts (disk)
491 rows processed
in test
SQL> set autotrace traceonly
SQL> SELECT rpt_horizon_subledger_entry_vw.onst_offst_cd,
2 rpt_horizon_subledger_entry_vw.bkng_prd,
3 rpt_horizon_subledger_entry_vw.systm_afflt_cd,
4 rpt_horizon_subledger_entry_vw.jrnl_id,
5 rpt_horizon_subledger_entry_vw.ntrl_accnt_cd,
rpt_horizon_subledger_entry_vw.gnrl_ldgr_chrt_of_accnt_nm,
6 7 rpt_horizon_subledger_entry_vw.lgl_entty_brnch_cd,
8 rpt_horizon_subledger_entry_vw.crprt_melob_cd AS corp_mlb_cd,
9 rpt_horizon_subledger_entry_vw.onst_offst_cd, SUM (amt) AS amount
10 FROM rpt_horizon_subledger_entry_vw
11 WHERE rpt_horizon_subledger_entry_vw.bkng_prd = '092008'
12 AND rpt_horizon_subledger_entry_vw.jrnl_id = 'RCS0002100'
AND rpt_horizon_subledger_entry_vw.systm_afflt_cd = 'SAFF01'
13 14 GROUP BY rpt_horizon_subledger_entry_vw.onst_offst_cd,
15 rpt_horizon_subledger_entry_vw.bkng_prd,
16 rpt_horizon_subledger_entry_vw.systm_afflt_cd,
17 rpt_horizon_subledger_entry_vw.jrnl_id,
18 rpt_horizon_subledger_entry_vw.ntrl_accnt_cd,
rpt_horizon_subledger_entry_vw.gnrl_ldgr_chrt_of_accnt_nm,
rpt_horizon_subledger_entry_vw.lgl_entty_brnch_cd,
rpt_horizon_subledger_entry_vw.crprt_melob_cd,
rpt_horizon_subledger_entry_vw.onst_offst_cd; 19 20 21 22
no rows selected
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=92944 Card=708 Bytes
=53100)
1 0 SORT (GROUP BY) (Cost=92944 Card=708 Bytes=53100)
2 1 VIEW OF 'RPT_HORIZON_SUBLEDGER_ENTRY_VW' (Cost=92937 Car
d=708 Bytes=53100)
3 2 SORT (UNIQUE) (Cost=92937 Card=708 Bytes=124962)
4 3 UNION-ALL
5 4 HASH JOIN (Cost=46456 Card=354 Bytes=60180)
6 5 TABLE ACCESS (FULL) OF 'SUBLEDGER_CHART_OF_ACCOU
NT' (Cost=2 Card=57 Bytes=1881)
7 5 NESTED LOOPS (Cost=46453 Card=354 Bytes=48498)
8 7 HASH JOIN (Cost=11065 Card=17694 Bytes=1362438
9 8 HASH JOIN (Cost=27 Card=87 Bytes=5133)
10 9 TABLE ACCESS (FULL) OF 'HORIZON_LINE' (Cos
t=24 Card=87 Bytes=2175)
11 9 TABLE ACCESS (FULL) OF 'GNRL_LDGR_CHRT_OF_
ACCNT' (Cost=2 Card=111 Bytes=3774)
12 8 TABLE ACCESS (FULL) OF 'HORIZON_SUBLEDGER_LI
NK' (Cost=11037 Card=142561 Bytes=2566098)
13 7 TABLE ACCESS (BY INDEX ROWID) OF 'SUBLEDGER_EN
TRY' (Cost=2 Card=1 Bytes=60)
14 13 INDEX (UNIQUE SCAN) OF 'SUBLEDGER_ENTRY_PK'
(UNIQUE) (Cost=1 Card=1)
15 4 HASH JOIN (Cost=46456 Card=354 Bytes=64782)
16 15 TABLE ACCESS (FULL) OF 'SUBLEDGER_CHART_OF_ACCOU
NT' (Cost=2 Card=57 Bytes=1881)
17 15 NESTED LOOPS (Cost=46453 Card=354 Bytes=53100)
18 17 HASH JOIN (Cost=11065 Card=17694 Bytes=1362438
19 18 HASH JOIN (Cost=27 Card=87 Bytes=5133)
20 19 TABLE ACCESS (FULL) OF 'HORIZON_LINE' (Cos
t=24 Card=87 Bytes=2175)
21 19 TABLE ACCESS (FULL) OF 'GNRL_LDGR_CHRT_OF_
ACCNT' (Cost=2 Card=111 Bytes=3774)
22 18 TABLE ACCESS (FULL) OF 'HORIZON_SUBLEDGER_LI
NK' (Cost=11037 Card=142561 Bytes=2566098)
23 17 TABLE ACCESS (BY INDEX ROWID) OF 'SUBLEDGER_EN
TRY' (Cost=2 Card=1 Bytes=73)
24 23 INDEX (UNIQUE SCAN) OF 'SUBLEDGER_ENTRY_PK'
(UNIQUE) (Cost=1 Card=1)
Statistics
1134 recursive calls
0 db block gets
38903505 consistent gets
598254 physical reads
60 redo size
901 bytes sent via SQL*Net to client
461 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
34 sorts (memory)
0 sorts (disk)
0 rows processed
Thanks a lot in advance
JerryHi
Basically there are two kinds of tables
- fact
- lookup
The number of records in a lookup table is usually small.
The number of records in a fact table is usually huge.
However, in test systems the number of records in a fact table is often also small.
This results in different execution plans.
I notice again you don't post version and platform info, and you didn't make sure your explain is properly idented
Please read the FAQ to make sure it is properly idented.
Also using the word 'buddies' is as far as I am concerned nearing disrespect and rudeness.
Sybrand Bakker
Senior Oracle DBA -
Hi, I would like some help tuning the following query:
SELECT distinct
cs.study,
de.STUDY_SITE Site,
iv.last_name INV,
de.PATIENT ,
pv.visit_number Visit,
-- REPLACE(asm.assessor_name, ',', '|') assessor_name,
de.DISCREPANCY_REV_STATUS_CODE Status,
FROM
RXC.discrepancy_management de, -- a view driven by table rxc.discrepancy_enties
RXC.procedures pd,
clinical_studies cs,
ocl_investigators iv,
rxa_des.clinical_planned_events pv,
dcis dc
-- s999$stable.asmasm asm -- a view, pls see comments below
WHERE
cs.study='999'
and de.PROCEDURE_ID=pd.PROCEDURE_ID
and de.clinical_study_id=cs.clinical_study_id
and iv.investigator_id=de.investigator_id
and de.clin_plan_eve_id=pv.clin_plan_eve_id
and pv.clin_study_id=cs.clinical_study_id
and cs.clinical_study_id=dc.clinical_study_id
and de.patient not like '99%'
and de.dci_id= dc.dci_id
and de.discrepancy_status_code not in ('OBSOLETE')
and de.discrepancy_rev_status_code in ('INV REVIEW','INV PENDING')
--and de.patient = asm.pt(+)
--and de.clin_plan_eve_name = asm.cpevent(+)
--and asm.assessor_name(+) is not null
and nvl(asm.subsetsn, 99) in (12,15,99) this might not work
The above query takes 16 seconds to run but when I add in the view "s999$stable.asmasm asm" execution time drops
to about 25 mins. Looking at the related explain plans the difference is an index lookup on RXC.DISCREPANCY_ENTRIES (the driving
table used in view RXC.discrepancy_management) is dropped and replaced by a full table scan resulting in a large increase in the cost.
I've tried using the following hints without any success...
/*+ NO_MERGE(s9999$stable.asmasm) INDEX(DISCREPANCY_MANAGEMENT.DISCREPANCY_ENTRIES DISCREPANCY_ENT_CS_IDX */
Any help on the cause and fix for this issue would be much appreciated.When your query takes too long ...
HOW TO: Post a SQL statement tuning request - template posting -
Hi All,
we tried to run SQL Tuning Advisor on one of our database version 11.2.0.2 on server AIX. However on running the advisor we faced some issues with undo tablespace error due to this application was down for sometime. Can anyone please share his experience how to go about this. I have never encounter this issue before
Thanks
ShaanHi;
>
we tried to run SQL Tuning Advisor on one of our database version 11.2.0.2 on server AIX. However on running the advisor we faced some issues with undo tablespace error due to this application was down for sometime. Can anyone please share his experience how to go about this. I have never encounter this issue beforeSome issues like? What is error message? What alert log mention? What have you been changed? Give more details please
Regard
Helios -
Comples SQL performance issues in 11g
We are facing Performance Issues for a Complex SQL in Version 11.2. But earlier in 11.1 this SQL is performing well..
We dont have previous versions SQL Plan for this SQL Statement.
We Dont want to rewrite the SQL as this SQL has performed Well in previous versions.
Do we need to change the optimizer parameters so that the Query will be tuned automatically.
Please help me outIf you're licensed for the SQL Tuning Pack, you could run the query through the SQL Tuning Advisor see if it can improve.
It will probably recommend a SQL profile which you can accept.
You could also hint the SQL directly - you might just want to look at /*+ OPT_PARAM('OPTIMIZER_FEATURES_ENABLE','11.1.0.x') */ 'x' depending on your exact 11.1 version.
You could alter the session, set optimizer_features_enable and capture a SQL profile manually for the 11.1 plan.
You could do some root cause analysis as suggested by Karthick.
See threads:
How to post a SQL tuning request: HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long: When your query takes too long ...
For some recent relevant examples about identifying plans changes following upgrade, see also Coskan Gundogar's blog:
http://coskan.wordpress.com/2011/02/14/plan-stability-through-upgrade-why-is-my-plan-changed-bugfixes-1/
http://coskan.wordpress.com/2011/02/15/plan-stability-through-upgrade-why-is-my-plan-changed-bugfixes-2/
http://coskan.wordpress.com/2011/02/17/plan-stability-through-upgrade-why-is-my-plan-changed-new-optimizer-parameters/ -
Hi,
I want to improve myself about plsql tuning.
Just now I am only looking to explain plans and if there are any full table scan, I am trying to force plsql engine for using index table scans.
Sometimes we are creating new indexes. But I have lack of experience of plsql tuning.
Now I am watching videos of Steven Feuerstein about mistakes in plsql development.
Then I want to develop a plan for learning and improving myself about plsql tuning.
As I know trace and alert log is used for sql tuning or performance issues in Oracle databases. I also heard a method like tkprof.
Could you please advice me some tutorials or books about plsql tuning?
I will also be glad if you advice me concepts like trace method which I can use in tuning and performance improvement operations.
Regards&ThanksHi,
firstly you have to understand how the database works...I would recommend you to read Oracle Database Concepts:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/toc.htm
BTW, there is also a book in Oracle documentation - Performance Tuning Guide:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/toc.htm -
What should be take action against following sql tuning report.
Hi
what should be take action against following sql tuning report.
SQL ID : fn3mt5dvm7fba
SQL Text : SELECT * FROM (select
to_number(ow.waybl_no) waybl_no,ow.id wb_id,
To_Number(ogp.gp_no) gp_no,
To_Number(ots.trip_sht_no) trip_sht_no,
otr.nm,
ots.gty_br_mast_id,
DECODE(otr.sign_recd,'1','YES','NO') Sign_Recd,
DECODE(otr.stamped,'1','YES','NO') Stamped,
otr.dlvry_dt dlvry_dt,
otr.tel_no,
--otr.remarks,
Decode(otr.comments, NULL,'','Yes') remarks,
otr.id ID,ops_safex_utl.get_br_nm(to_number(ow.bkg_br_mast_id))
book_br,
ow.pick_dt book_date
from
ops_ts_reconsile otr,
ops_pultd_wb_dtls opuwd,
ops_trip_sht ots,
ops_waybl ow,
ops_ultd_wb_dtls ouwd,
ops_gate_pass ogp
where
otr.trip_sht_id=ots.id and
otr.pultd_wb_dtls_id=opuwd.id and
opuwd.ultd_wb_dtls_id=ouwd.id and
ouwd.gate_pass_id=ogp.id and
opuwd.waybl_id=ow.id and
otr.status_lid=157 and
ots.gty_br_mast_id = (:br_Id) and
(otr.dlvry_dt = :searchDate OR :searchDate IS NULL) and
otr.note_prpd = 'N' and otr.pod_recd = '1' and
not exists (select TS_RECONSILE_ID from OPS_POD_FRWD_NOTE_DTLS
where TS_RECONSILE_ID = otr.id)
union
select
to_number(ow.waybl_no) waybl_no, ow.id wb_id,
To_Number(ogp.gp_no) gp_no,
null trip_sht_no,
ogr.nm,
ogp.dlvry_br_mast_id,
DECODE(ogr.sign_recd,'Y','YES','NO') Sign_Recd,
DECODE(ogr.stamped,'Y','YES','NO') Stamped,
ogr.dlvry_dt dlvry_dt,
ogr.tel_no,
--ogr.remarks,
Decode(ogr.comments, NULL,'', 'Yes') remarks,
ogr.id ID,ops_safex_utl.get_br_nm(to_number(ow.bkg_br_mast_id))
book_br,
ow.pick_dt book_date
from
ops_gp_reconcile ogr,
ops_gate_pass ogp,
ops_waybl ow
where
ogr.gp_id=ogp.id and
ogp.waybl_id=ow.id and
ogp.dlvry_br_mast_id = (:br_Id) and
(ogr.dlvry_dt = :searchDate) and
ogr.note_prpd = 'N' and ogr.pod_recd = 'Y' and
not exists (select GP_RECONSILE_ID from OPS_POD_FRWD_NOTE_DTLS
where GP_RECONSILE_ID = ogr.id)) QRSLT ORDER BY trip_sht_no desc
Bind Variables :
1 - (VARCHAR2(32)):37069
2 - (DATE):07/11/2011 00:00:00
3 - (DATE):07/11/2011 00:00:00
4 - (VARCHAR2(32)):37069
5 - (DATE):07/11/2011 00:00:00
FINDINGS SECTION (3 findings)
1- SQL Profile Finding (see explain plans section below)
2 potentially better execution plans were found for this statement. Choose
one of the following SQL profiles to implement.
Recommendation (estimated benefit<=10%)
- Consider accepting the recommended SQL profile.
execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_58643',
task_owner => 'SYS', replace => TRUE);
Recommendation (estimated benefit: 99.15%)
- Consider accepting the recommended SQL profile to use parallel execution
for this statement.
execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_58643',
task_owner => 'SYS', replace => TRUE, profile_type =>DBMS_SQLTUNE.PX_PROFILE);
Executing this query parallel with DOP 128 will improve its response time
99.11% over the SQL profile plan. However, there is some cost in enabling
parallel execution. It will increase the statement's resource consumption by
an estimated 14.56% which may result in a reduction of system throughput.
Also, because these resources are consumed over a much smaller duration, the
response time of concurrent statements might be negatively impacted if
sufficient hardware capacity is not available.
The following data shows some sampled statistics for this SQL from the past
week and projected weekly values when parallel execution is enabled.
Past week sampled statistics for this SQL
Number of executions 17494
Percent of total activity 7.2
Percent of samples with #Active Sessions > 2*CPU .63
Weekly DB time (in sec) 614696.04
Projected statistics with Parallel Execution
Weekly DB time (in sec) 704166.9
2- Restructure SQL finding (see plan 1 in explain plans section)
An expensive "UNION" operation was found at line ID 4 of the execution plan.
Recommendation
- Consider using "UNION ALL" instead of "UNION", if duplicates are allowed
or uniqueness is guaranteed.
3- Alternative Plan Finding
Some alternative execution plans for this statement were found by searching
the system's real-time and historical performance data.
The following table lists these plans ranked by their average elapsed time.
See section "ALTERNATIVE PLANS SECTION" for detailed information on each
plan.
id plan hash last seen elapsed (s) origin note
1 209247904 2011-07-12/10:09:08 7.564 Cursor Cache
2 4029269565 2011-07-12/10:20:21 15.374 Cursor Cache original plan
3 4128886984 2011-07-08/11:30:25 42.426 AWR
4 3695555639 2011-07-12/08:30:30 101.459 AWR
Recommendation
- Consider creating a SQL plan baseline for the plan with the best average
elapsed time.
execute dbms_sqltune.create_sql_plan_baseline(task_name => 'TASK_58643',
owner_name => 'SYS', plan_hash_value => 209247904);
ADDITIONAL INFORMATION SECTION
- The optimizer could not merge the view at line ID 3 of the execution plan.
The optimizer cannot merge a view that contains a set operator.
- SQL Profile "SYS_SQLPROF_01306b26f6aa0000" exists for this statement and
was ignored during the tuning process.afzal wrote:
Hi
what should be take action against following sql tuning report.
<snip>Perhaps no action at all.
You can ALWAYS produce a report that will show "top 5" issues. The question is NOT "do I have an issue reported by a tuning report". Yes you do. Everyone does. Always. Even if you slowest batch job runs in 1.3 seconds and your slowest OLTP transaction completes in 0.0001 second.
The question is "do I have a problem that is serious enough to spend time solving?"
If your average OLTP transaction completes in 3 seconds, how much effort is justified to get a 50% improvement?
How much effort is justified to get that same 50% improvement on transactions that complete in 1.5 seconds? 0.2 seconds?
Beware of Compulsive Tuning Disorder. -
Need help to debug SQL Tuning Advisor Error Message
Hi,
I am getting an error message while try to get recommendations from the SQL Tuning Advisor.
Environment:
Oracle Version: 11.2.0.3.0
O/S: AIX
Following is my code:
declare
my_task_name varchar2 (30);
my_sqltext clob;
begin
my_sqltext := 'SELECT DISTINCT MRKT_AREA AS DIVISION, PROMO_ID,
PROMO_CODE,
RBR_DTL_TYPE.PERF_DETL_TYP,
RBR_DTL_TYPE.PERF_DETL_DESC,
RBR_DTL_TYPE.PERF_DETL_SUB_TYP,
RBR_DTL_TYPE.PERF_DETL_SUB_DESC,
BU_SYS_ITM_NUM,
RBR_CPN_LOC_ITEM_ARCHIVE.CLI_SYS_ITM_DESC,
PROMO_START_DATE,
PROMO_END_DATE,
PROMO_VALUE2,
PROMO_VALUE1,
EXEC_COMMENTS,
PAGE_NUM,
BLOCK_NUM,
AD_PLACEMENT,
BUYER_CODE,
RBR_CPN_LOC_ITEM_ARCHIVE.CLI_STAT_TYP,
RBR_MASTER_CAL_ARCHIVE.STATUS_FLAG
FROM (PROMO_REPT_OWNER.RBR_CPN_LOC_ITEM_ARCHIVE
INNER JOIN PROMO_REPT_OWNER.RBR_MASTER_CAL_ARCHIVE
ON (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_PROMO_ID = PROMO_ID)
AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_PERF_DTL_ID = PERF_DETAIL_ID)
AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_STR_NBR = STORE_ZONE)
AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_ITM_ID = ITM_ID))
INNER JOIN PROMO_REPT_OWNER.RBR_DTL_TYPE
ON (RBR_MASTER_CAL_ARCHIVE.PERF_DETL_TYP = RBR_DTL_TYPE.PERF_DETL_TYP)
AND (RBR_MASTER_CAL_ARCHIVE.PERF_DETL_SUB_TYP = RBR_DTL_TYPE.PERF_DETL_SUB_TYP)
WHERE ( ((MRKT_AREA)=40)
AND ((RBR_DTL_TYPE.PERF_DETL_TYP)=1)
AND ((RBR_DTL_TYPE.PERF_DETL_SUB_TYP)=1) )
AND ((CLI_STAT_TYP)=1 Or (CLI_STAT_TYP)=6)
AND ((RBR_MASTER_CAL_ARCHIVE.STATUS_FLAG)=''A'')
AND ( ((PROMO_START_DATE) >= to_date(''2011-10-20'', ''YYYY-MM-DD'')
And (PROMO_END_DATE) <= to_date(''2011-10-26'', ''YYYY-MM-DD'')) )
ORDER BY MRKT_AREA';
my_task_name := dbms_sqltune.create_tuning_task
(sql_text => my_sqltext,
user_name => 'PROMO_REPT_OWNER',
scope => 'COMPREHENSIVE',
time_limit => 3600,
task_name => 'Test_Query',
description => 'Test Query');
end;
begin
dbms_sqltune.execute_tuning_task(task_name => 'Test_Query');
end;
set serveroutput on size unlimited;
set pagesize 5000
set linesize 130
set long 50000
set longchunksize 500000
SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK('Test_Query') FROM DUAL;
Output:
snippet .....
FINDINGS SECTION (1 finding)
1- Index Finding (see explain plans section below)
The execution plan of this statement can be improved by creating one or more
indices.
Recommendation (estimated benefit: 71.48%)
- Consider running the Access Advisor to improve the physical schema design
or creating the recommended index.
Error: Cannot fetch actions for recommendation: INDEX
Error: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
Rationale
Creating the recommended indices significantly improves the execution plan
of this statement. However, it might be preferable to run "Access Advisor"
using a representative SQL workload as opposed to a single statement. This
will allow to get comprehensive index recommendations which takes into
account index maintenance overhead and additional space consumption.
snippet
Any ideas why I am getting ORA-06502 error?
Thanks in advance
RogersBug 14407401 - ORA-6502 from index recommendation section of DBMS_SQLTUNE output (Doc ID 14407401.8)
Fixed:
The fix for 14407401 is first included in
12.1.0.1 (Base Release) -
Need Help in sql tuning in EXADATA environment
I am uploadin the sql with its current explain plan, this sql in Prd database is executing in 6-10 mins and we need to improve this sql perf to 1-2 mins as the requirement from business team.
I am giving some backgroud about this sql tuning requirement, this sql is newly developed in and currently is in UAT phase, we don't have much option for tuning code here since the sql is tool generated through COGNOS DataMart tool, options are there to look into from DBA end with plan level or creating indexes on suitible columns to reduce i/o in minimizing the rows traversing by the sql.
Is anybody can help me out here?
WITH "WCRS_CLAIM_DETAIL_VW5"
AS (SELECT "WCRS_CLAIM_DETAIL_VW"."CLAIM_DETAIL_PK_ID"
"CLAIM_DETAIL_PK_ID",
"WCRS_CLAIM_DETAIL_VW"."CLAIM_ID" "CLAIM_ID",
"WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
"CURRENT_SNAPSHOT_IND",
"WCRS_CLAIM_DETAIL_VW"."LOSS_DT" "LOSS_DT",
"WCRS_CLAIM_DETAIL_VW"."REGULATORY_STATE_CD"
"REGULATORY_STATE_CD"
FROM "CDW_DLV_IDS"."WCRS_CLAIM_DETAIL_VW" "WCRS_CLAIM_DETAIL_VW"
WHERE "WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y'),
"WCRS_POLICY_DETAIL_VW7"
AS (SELECT "WCRS_POLICY_DETAIL_VW"."CLAIM_NBR" "CLAIM_NBR",
"WCRS_POLICY_DETAIL_VW"."CLAIM_SYMBOL_CD" "CLAIM_SYMBOL_CD",
"WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
"CURRENT_SNAPSHOT_IND",
"WCRS_POLICY_DETAIL_VW"."KEY_OFFICE_CD" "KEY_OFFICE_CD",
"WCRS_POLICY_DETAIL_VW"."POLICY_NBR" "POLICY_NBR"
FROM "CDW_DLV_IDS"."WCRS_POLICY_DETAIL_VW" "WCRS_POLICY_DETAIL_VW"
WHERE "WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y')
SELECT /*+ gather_plan_statistics monitor bind_aware */
/* ^^unique_id */
"T0"."C0" "Account_Name",
"T0"."C1" "Accident_State_Cd",
"T0"."C2" "c3",
"T0"."C3" "PPO_Name",
"T0"."C4" "Invc_Classification_Type_Desc",
FIRST_VALUE (
"T0"."C5")
OVER (
PARTITION BY "T0"."C0",
"T0"."C1",
"T0"."C2",
"T0"."C3",
"T0"."C4",
"T0"."C6")
"Claim_Cnt___Distinct",
"T0"."C7" "Invc_Control_Number",
"T0"."C8" "Invc_Allowance_Amt",
"T0"."C9" "Invc_Charge_Amt",
"T0"."C10" "c10",
"T0"."C11" "PPO_Reduction_Amt",
"T0"."C12" "Dup_Ln_Save_Amt",
"T0"."C13" "c13",
"T0"."C14" "Sub_Total",
"T0"."C15" "c15",
"T0"."C6" "c16"
FROM (SELECT "T1"."C0" "C0",
"T1"."C1" "C1",
"T1"."C2" "C2",
"T1"."C3" "C3",
"T1"."C4" "C4",
"T1"."C6" "C5",
"T1"."C5" "C6",
"T0"."C0" "C7",
"T1"."C7" "C8",
"T1"."C8" "C9",
"T1"."C9" "C10",
"T1"."C10" "C11",
"T1"."C11" "C12",
"T1"."C12" "C13",
"T1"."C13" "C14",
"T1"."C14" "C15"
FROM (SELECT COUNT (DISTINCT "INVC_DIM_VW"."INVC_ID") "C0"
FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
"WCRS_CLAIM_DETAIL_VW5",
"EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
"EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
"EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
"EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
"EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
"CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
"CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
"WCRS_POLICY_DETAIL_VW7",
"EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
'Original'
AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
"ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
"WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
"WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
"WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
"WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
"WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
"INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
"INVC_DIM_VW"."INVC_GID"
AND "INVC_DIM_VW"."INVC_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT") "T0",
( SELECT "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" "C0",
"WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD" "C1",
CASE
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'Y'
THEN
'In - Network'
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'N'
THEN
'Out - Network'
ELSE
'Others'
END
"C2",
"PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM" "C3",
"INVC_DIM_VW"."INVC_CLASS_TYPE_DESC" "C4",
CASE
WHEN (EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
OR (EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
THEN
NULL
ELSE
( EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
|| EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
END
"C5",
COUNT (DISTINCT "WCRS_CLAIM_DETAIL_VW5"."CLAIM_ID")
"C6",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT") "C7",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
"C8",
SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."TOT_INVC_REVIEW_RULE_ALWC_AMT")
"C9",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PPO_REDUC_AMT")
"C10",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
"C11",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_OSR_REDUC_AMT")
"C12",
( SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
- SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT"))
- SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
"C13",
SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CLNT_SPEC_REDUC_AMT")
"C14"
FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
"WCRS_CLAIM_DETAIL_VW5",
"EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
"EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
"EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
"EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
"EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
"CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
"CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
"WCRS_POLICY_DETAIL_VW7",
"EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
'Original'
AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
"ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
"WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
"WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
"WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
"WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
"WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
"INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
"INVC_DIM_VW"."INVC_GID"
AND "INVC_DIM_VW"."INVC_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
GROUP BY "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM",
"WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD",
CASE
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'Y'
THEN
'In - Network'
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'N'
THEN
'Out - Network'
ELSE
'Others'
END,
"PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM",
"INVC_DIM_VW"."INVC_CLASS_TYPE_DESC",
CASE
WHEN (EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
OR (EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
THEN
NULL
ELSE
( EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
|| EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
END) "T1") "T0"
ORDER BY "Account_Name" ASC NULLS LAST,
"Accident_State_Cd" ASC NULLS LAST,
"c3" ASC NULLS LAST,
"PPO_Name" ASC NULLS LAST,
"Invc_Classification_Type_Desc" ASC NULLS LAST| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 838 | 1079K (1)| 00:00:34 | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 10M| 317M| 848K (1)| 00:00:27 | | |
| 4 | LOAD AS SELECT | SYS_TEMP_0FD9D677A_286AAA2E | | | | | | |
| 5 | PX BLOCK ITERATOR | | 10M| 317M| 848K (1)| 00:00:27 | | |
|* 6 | TABLE ACCESS STORAGE FULL | WCRS_CLAIM_DETAIL | 10M| 317M| 848K (1)| 00:00:27 | | |
| 7 | PX COORDINATOR | | | | | | | |
| 8 | PX SEND QC (RANDOM) | :TQ20000 | 10M| 268M| 44875 (1)| 00:00:02 | | |
| 9 | LOAD AS SELECT | SYS_TEMP_0FD9D677B_286AAA2E | | | | | | |
| 10 | PX BLOCK ITERATOR | | 10M| 268M| 44875 (1)| 00:00:02 | | |
|* 11 | TABLE ACCESS STORAGE FULL | WCRS_POLICY_DETAIL | 10M| 268M| 44875 (1)| 00:00:02 | | |
| 12 | PX COORDINATOR | | | | | | | |
| 13 | PX SEND QC (ORDER) | :TQ40017 | 1 | 838 | 186K (2)| 00:00:06 | | |
| 14 | WINDOW SORT | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 15 | PX RECEIVE | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 16 | PX SEND RANGE | :TQ40016 | 1 | 838 | 186K (2)| 00:00:06 | | |
| 17 | NESTED LOOPS | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 18 | BUFFER SORT | | | | | | | |
| 19 | PX RECEIVE | | | | | | | |
| 20 | PX SEND BROADCAST | :TQ40001 | | | | | | |
| 21 | VIEW | | 1 | 13 | 93216 (2)| 00:00:03 | | |
| 22 | SORT GROUP BY | | 1 | 393 | | | | |
| 23 | PX COORDINATOR | | | | | | | |
| 24 | PX SEND QC (RANDOM) | :TQ30015 | 1 | 393 | | | | |
| 25 | SORT GROUP BY | | 1 | 393 | | | | |
| 26 | PX RECEIVE | | 1 | 393 | | | | |
| 27 | PX SEND HASH | :TQ30014 | 1 | 393 | | | | |
| 28 | SORT GROUP BY | | 1 | 393 | | | | |
|* 29 | HASH JOIN ANTI | | 1 | 393 | 93216 (2)| 00:00:03 | | |
| 30 | PX RECEIVE | | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 31 | PX SEND HASH | :TQ30012 | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 32 | BUFFER SORT | | 1 | 838 | | | | |
| 33 | NESTED LOOPS | | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 34 | NESTED LOOPS | | 1 | 358 | 85197 (2)| 00:00:03 | | |
| 35 | NESTED LOOPS | | 1 | 348 | 85197 (2)| 00:00:03 | | |
|* 36 | HASH JOIN ANTI | | 1 | 316 | 85179 (2)| 00:00:03 | | |
| 37 | PX RECEIVE | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
| 38 | PX SEND HASH | :TQ30010 | 4 | 1156 | 77161 (2)| 00:00:03 | | |
|* 39 | HASH JOIN ANTI BUFFERED | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
| 40 | PX RECEIVE | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
| 41 | PX SEND HASH | :TQ30008 | 371 | 94605 | 69142 (2)| 00:00:03 | | |
|* 42 | HASH JOIN | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
| 43 | PX RECEIVE | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
| 44 | PX SEND BROADCAST | :TQ30007 | 350 | 77000 | 36642 (1)| 00:00:02 | | |
|* 45 | HASH JOIN | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
| 46 | PX RECEIVE | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
| 47 | PX SEND BROADCAST | :TQ30006 | 140 | 25200 | 28624 (1)| 00:00:01 | | |
|* 48 | HASH JOIN | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
| 49 | PX RECEIVE | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
| 50 | PX SEND BROADCAST | :TQ30005 | 140 | 22820 | 25169 (1)| 00:00:01 | | |
|* 51 | HASH JOIN BUFFERED | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
| 52 | BUFFER SORT | | | | | | | |
| 53 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
| 54 | T PX SEND BROADCAS | :TQ30000 | 9 | 306 | 5 (0)| 00:00:01 | | |
| 55 | INDEX ROWID TABLE ACCESS BY | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
|* 56 | AN INDEX RANGE SC | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
|* 57 | HASH JOIN | | 9699K| 1193M| 25149 (1)| 00:00:01 | | |
| 58 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 59 | PX SEND HASH | :TQ30003 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 60 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 61 | BUFFER SORT | | | | | | | |
| 62 | PX RECEIVE | | | | | | | |
| 63 | DCAST PX SEND BROA | :TQ30002 | | | | | | |
| 64 | CARTESIAN MERGE JOIN | | 1 | 14 | 13 (0)| 00:00:01 | | |
| 65 | TERATOR PX BLOCK I | | 1 | 8 | 10 (0)| 00:00:01 | | |
| 66 | ESS STORAGE FULL TABLE ACC | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
| 67 | T BUFFER SOR | | 1 | 6 | 3 (0)| 00:00:01 | | |
| 68 | E PX RECEIV | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 69 | BROADCAST PX SEND | :TQ30001 | 1 | 6 | 2 (0)| 00:00:01 | | |
| 70 | K ITERATOR PX BLOC | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 71 | ACCESS STORAGE FULL TABLE | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
| 72 | TOR PX BLOCK ITERA | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|* 73 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
| 74 | PX RECEIVE | | 10M| 785M| 2907 (2)| 00:00:01 | | |
| 75 | PX SEND HASH | :TQ30004 | 10M| 785M| 2907 (2)| 00:00:01 | | |
|* 76 | VIEW | | 10M| 785M| 2907 (2)| 00:00:01 | | |
| 77 | TOR PX BLOCK ITERA | | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 78 | STORAGE FULL TABLE ACCESS | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
|* 79 | VIEW | | 10M| 168M| 3439 (2)| 00:00:01 | | |
| 80 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 81 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 82 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 83 | LL TABLE ACCESS STORAGE FU | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 84 | PX BLOCK ITERATOR | | 15M| 521M| 32477 (2)| 00:00:02 | | |
|* 85 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 521M| 32477 (2)| 00:00:02 | | |
| 86 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 87 | PX SEND HASH | :TQ30009 | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 88 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 89 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 90 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 91 | PX SEND HASH | :TQ30011 | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 92 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 93 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 94 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 32 | 18 (0)| 00:00:01 | | |
|* 95 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
|* 96 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | 10 | 0 (0)| 00:00:01 | | |
|* 97 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
| 98 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 99 | PX SEND HASH | :TQ30013 | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 100 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 101 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 102 | VIEW | | 1 | 825 | | | | |
| 103 | SORT GROUP BY | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 104 | BUFFER SORT | | | | | | | |
| 105 | PX RECEIVE | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 106 | PX SEND HASH | :TQ40015 | 1 | 430 | 93216 (2)| 00:00:03 | | |
|*107 | HASH JOIN ANTI BUFFERED | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 108 | PX RECEIVE | | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 109 | PX SEND HASH | :TQ40013 | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 110 | BUFFER SORT | | 1 | 838 | | | | |
| 111 | NESTED LOOPS | | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 112 | NESTED LOOPS | | 1 | 395 | 85197 (2)| 00:00:03 | | |
| 113 | NESTED LOOPS | | 1 | 369 | 85197 (2)| 00:00:03 | | |
|*114 | HASH JOIN ANTI | | 1 | 311 | 85179 (2)| 00:00:03 | | |
| 115 | PX RECEIVE | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
| 116 | PX SEND HASH | :TQ40011 | 4 | 1136 | 77161 (2)| 00:00:03 | | |
|*117 | HASH JOIN ANTI BUFFERED | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
| 118 | PX RECEIVE | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
| 119 | PX SEND HASH | :TQ40009 | 371 | 92750 | 69143 (2)| 00:00:03 | | |
|*120 | HASH JOIN | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
| 121 | PX RECEIVE | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
| 122 | PX SEND BROADCAST | :TQ40008 | 350 | 72450 | 36642 (1)| 00:00:02 | | |
|*123 | HASH JOIN | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
| 124 | PX RECEIVE | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
| 125 | PX SEND BROADCAST | :TQ40007 | 140 | 23380 | 28624 (1)| 00:00:01 | | |
|*126 | HASH JOIN | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
| 127 | PX RECEIVE | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
| 128 | PX SEND BROADCAST | :TQ40006 | 140 | 15540 | 25169 (1)| 00:00:01 | | |
|*129 | HASH JOIN BUFFERED | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
| 130 | BUFFER SORT | | | | | | | |
| 131 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
| 132 | PX SEND BROADCAST | :TQ40000 | 9 | 306 | 5 (0)| 00:00:01 | | |
| 133 | ROWID TABLE ACCESS BY INDEX | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
|*134 | INDEX RANGE SCAN | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
|*135 | HASH JOIN | | 9699K| 712M| 25149 (1)| 00:00:01 | | |
| 136 | PX RECEIVE | | 10M| 287M| 2907 (2)| 00:00:01 | | |
| 137 | PX SEND HASH | :TQ40004 | 10M| 287M| 2907 (2)| 00:00:01 | | |
|*138 | VIEW | | 10M| 287M| 2907 (2)| 00:00:01 | | |
| 139 | PX BLOCK ITERATOR | | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 140 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 141 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 142 | PX SEND HASH | :TQ40005 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 143 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 144 | BUFFER SORT | | | | | | | |
| 145 | PX RECEIVE | | | | | | | |
| 146 | PX SEND BROADCAST | :TQ40003 | | | | | | |
| 147 | IAN MERGE JOIN CARTES | | 1 | 14 | 13 (0)| 00:00:01 | | |
| 148 | R PX BLOCK ITERATO | | 1 | 8 | 10 (0)| 00:00:01 | | |
| 149 | ORAGE FULL TABLE ACCESS ST | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
| 150 | BUFFER SORT | | 1 | 6 | 3 (0)| 00:00:01 | | |
| 151 | PX RECEIVE | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 152 | AST PX SEND BROADC | :TQ40002 | 1 | 6 | 2 (0)| 00:00:01 | | |
| 153 | ATOR PX BLOCK ITER | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 154 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
| 155 | PX BLOCK ITERATOR | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|*156 | E FULL TABLE ACCESS STORAG | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|*157 | VIEW | | 10M| 555M| 3439 (2)| 00:00:01 | | |
| 158 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 159 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 160 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 161 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 162 | PX BLOCK ITERATOR | | 15M| 641M| 32477 (2)| 00:00:02 | | |
|*163 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 641M| 32477 (2)| 00:00:02 | | |
| 164 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 165 | PX SEND HASH | :TQ40010 | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 166 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 167 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 168 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 169 | PX SEND HASH | :TQ40012 | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 170 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 171 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 172 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 58 | 18 (0)| 00:00:01 | | |
|*173 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
| 174 | TABLE ACCESS BY INDEX ROWID | PROVIDER_NETWORK_DIM | 1 | 26 | 0 (0)| 00:00:01 | | |
|*175 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | | 0 (0)| 00:00:01 | | |
|*176 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
| 177 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 178 | PX SEND HASH | :TQ40014 | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 179 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 180 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------- -
SQL Performance issue: Using user defined function with group by
Hi Everyone,
im new here and I really could need some help on a weird performance issue. I hope this is the right topic for SQL performance issues.
Well ok, i create a function for converting a date from timezone GMT to a specified timzeone.
CREATE OR REPLACE FUNCTION I3S_REP_1.fnc_user_rep_date_to_local (date_in IN date, tz_name_in IN VARCHAR2) RETURN date
IS
tz_name VARCHAR2(100);
date_out date;
BEGIN
SELECT
to_date(to_char(cast(from_tz(cast( date_in AS TIMESTAMP),'GMT')AT
TIME ZONE (tz_name_in) AS DATE),'dd-mm-yyyy hh24:mi:ss'),'dd-mm-yyyy hh24:mi:ss')
INTO date_out
FROM dual;
RETURN date_out;
END fnc_user_rep_date_to_local;The following statement is just an example, the real statement is much more complex. So I select some date values from a table and aggregate a little.
select
stp_end_stamp,
count(*) noi
from step
where
stp_end_stamp
BETWEEN
to_date('23-05-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
AND
to_date('23-07-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
group by
stp_end_stampThis statement selects ~70000 rows and needs ~ 70ms
If i use the function it selects the same number of rows ;-) and takes ~ 4 sec ...
select
fnc_user_rep_date_to_local(stp_end_stamp,'Europe/Berlin'),
count(*) noi
from step
where
stp_end_stamp
BETWEEN
to_date('23-05-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
AND
to_date('23-07-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
group by
fnc_user_rep_date_to_local(stp_end_stamp,'Europe/Berlin')I understand that the DB has to execute the function for each row.
But if I execute the following statement, it takes only ~90ms ...
select
fnc_user_rep_date_to_gmt(stp_end_stamp,'Europe/Berlin','ny21654'),
noi
from
select
stp_end_stamp,
count(*) noi
from step
where
stp_end_stamp
BETWEEN
to_date('23-05-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
AND
to_date('23-07-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
group by
stp_end_stamp
)The execution plan for all three statements is EXACTLY the same!!!
Usually i would say, that I use the third statement and the world is in order. BUT I'm working on a BI project with a tool called Business Objects and it generates SQL, so my hands are bound and I can't make this tool to generate the SQL as a subselect.
My questions are:
Why is the second statement sooo much slower than the third?
and
Howcan I force the optimizer to do whatever he is doing to make the third statement so fast?
I would really appreciate some help on this really weird issue.
Thanks in advance,
AndiHi,
The execution plan for all three statements is EXACTLY the same!!!Not exactly. Plans are the same - true. They uses slightly different approach to call function. See:
drop table t cascade constraints purge;
create table t as select mod(rownum,10) id, cast('x' as char(500)) pad from dual connect by level <= 10000;
exec dbms_stats.gather_table_stats(user, 't');
create or replace function test_fnc(p_int number) return number is
begin
return trunc(p_int);
end;
explain plan for select id from t group by id;
select * from table(dbms_xplan.display(null,null,'advanced'));
explain plan for select test_fnc(id) from t group by test_fnc(id);
select * from table(dbms_xplan.display(null,null,'advanced'));
explain plan for select test_fnc(id) from (select id from t group by id);
select * from table(dbms_xplan.display(null,null,'advanced'));Output:
PLAN_TABLE_OUTPUT
Plan hash value: 47235625
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 10 | 30 | 162 (3)| 00:00:02 |
| 1 | HASH GROUP BY | | 10 | 30 | 162 (3)| 00:00:02 |
| 2 | TABLE ACCESS FULL| T | 10000 | 30000 | 159 (1)| 00:00:02 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
2 - SEL$1 / T@SEL$1
Outline Data
/*+
BEGIN_OUTLINE_DATA
FULL(@"SEL$1" "T"@"SEL$1")
OUTLINE_LEAF(@"SEL$1")
ALL_ROWS
OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
IGNORE_OPTIM_EMBEDDED_HINTS
END_OUTLINE_DATA
Column Projection Information (identified by operation id):
1 - (#keys=1) "ID"[NUMBER,22]
2 - "ID"[NUMBER,22]
34 rows selected.
SQL>
Explained.
SQL>
PLAN_TABLE_OUTPUT
Plan hash value: 47235625
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 10 | 30 | 162 (3)| 00:00:02 |
| 1 | HASH GROUP BY | | 10 | 30 | 162 (3)| 00:00:02 |
| 2 | TABLE ACCESS FULL| T | 10000 | 30000 | 159 (1)| 00:00:02 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
2 - SEL$1 / T@SEL$1
Outline Data
/*+
BEGIN_OUTLINE_DATA
FULL(@"SEL$1" "T"@"SEL$1")
OUTLINE_LEAF(@"SEL$1")
ALL_ROWS
OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
IGNORE_OPTIM_EMBEDDED_HINTS
END_OUTLINE_DATA
Column Projection Information (identified by operation id):
1 - (#keys=1) "TEST_FNC"("ID")[22]
2 - "ID"[NUMBER,22]
34 rows selected.
SQL>
Explained.
SQL> select * from table(dbms_xplan.display(null,null,'advanced'));
PLAN_TABLE_OUTPUT
Plan hash value: 47235625
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 10 | 30 | 162 (3)| 00:00:02 |
| 1 | HASH GROUP BY | | 10 | 30 | 162 (3)| 00:00:02 |
| 2 | TABLE ACCESS FULL| T | 10000 | 30000 | 159 (1)| 00:00:02 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$F5BB74E1
2 - SEL$F5BB74E1 / T@SEL$2
Outline Data
/*+
BEGIN_OUTLINE_DATA
FULL(@"SEL$F5BB74E1" "T"@"SEL$2")
OUTLINE(@"SEL$2")
OUTLINE(@"SEL$1")
MERGE(@"SEL$2")
OUTLINE_LEAF(@"SEL$F5BB74E1")
ALL_ROWS
OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
IGNORE_OPTIM_EMBEDDED_HINTS
END_OUTLINE_DATA
Column Projection Information (identified by operation id):
1 - (#keys=1) "ID"[NUMBER,22]
2 - "ID"[NUMBER,22]
37 rows selected. -
How to track the sql commands issued against database
Hello, We are using an interface developed by oracle forms. Its giving some error while pressing an icon. I can not able to trace out from where it arises. This error is displayed by form developed by oracle forms. I dont have source code to track it. I would like to know , which SQL statement rises the error, so that I can update the oracle object and can able to solve the problem if I can able to find the exect SQL statment issued before the error was displayed. kindly help me . thanks.
habfat wrote:
Hello, We are using an interface developed by oracle forms. Its giving some error while pressing an icon. I can not able to trace out from where it arises. This error is displayed by form developed by oracle forms. I dont have source code to track it. I would like to know , which SQL statement rises the error, so that I can update the oracle object and can able to solve the problem if I can able to find the exect SQL statment issued before the error was displayed. kindly help me . thanks.Hmm, well kind of a silly but still, if you don't have source code of the form( you said so) so even if you would come to know what statement is raising the error, how would you go and edit it ? Did I miss some thing? And you asked for a sql statement ? How did you come to know that its a sql statement that is causing the error? And if that's actually a sql statement error, isn't it associated with a meaningful message ?
Find the developer who coded the application, he would be the best person to track the error and tell you its resolution IMO.
HTH
Aman.... -
PL/SQL speed issues when using a variable
I have a very strange issue that is causing problems.
I am running Golden connecting to a 11g database.
I created a procedure to insert records into a table based on a query. The source query includes variables that I have populated prior to the insert statement. The problem is that if I use the variable for one very specific where statement, the statement goes from running in less than 1 second, to running in 15 minutes. It gets even more strange though. Not only does a 2nd variable not cause any problems, the exact same variable in the same statement works fine.
This procedure takes 15 minutes to run.
declare
v_start_period date;
v_end_period date;
begin
select add_months(trunc(sysdate,'mm'), -1), trunc(sysdate,'mm')
into v_start_period, v_end_period
from dual;
insert into RESULTS_TABLE
(first_audit_date, last_audit_date,
data_column1, data_column2, data_column3)
select
a.first_audit_date, a.last_audit_date,
b.data_column1, b.data_column2, b.data_column3
from
SOURCE_TABLE_1 b,
(select marker_id, min(action_time) as first_audit_date, max(action_time) as last_audit_date
from SOURCE_TABLE_2
where action_time >= v_start_period and action_time < v_end_period
group by marker_id) a
where b.marker_id = a.marker_id
and exists (select 1 from SOURCE_TABLE_2
where marker_id = b.marker_id
and action_time >= v_start_period and action_time < v_end_period
and action_type = 'XYZ');
commit;
end;This procedure runs in less than 1 second, yet returns the exact same results.
declare
v_start_period date;
v_end_period date;
begin
select add_months(trunc(sysdate,'mm'), -1), trunc(sysdate,'mm')
into v_start_period, v_end_period
from dual;
insert into RESULTS_TABLE
(first_audit_date, last_audit_date,
data_column1, data_column2, data_column3)
select
a.first_audit_date, a.last_audit_date,
b.data_column1, b.data_column2, b.data_column3
from
SOURCE_TABLE_1 b,
(select marker_id, min(action_time) as first_audit_date, max(action_time) as last_audit_date
from SOURCE_TABLE_2
where action_time >= v_start_period and action_time < trunc(sysdate,'mm')
group by marker_id) a
where b.marker_id = a.marker_id
and exists (select 1 from SOURCE_TABLE_2
where marker_id = b.marker_id
and action_time >= v_start_period and action_time < v_end_period
and action_type = 'XYZ');
commit;
end;The only difference between the two is where I replace the first v_end_period variable with trunc(sysdate,'mm').
I've been googling for possible solutions and keep running into something called "parameter sniffing". It appears to be a SQL Server issue though, as I cannot find solutions for Oracle. I tried nesting the insert statement inside it's own procedure with new variables populated by the old variables, but nothing changed.
Edited by: user_7000017 on Jan 8, 2013 9:45 AM
Edited by: user_7000017 on Jan 8, 2013 9:52 AM Put the code in code tags.You are not describing procedures. You are listing anonymous PL/SQL blocks.
As for the code - this approach to assigning PL/SQL variables are highly questionable. As the functions are native PL/SQL functions too, there is no need to parse and execute a SQL cursor, do context switching, in order to assign values to PL/SQL variables.
This is wrong:
select
add_months(trunc(sysdate,'mm'), -1), trunc(sysdate,'mm')
into v_start_period, v_end_period
from dual;This is correct:
v_start_period := add_months(trunc(sysdate,'mm'), -1);
v_end_period := trunc(sysdate,'mm');Just as you would not use +"select 1 into plVariable from dual;+", instead of a standard variable assignment statement like +"plVariable := 1;"+.
As for the performance/execution difference. Does not make sense. I suggest simplifying the code in order to isolate the problem. For example, take that in-line SQL (aliased as a in the main SQL) and create a testcase where it uses the function, versus a PL/SQL bind variable with the same data type and value as that returned by the function. Examine and compare the execution plans.
Increase complexity (if no error) and repeat. Until the error is isolated.
The 1st step in any troubleshooting, is IDENTIFYING the problem. Without knowing what the problem is, how can one fix it? -
Hi,
I would like to know any SQL tuning methods specific to Oracle exadata so that they could improve the performance of the database?
I am aware that oracle exadata runs with Oracle 11g, but i would like to know wheather there is any tuning scope w.r.t to SQL's on exadata?
regards
sunilWell there are some things that are very different about Exadata. All the standard Oracle SQL tuning you have learned already should not be forgotten as Exadata is running standard 11g database code, but there are many optimizations that have been added that you should be aware of. At a high level, if you are doing OLTP type work you should be trying to make sure that you take advantage of Exadata Smart Flash Cache which will significantly speed up your small I/O's. But long running queries are where the big benefits show up. The high level tuning approach for them is as follows:
1. Check to see if you are getting Smart Scans.
2. If you aren't, fix what ever is preventing them from being used.
We've been involved in somewhere between 25-30 DB Machine installations now and in many cases, a little bit of effort changes performance dramatically. If you are only getting 2 to 3X improvement over your previous platform on these long running queries you are probably not getting the full benefit of the Exadata optimizations. So the first step is learning how to determine if you are getting Smart Scans or not and on what portions of the statement. Wait events, session statistics, V$SQL, SQL Monitoring are all viable tools that can show you that information. -
Permissions needed for Applying SQL Tuning Sets/SQL Plans 11g?
What permission are needed for a user to apply/activate sql tuning sets (sql plans) in 11g? The user can capture and move the the sql tuning sets from a 10g database to an 11g database but is getting "ORA-01031: insufficient privileges" when trying to activate/apply the sqlplans in 11g.
The user has:
ADMINISTER SQL MANAGEMENT OBJECT and ADMINISTER SQL TUNING SET and EXECUTE on SYS.DBMS_SPM
The user is an administrator for our Data Warehouse team but they do not have sysdba priviliges.
Do you also know of a good white paper that covers the step by step instructions and permissions needed for aquiring and applying/activating sqlplans?
If more information is needed in order to respond please advise.
Thank youWhat permission are needed for a user to apply/activate sql tuning sets (sql plans) in 11g? The user can capture and move the the sql tuning sets from a 10g database to an 11g database but is getting "ORA-01031: insufficient privileges" when trying to activate/apply the sqlplans in 11g.
The user has:
ADMINISTER SQL MANAGEMENT OBJECT and ADMINISTER SQL TUNING SET and EXECUTE on SYS.DBMS_SPM
The user is an administrator for our Data Warehouse team but they do not have sysdba priviliges.
Do you also know of a good white paper that covers the step by step instructions and permissions needed for aquiring and applying/activating sqlplans?
If more information is needed in order to respond please advise.
Thank you -
Hi
I am not a sql programmer and developers have given me this sql to have a look. I made the following recommendations after going through the sql. Is there anything else that can be added . I did not add about stats because they are representative and up to date.
SELECT /*+ PARALLEL(q1,4) */ *
FROM
(SELECT /*+ FIRST_ROWS(20) */
br.resource_id,
br.resource_code,
x.resource_seq_num employee_resource_number,
br.organization_id,
bd.department_id,
bd.department_code,
pf.full_name employee_name,
(SELECT xxdl_eam_util_pkg.xxdl_eam_get_resource_code(pf.person_id, bd.department_id)
FROM dual)
maximum_cost_resource,
pf.person_id,
x.wip_entity_id wo_id,
(SELECT weo1.wip_entity_name
FROM wip_eam_work_orders_v weo1
WHERE weo1.wip_entity_id = x.wip_entity_id)
wo_number,
CAST(x.start_date AS
TIMESTAMP) start_date,
CAST(x.completion_date AS
TIMESTAMP) completion_date,
wor.operation_seq_num wo_operation_number,
wor.resource_seq_num wo_resource_number,
wor.usage_rate_or_amount HOURS,
BRE.effective_start_date instance_start_date,
BRE.effective_end_date instance_end_date,
BRE.instance_id,
crc.resource_rate AS
resource_cost,
(SELECT xxdl_eam_util_pkg.xxdl_eam_get_all_res_code(pf.person_id, bd.department_id)
FROM dual)
all_resources
FROM per_all_people_f pf,
wip_eam_work_orders_v weo,
wip_operations wo,
wip_operation_resources wor,
(SELECT instance_id,
wip_entity_id,
operation_seq_num,
resource_seq_num,
start_date,
completion_date
FROM wip_op_resource_instances_v) x,
bom_dept_res_instances bdri,
bom_resource_employees BRE,
bom_department_resources bdr,
bom_resources br,
cst_resource_costs crc,
bom_departments bd
WHERE br.organization_id = bd.organization_id
AND bdr.resource_id = br.resource_id
AND bdr.department_id = bd.department_id
AND BRE.resource_id = br.resource_id
AND pf.effective_start_date <=sysdate
AND pf.effective_end_date >= sysdate
AND pf.person_id = BRE.person_id
AND wo.department_id = bd.department_id
AND wor.operation_seq_num(+) = wo.operation_seq_num
AND wor.wip_entity_id(+) = wo.wip_entity_id
AND wor.organization_id(+) = wo.organization_id
AND weo.wip_entity_id = wo.wip_entity_id
AND weo.organization_id = wo.organization_id
-- AND weo.organization_id = 6921
AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
AND crc.resource_id(+) = BRE.resource_id
AND x.wip_entity_id = wor.wip_entity_id
AND x.operation_seq_num = wor.operation_seq_num
AND x.resource_seq_num = wor.resource_seq_num
AND x.instance_id(+) = BRE.instance_id
AND bdri.department_id = bd.department_id
AND bdri.resource_id = br.resource_id
AND weo.organization_id = 6921
AND bdri.department_id = 5004
UNION
SELECT /*+ FIRST_ROWS(20) */ DISTINCT NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
pf.full_name employee_name,
NULL,
pf.person_id,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL HOURS,
NULL,
NULL,
NULL,
NULL,
NULL
FROM per_all_people_f pf,
wip_eam_work_orders_v weo,
wip_operations wo,
wip_operation_resources wor,
bom_dept_res_instances bdri,
bom_resource_employees BRE,
bom_department_resources bdr,
bom_resources br,
cst_resource_costs crc,
bom_departments bd
WHERE br.organization_id = bd.organization_id
AND bdr.resource_id = br.resource_id
AND bdr.department_id = bd.department_id
AND BRE.resource_id = br.resource_id
AND pf.effective_start_date <=sysdate
AND pf.effective_end_date >= sysdate
AND pf.person_id = BRE.person_id
AND wo.department_id = bd.department_id
AND wor.operation_seq_num(+) = wo.operation_seq_num
AND wor.wip_entity_id(+) = wo.wip_entity_id
AND wor.organization_id(+) = wo.organization_id
AND weo.wip_entity_id = wo.wip_entity_id
AND weo.organization_id = wo.organization_id
AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
AND crc.resource_id(+) = BRE.resource_id
AND bdri.department_id = bd.department_id
AND bdri.resource_id = br.resource_id
AND weo.organization_id = 6921
AND bdri.department_id = 5004
AND NOT EXISTS
(SELECT instance_id,
wip_entity_id operation_seq_num,
resource_seq_num
FROM wip_op_resource_instances_v)
) q1
ORDER BY department_id,
resource_code,
employee_name,
wo_number
My suggestions:
. Try to use UNION ALL instead of UNION. If you can eliminate UNION all together and flatten the query that will be even better.
2. You are using the function in a select statement xxdl_eam_util_pkg.xxdl_eam_get_resource_code(pf.person_id, bd.department_id)This will slow the performance. Try to get rid of this. Function calls in select are expensive.
3. Dont use the parallel hint and optimize. It wont get you consistent results.
4. Use of per_all_people_F is expensive. The UNION again complicates things. per_all_people_f has to be scanned 2x times.
5. Where does the application get the values for department id? Whether user inputs a value or whether it is hard coded . Most likely user will input value and each time it may be different. If that is the case, then you may be hitting bind peeking. There is not much hope for this. Not much can be done. Whatever you do this can happen. Only way is to pin the plan if you can use literals instead of binds. But that is not possible I think.
6. AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
Those statements, if you can rewrite would be good. If there are indexes on any of those columns, they are more than likely not used.
7. Are the outer joins really required. If not required remove them.
8. There is a 'WITH' clause in 10g . Try to use that for your subqueries or main query where applicable. It will save some I/O.
9. Try to tune without any hints. Remove the first rows as well and see the difference.
I know that the sql is definately bad and can be rewritten but I am not able to exactly write it for them.
Any inputs or thoughts?
MSKHi,
Any suggestions for reading on Sql tuning
I am looking for a practical book with solutions .
And books showing the Sql internal workings ?Take a look on Amazon some Jonathan Lewis books.
I will also recommend you to take a look on the following blogs:
- http://jonathanlewis.wordpress.com/
- http://www.juliandyke.com/
- http://richardfoote.wordpress.com/
- http://tkyte.blogspot.com/
And also any good interview based good Oracle DBA books ?You can take a look on my blog for some common DBA interview questions.
http://oraclenz.com/category/interview-tips/
Regards,
Francisco Munoz Alvarez
www.oraclenz.com
Maybe you are looking for
-
Having updated firefox, it does not work. After an hour or so to try and open firefox, it says firefox has crashed and gives option to restart or quit. Same with internet explorer and chrome - no response. After about an hour, excel finally opened bu
-
Not able to see the navigation structure in 'System Administration'
Hello All I have installed CE7.1 SR3, now I want to SSO between the ECC system. I am not able to find the navigation under 'System Administration' >> 'System configuration' >>.....KEY STORE ADMINISTRATION...... Can anyone help me in making SSO with C
-
PR1.1 (N8) available for O2 (UK) handsets
Downloaded it last night, no problems at all. Handset feels much snappier, and you get a full version of Quickoffice. Not noticed any other changes. Regarding some of the stuff in other threads, I have no problem with videos or photo zooming.
-
Create an event using abap class
Hi, Im trying to create an event by using an abap class. The purpose is to update po reqs using BAPI_REQUISITION_CHANGE upon saving a sales order. The exit is called on saving a sales order MV45AFZZ. In MV45AFZZ the method cl_swf_evt_event is call
-
Hi, hope someone can help me: I've currently written the following code: import java.applet.*; import java.awt.*; import java.awt.event.*; public class FracDeci extends Applet private static final int NUMFRACS=30; private List fracList = new List(10,