Sql tuning with siebel 8.0

hi all
i am currently working with siebel 8.0 with oracle as database (10g) , can any one provide me with sql tuning docs
as i have never worked with siebel and most of the tuning work is to be done on dynamic sql
thanx in advance

changing the code is the last thing on my mind as i have never worked with siebel
but will start with analysing the DB and will certainly use addm, awr and ash
and i hope this forum will guide me before i make some changesChanging the code isn't easy with Siebel as its a packaged application and the SQl's are dynamically generated from Siebel engine based on the Business component layer configurations.
AWR and ADDM can give you information on the Top queries and other information.
You have to approach tuning the way in which siebel generates the sql from the application. In order to start with Tuning, Take a look at the link posted in this post. There are session level settings for every application connection into siebel and you have to follow the same way when you try to tune from the database.
HTH
-Anantha

Similar Messages

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.

How to Run SQL Tuning Advisor on the SQL statement with SQL_ID?

Can you give the steps to run the SQL tuning advisor on the SQL statement with SQL_ID?
Database version: 10g Release 2

Hi,
You can use either the automatic SQL tuning features that are accessible from Enterprise Manager Database Console on the "Advisor Central" page or trough SQL*PLUS using the DBMS_SQLTUNE pakage:
-- creating the tuning task
set serveroutput on
declare
l_sql_tune_task_id varchar2(100);
begin
l_sql_tune_task_id := dbms_sqltune.create_tuning_task (
 sql_id => '<your_sql_id>',
 scope => dbms_sqltune.scope_comprehensive,
 time_limit => 60,
 task_name => '<your_tuning_task_name>',
 description => 'tuning task for statement your_sql_id.');
dbms_output.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
end;
-- executing the tuning task
exec dbms_sqltune.execute_tuning_task(task_name => '<your_tuning_task_name>');
-- displaying the recommendations
set long 100000;
set longchunksize 1000
set pagesize 10000
set linesize 100
select dbms_sqltune.report_tuning_task('<your_tuning_task_name>') as recommendations from dual;For more information, take a look at link provided by Jaffy.
Cheers
Legatti

Need Help in sql tuning in EXADATA environment

I am uploadin the sql with its current explain plan, this sql in Prd database is executing in 6-10 mins and we need to improve this sql perf to 1-2 mins as the requirement from business team.
I am giving some backgroud about this sql tuning requirement, this sql is newly developed in and currently is in UAT phase, we don't have much option for tuning code here since the sql is tool generated through COGNOS DataMart tool, options are there to look into from DBA end with plan level or creating indexes on suitible columns to reduce i/o in minimizing the rows traversing by the sql.
Is anybody can help me out here?
WITH "WCRS_CLAIM_DETAIL_VW5"
AS (SELECT "WCRS_CLAIM_DETAIL_VW"."CLAIM_DETAIL_PK_ID"
"CLAIM_DETAIL_PK_ID",
"WCRS_CLAIM_DETAIL_VW"."CLAIM_ID" "CLAIM_ID",
"WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
"CURRENT_SNAPSHOT_IND",
"WCRS_CLAIM_DETAIL_VW"."LOSS_DT" "LOSS_DT",
"WCRS_CLAIM_DETAIL_VW"."REGULATORY_STATE_CD"
"REGULATORY_STATE_CD"
FROM "CDW_DLV_IDS"."WCRS_CLAIM_DETAIL_VW" "WCRS_CLAIM_DETAIL_VW"
WHERE "WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y'),
"WCRS_POLICY_DETAIL_VW7"
AS (SELECT "WCRS_POLICY_DETAIL_VW"."CLAIM_NBR" "CLAIM_NBR",
"WCRS_POLICY_DETAIL_VW"."CLAIM_SYMBOL_CD" "CLAIM_SYMBOL_CD",
"WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
"CURRENT_SNAPSHOT_IND",
"WCRS_POLICY_DETAIL_VW"."KEY_OFFICE_CD" "KEY_OFFICE_CD",
"WCRS_POLICY_DETAIL_VW"."POLICY_NBR" "POLICY_NBR"
FROM "CDW_DLV_IDS"."WCRS_POLICY_DETAIL_VW" "WCRS_POLICY_DETAIL_VW"
WHERE "WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y')
SELECT /*+ gather_plan_statistics monitor bind_aware */
/* ^^unique_id */
"T0"."C0" "Account_Name",
"T0"."C1" "Accident_State_Cd",
"T0"."C2" "c3",
"T0"."C3" "PPO_Name",
"T0"."C4" "Invc_Classification_Type_Desc",
FIRST_VALUE (
"T0"."C5")
OVER (
PARTITION BY "T0"."C0",
"T0"."C1",
"T0"."C2",
"T0"."C3",
"T0"."C4",
"T0"."C6")
"Claim_Cnt___Distinct",
"T0"."C7" "Invc_Control_Number",
"T0"."C8" "Invc_Allowance_Amt",
"T0"."C9" "Invc_Charge_Amt",
"T0"."C10" "c10",
"T0"."C11" "PPO_Reduction_Amt",
"T0"."C12" "Dup_Ln_Save_Amt",
"T0"."C13" "c13",
"T0"."C14" "Sub_Total",
"T0"."C15" "c15",
"T0"."C6" "c16"
FROM (SELECT "T1"."C0" "C0",
"T1"."C1" "C1",
"T1"."C2" "C2",
"T1"."C3" "C3",
"T1"."C4" "C4",
"T1"."C6" "C5",
"T1"."C5" "C6",
"T0"."C0" "C7",
"T1"."C7" "C8",
"T1"."C8" "C9",
"T1"."C9" "C10",
"T1"."C10" "C11",
"T1"."C11" "C12",
"T1"."C12" "C13",
"T1"."C13" "C14",
"T1"."C14" "C15"
FROM (SELECT COUNT (DISTINCT "INVC_DIM_VW"."INVC_ID") "C0"
FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
"WCRS_CLAIM_DETAIL_VW5",
"EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
"EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
"EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
"EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
"EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
"CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
"CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
"WCRS_POLICY_DETAIL_VW7",
"EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
'Original'
AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
"ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
"WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
"WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
"WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
"WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
"WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
"INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
"INVC_DIM_VW"."INVC_GID"
AND "INVC_DIM_VW"."INVC_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT") "T0",
( SELECT "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" "C0",
"WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD" "C1",
CASE
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'Y'
THEN
'In - Network'
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'N'
THEN
'Out - Network'
ELSE
'Others'
END
"C2",
"PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM" "C3",
"INVC_DIM_VW"."INVC_CLASS_TYPE_DESC" "C4",
CASE
WHEN (EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
OR (EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
THEN
NULL
ELSE
( EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
|| EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
END
"C5",
COUNT (DISTINCT "WCRS_CLAIM_DETAIL_VW5"."CLAIM_ID")
"C6",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT") "C7",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
"C8",
SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."TOT_INVC_REVIEW_RULE_ALWC_AMT")
"C9",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PPO_REDUC_AMT")
"C10",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
"C11",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_OSR_REDUC_AMT")
"C12",
( SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
- SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT"))
- SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
"C13",
SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CLNT_SPEC_REDUC_AMT")
"C14"
FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
"WCRS_CLAIM_DETAIL_VW5",
"EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
"EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
"EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
"EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
"EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
"CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
"CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
"WCRS_POLICY_DETAIL_VW7",
"EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
'Original'
AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
"ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
"WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
"WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
"WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
"WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
"WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
"INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
"INVC_DIM_VW"."INVC_GID"
AND "INVC_DIM_VW"."INVC_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
GROUP BY "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM",
"WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD",
CASE
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'Y'
THEN
'In - Network'
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'N'
THEN
'Out - Network'
ELSE
'Others'
END,
"PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM",
"INVC_DIM_VW"."INVC_CLASS_TYPE_DESC",
CASE
WHEN (EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
OR (EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
THEN
NULL
ELSE
( EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
|| EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
END) "T1") "T0"
ORDER BY "Account_Name" ASC NULLS LAST,
"Accident_State_Cd" ASC NULLS LAST,
"c3" ASC NULLS LAST,
"PPO_Name" ASC NULLS LAST,
"Invc_Classification_Type_Desc" ASC NULLS LAST

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 838 | 1079K (1)| 00:00:34 | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 10M| 317M| 848K (1)| 00:00:27 | | |
| 4 | LOAD AS SELECT | SYS_TEMP_0FD9D677A_286AAA2E | | | | | | |
| 5 | PX BLOCK ITERATOR | | 10M| 317M| 848K (1)| 00:00:27 | | |
|* 6 | TABLE ACCESS STORAGE FULL | WCRS_CLAIM_DETAIL | 10M| 317M| 848K (1)| 00:00:27 | | |
| 7 | PX COORDINATOR | | | | | | | |
| 8 | PX SEND QC (RANDOM) | :TQ20000 | 10M| 268M| 44875 (1)| 00:00:02 | | |
| 9 | LOAD AS SELECT | SYS_TEMP_0FD9D677B_286AAA2E | | | | | | |
| 10 | PX BLOCK ITERATOR | | 10M| 268M| 44875 (1)| 00:00:02 | | |
|* 11 | TABLE ACCESS STORAGE FULL | WCRS_POLICY_DETAIL | 10M| 268M| 44875 (1)| 00:00:02 | | |
| 12 | PX COORDINATOR | | | | | | | |
| 13 | PX SEND QC (ORDER) | :TQ40017 | 1 | 838 | 186K (2)| 00:00:06 | | |
| 14 | WINDOW SORT | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 15 | PX RECEIVE | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 16 | PX SEND RANGE | :TQ40016 | 1 | 838 | 186K (2)| 00:00:06 | | |
| 17 | NESTED LOOPS | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 18 | BUFFER SORT | | | | | | | |
| 19 | PX RECEIVE | | | | | | | |
| 20 | PX SEND BROADCAST | :TQ40001 | | | | | | |
| 21 | VIEW | | 1 | 13 | 93216 (2)| 00:00:03 | | |
| 22 | SORT GROUP BY | | 1 | 393 | | | | |
| 23 | PX COORDINATOR | | | | | | | |
| 24 | PX SEND QC (RANDOM) | :TQ30015 | 1 | 393 | | | | |
| 25 | SORT GROUP BY | | 1 | 393 | | | | |
| 26 | PX RECEIVE | | 1 | 393 | | | | |
| 27 | PX SEND HASH | :TQ30014 | 1 | 393 | | | | |
| 28 | SORT GROUP BY | | 1 | 393 | | | | |
|* 29 | HASH JOIN ANTI | | 1 | 393 | 93216 (2)| 00:00:03 | | |
| 30 | PX RECEIVE | | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 31 | PX SEND HASH | :TQ30012 | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 32 | BUFFER SORT | | 1 | 838 | | | | |
| 33 | NESTED LOOPS | | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 34 | NESTED LOOPS | | 1 | 358 | 85197 (2)| 00:00:03 | | |
| 35 | NESTED LOOPS | | 1 | 348 | 85197 (2)| 00:00:03 | | |
|* 36 | HASH JOIN ANTI | | 1 | 316 | 85179 (2)| 00:00:03 | | |
| 37 | PX RECEIVE | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
| 38 | PX SEND HASH | :TQ30010 | 4 | 1156 | 77161 (2)| 00:00:03 | | |
|* 39 | HASH JOIN ANTI BUFFERED | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
| 40 | PX RECEIVE | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
| 41 | PX SEND HASH | :TQ30008 | 371 | 94605 | 69142 (2)| 00:00:03 | | |
|* 42 | HASH JOIN | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
| 43 | PX RECEIVE | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
| 44 | PX SEND BROADCAST | :TQ30007 | 350 | 77000 | 36642 (1)| 00:00:02 | | |
|* 45 | HASH JOIN | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
| 46 | PX RECEIVE | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
| 47 | PX SEND BROADCAST | :TQ30006 | 140 | 25200 | 28624 (1)| 00:00:01 | | |
|* 48 | HASH JOIN | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
| 49 | PX RECEIVE | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
| 50 | PX SEND BROADCAST | :TQ30005 | 140 | 22820 | 25169 (1)| 00:00:01 | | |
|* 51 | HASH JOIN BUFFERED | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
| 52 | BUFFER SORT | | | | | | | |
| 53 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
| 54 | T PX SEND BROADCAS | :TQ30000 | 9 | 306 | 5 (0)| 00:00:01 | | |
| 55 | INDEX ROWID TABLE ACCESS BY | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
|* 56 | AN INDEX RANGE SC | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
|* 57 | HASH JOIN | | 9699K| 1193M| 25149 (1)| 00:00:01 | | |
| 58 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 59 | PX SEND HASH | :TQ30003 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 60 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 61 | BUFFER SORT | | | | | | | |
| 62 | PX RECEIVE | | | | | | | |
| 63 | DCAST PX SEND BROA | :TQ30002 | | | | | | |
| 64 | CARTESIAN MERGE JOIN | | 1 | 14 | 13 (0)| 00:00:01 | | |
| 65 | TERATOR PX BLOCK I | | 1 | 8 | 10 (0)| 00:00:01 | | |
| 66 | ESS STORAGE FULL TABLE ACC | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
| 67 | T BUFFER SOR | | 1 | 6 | 3 (0)| 00:00:01 | | |
| 68 | E PX RECEIV | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 69 | BROADCAST PX SEND | :TQ30001 | 1 | 6 | 2 (0)| 00:00:01 | | |
| 70 | K ITERATOR PX BLOC | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 71 | ACCESS STORAGE FULL TABLE | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
| 72 | TOR PX BLOCK ITERA | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|* 73 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
| 74 | PX RECEIVE | | 10M| 785M| 2907 (2)| 00:00:01 | | |
| 75 | PX SEND HASH | :TQ30004 | 10M| 785M| 2907 (2)| 00:00:01 | | |
|* 76 | VIEW | | 10M| 785M| 2907 (2)| 00:00:01 | | |
| 77 | TOR PX BLOCK ITERA | | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 78 | STORAGE FULL TABLE ACCESS | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
|* 79 | VIEW | | 10M| 168M| 3439 (2)| 00:00:01 | | |
| 80 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 81 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 82 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 83 | LL TABLE ACCESS STORAGE FU | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 84 | PX BLOCK ITERATOR | | 15M| 521M| 32477 (2)| 00:00:02 | | |
|* 85 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 521M| 32477 (2)| 00:00:02 | | |
| 86 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 87 | PX SEND HASH | :TQ30009 | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 88 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 89 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 90 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 91 | PX SEND HASH | :TQ30011 | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 92 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 93 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 94 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 32 | 18 (0)| 00:00:01 | | |
|* 95 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
|* 96 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | 10 | 0 (0)| 00:00:01 | | |
|* 97 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
| 98 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 99 | PX SEND HASH | :TQ30013 | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 100 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 101 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 102 | VIEW | | 1 | 825 | | | | |
| 103 | SORT GROUP BY | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 104 | BUFFER SORT | | | | | | | |
| 105 | PX RECEIVE | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 106 | PX SEND HASH | :TQ40015 | 1 | 430 | 93216 (2)| 00:00:03 | | |
|*107 | HASH JOIN ANTI BUFFERED | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 108 | PX RECEIVE | | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 109 | PX SEND HASH | :TQ40013 | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 110 | BUFFER SORT | | 1 | 838 | | | | |
| 111 | NESTED LOOPS | | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 112 | NESTED LOOPS | | 1 | 395 | 85197 (2)| 00:00:03 | | |
| 113 | NESTED LOOPS | | 1 | 369 | 85197 (2)| 00:00:03 | | |
|*114 | HASH JOIN ANTI | | 1 | 311 | 85179 (2)| 00:00:03 | | |
| 115 | PX RECEIVE | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
| 116 | PX SEND HASH | :TQ40011 | 4 | 1136 | 77161 (2)| 00:00:03 | | |
|*117 | HASH JOIN ANTI BUFFERED | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
| 118 | PX RECEIVE | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
| 119 | PX SEND HASH | :TQ40009 | 371 | 92750 | 69143 (2)| 00:00:03 | | |
|*120 | HASH JOIN | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
| 121 | PX RECEIVE | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
| 122 | PX SEND BROADCAST | :TQ40008 | 350 | 72450 | 36642 (1)| 00:00:02 | | |
|*123 | HASH JOIN | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
| 124 | PX RECEIVE | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
| 125 | PX SEND BROADCAST | :TQ40007 | 140 | 23380 | 28624 (1)| 00:00:01 | | |
|*126 | HASH JOIN | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
| 127 | PX RECEIVE | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
| 128 | PX SEND BROADCAST | :TQ40006 | 140 | 15540 | 25169 (1)| 00:00:01 | | |
|*129 | HASH JOIN BUFFERED | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
| 130 | BUFFER SORT | | | | | | | |
| 131 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
| 132 | PX SEND BROADCAST | :TQ40000 | 9 | 306 | 5 (0)| 00:00:01 | | |
| 133 | ROWID TABLE ACCESS BY INDEX | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
|*134 | INDEX RANGE SCAN | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
|*135 | HASH JOIN | | 9699K| 712M| 25149 (1)| 00:00:01 | | |
| 136 | PX RECEIVE | | 10M| 287M| 2907 (2)| 00:00:01 | | |
| 137 | PX SEND HASH | :TQ40004 | 10M| 287M| 2907 (2)| 00:00:01 | | |
|*138 | VIEW | | 10M| 287M| 2907 (2)| 00:00:01 | | |
| 139 | PX BLOCK ITERATOR | | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 140 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 141 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 142 | PX SEND HASH | :TQ40005 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 143 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 144 | BUFFER SORT | | | | | | | |
| 145 | PX RECEIVE | | | | | | | |
| 146 | PX SEND BROADCAST | :TQ40003 | | | | | | |
| 147 | IAN MERGE JOIN CARTES | | 1 | 14 | 13 (0)| 00:00:01 | | |
| 148 | R PX BLOCK ITERATO | | 1 | 8 | 10 (0)| 00:00:01 | | |
| 149 | ORAGE FULL TABLE ACCESS ST | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
| 150 | BUFFER SORT | | 1 | 6 | 3 (0)| 00:00:01 | | |
| 151 | PX RECEIVE | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 152 | AST PX SEND BROADC | :TQ40002 | 1 | 6 | 2 (0)| 00:00:01 | | |
| 153 | ATOR PX BLOCK ITER | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 154 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
| 155 | PX BLOCK ITERATOR | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|*156 | E FULL TABLE ACCESS STORAG | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|*157 | VIEW | | 10M| 555M| 3439 (2)| 00:00:01 | | |
| 158 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 159 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 160 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 161 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 162 | PX BLOCK ITERATOR | | 15M| 641M| 32477 (2)| 00:00:02 | | |
|*163 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 641M| 32477 (2)| 00:00:02 | | |
| 164 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 165 | PX SEND HASH | :TQ40010 | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 166 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 167 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 168 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 169 | PX SEND HASH | :TQ40012 | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 170 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 171 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 172 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 58 | 18 (0)| 00:00:01 | | |
|*173 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
| 174 | TABLE ACCESS BY INDEX ROWID | PROVIDER_NETWORK_DIM | 1 | 26 | 0 (0)| 00:00:01 | | |
|*175 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | | 0 (0)| 00:00:01 | | |
|*176 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
| 177 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 178 | PX SEND HASH | :TQ40014 | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 179 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 180 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
---------------------------------------------------------------------------------------------------------------------------------------------------------------

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

SQL tuning suggestions.

Hi
I am not a sql programmer and developers have given me this sql to have a look. I made the following recommendations after going through the sql. Is there anything else that can be added . I did not add about stats because they are representative and up to date.
SELECT /*+ PARALLEL(q1,4) */ *
FROM
(SELECT /*+ FIRST_ROWS(20) */
br.resource_id,
br.resource_code,
x.resource_seq_num employee_resource_number,
br.organization_id,
bd.department_id,
bd.department_code,
pf.full_name employee_name,
(SELECT xxdl_eam_util_pkg.xxdl_eam_get_resource_code(pf.person_id, bd.department_id)
FROM dual)
maximum_cost_resource,
pf.person_id,
x.wip_entity_id wo_id,
(SELECT weo1.wip_entity_name
FROM wip_eam_work_orders_v weo1
WHERE weo1.wip_entity_id = x.wip_entity_id)
wo_number,
CAST(x.start_date AS
TIMESTAMP) start_date,
CAST(x.completion_date AS
TIMESTAMP) completion_date,
wor.operation_seq_num wo_operation_number,
wor.resource_seq_num wo_resource_number,
wor.usage_rate_or_amount HOURS,
BRE.effective_start_date instance_start_date,
BRE.effective_end_date instance_end_date,
BRE.instance_id,
crc.resource_rate AS
resource_cost,
(SELECT xxdl_eam_util_pkg.xxdl_eam_get_all_res_code(pf.person_id, bd.department_id)
FROM dual)
all_resources
FROM per_all_people_f pf,
wip_eam_work_orders_v weo,
wip_operations wo,
wip_operation_resources wor,
(SELECT instance_id,
wip_entity_id,
operation_seq_num,
resource_seq_num,
start_date,
completion_date
FROM wip_op_resource_instances_v) x,
bom_dept_res_instances bdri,
bom_resource_employees BRE,
bom_department_resources bdr,
bom_resources br,
cst_resource_costs crc,
bom_departments bd
WHERE br.organization_id = bd.organization_id
AND bdr.resource_id = br.resource_id
AND bdr.department_id = bd.department_id
AND BRE.resource_id = br.resource_id
AND pf.effective_start_date <=sysdate
AND pf.effective_end_date >= sysdate
AND pf.person_id = BRE.person_id
AND wo.department_id = bd.department_id
AND wor.operation_seq_num(+) = wo.operation_seq_num
AND wor.wip_entity_id(+) = wo.wip_entity_id
AND wor.organization_id(+) = wo.organization_id
AND weo.wip_entity_id = wo.wip_entity_id
AND weo.organization_id = wo.organization_id
-- AND weo.organization_id = 6921
AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
AND crc.resource_id(+) = BRE.resource_id
AND x.wip_entity_id = wor.wip_entity_id
AND x.operation_seq_num = wor.operation_seq_num
AND x.resource_seq_num = wor.resource_seq_num
AND x.instance_id(+) = BRE.instance_id
AND bdri.department_id = bd.department_id
AND bdri.resource_id = br.resource_id
AND weo.organization_id = 6921
AND bdri.department_id = 5004
UNION
SELECT /*+ FIRST_ROWS(20) */ DISTINCT NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
pf.full_name employee_name,
NULL,
pf.person_id,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL HOURS,
NULL,
NULL,
NULL,
NULL,
NULL
FROM per_all_people_f pf,
wip_eam_work_orders_v weo,
wip_operations wo,
wip_operation_resources wor,
bom_dept_res_instances bdri,
bom_resource_employees BRE,
bom_department_resources bdr,
bom_resources br,
cst_resource_costs crc,
bom_departments bd
WHERE br.organization_id = bd.organization_id
AND bdr.resource_id = br.resource_id
AND bdr.department_id = bd.department_id
AND BRE.resource_id = br.resource_id
AND pf.effective_start_date <=sysdate
AND pf.effective_end_date >= sysdate
AND pf.person_id = BRE.person_id
AND wo.department_id = bd.department_id
AND wor.operation_seq_num(+) = wo.operation_seq_num
AND wor.wip_entity_id(+) = wo.wip_entity_id
AND wor.organization_id(+) = wo.organization_id
AND weo.wip_entity_id = wo.wip_entity_id
AND weo.organization_id = wo.organization_id
AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
AND crc.resource_id(+) = BRE.resource_id
AND bdri.department_id = bd.department_id
AND bdri.resource_id = br.resource_id
AND weo.organization_id = 6921
AND bdri.department_id = 5004
AND NOT EXISTS
(SELECT instance_id,
wip_entity_id operation_seq_num,
resource_seq_num
FROM wip_op_resource_instances_v)
) q1
ORDER BY department_id,
resource_code,
employee_name,
wo_number
My suggestions:
. Try to use UNION ALL instead of UNION. If you can eliminate UNION all together and flatten the query that will be even better.
2. You are using the function in a select statement xxdl_eam_util_pkg.xxdl_eam_get_resource_code(pf.person_id, bd.department_id)This will slow the performance. Try to get rid of this. Function calls in select are expensive.
3. Dont use the parallel hint and optimize. It wont get you consistent results.
4. Use of per_all_people_F is expensive. The UNION again complicates things. per_all_people_f has to be scanned 2x times.
5. Where does the application get the values for department id? Whether user inputs a value or whether it is hard coded . Most likely user will input value and each time it may be different. If that is the case, then you may be hitting bind peeking. There is not much hope for this. Not much can be done. Whatever you do this can happen. Only way is to pin the plan if you can use literals instead of binds. But that is not possible I think.
6. AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
Those statements, if you can rewrite would be good. If there are indexes on any of those columns, they are more than likely not used.
7. Are the outer joins really required. If not required remove them.
8. There is a 'WITH' clause in 10g . Try to use that for your subqueries or main query where applicable. It will save some I/O.
9. Try to tune without any hints. Remove the first rows as well and see the difference.
I know that the sql is definately bad and can be rewritten but I am not able to exactly write it for them.
Any inputs or thoughts?
MSK

Hi,
Any suggestions for reading on Sql tuning
I am looking for a practical book with solutions .
And books showing the Sql internal workings ?Take a look on Amazon some Jonathan Lewis books.
I will also recommend you to take a look on the following blogs:
- http://jonathanlewis.wordpress.com/
- http://www.juliandyke.com/
- http://richardfoote.wordpress.com/
- http://tkyte.blogspot.com/
And also any good interview based good Oracle DBA books ?You can take a look on my blog for some common DBA interview questions.
http://oraclenz.com/category/interview-tips/
Regards,
Francisco Munoz Alvarez
www.oraclenz.com

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 advisor 11g

Dear all,
We have installed oracle 11g on solaris. We have configured EM with this DB.. Is there anyway I can check a query using sql tuning advisor in oracle 11g. ? .. I tried, but I couldn't find the exact navigation ?. I need to submit th query and get the advise from sql tuninig advisor ?
Please guide
Kai

OEM db console ?
Am doing this for educational purpose and not in production
kai

Help required in SQL Tuning

Hi
SQL : 1
Following Hierarchical SQL giving output with 2 seconds with 1169 records.
SELECT LPAD ('.', 2 * (LEVEL - 1), '.') || LEVEL bom_level,
msia.segment1
|| '.'
|| msia.segment2
|| '.'
|| msia.segment3
|| '.'
|| msia.segment4 parent_item_code,
msia.description parent_description, msia.primary_unit_of_measure,
LPAD ('.', 2 * (LEVEL - 1), '.')
|| msic.segment1
|| '.'
|| msic.segment2
|| '.'
|| msic.segment3
|| '.'
|| msic.segment4 component_item_code,
msic.description component_description, bic.operation_seq_num,
bic.component_quantity
FROM bom_bill_of_materials bom,
bom_inventory_components bic,
mtl_system_items msia,
mtl_system_items msic
WHERE bic.bill_sequence_id = bom.bill_sequence_id
AND msia.inventory_item_id = bom.assembly_item_id
AND msia.organization_id = bom.organization_id
AND msic.inventory_item_id = bic.component_item_id
AND msic.organization_id = bom.organization_id
START WITH bom.assembly_item_id = 1407543
AND bom.organization_id = 56
CONNECT BY bom.assembly_item_id = PRIOR bic.component_item_id
AND bom.organization_id = 56;
SQL : 2
Following SQL giving output = 1407543
SELECT e.equipment_item_id FROM websupp.epa_transaction_header e WHERE equipment_id = 34
Now, when I am replacing START WITH clause of SQL:1 with SQL:2 means to replace 1407543 with SQL:2, it is taking so long time .
Can you guide me in tuning SQL :1
Thanks in advance
Sanjay

try something
with t as
SELECT e.equipment_item_id val FROM websupp.epa_transaction_header e WHERE equipment_id = 34
SELECT LPAD ('.', 2 * (LEVEL - 1), '.') || LEVEL bom_level,
msia.segment1
|| '.'
|| msia.segment2
|| '.'
|| msia.segment3
|| '.'
|| msia.segment4 parent_item_code,
msia.description parent_description, msia.primary_unit_of_measure,
LPAD ('.', 2 * (LEVEL - 1), '.')
|| msic.segment1
|| '.'
|| msic.segment2
|| '.'
|| msic.segment3
|| '.'
|| msic.segment4 component_item_code,
msic.description component_description, bic.operation_seq_num,
bic.component_quantity
FROM bom_bill_of_materials bom,
bom_inventory_components bic,
mtl_system_items msia,
mtl_system_items msic,
t t
WHERE bic.bill_sequence_id = bom.bill_sequence_id
AND msia.inventory_item_id = bom.assembly_item_id
AND msia.organization_id = bom.organization_id
AND msic.inventory_item_id = bic.component_item_id
AND msic.organization_id = bom.organization_id
START WITH bom.assembly_item_id = t.val --1407543
AND bom.organization_id = 56
CONNECT BY bom.assembly_item_id = PRIOR bic.component_item_id
AND bom.organization_id = 56;

Oracle 10g SQL Tuning Advisor

I am working as a junior DBA. I tried to tune a query using SQL Tuning Advisor that is with DBMS_SQLTUNE.I have created the tuning task successfully with DBMS_SQLTUNE.create_tuning_task.But when i execute the tuning task with EXEC DBMS_SQLTUNE.execute_tuning_task() i got an error like
SQL> EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'rep_three');
BEGIN DBMS_SQLTUNE.execute_tuning_task(task_name => 'rep_three'); END;
ERROR at line 1:
ORA-00081: address range [0x60000000000A7D70, 0x60000000000A7D74) is not
readable
ORA-00600: internal error code, arguments: [kesatmGetSqlStats:optCost], [], [],
ORA-06512: at "SYS.PRVT_ADVISOR", line 1624
ORA-06512: at "SYS.DBMS_ADVISOR", line 186
ORA-06512: at "SYS.DBMS_SQLTUNE", line 1008
ORA-06512: at line 1The oracle version is Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi. The OS is HP-UX. The version is HP-UX B.11.23 U ia64.
I tried to execute DBMS_SQLTUNE as DWH user.I have granted the advisor,DROP ANY SQL PROFILE,ALTER ANY SQL PROFILE,CREATE ANY SQL PROFILE privileges and DBA roles to the DWH user. The way i ran DBMS_SQLTUNE is, first i logged in as DWH user and i tried to execute the query for getting the SQL_ID for the query. For getting the SQL_ID i selected the SQL_ID column value for the DWH user session from v$session.I kept that query executing and meanwhile i opened another session as DWH user and created the tuning task as follows
DECLARE
l_sql_tune_task_id VARCHAR2(100);
BEGIN
l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
 sql_id => 'b65fj39dkkb9v',
 scope => DBMS_SQLTUNE.scope_limited,
 time_limit => 3600,
 task_name => 'rep_three',
 description => 'Report Tuning');
DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
/The creation of tuning task was successful.And i executed the tuning task as follows
EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'rep_three');The above mentioned errors came when i executed the tuning task.
I am also adding the query which i have tried to tune
select * from dwh.beneficiary_dim BEN_DIM,
 (Select adr_dp_id,
 adr_account_no,
 ADR_ADDRESS_LINE_1 || ' ' ||
 ADR_ADDRESS_LINE_2 || ' ' ||
 ADR_ADDRESS_LINE_3 || ' ' ||
 ADR_ADDRESS_LINE_4 as ADDRESS,
 adr_pin_code,adr_phone_no,adr_fax_no
 from dwh.beneficiary_address_dim where adr_type_id = 1) PERMANENT_ADD_DIM,
 (Select adr_dp_id,
 adr_account_no,
 ADR_ADDRESS_LINE_1 || ' ' ||
 ADR_ADDRESS_LINE_2 || ' ' ||
 ADR_ADDRESS_LINE_3 || ' ' ||
 ADR_ADDRESS_LINE_4 as ADDRESS,
 adr_pin_code,adr_phone_no,adr_fax_no
 from dwh.beneficiary_address_dim where adr_type_id = 2) BANK_ADD_DIM,
 (Select adr_dp_id,
 adr_account_no,
 ADR_ADDRESS_LINE_1 || ' ' ||
 ADR_ADDRESS_LINE_2 || ' ' ||
 ADR_ADDRESS_LINE_3 || ' ' ||
 ADR_ADDRESS_LINE_4 as ADDRESS,
 adr_pin_code,adr_phone_no,adr_fax_no
 from dwh.beneficiary_address_dim where adr_type_id = 3) NOM_GUARDIAN_ADD_DIM,
 (Select adr_dp_id,
 adr_account_no,
 ADR_ADDRESS_LINE_1 || ' ' ||
 ADR_ADDRESS_LINE_2 || ' ' ||
 ADR_ADDRESS_LINE_3 || ' ' ||
 ADR_ADDRESS_LINE_4 as ADDRESS,
 adr_pin_code,adr_phone_no,adr_fax_no
 from dwh.beneficiary_address_dim where adr_type_id = 4) CORR_ADD_DIM,
 (Select adr_dp_id,
 adr_account_no,
 ADR_ADDRESS_LINE_1 || ' ' ||
 ADR_ADDRESS_LINE_2 || ' ' ||
 ADR_ADDRESS_LINE_3 || ' ' ||
 ADR_ADDRESS_LINE_4 as ADDRESS,
 adr_pin_code,adr_phone_no,adr_fax_no
 from dwh.beneficiary_address_dim where adr_type_id = 6) MINOR_ADDRESS,
 (Select rp.requestid as requestid,
decode(rp.value,'ALL','ALL','','ALL',decode(substr(rp.value,1,instr(rp.value,'|',1,1)-1),'','ALL',substr(rp.value,1,instr(rp.value,'|',1,1)-1))) as Name,
decode(rp.value,'ALL','ALL','','ALL',decode(substr(rp.value,(instr(rp.value,'|',1,1)+1),((instr(rp.value,'|',1,2))-(instr(rp.value,'|',1,1)+1))),'','ALL',substr(rp.value,(instr(rp.value,'|',1,1)+1),((instr(rp.value,'|',1,2))-(instr(rp.value,'|',1,1)+1))))) as Address,
decode(rp.value,'ALL','ALL','','ALL',decode(substr(rp.value,(instr(rp.value,'|',1,2)+1)),'','ALL',substr(rp.value,(instr(rp.value,'|',1,2)+1)))) as PAN
 from disadmin.requestparameters rp, disadmin.requestparameters rps, disadmin.reportrequests rr
 where rp.parameterid = 'CNAS_PARAM_VALUE'
 and rr.status = 'A'
 and rp.requestid = rr.id
 and rp.id = rps.id) P_PARAM_VALUE,
 (Select rp.requestid as requestid, rp.value as Type
 from disadmin.requestparameters rp, disadmin.reportrequests rr
 where rp.parameterid = 'CNAS_NAME_TYPE'
 and rr.status = 'A'
 and rp.requestid = rr.id) P_NAME_TYPE,
 (Select rp.requestid as requestid, rp.value as Addtype
 from disadmin.requestparameters rp, disadmin.reportrequests rr
 where rp.parameterid = 'CNAS_ADDRESS_TYPE'
 and rr.status = 'A'
 and rp.requestid = rr.id) P_ADDRESS_TYPE
 where ( 1= case when P_NAME_TYPE.Type = 'F' then
 case when BEN_DIM.BDM_FIRST_HOLDER_NAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_FIRST_HOLDER_NAME||'%','%'||P_PARAM_VALUE.Name||'%')
 or BEN_DIM.BDM_FIRST_HOLDER_SURNAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_FIRST_HOLDER_SURNAME||'%','%'||P_PARAM_VALUE.Name||'%')
 then 1
 else null end
 else
 case when P_NAME_TYPE.Type = 'ALL' then
 case when (BEN_DIM.BDM_FIRST_HOLDER_NAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_FIRST_HOLDER_NAME||'%','%'||P_PARAM_VALUE.Name||'%')
 or BEN_DIM.BDM_FIRST_HOLDER_SURNAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_FIRST_HOLDER_SURNAME||'%','%'||P_PARAM_VALUE.Name||'%'))
 and BEN_DIM.BDM_SECOND_HOLDER_NAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_SECOND_HOLDER_NAME||'%','%'||P_PARAM_VALUE.Name||'%')
 and BEN_DIM.BDM_THIRD_HOLDER_NAME like DECODE(P_PARAM_VALUE.Name,'ALL','%'||BEN_DIM.BDM_THIRD_HOLDER_NAME||'%','%'||P_PARAM_VALUE.Name||'%')
 then 1
 else null end
 else null end
 end )
 and BEN_DIM.BDM_IT_PAN like DECODE(P_PARAM_VALUE.PAN,'ALL','%'||BEN_DIM.BDM_IT_PAN||'%','%'||P_PARAM_VALUE.PAN||'%')
 and (1 = case when P_ADDRESS_TYPE.ADDTYPE = 1 then
 case when instr(PERMANENT_ADD_DIM.ADDRESS, DECODE(P_PARAM_VALUE.ADDRESS,'ALL',PERMANENT_ADD_DIM.ADDRESS, P_PARAM_VALUE.ADDRESS)) <> 0
 then 1
 else null end
 when P_ADDRESS_TYPE.ADDTYPE = 3 then
 case when instr(NOM_GUARDIAN_ADD_DIM.ADDRESS, DECODE(P_PARAM_VALUE.ADDRESS,'ALL',NOM_GUARDIAN_ADD_DIM.ADDRESS, P_PARAM_VALUE.ADDRESS)) <> 0
 then 1
 else null end
 when P_ADDRESS_TYPE.ADDTYPE = 4 then
 case when instr(CORR_ADD_DIM.ADDRESS, DECODE(P_PARAM_VALUE.ADDRESS,'ALL',CORR_ADD_DIM.ADDRESS, P_PARAM_VALUE.ADDRESS)) <> 0
 then 1
 else null end
 when P_ADDRESS_TYPE.ADDTYPE = 6 then
 case when instr(MINOR_ADDRESS.ADDRESS, DECODE(P_PARAM_VALUE.ADDRESS,'ALL',MINOR_ADDRESS.ADDRESS, P_PARAM_VALUE.ADDRESS)) <> 0
 then 1
 else null end
 else null end );The above query also tries to access some tables from another user DISADMIN. Could you please help me in solving this problem while using SQL Tuning Advisor ? I am the only DBA here.

will the rows really be updated just by using the package?Considering DMLs
SQL> select * from test
2 /
 NO
 1
 2
SQL> ed
Wrote file afiedt.buf
1 DECLARE
2 my_task_name VARCHAR2(30);
3 my_sqltext CLOB;
4 BEGIN
5 my_sqltext := 'insert into test values (3)';
6 my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
7 sql_text => my_sqltext,
8 task_name => 'my_sql_tuning_task');
9* end;
SQL> /
PL/SQL procedure successfully completed.
SQL> BEGIN
2 DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'my_sql_tuning_task' );
3 END;
4 /
PL/SQL procedure successfully completed.
SQL> select * from test
2 /
 NO
 1
 2
SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'my_sql_tuning_task')
2 FROM DUAL;
DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_SQL_TUNING_TASK')
GENERAL INFORMATION SECTION
Tuning Task Name : my_sql_tuning_task
Tuning Task Owner : TEST
Scope : COMPREHENSIVE
Time Limit(seconds): 1800
Completion Status : COMPLETED
Started at : 03/27/2008 05:16:14
Completed at : 03/27/2008 05:16:16
DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_SQL_TUNING_TASK')
Schema Name: TEST
SQL ID : gwkmgmyj9824t
SQL Text : insert into test values (3)
There are no recommendations to improve the statement.
-------------------------------------------------------------------------------Adith

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

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

SQL Tuning Advisor against the session (is it poosible)

My Company customer has observed that there is job that are running longer than expected running(5 days).
They did not gave any information.they want me to run
SQL Tuning Advisor against the session running this job.
can you run sql tunning advisor against running session?
if so how
Please suggest me your valuable tips so that I approach this work properly.
DB = 11g
OS= Solaris 10

>
...SQL Tuning Advisor against the session running this job.
can you run sql tunning advisor against running session?
>
SQL Tuning Advisor is run on statements and not sessions. I don't do much with SQL Tuning Advisor, but I'd consider that current running sessions a lost cause until it completes or you kill it. You can see the "estimate" of how long that current running SQL is going to take in v$session_longops. You can use a script like Tanel's sw.sql
http://blog.tanelpoder.com/2008/01/08/updated-session-wait-script/
to see what the wait interface has to say.
>
Please suggest me your valuable tips so that I approach this work properly.
>
My approach for this would be to determine what the current explain plan is and compare it to one that ran (correctly) in the past and then try to determine why it changed. (bad stats, dropped index, parameter changes, etc).
Cheers.

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.

Tune the PL/SQL block with SQL_ID

Hi There,
I have found some recommendation in ADDM report as follows.
"" Action
Tune the PL/SQL block with SQL_ID "48trcns4mx5bk". Refer to the "Tuning
PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and
Reference".
Related Object ""
can any one let me how to Tune the PL/SQL block with SQL_ID?
looking forward.
Db: 11.1.0.7
OS: OracleLinux5-86*64
Regards,
Mohsin

Hi,
you can't tune a PL/SQL block directly. Instead, you'll need to profile it first (i.e. see how much time SQL statements inside it consume) using dbms_profiler or some other tool. If you find that the problem is that some SQL is called too frequently because of flawed PL/SQL logic, then you'll need to address that. Otherwise, you'll need to take the top time consuming statement(s) and tune it (them).
Best regards,
Nikolay

Sql tuning with siebel 8.0

Similar Messages

Maybe you are looking for