Gurus..Help in understanding PL/SQL Tuning

Hi Gurus,
I am trying to understand PL/SQL tuning and I have read few articles on PL/SQL profiler,dbms_trace,tk-prof ect.
When doing PL/SQL tuning I understand we will take trace from DBMS_PROFILER.
Can any one tell me step by step procedure for DBMS_PROFILER with some example.
Once you collect what will be the next steps for PL/SQL tuning.
My understanding is we cannot tune much in PL/SQL block all we can do is we can take out SQL statement from PL/SQL and tune that
SQL statement.
Correct me if I am wrong.
Thanks in advance.
Regards
MMU

check this one, it may help -
Re: HOw to check the performance of a pl/sql command

Similar Messages

List Sql Tuning Sets

I am hoping for a quick easy answer on this. grin
We have been generating a number of Sql Tuning Sets via Grid Control and now we want to export them. Of course, they all have these awful, non-descriptive names. How do we list them? I was unable to find any help in the "automatic SQL tuning" guide (Chapter 12) of the Performance Guide, and browsing the DBA_* and other fixed views has not revealed anything, yet.

Does this help?
BANPROD_SQL > select id,name,owner,description,created from WRI$_SQLSET_DEFINITIONS order by 1 desc;
ID NAME OWNER DESCRIPTION CREATED
10 TUNING_SET_1141930799317 ORACLE Automatically generated by ADDM 09-MAR-06
9 TUNING_SET_1141921159123 ORACLE Automatically generated by ADDM 09-MAR-06
8 TUNING_SET_1141831053351 ORACLE Automatically generated by ADDM 08-MAR-06
7 TUNING_SET_1141826801391 ORACLE Automatically generated by ADDM 08-MAR-06
6 TOP_SQL_1141752418284 ORACLE Automatically generated by Top SQL 07-MAR-06
5 TOP_SQL_1141749589578 ORACLE Automatically generated by Top SQL 07-MAR-06
4 TOP_SQL_1141747575814 ORACLE Automatically generated by Top SQL 07-MAR-06
2 TOP_SQL_1141746930242 ORACLE Automatically generated by Top SQL 07-MAR-06
1 TUNING_SET_1141660362671 ORACLE Automatically generated by ADDM 06-MAR-06
9 rows selected.

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 | | |
---------------------------------------------------------------------------------------------------------------------------------------------------------------

Noob in SQL Tuning seeking help

I am trying to learn SQL Tuning and the workings of it. I know the first step is probably explain execution plan of the sql statement? My problem is I do not understand what am I suppose to gather from the execution plan.
SQL> set autotrace traceonly explain
SQL> select * from employees A
 where A.last_employed =
 ( SELECT TO_CHAR(MAX(TO_DATE(PAY_DATE,'MMRR')),'MMYY')
 FROM PAYROLL_VW1 B
 WHERE B.SSN = A.SSN AND B.PAY_TYPE_CODE IN ('02','12','22','32')
 AND STATUS = 'ACTIVE' AND A.BRANCH=B.BRANCH
Execution Plan
 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=47427 Card=1 Bytes
 =180)
 1 0 FILTER
 2 1 TABLE ACCESS (FULL) OF 'EMPLOYEES' (TABLE) (Cost=1618 Card
 =297964 Bytes=53633520)
 3 1 SORT (AGGREGATE)
 4 3 VIEW OF 'PAYROLL_VW1' (VIEW) (Cost=2290 Card=2 Bytes=
 46)
 5 4 SORT (UNIQUE) (Cost=2290 Card=2 Bytes=217)
 6 5 UNION-ALL
 7 6 FILTER
 8 7 TABLE ACCESS (FULL) OF 'PAYROLL2012' (TABLE) (C
 ost=2284 Card=1 Bytes=105)
 9 6 FILTER
10 9 TABLE ACCESS (BY INDEX ROWID) OF 'PAYROLL2011'
 (TABLE) (Cost=4 Card=1 Bytes=112)
11 10 INDEX (RANGE SCAN) OF 'PAYROLL2011_IDX1' (IND
 EX) (Cost=3 Card=29)So what do I do with the execution plan? What else do I need to check on it? How do I tune the query?
Edited by: apex_disco on May 1, 2012 5:57 AM

I'm not sure how the licensing works. There is a difference between EM and Grid Control. I believe if you just have a single instance, Enterprise Manager is installed and if anything is free I would think that would be. Now, how much of the diagnostic stuff is free? Who knows.
But it may not matter. If you are just playing around "trying to learn SQL Tuning" say, at home on a Linux box, you can install anything you want and play with it.
If adding an index sped things up (in your re-written query that now makes sense) then you must have had a fair amount of records in one of those unindexed tables. If you look at the explain plan now it'll probably show the indexes being used, less records searched, less cost, etc. than the other plan.
But maybe I missed your initial point. Are you trying to learn how to tune queries in general or are you trying to tune this particular query? I assumed the former for my previous replies.
As to your results, your stats tell at least the high level info. The consistent gets and physical reads went WAY down.
Initial Statistics
0 recursive calls
0 db block gets
 1172490142 consistent gets
4914 physical reads
191496 redo size
2340 bytes sent via SQL*Net to client
329 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
115881 sorts (memory) 
0 sorts (disk)
0 rows processed
on those tables and below are my stats now. I think it's a major improvement. Time elapsed has greatly been reduced to 00:00:00.65
Tuned Statistics
352 recursive calls
0 db block gets
31498 consistent gets
1101 physical reads
0 redo size

2340 bytes sent via SQL*Net to client
329 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
13 sorts (memory) 
0 sorts (disk)
0 rows processed
Edited by: Gaff on May 1, 2012 1:18 PM

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
Rogers

Bug 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)

E-Rows = NULL and A-Rows=42M? Need help in understanding why.

Hi,
Oracle Standard Edition 11.2.0.3.0 CPU Oct 2012 running on Windows 2008 R2 x64. I am using Oracle 10g syntax for WITH clause as the query will also run on Oracle 10gR2. I do not have a Oracle 10gR2 environment at hand to comment if this behaves the same.
Following query is beyond me. It takes around 2 minutes to return the "computed" result set of 66 rows.
SQL> WITH dat AS
2 (SELECT 723677 vid,
3 243668 fid,
4 TO_DATE ('06.03.2013', 'dd.mm.yyyy') mindt,
5 TO_DATE ('06.03.2013', 'dd.mm.yyyy') maxdt
6 FROM DUAL
7 UNION ALL
8 SELECT 721850,
9 243668,
10 TO_DATE ('06.02.2013', 'dd.mm.yyyy'),
11 TO_DATE (' 22.03.2013', 'dd.mm.yyyy')
12 FROM DUAL
13 UNION ALL
14 SELECT 723738,
15 243668,
16 TO_DATE ('16.03.2013', 'dd.mm.yyyy'),
17 TO_DATE (' 04.04.2013', 'dd.mm.yyyy')
18 FROM DUAL)
19 SELECT /*+ GATHER_PLAN_STATISTICS */ DISTINCT vid, fid, mindt - 1 + LEVEL dtshow
20 FROM dat
21 CONNECT BY LEVEL <= maxdt - mindt + 1
22 order by fid, vid, dtshow;
66 rows selected.
SQL>
SQL> SELECT * FROM TABLE (DBMS_XPLAN.display_cursor (NULL, NULL, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID 9c4vma4mds6zk, child number 0
WITH dat AS (SELECT 723677 vid, 243668 fid,
 TO_DATE ('06.03.2013', 'dd.mm.yyyy') mindt,
TO_DATE ('06.03.2013', 'dd.mm.yyyy') maxdt FROM DUAL
UNION ALL SELECT 721850, 243668,
 TO_DATE ('06.02.2013', 'dd.mm.yyyy'), TO_DATE ('
22.03.2013', 'dd.mm.yyyy') FROM DUAL UNION ALL
 SELECT 723738, 243668, TO_DATE
('16.03.2013', 'dd.mm.yyyy'), TO_DATE (' 04.04.2013',
'dd.mm.yyyy') FROM DUAL) SELECT /*+
GATHER_PLAN_STATISTICS */ DISTINCT vid, fid, mindt - 1 + LEVEL dtshow
 FROM dat CONNECT BY LEVEL <= maxdt - mindt + 1 order by fid, vid,
dtshow
Plan hash value: 1865145249
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | OMem | 1Mem | Used-Mem |
| 0 | SELECT STATEMENT | | 1 | | 66 |00:01:54.64 | | | |
| 1 | SORT UNIQUE | | 1 | 3 | 66 |00:01:54.64 | 6144 | 6144 | 6144 (0)|
| 2 | CONNECT BY WITHOUT FILTERING (UNIQUE)| | 1 | | 42M|00:01:04.00 | | | |
| 3 | VIEW | | 1 | 3 | 3 |00:00:00.01 | | | |
| 4 | UNION-ALL | | 1 | | 3 |00:00:00.01 | | | |
| 5 | FAST DUAL | | 1 | 1 | 1 |00:00:00.01 | | | |
| 6 | FAST DUAL | | 1 | 1 | 1 |00:00:00.01 | | | |
| 7 | FAST DUAL | | 1 | 1 | 1 |00:00:00.01 | | | |
--------------------------------------------------------------------------------------------------------------------------If I take out one of the UNION queries, the query returns in under 1 second.
SQL> WITH dat AS
2 (SELECT 723677 vid,
3 243668 fid,
4 TO_DATE ('06.03.2013', 'dd.mm.yyyy') mindt,
5 TO_DATE ('06.03.2013', 'dd.mm.yyyy') maxdt
6 FROM DUAL
7 UNION ALL
8 SELECT 721850,
9 243668,
10 TO_DATE ('06.02.2013', 'dd.mm.yyyy'),
11 TO_DATE (' 22.03.2013', 'dd.mm.yyyy')
12 FROM DUAL)
13 SELECT /*+ GATHER_PLAN_STATISTICS */ DISTINCT vid, fid, mindt - 1 + LEVEL dtshow
14 FROM dat
15 CONNECT BY LEVEL <= maxdt - mindt + 1
16 order by fid, vid, dtshow;
46 rows selected.
SQL>
SQL> SELECT * FROM TABLE (DBMS_XPLAN.display_cursor (NULL, NULL, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID 1d2f62uy0521p, child number 0
WITH dat AS (SELECT 723677 vid, 243668 fid,
 TO_DATE ('06.03.2013', 'dd.mm.yyyy') mindt,
TO_DATE ('06.03.2013', 'dd.mm.yyyy') maxdt FROM DUAL
UNION ALL SELECT 721850, 243668,
 TO_DATE ('06.02.2013', 'dd.mm.yyyy'), TO_DATE ('
22.03.2013', 'dd.mm.yyyy') FROM DUAL) SELECT /*+
GATHER_PLAN_STATISTICS */ DISTINCT vid, fid, mindt - 1 + LEVEL dtshow
 FROM dat CONNECT BY LEVEL <= maxdt - mindt + 1 order by fid, vid,
dtshow
Plan hash value: 2232696677
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | OMem | 1Mem | Used-Mem |
| 0 | SELECT STATEMENT | | 1 | | 46 |00:00:00.01 | | | |
| 1 | SORT UNIQUE | | 1 | 2 | 46 |00:00:00.01 | 4096 | 4096 | 4096 (0)|
| 2 | CONNECT BY WITHOUT FILTERING (UNIQUE)| | 1 | | 90 |00:00:00.01 | | | |
| 3 | VIEW | | 1 | 2 | 2 |00:00:00.01 | | | |
| 4 | UNION-ALL | | 1 | | 2 |00:00:00.01 | | | |
| 5 | FAST DUAL | | 1 | 1 | 1 |00:00:00.01 | | | |
| 6 | FAST DUAL | | 1 | 1 | 1 |00:00:00.01 | | | |
26 rows selected.What I cannot understand is why the E-Rows is NULL for "CONNECT BY WITHOUT FILTERING (UNIQUE)" step and A-Rows shoots up to 42M for first case. The behaviour is the same for any number of UNION queries above two.
Can anyone please help me understand this and aid in tuning this accordingly? Also, I would be happy to know if there are better ways to generate the missing date range.
Regards,
Satish

May be, this?
WITH dat AS
 (SELECT 723677 vid,
 243668 fid,
 TO_DATE ('06.03.2013', 'dd.mm.yyyy') mindt,
 TO_DATE ('06.03.2013', 'dd.mm.yyyy') maxdt
 FROM DUAL
 UNION ALL
 SELECT 721850,
 243668,
 TO_DATE ('06.02.2013', 'dd.mm.yyyy'),
 TO_DATE (' 22.03.2013', 'dd.mm.yyyy')
 FROM DUAL
 UNION ALL
 SELECT 723738,
 243668,
 TO_DATE ('16.03.2013', 'dd.mm.yyyy'),
 TO_DATE (' 04.04.2013', 'dd.mm.yyyy')
 FROM DUAL)
 SELECT vid, fid, mindt - 1 + LEVEL dtshow
 FROM dat
CONNECT BY LEVEL <= maxdt - mindt + 1
 and prior vid = vid
 and prior fid = fid
 and prior sys_guid() is not null
order by fid, vid, dtshow;
66 rows selected.
Elapsed: 00:00:00.03

SQL tuning for a query

Hello Gurus,
I have 2 tables. One with a million records and the other with 50,000 records.
Both have an account id column. The first table contains all the customer accounts and the second table has all the bad debt accounts.
My problem is I need to update the status column in the first table for all the bad debt records from the second table.
As I’m still a beginner in SQL tuning, can someone please help me write this query effi ciently considering the table sizes.
tables description:
SQL> desc customer
Name Null? Type
ACNTNO NUMBER(8)
STATUS VARCHAR2(6)
SQL> desc badcustomer
Name Null? Type
ACNTNO NUMBER(8)
The sql I could come up with is:
update customer outer
set status='closed'
where acntno exists (select 'X'
from badcustomer
where acntno=outer.acntno);
Thanks for taking time to read this post.

To post formatted code, put the {noformat} {noformat}- tag before and after your examples.
When you post:
{noformat} select *
from dual;
{noformat}
it will appear as: select *
from dual;
on the forum.
The FAQ will tell you more: http://forums.oracle.com/forums/help.jspa

Help in wriring an sql

Hi gurus,
just wondering whether this sql works fine.
Insert into contact_history@demo (narrative) select substrb(narrative,1,4000) from CONTACT_HISTORY
where I in (select i from missing_ivalue)
where demo is a dblink for source and the target database and narrative is a column name which is varchar2(4000)
contact_history@demo is a target table.
i actually need to insert complete record which has missing i value with the substrb(narrative,1,4000)
any suggestion is highly apprciated
Thanks
Edited by: 790072 on 8/02/2011 15:54
Edited by: 790072 on 16/08/2011 19:56

Hi,
790072 wrote:
Insert into toccontact_history@demo (narrative) select substrb(narrative,1,4000) from TOCCONTACT_HISTORY
where I in (select i from missing_ivalue)
where demo is a dblink for source and the target database and narrative is a column name which is varchar2(4000)
toccontact_history@demo is a target table.As per your post,the above insert statement will absolutely work fine,unless if you have insert permission for toccontact_history table,to your present schema,where you are executing the insert statement.Also you need to have db link created to access the tables,created in other schema.
Check the db_link created by using the query
select * from user_db_linksIts always suggested to post a sample data to understand your requirement cleary and we can try to provide you a solution to your problem.
Hope this helps.
Regards,
Achyut

ADDM recommendation regarding SQL Tuning

Hi all.
Several times, I've seen this recommendation when I run ADDM:
Recommendation 1: SQL Tuning
Estimated benefit is 1.78 active sessions, 4.93% of total activity.
Action
Tune the PL/SQL block with SQL_ID "9f9y14fzgg9a9". Refer to the "Tuning
PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and
Reference".
Related Object
SQL statement with SQL_ID 9f9y14fzgg9a9.
declare
rc__ number;
simple_list__ owa_util.vc_arr;
complex_list__ owa_util.vc_arr;
begin
owa.init_cgi_env(:n__,:nm__,:v__);
htp.HTBUF_LEN := 255;
null;
null;
simple_list__(1) := 'sys.%';
simple_list__(2) := 'dbms\_%';
simple_list__(3) := 'utl\_%';
simple_list__(4) := 'owa\_%';
simple_list__(5) := 'owa.%';
simple_list__(6) := 'htp.%';
simple_list__(7) := 'htf.%';
simple_list__(8) := 'wpg_docload.%';
if ((owa_match.match_pattern('adhoc_run.submit_rep', simple_list__,
complex_list__, true))) then
rc__ := 2;
else
null;
null;
adhoc_run.submit_rep(NAME_ARRAY=>:NAME_ARRAY,VALUE_ARRAY=>:VALUE_ARRA
Y);
if (wpg_docload.is_file_download) then
rc__ := 1;
wpg_docload.get_download_file(:doc_info);
null;
null;
null;
commit;
else
rc__ := 0;
null;
null;
null;
commit;
owa.get_page(:data__,:ndata__);
end if;
end if;
:rc__ := rc__;
end;
Rationale
SQL statement with SQL_ID "9f9y14fzgg9a9" was executed 206 times and had
an average elapsed time of 46 seconds.
My understanding is that this is an embedded APEX routine I can't control.
Question for the gurus out there:
- Have you seen this before?
- Is there any way to tune this (any parameter, etc.)? Any recommendation?
Thanks a lot,
Ignacio.

Hi,
How about SQL Profiles? Have thought in this direction?
Some info is here http://www.oracle-base.com/articles/10g/AutomaticSQLTuning10g.php
Regards,

SQL tuning or a simple comprise between time and cost?

Hi,
What I understand is that SQL tuning is a simple comprise between time and cost. Objectives of SQL tuning include:
Reduce Cost
Reduce Time
Better Results
Is it right and correct?
Adith

NO, WRONG.
reducing COST is meaningless, because COST is meaningless. It's used internally by the optimizer to weigh the cost/benefits of different execution plans (access methods) for a single query. cost CANNOT be compared across queries. and if you add a hint to a sql, then it becomes a different sql (proven by looking in v$sql) so you cannot compare costs. in fact, when you provide a hint, oracle artificially lowers the cost associated with the hinted action in order to make that action look better to the optimizer, helping it to be choosen.
reduce time. reduce io. reduce memory usage. that's it.

What is this SQL Tuning Advisor's Advice means

HI ,
I am Tuning a query wit hthe help of ORACLE 10 g 's SQL Tuning Advisor.I got the following recommendation .
**Consider removing the disconnected table or view from this statement or add a join condition which refers to it.**
I didn't understand what does this mean.
Can anyone please help me
Thanks,
Pramod.
Edited by: Pramod Garre on Jul 15, 2009 6:20 AM

Simply saying if i apply that profile i will get Good plan.But I want to change the SQL itself rather than applying profile.in that case what can be done.Automatic SQL Tuning deals with this problem with its SQL Profiling capability. The Automatic Tuning Optimizer creates a profile of the SQL statement called a SQL Profile, consisting of auxiliary statistics specific to that statement. The query optimizer under normal mode makes estimates about cardinality, selectivity, and cost that can sometimes be off by a significant amount resulting in poor execution plans. SQL Profile addresses this problem by collecting additional information using sampling and partial execution techniques to verify and, if necessary, adjust these estimates.During SQL Profiling, the Automatic Tuning Optimizer also uses execution history information of the SQL statement to appropriately set optimizer parameter settings, such as changing the OPTIMIZER_MODE initialization parameter setting from ALL_ROWS to FIRST_ROWS for that SQL statement.
If you want to change the SQL, You can re-write the SQL and evaluate the Performance recommendations SQL tuning Advisor.

Sql tuning advisor question on bind values

Hi guys,
I used the sql tuning wizard in Oracle 11g to get recommendation on how to improve performance on a long running query. Here is the recommendation I received:
At least one important bind value was missing for this sql statement. The
accuracy of the advisor's analysis may depend on all important bind values
being supplied.
Could someone please help me understand what it means? For example, what is a bind value, why was it missing, and why are they important?
Thanks!

I've seen this message maybe once before but I've never investigated it - I don't tend to run the SQL tuning advisor.
The best thing you could do is investigate the circumstances yourself, maybe trace the tuning advisor and see where it's getting its data from internally.
As mentioned, where it gets its data from depends on how you populate the tuning advisor - from cursor cache, awr, etc.
If it's from AWR as you mentioned, have a look at DBA_HIST_SQLSTAT.BIND_DATA for example? Or maybe DBA_HIST_SQLBIND? Etc.
You can check what the advisor probably pulls out of AWR using something like this:
select *
from table(dbms_Sqltune.select_workload_repository
 (begin_snap => 6441,
 end_snap => 6443,
 basic_filter => 'sql_id = ''gr5tqfnz07sxk'''));If the bind_list is empty then you know what it's complaining about.
I just tried it with an example sql it that I can see has bind data in DBA_HIST_SQLSTAT and DBA_HIST_SQLBIND and the BIND_LIST in the SQLSET returned by the SQL set above is null so that raises some questions ( I might be doing something wrong but as mentioned, it's not really something I tend to use).
The BIND_DATA raw is populated for me (although the bind_list collection isn't hence why original comment above).
If you know a representative set of binds, you can kick off your own tuning task manually and supply your own set of binds - see DBMS_SQLTUNE.CREATE_TUNING_TASK.
You can also extract and inspect the RAW BIND_DATA into a set of binds using DBMS_SQLTUNE.EXTRACT_BINDS.
e.g. to inspect:
select x.*
from v$sql s
, table(dbms_sqltune.extract_binds(s.bind_data)) x
where sql_id = '<sql_id>';Edited by: Dom Brooks on May 17, 2012 5:59 PM

Need help in rewriting a sql query

Can any one please tell me if there is any utility that can help me correcting the sql I have I need to tune the query as its taking lot of time. I want to use some tool that will help me re-formating the query.
Any help in this regard will be highly appreciated.

If you think that Oracle SQL Tuning Tools like SQL Tuning Advisor and SQL Access Advisor are not helping.
You might look into thrid party tools like Quest- SQL Navigator and TOAD.
But I don't advise this based on the following:
Re: Oracle Third Party Tools and Oracle Database
Oracle have enough tools of its own to satisfy the various needs.
Adith

Need help in understanding why so many gets and I/O

Hi there,
I have a sql file somewhat similar in structure to below:
delete from table emp;-- changed to Truncate table emp;
delete from table dept;--changed to Truncate table dept;
insert into emp values() select a,b,c from temp_emp,temp_dept where temp_emp.id=temp_dept.emp_id
update emp set emp_name=(select emp_name from dept where emp.id=dept.emp_id);
commit --only at the end
the above file takes about 9-10 hrs to complete its operation. and
the values from v$sql for the statement
update emp set emp_name=(select emp_name from dept where emp.id=dept.emp_id);
are as below:
SHARABLE_MEM PERSISTENT_MEM RUNTIME_MEM SORTS LOADED_VERSIONS OPEN_VERSIONS USERS_OPENING FETCHES EXECUTIONS PX_SERVERS_EXECUTIONS END_OF_FETCH_COUNT USERS_EXECUTING LOADS FIRST_LOAD_TIME INVALIDATIONS PARSE_CALLS DISK_READS DIRECT_WRITES BUFFER_GETS APPLICATION_WAIT_TIME CONCURRENCY_WAIT_TIME CLUSTER_WAIT_TIME USER_IO_WAIT_TIME PLSQL_EXEC_TIME JAVA_EXEC_TIME ROWS_PROCESSED COMMAND_TYPE OPTIMIZER_MODE OPTIMIZER_COST OPTIMIZER_ENV OPTIMIZER_ENV_HASH_VALUE PARSING_USER_ID PARSING_SCHEMA_ID PARSING_SCHEMA_NAME KEPT_VERSIONS ADDRESS TYPE_CHK_HEAP HASH_VALUE OLD_HASH_VALUE PLAN_HASH_VALUE CHILD_NUMBER SERVICE SERVICE_HASH MODULE MODULE_HASH ACTION ACTION_HASH SERIALIZABLE_ABORTS OUTLINE_CATEGORY CPU_TIME ELAPSED_TIME OUTLINE_SID CHILD_ADDRESS SQLTYPE REMOTE OBJECT_STATUS LITERAL_HASH_VALUE LAST_LOAD_TIME IS_OBSOLETE CHILD_LATCH SQL_PROFILE PROGRAM_ID PROGRAM_LINE# EXACT_MATCHING_SIGNATURE FORCE_MATCHING_SIGNATURE LAST_ACTIVE_TIME BIND_DATA TYPECHECK_MEM
18965 8760 7880 0 1 0 0 0 2 0 2 0 2 2011-05-10/21:16:44 1 2 163270378 0 164295929 0 509739 0 3215857850 0 0 20142 6 ALL_ROWS 656 E289FB89A4E49800CE001000AEF9E3E2CFFA331056414155519421105555551545555558591555449665851D5511058555155511152552455580588055A1454A8E0950402000002000000000010000100050000002002080007D000000000002C06566001010000080830F400000E032330000000001404A8E09504646262040262320030020003020A000A5A000 4279923421 50 50 APPS 0 00000003CBE5EF50 00 1866523305 816672812 1937724149 0 SYS$USERS 0 01@</my.sql -2038272289 -265190056 0 9468268067 10420092918 00000003E8593000 6 N VALID 0 2011-05-11/10:23:45 N 5 0 0 1.57848E+19 1.57848E+19 5/12/2011 4:39 0
1) how do i re-write this legacy script? and what should be done to improve performance?
2) Should i use PL/sql to re-write it?
3) Also help in understanding why a simple update statement is doing so many buffer gets and reading , Is this Read consistency Trap as i'm not committing anywhere in between or it is actually doing so much of work.
(assume dept table has cols emp_name and emp_id also)

update emp set emp_name=(select emp_name from dept where emp.id=dept.emp_id);I guess that these are masked table names ? Nobody would have emp_name in a dept table.
Can you re-format the output, using "code" tags ( [ or { }
Hemant K Chitale
Edited by: Hemant K Chitale on May 12, 2011 12:44 PM

Need help for understanding the behaviour of these 2 queries....

Hi,
I need your help for understanding the behaviour of following two queries.
The requirement is to repeat the values of the column in a table random no of times.
Eg. A table xyz is like -
create table xyz as
select 'A' || rownum my_col
from all_objects
where rownum < 6;
my_col
A1
A2
A3
A4
A5
I want to repeat each of these values (A1, A2,...A5) multiple times - randomly decide. I have written the following query..
with x as (select my_col, trunc(dbms_random.value(1,6)) repeat from xyz),
y as (select level lvl from dual connect by level < 6)
select my_col, lvl
from x, y
where lvl <= repeat
order by my_col, lvl
It gives output like
my_col lvl
A1 1
A1 3
A1 5
A2 1
A2 3
A2 5
A3 1
A3 3
A3 5
A4 1
A4 3
A4 5
A5 1
A5 3
A5 5
Here in the output, I am not getting rows like
A1 2
A1 4
A2 2
A2 4
Also, it has generated the same set of records for all the values (A1, A2,...,A5).
Now, if I store the randomly-decided value in the table like ---
create table xyz as
select 'A' || rownum my_col, trunc(dbms_random.value(1,6)) repeat
from all_objects
where rownum < 6;
my_col repeat
A1 4
A2 1
A3 5
A4 2
A5 2
And then run the query,
with x as (select my_col, repeat from xyz),
y as (select level lvl from dual connect by level < 6)
select my_col, lvl
from x, y
where lvl <= repeat
order by my_col, lvl
I will get the output, exactly what I want ---
my_col ....lvl
A1 1
A1 2
A1 3
A1 4
A2 1
A3 1
A3 2
A3 3
A3 4
A3 5
A4 1
A4 2
A5 1
A5 2
Why the first approach do not generate such output?
How can I get such a result without storing the repeat values?

If I've understood your requirement, the below will achieve it:
SQL> create table test(test varchar2(10));
Table created.
SQL> insert into test values('&test');
Enter value for test: bob
old 1: insert into test values('&test')
new 1: insert into test values('bob')
1 row created.
SQL> insert into test values('&test');
Enter value for test: terry
old 1: insert into test values('&test')
new 1: insert into test values('terry')
1 row created.
SQL> insert into test values('&test');
Enter value for test: steve
old 1: insert into test values('&test')
new 1: insert into test values('steve')
1 row created.
SQL> insert into test values('&test');
Enter value for test: roger
old 1: insert into test values('&test')
new 1: insert into test values('roger')
1 row created.
SQL> commit;
Commit complete.
SQL> select lpad(test,(ceil(dbms_random.value*10))*length(test),test) from test;
LPAD(TEST,(CEIL(DBMS_RANDOM.VALUE*10))*LENGTH(TEST),TEST)
bobbobbobbobbobbobbobbobbobbob
terryterry
stevestevesteve
rogerrogerrogerrogerrogerrogerrogerrogerrogerYou can alter the value of 10 in the SQL if you want the potential for a higher number of names.
Andy

Gurus..Help in understanding PL/SQL Tuning

Similar Messages

Maybe you are looking for