Need a SQL tuning tool!! Urgent

Hi,
does anyone know any good SQL tuning tool on Oracle?? I need one urgently for a large project.
I've tried Quest SQLLab and it can't solve my problems. It only "advice" me. I need something more powerful!!
Any suggestions??
Many thanks
Bosco

all the other columns used in query will not be indexed!
IMSDBA     IMS_TRDE_HSTRY_INDX_ARCH     IMSDBA     IMS_TRDE_HSTRY     ARCHIVEDT     1     7     0     ASC
IMSDBA     IMS_TRDE_HSTRY_INDX1     IMSDBA     IMS_TRDE_HSTRY     IMS_TRDE_OID     1     16     16     ASC
IMSDBA     PK_IMS_TRDE     IMSDBA     IMS_TRDE     IMS_TRDE_OID     1     16     16     ASC
IMSDBA     IMS_TRDE_INDX_ARCH     IMSDBA     IMS_TRDE     ARCHIVEDT     1     7     0     ASCAlso,the table is a very big table indeed:
SEGMENT_NAME                   BYTES/1024/1024/1024
IMS_TRDE_HSTRY                             30.28125GBthanks
Edited by: PhoenixBai on Oct 14, 2009 5:14 PM

Similar Messages

  • MS Access developer with a change of career, so need PL/SQL type tools pls

    Hello,
    I am a recent MS Access developer, my position went away, so now need to bone up on PL/SQL 101 sort of knowledge. I have very little SQL experience, so am starting from square one in my learning Oracle. I would like available to me to-the-point examples of code when working with Oracle data using SQL Navigator 5 as my "Enterprise Manager" type tool. I need to quickly understand the basics in creating\constructing Stored Procedures and PL/SQL statements, need examples of naming conventions in the code and what the conventions achieve for me. I don’t want full details, just more to the point info please, unless you feel the details will be very useful in my understanding of the dbase tool.
    Any info that you are willing to share to get me up and going would be appreciated!

    1) If at all possible, use plain SQL instead of PL/SQL. See the O'Reilly book 'Mastering Oracle SQL'. A very high percentage of procedural code developed against Oracle is caused by not understanding how to code in 'plain' SQL.
    2) Learn Oracle PL/SQL - any book by Steven Feuerstein will do. Again, look at O'Reilly.
    3) Learn to read the Oracle docco. See http://tahiti.oracle.com
    4) Understand 'effective Oracle coding' by reading any Tom Kyte book (at http://www.apress.com)
    5) Use Oracle's SQL Developer as your basic development tool, and Oracle's JDeveloper as the advanced development tool - JDeveloper has a PL/SQL debugger built-in.
    6) Get very, very familiar with the available PL/SQL library API ... look for the Supplied PL/SQL Procedures and Packages manual for the version of interest. (Name changes with versions, but that should give you the idea.)

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

  • Any tool or shortcut to get SQL tuning suggestion???????

    Hi I have to tune an application and need to go throught alot many SQL their PLAN and ti tune them.
    I want to know ether is there any tool online or may be from oracle to get the tuning suggestions straighytway.my oracle version is 9206
    Can i use 10g SQL tuning advisor with 9i database????
    Thanks
    Gagan

    Hi Gagan,
    Can i use 10g SQL tuning advisor with 9i databaseNo, but you can do the same thing manually, and often do a better job:
    Tune SQL with optimizer parms:
    http://www.dba-oracle.com/t_sql_optimizer_parameters.htm
    Find missing indexes:
    1 - Search for unnecessary large-table, full-table scans
    2 - Compare consistent gets to rows returned
    http://www.dba-oracle.com/art_sql_tune.htm
    Hope this helps. . . .
    Donald K. Burleson
    Oracle Press author

  • Tuning sql automatic using SQL Tuning Advisor Tool

    I need to work on Automatic sql tuning..
    Please give suggestion for the below
    1) I have installed oracle11g client version. confirm this is okey for my project. because i heard we should have oracle enterprise edition for this.
    2) User with only sys privelage can work on this automatic sql tuning using sql tuning advisior tool.
    Please clarify above suggestions.
    ALso suggest me best way to proceed further
    S

    Sunny kichloo wrote:
    This docs will help
    http://www.oracle-base.com/articles/10g/automatic-sql-tuning-10g.php
    http://www.oracle-base.com/articles/11g/automatic-sql-tuning-11gr1.php
    Thanks for your link. i already seen this link.
    Could u pls answer my question on above with " Yes" or "No"
    Kindly reply
    S

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

    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 you

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

  • 1Z0-117: Oracle Database 11g Release 2: SQL Tuning Need Materia and Dumps

    Hi all,
    We are preparing for 1Z0-117: Oracle Database 11g Release 2: SQL Tuning, There is shortage of material available on net.
    Can anybody please provide books or Sample question answers and share more idea about the exan.
    mail id XXXXXXXXXXXXX
    Thanks in Advance
    Sandeep
    Edited by: 1005555 on 13 May, 2013 4:54 AM+
    Mod: email deleted, don't draw discussion away from the forum.
    Edited by: PhHein on 13.05.2013 14:16
    Edited by: 1005555 on 13 May, 2013 10:16 PM

    We are preparing for 1Z0-117: Oracle Database 11g Release 2: SQL Tuning, There is shortage of material available on net.There are actually a fair number of articles about the material covered on 117 on the net, but yes, the test is new enough that cheaters have not had much of a chance to email around illegal material such as dumps yet.
    Can anybody please provide books or Dumps and share more idea about the exan.There is a significant amount of legitimate material you can use to study for the exam here:
    http://www.oraclecertificationprep.com/apex/f?p=OCPSG:EXAM_DETAILS:0::NO::P2_EXAM:1Z0-117
    As for ideas about the exam -- it's probably the hardest Oracle certification exam I have ever taken:
    http://ocprep.blogspot.com/2013/03/1z0-117-this-exam-is-rough.html

  • Need a SQL query(Pls Its urgent)

    Hi,
    I want a SQL query for the foll..
    Details r below..
    Table AFPFTRAN
    BU TRansactiondate Amt
    13202 10-04-05 10,000
    13203 11-05-05 20,000
    13202 20-04-05 5,000
    Table AFGENCOD
    BU Clerk Name Clerk Code
    13202 Amit TFBG
    13203 Anand TFMG
    I want a query to get data as below..
    Tr Date TFBG TFMG
    Apr 15,000 0
    May 0 20,000
    JUn 0 0
    Jul 0 0
    Aug
    Sep
    Aug
    Nov
    DEc
    Jan
    Feb
    Mar
    I want this to achieve using a single query...?How can I achive this?
    Pls give the sol...
    Adios...
    Prashanth Deshmukh

    Does it look like you need ?
    SQL> select * from t;
            BU TDATE           AMT
         13202 10.04.05      10000
         13203 11.05.05      20000
         13202 20.04.05       5000
    SQL> select * from t1;
            BU NAME  CODE
         13202 Amit  TFBG
         13203 Anand TFMG
    SQL> SELECT pivot_month.mname, tops.TFBG, tops.TFMG
      2  from
      3  (
      4  select to_char(t.tdate,'MM') month_no,
      5  sum(decode(t1.code,'TFBG',t.amt,0)) TFBG,
      6  sum(decode(t1.code,'TFMG',t.amt,0)) TFMG
      7  from t1, t
      8  where t.bu=t1.bu
      9  and to_char(t.tdate,'yyyy') = 2005
    10  GROUP BY t1.code, to_char(t.tdate,'MM')
    11  ) tops,
    12  (select rownum mn, to_char(to_date(rownum,'MM'),'MON') mname,
    13  case when rownum between 1 and 3 then rownum + 9
    14  else rownum - 3 end rn
    15  from dict where rownum < 13) pivot_month
    16  where pivot_month.mn = tops.month_no (+)
    17  order by pivot_month.rn
    18  /
    MNA       TFBG       TFMG
    APR      15000          0
    MAY          0      20000
    JUN
    JUL
    AUG
    SEP
    OCT
    NOV
    DEC
    JAN
    FEB
    MAR
    12 rows selected.Rgds.

  • Loading SQL Tuning Sets

    On a 10.2.0.4 database, is it possible to load SQL Tuning sets with SQL from a text file? I can't find anything in the documentation mentioning this but I could have simply missed it and this facility would be very useful to us.
    Our reporting tool is MicroStrategy which operates by building lots of temporary tables: extracting the SQL via Top Activity EM page will put the CTAS statement into the tuning set which (I believe) is ignored by SQL Access Advisor - extracting the sql to a text file, editting to remove the "create table as" and executing in order to load the tuning set is very long winded for a set of queries - at least being able to load the tuning set directly with a set of SQL select statements directly from a text file would help significantly.
    Many thanks for any advice
    Pete

    I did not see a direct way to create the STS from a text file. From the docs:
    "The standard sources for populating an STS are the workload repository, another STS, or the cursor cache"
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sql_tune.htm#i34915
    But you could try a couple of things:
    1) create one tuning task per statement, using DBMS_SQLTUNE.CREATE_TUNING_TASK, which can use plain text as input: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sql_tune.htm#CHDJDHGE
    2) create the STS with queries from cursor cache: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_sqltun.htm#i1010615
    Both approaches needs some PL/SQL programming, but it can be useful if you can identify your SQL statements some way.
    Regards.

  • SQL Tuning for Exadata

    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
    sunil

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

  • SSDT, SSDT-BI, and SQL Server Tooling in VS 2013

    I am upgrading from SQL Server 2008 R2 to SQL Server 2014, and I'm a little confused as to the upgrade path for SQL Server Business Intelligence Studio (BIDS). I'd thought that SQL Server Data Tools (SSDT) was replacing BIDS in subsequent versions of SQL
    Server i.e., 2012 and 2014. However, when I go to install SQL Server 2014, I don't see an option for SSDT. Do I need to download and install SSDT seperately in the form of SSDT 2012, SQL Server Tooling in VS 2013, SSDT-BI for 2013?
    http://msdn.microsoft.com/en-us/data/hh297027
    What's the difference between SSDT and SSDT-BI?
    A-
    Adam

    Hi Adam,
    >> Do I need to download and install SSDT separately in the form of SSDT 2012, SQL Server Tooling in VS 2013, SSDT-BI for 2013?
    In addition to Piotr’s post, you can install SSDT for 2014 via the following method:
    In Visual Studio 2013, go to the Tools menu, select “Extensions and Updates”. On the left of the window there is a section named “Updates”, and under that is “Product Updates”, then look for the Microsoft SQL Server Update for database tooling and click update.
    >> What's the difference between SSDT and SSDT-BI?
    SSDT-BI is a distinct toolset from SSDT or the SQL Server database tooling in Visual Studio, it includes BI project authoring tools and project templates for SSIS/SSAS/SSRS. However, SSDT does not include the BI templates, it is used for building databases.
    Thanks,
    Lydia Zhang
    If you have any feedback on our support, please click
    here.

  • 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                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • SQL Tuning and OPTIMIZER - Execution Time with  " AND col .."

    Hi all,
    I get a question about SQL Tuning and OPTIMIZER.
    There are three samples with EXPLAIN PLAN and execution time.
    This "tw_pkg.getMaxAktion" is a PLSQL Package.
    1.) Execution Time : 0.25 Second
    2.) Execution Time : 0.59 Second
    3.) Execution Time : 1.11 Second
    The only difference is some additional "AND col <> .."
    Why is this execution time growing so strong?
    Many Thanks,
    Thomas
    ----[First example]---
    Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
    Connected as dbadmin2
    SQL>
    SQL> EXPLAIN PLAN FOR
      2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
      3                    FROM studie
      4                 ) max_aktion
      5  WHERE max_aktion.max_aktion_id < 900 ;
    Explained
    SQL> SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3201460684
    | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
    |   0 | SELECT STATEMENT     |             |   220 |   880 |     5  (40)| 00:00:
    |*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |   220 |   880 |     5  (40)| 00:00:
    Predicate Information (identified by operation id):
       1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900)
    13 rows selected
    SQL>
    Execution time (PL/SQL Developer says): 0.25 seconds
    ----[/First]---
    ----[Second example]---
    Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
    Connected as dbadmin2
    SQL>
    SQL> EXPLAIN PLAN FOR
      2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
      3                    FROM studie
      4                 ) max_aktion
      5  WHERE max_aktion.max_aktion_id < 900
      6    AND max_aktion.max_aktion_id <> 692;
    Explained
    SQL> SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3201460684
    | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
    |   0 | SELECT STATEMENT     |             |    11 |    44 |     6  (50)| 00:00:
    |*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |    11 |    44 |     6  (50)| 00:00:
    Predicate Information (identified by operation id):
       1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
                  "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692)
    14 rows selected
    SQL>
    Execution time (PL/SQL Developer says): 0.59 seconds
    ----[/Second]---
    ----[Third example]---
    SQL> EXPLAIN PLAN FOR
      2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
      3                    FROM studie
      4                 ) max_aktion
      5  WHERE max_aktion.max_aktion_id < 900
      6    AND max_aktion.max_aktion_id <> 692
      7    AND max_aktion.max_aktion_id <> 392;
    Explained
    SQL> SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3201460684
    | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
    |   0 | SELECT STATEMENT     |             |     1 |     4 |     6  (50)| 00:00:
    |*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |     1 |     4 |     6  (50)| 00:00:
    Predicate Information (identified by operation id):
       1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
                  "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692 AND
                  "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>392)
    15 rows selected
    SQL>
    Execution time (PL/SQL Developer says): 1.11 seconds
    ----[/Third]---Edited by: thomas_w on Jul 9, 2010 11:35 AM
    Edited by: thomas_w on Jul 12, 2010 8:29 AM

    Hi,
    this is likely because SQL Developer fetches and displays only limited number of rows from query results.
    This number is a parameter called 'sql array fetch size', you can find it in SQL Developer preferences under Tools/Preferences/Database/Advanced tab, and it's default value is 50 rows.
    Query scans a table from the beginning and continue scanning until first 50 rows are selected.
    If query conditions are more selective, then more table rows (or index entries) must be scanned to fetch first 50 results and execution time grows.
    This effect is usually unnoticeable when query uses simple and fast built-in comparison operators (like = <> etc) or oracle built-in functions, but your query uses a PL/SQL function that is much more slower than built-in functions/operators.
    Try to change this parameter to 1000 and most likely you will see that execution time of all 3 queries will be similar.
    Look at this simple test to figure out how it works:
    CREATE TABLE studie AS
    SELECT row_number() OVER (ORDER BY object_id) studie_id,  o.*
    FROM (
      SELECT * FROM all_objects
      CROSS JOIN
      (SELECT 1 FROM dual CONNECT BY LEVEL <= 100)
    ) o;
    CREATE INDEX studie_ix ON studie(object_name, studie_id);
    ANALYZE TABLE studie COMPUTE STATISTICS;
    CREATE OR REPLACE FUNCTION very_slow_function(action IN NUMBER)
    RETURN NUMBER
    IS
    BEGIN
      RETURN action;
    END;
    /'SQL array fetch size' parameter in SQLDeveloper has been set to 50 (default). We will run 3 different queries on test table.
    Query 1:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id < 900
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      1.22       1.29          0       1310          0          50
    total        3      1.22       1.29          0       1310          0          50
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
         50  INDEX FAST FULL SCAN STUDIE_IX (cr=1310 pr=0 pw=0 time=355838 us cost=5536 size=827075 card=165415)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
         50   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id < 900
          AND max_aktion.max_aktion_id > 800
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.01          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      8.40       8.62          0       9351          0          50
    total        3      8.40       8.64          0       9351          0          50
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
         50  INDEX FAST FULL SCAN STUDIE_IX (cr=9351 pr=0 pw=0 time=16988202 us cost=5552 size=41355 card=8271)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
         50   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id = 600
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.01       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     18.72      19.16          0      19315          0           1
    total        3     18.73      19.16          0      19315          0           1
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
          1  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          1   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 1 - 1,29 sec, 50 rows fetched, 1310 index entries scanned to find these 50 rows.
    Query 2 - 8,64 sec, 50 rows fetched, 9351 index entries scanned to find these 50 rows.
    Query 3 - 19,16 sec, only 1 row fetched, 19315 index entries scanned (full index).
    Now 'SQL array fetch size' parameter in SQLDeveloper has been set to 1000.
    Query 1:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id < 900
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     18.35      18.46          0      19315          0         899
    total        3     18.35      18.46          0      19315          0         899
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
        899  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=20571272 us cost=5536 size=827075 card=165415)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
        899   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id < 900
          AND max_aktion.max_aktion_id > 800
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     18.79      18.86          0      19315          0          99
    total        3     18.79      18.86          0      19315          0          99
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
         99  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=32805696 us cost=5552 size=41355 card=8271)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
         99   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id = 600
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     18.69      18.84          0      19315          0           1
    total        3     18.69      18.84          0      19315          0           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
          1  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          1   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)And now:
    Query 1 - 18.46 sec, 899 rows fetched, 19315 index entries scanned.
    Query 2 - 18.86 sec, 99 rows fetched, 19315 index entries scanned.
    Query 3 - 18.84 sec, 1 row fetched, 19315 index entries scanned.

  • Oracle 10g performance tuning tools

    hi,
    can anyone please suggest me any oracle database tuning tool to use for improving the performance of the database?(oracle 10g)

    Hi,
    Do you want a tuning tool that does not require the user to have in-depth Oracle knowledge? If so, try here:
    http://images.google.com/images?&q=ouija+board&um=1&ie=UTF-8&sa=N&tab=wi
    Seriously, I like to use AWR and STATSPACK reports, and there are some freeware tools to help analyze them, one that I sponsor:
    http://www.statspackanalyzer.com
    For online tools, Oracle SQL Developer is a great way to get started, as-is the Oracle performance pack:
    http://www.oracle.com/technology/products/database/sql_developer/index.html
    For third-party tuning tools, look at Confio, quite good:
    http://www.confio.com/
    Hope this helps. . .
    Don Burleson
    Oracle Press author
    Author of “Oracle Tuning: The Definitive Reference”
    http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

Maybe you are looking for