SQL Tuning Advise
Hello
I have a very huge table to join itself.
SELECT
FROM huge_table a,
(select id,MAX(txndate)
from huge_table
where .....
group by id) b
WHERE a.id = b.id
AND a.txndate = b.txndate;
I found this statement really a time-consuming statement after execute it. Anyone have good idea to tune this ?
Thanks
Regards,
ckwan
Regarding this table, I had created indexes for id and txntimestamp.
But the performance still not ideal.
Thanks
Similar Messages
-
Permissions needed for Applying SQL Tuning Sets/SQL Plans 11g?
What permission are needed for a user to apply/activate sql tuning sets (sql plans) in 11g? The user can capture and move the the sql tuning sets from a 10g database to an 11g database but is getting "ORA-01031: insufficient privileges" when trying to activate/apply the sqlplans in 11g.
The user has:
ADMINISTER SQL MANAGEMENT OBJECT and ADMINISTER SQL TUNING SET and EXECUTE on SYS.DBMS_SPM
The user is an administrator for our Data Warehouse team but they do not have sysdba priviliges.
Do you also know of a good white paper that covers the step by step instructions and permissions needed for aquiring and applying/activating sqlplans?
If more information is needed in order to respond please advise.
Thank youWhat permission are needed for a user to apply/activate sql tuning sets (sql plans) in 11g? The user can capture and move the the sql tuning sets from a 10g database to an 11g database but is getting "ORA-01031: insufficient privileges" when trying to activate/apply the sqlplans in 11g.
The user has:
ADMINISTER SQL MANAGEMENT OBJECT and ADMINISTER SQL TUNING SET and EXECUTE on SYS.DBMS_SPM
The user is an administrator for our Data Warehouse team but they do not have sysdba priviliges.
Do you also know of a good white paper that covers the step by step instructions and permissions needed for aquiring and applying/activating sqlplans?
If more information is needed in order to respond please advise.
Thank you -
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
KaiOEM db console ?
Am doing this for educational purpose and not in production
kai -
SQL tuning advisor recommnds to create SYS_OP_C2C function based index
I have a large table and one index on it. I use some tool to populate data, this tool simple submits the sql to Oracle DB and it does NOT use use index for queries. When I run the sql tuning advisor it recommends to create additional index and use SYS_OP_C2C function, which I do not want.
When I run the query via sql plus it picks up the index.
Have any of you come across, why its recommending this additional non-sense?
create index abc.xxxx on this_table(SYS_OP_C2C("this_column"));
ThanksThe internal Oracle function SYS_OP_C2C performs conversion from one character set to another character set - C(haracterSet)2C(haracterSet). There are situations when one will see this conversion going on without explicit command as in this case what should be a sign that the data types are not the same and implicit conversion is taking place and this might be also a problem from performance perspective as it may disable index usage.
Make sure you the characterset and nls defined of any of the database and tool are same.
Make sure the data type of the column on the index is same as database.
Confirm with ETL vendor for your database support and any patches etc.
Optimizer will only advise to use that function when characterset or data type does not match.
Thanks,
TaraChand -
Dear all,
DB : 10.2.0.4.
Solaris 5.10
One of the monthly process had a problem and one of the select statements was taking a lot of time and when I ran sql tuning advisor, initially it advised me to accept the new sql profile. then since there is no improvements, I proceeded with running sql tuning advisor again which resulted in
Optimizer statistics for index "USER"."CDR_BITMAP_IDX" are stale. Consider collecting optimizer statistics for this index. The optimizer requires up-to-date statistics for the index in order to select a good execution plan.
Miscellaneous SQL Profile "SYS_SQLPROF_02492cc266e98000" exists for this statement and was ignored during the tuning process.
select b.custno ,b.contrno ,b.rowid ,a.subscr_type ,a.area ,a.subno ,
nvl(a.imsi_no,:"SYS_B_00") ,a.extn ,a.b_subno ,a.chargetype ,a.tariffclass ,
a.cdrcode ,to_char(a.transdate,'YYYYMMDD') ,to_char(nvl(a.transdate_to,
a.transdate),'YYYYMMDD') ,nvl(a.no_of_calls,:"SYS_B_01") ,nvl(a.duration,
:"SYS_B_02") ,nvl(a.act_duration,:"SYS_B_03") ,a. time ,a.time_data ,
a.act_time ,a.cdrtext ,a.ar_cdrtext ,a.cdramount ,a.cdramount_int ,
a.gross_amount ,a.gross_amount_int ,nvl(adv_cdramount,:"SYS_B_04") ,
nvl(adv_gross_amount,:"SYS_B_05") ,to_char(nvl(adv_transdate,transdate),
'YYYYMMDD') ,to_char(nvl(adv_transdate_to,transdate_to),'YYYYMMDD') ,
a.factor ,a.factor_int ,to_char(a.upddate,'YYYYMMDD') ,a.tax_class ,
a.vol_group ,nvl(a.table_gen,:"SYS_B_06") ,a.call_type ,
to_char(a.ltd,'YYYYMMDD') ,nvl(a.equipgroup,:"SYS_B_07") ,
nvl(a.equipid,:"SYS_B_08") ,dest_code ,rate_type ,org_tariff_group ,
tariff_group ,rate_pos ,nvl(a.tariff_profile,:"SYS_B_09") ,a.rowid ,
nvl(a.adv_cdred,:"SYS_B_10") ,a.SPLIT_TARIFFCLASS ,a.SPLIT_DURATION ,
a.SPLIT_cdrAMOUNT ,a.SPLIT_cdrAMOUNT_INT
from
cdr_master a ,cdr_control b where (((((b.ltd=to_date(:b0,
:"SYS_B_11") and a.contrno=b.contrno) and b.run_group=:b1) and b.cdr_flag=
:"SYS_B_12") and nvl(a.cdred,:"SYS_B_13")<>:"SYS_B_14") and
(((trunc(a.transdate)<=to_date(:b0,:"SYS_B_15") or ((trunc(a.upddate)<=
to_date(:b0,:"SYS_B_16") and chargetype=:"SYS_B_17") and (((a.cdred is
not null and a.cdred=:"SYS_B_18") and nvl(adv_cdred,:"SYS_B_19")=
:"SYS_B_20") or (((a.cdred is not null and a.cdred=:"SYS_B_21") and
nvl(adv_cdred,:"SYS_B_22")=:"SYS_B_23") and adv_transdate_to<=to_date(:b0,
:"SYS_B_24"))))) or ((a.cdred is not null and a.cdred=:"SYS_B_25") and
nvl(adv_cdred,:"SYS_B_26")=:"SYS_B_27")) or (((a.cdred is not null and
a.cdred=:"SYS_B_28") and nvl(adv_cdred,:"SYS_B_29")=:"SYS_B_30") and
adv_transdate_to<=to_date(:b0,:"SYS_B_31")))) order by a.contrno,a.subno,
a.subscr_type,a.area,nvl(a.equipgroup,:"SYS_B_32"),a.chargetype,a.cdrcode
for update of a.cdred nowait
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 5 451.99 1997.19 596620 37306277 3351623 0
Fetch 404 0.96 0.84 0 0 0 39900
total 409 452.95 1998.04 596620 37306277 3351623 39900
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 185
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 404 0.00 0.00
SQL*Net more data to client 3219 0.00 0.03
SQL*Net message from client 404 0.00 0.22
gc current block 2-way 34454 0.27 21.77
gc cr multi block request 2649 0.27 1.06
db file sequential read 596211 0.15 1561.81
gc cr block busy 16 0.00 0.02
db file parallel read 11 0.00 0.04
db file scattered read 50 0.01 0.10
gc cr block 2-way 2 0.00 0.00
gc current grant 2-way 6 0.00 0.00
latch: cache buffers chains 9 0.00 0.00
gc current block congested 6 0.00 0.02
gc current grant busy 257 0.00 0.17
latch: object queue header operation 3 0.00 0.00
log file switch completion 22 0.82 2.52
latch free 27 0.00 0.00
log buffer space 7 0.24 0.83
log file switch (checkpoint incomplete) 10 0.98 1.47
gc cr grant 2-way 2 0.00 0.00Any idea what am missing ?
KaiHi,
Try to Update the Stats of the Source tables and re-reun the Advisor, that might give or suggest different things further.
Second thing, check that Referred SQL profile and I would suggest if it not used, then drop that and check.
Surprised to see huge wait event on "db file sequential read"
- Pavan Kumar N -
Sql tuning advisor for concurrent requests
Dear all,
I am having one doubt in my mind from very long time.Can we use sql tuning advisor from 10G(EM) to tune concurrent requests and reports?
RegardsHi Helios,
I am just thinking wiht voice. If you have one code blog which is typed in sql-pl/sql for your concurrent request, its going and run on dbtier. So it has one SQL'ID and also can be check on AWR report. So i belive you can use sqltuning adviser for to can tune related sqlAFAIK, some Instances a single concurrent request may contain multiple SQLID's and in that scenario tuning approach is difficult. Any information how can we consolidate it. If tune one specific sql then the explain plan for other sql become more worst. I came across this situation so many time.
Any information or inputs on this is really appreciated.
thanks,
X A H E E R -
Need help to debug SQL Tuning Advisor Error Message
Hi,
I am getting an error message while try to get recommendations from the SQL Tuning Advisor.
Environment:
Oracle Version: 11.2.0.3.0
O/S: AIX
Following is my code:
declare
my_task_name varchar2 (30);
my_sqltext clob;
begin
my_sqltext := 'SELECT DISTINCT MRKT_AREA AS DIVISION, PROMO_ID,
PROMO_CODE,
RBR_DTL_TYPE.PERF_DETL_TYP,
RBR_DTL_TYPE.PERF_DETL_DESC,
RBR_DTL_TYPE.PERF_DETL_SUB_TYP,
RBR_DTL_TYPE.PERF_DETL_SUB_DESC,
BU_SYS_ITM_NUM,
RBR_CPN_LOC_ITEM_ARCHIVE.CLI_SYS_ITM_DESC,
PROMO_START_DATE,
PROMO_END_DATE,
PROMO_VALUE2,
PROMO_VALUE1,
EXEC_COMMENTS,
PAGE_NUM,
BLOCK_NUM,
AD_PLACEMENT,
BUYER_CODE,
RBR_CPN_LOC_ITEM_ARCHIVE.CLI_STAT_TYP,
RBR_MASTER_CAL_ARCHIVE.STATUS_FLAG
FROM (PROMO_REPT_OWNER.RBR_CPN_LOC_ITEM_ARCHIVE
INNER JOIN PROMO_REPT_OWNER.RBR_MASTER_CAL_ARCHIVE
ON (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_PROMO_ID = PROMO_ID)
AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_PERF_DTL_ID = PERF_DETAIL_ID)
AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_STR_NBR = STORE_ZONE)
AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_ITM_ID = ITM_ID))
INNER JOIN PROMO_REPT_OWNER.RBR_DTL_TYPE
ON (RBR_MASTER_CAL_ARCHIVE.PERF_DETL_TYP = RBR_DTL_TYPE.PERF_DETL_TYP)
AND (RBR_MASTER_CAL_ARCHIVE.PERF_DETL_SUB_TYP = RBR_DTL_TYPE.PERF_DETL_SUB_TYP)
WHERE ( ((MRKT_AREA)=40)
AND ((RBR_DTL_TYPE.PERF_DETL_TYP)=1)
AND ((RBR_DTL_TYPE.PERF_DETL_SUB_TYP)=1) )
AND ((CLI_STAT_TYP)=1 Or (CLI_STAT_TYP)=6)
AND ((RBR_MASTER_CAL_ARCHIVE.STATUS_FLAG)=''A'')
AND ( ((PROMO_START_DATE) >= to_date(''2011-10-20'', ''YYYY-MM-DD'')
And (PROMO_END_DATE) <= to_date(''2011-10-26'', ''YYYY-MM-DD'')) )
ORDER BY MRKT_AREA';
my_task_name := dbms_sqltune.create_tuning_task
(sql_text => my_sqltext,
user_name => 'PROMO_REPT_OWNER',
scope => 'COMPREHENSIVE',
time_limit => 3600,
task_name => 'Test_Query',
description => 'Test Query');
end;
begin
dbms_sqltune.execute_tuning_task(task_name => 'Test_Query');
end;
set serveroutput on size unlimited;
set pagesize 5000
set linesize 130
set long 50000
set longchunksize 500000
SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK('Test_Query') FROM DUAL;
Output:
snippet .....
FINDINGS SECTION (1 finding)
1- Index Finding (see explain plans section below)
The execution plan of this statement can be improved by creating one or more
indices.
Recommendation (estimated benefit: 71.48%)
- Consider running the Access Advisor to improve the physical schema design
or creating the recommended index.
Error: Cannot fetch actions for recommendation: INDEX
Error: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
Rationale
Creating the recommended indices significantly improves the execution plan
of this statement. However, it might be preferable to run "Access Advisor"
using a representative SQL workload as opposed to a single statement. This
will allow to get comprehensive index recommendations which takes into
account index maintenance overhead and additional space consumption.
snippet
Any ideas why I am getting ORA-06502 error?
Thanks in advance
RogersBug 14407401 - ORA-6502 from index recommendation section of DBMS_SQLTUNE output (Doc ID 14407401.8)
Fixed:
The fix for 14407401 is first included in
12.1.0.1 (Base Release) -
Need Help in sql tuning in EXADATA environment
I am uploadin the sql with its current explain plan, this sql in Prd database is executing in 6-10 mins and we need to improve this sql perf to 1-2 mins as the requirement from business team.
I am giving some backgroud about this sql tuning requirement, this sql is newly developed in and currently is in UAT phase, we don't have much option for tuning code here since the sql is tool generated through COGNOS DataMart tool, options are there to look into from DBA end with plan level or creating indexes on suitible columns to reduce i/o in minimizing the rows traversing by the sql.
Is anybody can help me out here?
WITH "WCRS_CLAIM_DETAIL_VW5"
AS (SELECT "WCRS_CLAIM_DETAIL_VW"."CLAIM_DETAIL_PK_ID"
"CLAIM_DETAIL_PK_ID",
"WCRS_CLAIM_DETAIL_VW"."CLAIM_ID" "CLAIM_ID",
"WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
"CURRENT_SNAPSHOT_IND",
"WCRS_CLAIM_DETAIL_VW"."LOSS_DT" "LOSS_DT",
"WCRS_CLAIM_DETAIL_VW"."REGULATORY_STATE_CD"
"REGULATORY_STATE_CD"
FROM "CDW_DLV_IDS"."WCRS_CLAIM_DETAIL_VW" "WCRS_CLAIM_DETAIL_VW"
WHERE "WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y'),
"WCRS_POLICY_DETAIL_VW7"
AS (SELECT "WCRS_POLICY_DETAIL_VW"."CLAIM_NBR" "CLAIM_NBR",
"WCRS_POLICY_DETAIL_VW"."CLAIM_SYMBOL_CD" "CLAIM_SYMBOL_CD",
"WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
"CURRENT_SNAPSHOT_IND",
"WCRS_POLICY_DETAIL_VW"."KEY_OFFICE_CD" "KEY_OFFICE_CD",
"WCRS_POLICY_DETAIL_VW"."POLICY_NBR" "POLICY_NBR"
FROM "CDW_DLV_IDS"."WCRS_POLICY_DETAIL_VW" "WCRS_POLICY_DETAIL_VW"
WHERE "WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y')
SELECT /*+ gather_plan_statistics monitor bind_aware */
/* ^^unique_id */
"T0"."C0" "Account_Name",
"T0"."C1" "Accident_State_Cd",
"T0"."C2" "c3",
"T0"."C3" "PPO_Name",
"T0"."C4" "Invc_Classification_Type_Desc",
FIRST_VALUE (
"T0"."C5")
OVER (
PARTITION BY "T0"."C0",
"T0"."C1",
"T0"."C2",
"T0"."C3",
"T0"."C4",
"T0"."C6")
"Claim_Cnt___Distinct",
"T0"."C7" "Invc_Control_Number",
"T0"."C8" "Invc_Allowance_Amt",
"T0"."C9" "Invc_Charge_Amt",
"T0"."C10" "c10",
"T0"."C11" "PPO_Reduction_Amt",
"T0"."C12" "Dup_Ln_Save_Amt",
"T0"."C13" "c13",
"T0"."C14" "Sub_Total",
"T0"."C15" "c15",
"T0"."C6" "c16"
FROM (SELECT "T1"."C0" "C0",
"T1"."C1" "C1",
"T1"."C2" "C2",
"T1"."C3" "C3",
"T1"."C4" "C4",
"T1"."C6" "C5",
"T1"."C5" "C6",
"T0"."C0" "C7",
"T1"."C7" "C8",
"T1"."C8" "C9",
"T1"."C9" "C10",
"T1"."C10" "C11",
"T1"."C11" "C12",
"T1"."C12" "C13",
"T1"."C13" "C14",
"T1"."C14" "C15"
FROM (SELECT COUNT (DISTINCT "INVC_DIM_VW"."INVC_ID") "C0"
FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
"WCRS_CLAIM_DETAIL_VW5",
"EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
"EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
"EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
"EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
"EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
"CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
"CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
"WCRS_POLICY_DETAIL_VW7",
"EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
'Original'
AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
"ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
"WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
"WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
"WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
"WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
"WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
"INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
"INVC_DIM_VW"."INVC_GID"
AND "INVC_DIM_VW"."INVC_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT") "T0",
( SELECT "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" "C0",
"WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD" "C1",
CASE
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'Y'
THEN
'In - Network'
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'N'
THEN
'Out - Network'
ELSE
'Others'
END
"C2",
"PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM" "C3",
"INVC_DIM_VW"."INVC_CLASS_TYPE_DESC" "C4",
CASE
WHEN (EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
OR (EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
THEN
NULL
ELSE
( EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
|| EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
END
"C5",
COUNT (DISTINCT "WCRS_CLAIM_DETAIL_VW5"."CLAIM_ID")
"C6",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT") "C7",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
"C8",
SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."TOT_INVC_REVIEW_RULE_ALWC_AMT")
"C9",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PPO_REDUC_AMT")
"C10",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
"C11",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_OSR_REDUC_AMT")
"C12",
( SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
- SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT"))
- SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
"C13",
SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CLNT_SPEC_REDUC_AMT")
"C14"
FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
"WCRS_CLAIM_DETAIL_VW5",
"EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
"EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
"EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
"EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
"EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
"CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
"CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
"WCRS_POLICY_DETAIL_VW7",
"EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
'Original'
AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
"ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
"WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
"WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
"WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
"WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
"WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
"INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
"INVC_DIM_VW"."INVC_GID"
AND "INVC_DIM_VW"."INVC_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
GROUP BY "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM",
"WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD",
CASE
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'Y'
THEN
'In - Network'
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'N'
THEN
'Out - Network'
ELSE
'Others'
END,
"PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM",
"INVC_DIM_VW"."INVC_CLASS_TYPE_DESC",
CASE
WHEN (EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
OR (EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
THEN
NULL
ELSE
( EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
|| EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
END) "T1") "T0"
ORDER BY "Account_Name" ASC NULLS LAST,
"Accident_State_Cd" ASC NULLS LAST,
"c3" ASC NULLS LAST,
"PPO_Name" ASC NULLS LAST,
"Invc_Classification_Type_Desc" ASC NULLS LAST| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 838 | 1079K (1)| 00:00:34 | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 10M| 317M| 848K (1)| 00:00:27 | | |
| 4 | LOAD AS SELECT | SYS_TEMP_0FD9D677A_286AAA2E | | | | | | |
| 5 | PX BLOCK ITERATOR | | 10M| 317M| 848K (1)| 00:00:27 | | |
|* 6 | TABLE ACCESS STORAGE FULL | WCRS_CLAIM_DETAIL | 10M| 317M| 848K (1)| 00:00:27 | | |
| 7 | PX COORDINATOR | | | | | | | |
| 8 | PX SEND QC (RANDOM) | :TQ20000 | 10M| 268M| 44875 (1)| 00:00:02 | | |
| 9 | LOAD AS SELECT | SYS_TEMP_0FD9D677B_286AAA2E | | | | | | |
| 10 | PX BLOCK ITERATOR | | 10M| 268M| 44875 (1)| 00:00:02 | | |
|* 11 | TABLE ACCESS STORAGE FULL | WCRS_POLICY_DETAIL | 10M| 268M| 44875 (1)| 00:00:02 | | |
| 12 | PX COORDINATOR | | | | | | | |
| 13 | PX SEND QC (ORDER) | :TQ40017 | 1 | 838 | 186K (2)| 00:00:06 | | |
| 14 | WINDOW SORT | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 15 | PX RECEIVE | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 16 | PX SEND RANGE | :TQ40016 | 1 | 838 | 186K (2)| 00:00:06 | | |
| 17 | NESTED LOOPS | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 18 | BUFFER SORT | | | | | | | |
| 19 | PX RECEIVE | | | | | | | |
| 20 | PX SEND BROADCAST | :TQ40001 | | | | | | |
| 21 | VIEW | | 1 | 13 | 93216 (2)| 00:00:03 | | |
| 22 | SORT GROUP BY | | 1 | 393 | | | | |
| 23 | PX COORDINATOR | | | | | | | |
| 24 | PX SEND QC (RANDOM) | :TQ30015 | 1 | 393 | | | | |
| 25 | SORT GROUP BY | | 1 | 393 | | | | |
| 26 | PX RECEIVE | | 1 | 393 | | | | |
| 27 | PX SEND HASH | :TQ30014 | 1 | 393 | | | | |
| 28 | SORT GROUP BY | | 1 | 393 | | | | |
|* 29 | HASH JOIN ANTI | | 1 | 393 | 93216 (2)| 00:00:03 | | |
| 30 | PX RECEIVE | | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 31 | PX SEND HASH | :TQ30012 | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 32 | BUFFER SORT | | 1 | 838 | | | | |
| 33 | NESTED LOOPS | | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 34 | NESTED LOOPS | | 1 | 358 | 85197 (2)| 00:00:03 | | |
| 35 | NESTED LOOPS | | 1 | 348 | 85197 (2)| 00:00:03 | | |
|* 36 | HASH JOIN ANTI | | 1 | 316 | 85179 (2)| 00:00:03 | | |
| 37 | PX RECEIVE | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
| 38 | PX SEND HASH | :TQ30010 | 4 | 1156 | 77161 (2)| 00:00:03 | | |
|* 39 | HASH JOIN ANTI BUFFERED | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
| 40 | PX RECEIVE | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
| 41 | PX SEND HASH | :TQ30008 | 371 | 94605 | 69142 (2)| 00:00:03 | | |
|* 42 | HASH JOIN | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
| 43 | PX RECEIVE | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
| 44 | PX SEND BROADCAST | :TQ30007 | 350 | 77000 | 36642 (1)| 00:00:02 | | |
|* 45 | HASH JOIN | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
| 46 | PX RECEIVE | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
| 47 | PX SEND BROADCAST | :TQ30006 | 140 | 25200 | 28624 (1)| 00:00:01 | | |
|* 48 | HASH JOIN | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
| 49 | PX RECEIVE | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
| 50 | PX SEND BROADCAST | :TQ30005 | 140 | 22820 | 25169 (1)| 00:00:01 | | |
|* 51 | HASH JOIN BUFFERED | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
| 52 | BUFFER SORT | | | | | | | |
| 53 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
| 54 | T PX SEND BROADCAS | :TQ30000 | 9 | 306 | 5 (0)| 00:00:01 | | |
| 55 | INDEX ROWID TABLE ACCESS BY | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
|* 56 | AN INDEX RANGE SC | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
|* 57 | HASH JOIN | | 9699K| 1193M| 25149 (1)| 00:00:01 | | |
| 58 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 59 | PX SEND HASH | :TQ30003 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 60 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 61 | BUFFER SORT | | | | | | | |
| 62 | PX RECEIVE | | | | | | | |
| 63 | DCAST PX SEND BROA | :TQ30002 | | | | | | |
| 64 | CARTESIAN MERGE JOIN | | 1 | 14 | 13 (0)| 00:00:01 | | |
| 65 | TERATOR PX BLOCK I | | 1 | 8 | 10 (0)| 00:00:01 | | |
| 66 | ESS STORAGE FULL TABLE ACC | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
| 67 | T BUFFER SOR | | 1 | 6 | 3 (0)| 00:00:01 | | |
| 68 | E PX RECEIV | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 69 | BROADCAST PX SEND | :TQ30001 | 1 | 6 | 2 (0)| 00:00:01 | | |
| 70 | K ITERATOR PX BLOC | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 71 | ACCESS STORAGE FULL TABLE | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
| 72 | TOR PX BLOCK ITERA | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|* 73 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
| 74 | PX RECEIVE | | 10M| 785M| 2907 (2)| 00:00:01 | | |
| 75 | PX SEND HASH | :TQ30004 | 10M| 785M| 2907 (2)| 00:00:01 | | |
|* 76 | VIEW | | 10M| 785M| 2907 (2)| 00:00:01 | | |
| 77 | TOR PX BLOCK ITERA | | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 78 | STORAGE FULL TABLE ACCESS | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
|* 79 | VIEW | | 10M| 168M| 3439 (2)| 00:00:01 | | |
| 80 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 81 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 82 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 83 | LL TABLE ACCESS STORAGE FU | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 84 | PX BLOCK ITERATOR | | 15M| 521M| 32477 (2)| 00:00:02 | | |
|* 85 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 521M| 32477 (2)| 00:00:02 | | |
| 86 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 87 | PX SEND HASH | :TQ30009 | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 88 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 89 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 90 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 91 | PX SEND HASH | :TQ30011 | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 92 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 93 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 94 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 32 | 18 (0)| 00:00:01 | | |
|* 95 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
|* 96 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | 10 | 0 (0)| 00:00:01 | | |
|* 97 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
| 98 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 99 | PX SEND HASH | :TQ30013 | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 100 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 101 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 102 | VIEW | | 1 | 825 | | | | |
| 103 | SORT GROUP BY | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 104 | BUFFER SORT | | | | | | | |
| 105 | PX RECEIVE | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 106 | PX SEND HASH | :TQ40015 | 1 | 430 | 93216 (2)| 00:00:03 | | |
|*107 | HASH JOIN ANTI BUFFERED | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 108 | PX RECEIVE | | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 109 | PX SEND HASH | :TQ40013 | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 110 | BUFFER SORT | | 1 | 838 | | | | |
| 111 | NESTED LOOPS | | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 112 | NESTED LOOPS | | 1 | 395 | 85197 (2)| 00:00:03 | | |
| 113 | NESTED LOOPS | | 1 | 369 | 85197 (2)| 00:00:03 | | |
|*114 | HASH JOIN ANTI | | 1 | 311 | 85179 (2)| 00:00:03 | | |
| 115 | PX RECEIVE | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
| 116 | PX SEND HASH | :TQ40011 | 4 | 1136 | 77161 (2)| 00:00:03 | | |
|*117 | HASH JOIN ANTI BUFFERED | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
| 118 | PX RECEIVE | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
| 119 | PX SEND HASH | :TQ40009 | 371 | 92750 | 69143 (2)| 00:00:03 | | |
|*120 | HASH JOIN | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
| 121 | PX RECEIVE | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
| 122 | PX SEND BROADCAST | :TQ40008 | 350 | 72450 | 36642 (1)| 00:00:02 | | |
|*123 | HASH JOIN | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
| 124 | PX RECEIVE | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
| 125 | PX SEND BROADCAST | :TQ40007 | 140 | 23380 | 28624 (1)| 00:00:01 | | |
|*126 | HASH JOIN | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
| 127 | PX RECEIVE | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
| 128 | PX SEND BROADCAST | :TQ40006 | 140 | 15540 | 25169 (1)| 00:00:01 | | |
|*129 | HASH JOIN BUFFERED | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
| 130 | BUFFER SORT | | | | | | | |
| 131 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
| 132 | PX SEND BROADCAST | :TQ40000 | 9 | 306 | 5 (0)| 00:00:01 | | |
| 133 | ROWID TABLE ACCESS BY INDEX | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
|*134 | INDEX RANGE SCAN | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
|*135 | HASH JOIN | | 9699K| 712M| 25149 (1)| 00:00:01 | | |
| 136 | PX RECEIVE | | 10M| 287M| 2907 (2)| 00:00:01 | | |
| 137 | PX SEND HASH | :TQ40004 | 10M| 287M| 2907 (2)| 00:00:01 | | |
|*138 | VIEW | | 10M| 287M| 2907 (2)| 00:00:01 | | |
| 139 | PX BLOCK ITERATOR | | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 140 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 141 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 142 | PX SEND HASH | :TQ40005 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 143 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 144 | BUFFER SORT | | | | | | | |
| 145 | PX RECEIVE | | | | | | | |
| 146 | PX SEND BROADCAST | :TQ40003 | | | | | | |
| 147 | IAN MERGE JOIN CARTES | | 1 | 14 | 13 (0)| 00:00:01 | | |
| 148 | R PX BLOCK ITERATO | | 1 | 8 | 10 (0)| 00:00:01 | | |
| 149 | ORAGE FULL TABLE ACCESS ST | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
| 150 | BUFFER SORT | | 1 | 6 | 3 (0)| 00:00:01 | | |
| 151 | PX RECEIVE | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 152 | AST PX SEND BROADC | :TQ40002 | 1 | 6 | 2 (0)| 00:00:01 | | |
| 153 | ATOR PX BLOCK ITER | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 154 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
| 155 | PX BLOCK ITERATOR | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|*156 | E FULL TABLE ACCESS STORAG | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|*157 | VIEW | | 10M| 555M| 3439 (2)| 00:00:01 | | |
| 158 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 159 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 160 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 161 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 162 | PX BLOCK ITERATOR | | 15M| 641M| 32477 (2)| 00:00:02 | | |
|*163 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 641M| 32477 (2)| 00:00:02 | | |
| 164 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 165 | PX SEND HASH | :TQ40010 | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 166 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 167 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 168 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 169 | PX SEND HASH | :TQ40012 | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 170 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 171 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 172 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 58 | 18 (0)| 00:00:01 | | |
|*173 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
| 174 | TABLE ACCESS BY INDEX ROWID | PROVIDER_NETWORK_DIM | 1 | 26 | 0 (0)| 00:00:01 | | |
|*175 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | | 0 (0)| 00:00:01 | | |
|*176 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
| 177 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 178 | PX SEND HASH | :TQ40014 | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 179 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 180 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------- -
Hi,
I would like to know any SQL tuning methods specific to Oracle exadata so that they could improve the performance of the database?
I am aware that oracle exadata runs with Oracle 11g, but i would like to know wheather there is any tuning scope w.r.t to SQL's on exadata?
regards
sunilWell there are some things that are very different about Exadata. All the standard Oracle SQL tuning you have learned already should not be forgotten as Exadata is running standard 11g database code, but there are many optimizations that have been added that you should be aware of. At a high level, if you are doing OLTP type work you should be trying to make sure that you take advantage of Exadata Smart Flash Cache which will significantly speed up your small I/O's. But long running queries are where the big benefits show up. The high level tuning approach for them is as follows:
1. Check to see if you are getting Smart Scans.
2. If you aren't, fix what ever is preventing them from being used.
We've been involved in somewhere between 25-30 DB Machine installations now and in many cases, a little bit of effort changes performance dramatically. If you are only getting 2 to 3X improvement over your previous platform on these long running queries you are probably not getting the full benefit of the Exadata optimizations. So the first step is learning how to determine if you are getting Smart Scans or not and on what portions of the statement. Wait events, session statistics, V$SQL, SQL Monitoring are all viable tools that can show you that information. -
Hi
I am not a sql programmer and developers have given me this sql to have a look. I made the following recommendations after going through the sql. Is there anything else that can be added . I did not add about stats because they are representative and up to date.
SELECT /*+ PARALLEL(q1,4) */ *
FROM
(SELECT /*+ FIRST_ROWS(20) */
br.resource_id,
br.resource_code,
x.resource_seq_num employee_resource_number,
br.organization_id,
bd.department_id,
bd.department_code,
pf.full_name employee_name,
(SELECT xxdl_eam_util_pkg.xxdl_eam_get_resource_code(pf.person_id, bd.department_id)
FROM dual)
maximum_cost_resource,
pf.person_id,
x.wip_entity_id wo_id,
(SELECT weo1.wip_entity_name
FROM wip_eam_work_orders_v weo1
WHERE weo1.wip_entity_id = x.wip_entity_id)
wo_number,
CAST(x.start_date AS
TIMESTAMP) start_date,
CAST(x.completion_date AS
TIMESTAMP) completion_date,
wor.operation_seq_num wo_operation_number,
wor.resource_seq_num wo_resource_number,
wor.usage_rate_or_amount HOURS,
BRE.effective_start_date instance_start_date,
BRE.effective_end_date instance_end_date,
BRE.instance_id,
crc.resource_rate AS
resource_cost,
(SELECT xxdl_eam_util_pkg.xxdl_eam_get_all_res_code(pf.person_id, bd.department_id)
FROM dual)
all_resources
FROM per_all_people_f pf,
wip_eam_work_orders_v weo,
wip_operations wo,
wip_operation_resources wor,
(SELECT instance_id,
wip_entity_id,
operation_seq_num,
resource_seq_num,
start_date,
completion_date
FROM wip_op_resource_instances_v) x,
bom_dept_res_instances bdri,
bom_resource_employees BRE,
bom_department_resources bdr,
bom_resources br,
cst_resource_costs crc,
bom_departments bd
WHERE br.organization_id = bd.organization_id
AND bdr.resource_id = br.resource_id
AND bdr.department_id = bd.department_id
AND BRE.resource_id = br.resource_id
AND pf.effective_start_date <=sysdate
AND pf.effective_end_date >= sysdate
AND pf.person_id = BRE.person_id
AND wo.department_id = bd.department_id
AND wor.operation_seq_num(+) = wo.operation_seq_num
AND wor.wip_entity_id(+) = wo.wip_entity_id
AND wor.organization_id(+) = wo.organization_id
AND weo.wip_entity_id = wo.wip_entity_id
AND weo.organization_id = wo.organization_id
-- AND weo.organization_id = 6921
AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
AND crc.resource_id(+) = BRE.resource_id
AND x.wip_entity_id = wor.wip_entity_id
AND x.operation_seq_num = wor.operation_seq_num
AND x.resource_seq_num = wor.resource_seq_num
AND x.instance_id(+) = BRE.instance_id
AND bdri.department_id = bd.department_id
AND bdri.resource_id = br.resource_id
AND weo.organization_id = 6921
AND bdri.department_id = 5004
UNION
SELECT /*+ FIRST_ROWS(20) */ DISTINCT NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
pf.full_name employee_name,
NULL,
pf.person_id,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL HOURS,
NULL,
NULL,
NULL,
NULL,
NULL
FROM per_all_people_f pf,
wip_eam_work_orders_v weo,
wip_operations wo,
wip_operation_resources wor,
bom_dept_res_instances bdri,
bom_resource_employees BRE,
bom_department_resources bdr,
bom_resources br,
cst_resource_costs crc,
bom_departments bd
WHERE br.organization_id = bd.organization_id
AND bdr.resource_id = br.resource_id
AND bdr.department_id = bd.department_id
AND BRE.resource_id = br.resource_id
AND pf.effective_start_date <=sysdate
AND pf.effective_end_date >= sysdate
AND pf.person_id = BRE.person_id
AND wo.department_id = bd.department_id
AND wor.operation_seq_num(+) = wo.operation_seq_num
AND wor.wip_entity_id(+) = wo.wip_entity_id
AND wor.organization_id(+) = wo.organization_id
AND weo.wip_entity_id = wo.wip_entity_id
AND weo.organization_id = wo.organization_id
AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
AND crc.resource_id(+) = BRE.resource_id
AND bdri.department_id = bd.department_id
AND bdri.resource_id = br.resource_id
AND weo.organization_id = 6921
AND bdri.department_id = 5004
AND NOT EXISTS
(SELECT instance_id,
wip_entity_id operation_seq_num,
resource_seq_num
FROM wip_op_resource_instances_v)
) q1
ORDER BY department_id,
resource_code,
employee_name,
wo_number
My suggestions:
. Try to use UNION ALL instead of UNION. If you can eliminate UNION all together and flatten the query that will be even better.
2. You are using the function in a select statement xxdl_eam_util_pkg.xxdl_eam_get_resource_code(pf.person_id, bd.department_id)This will slow the performance. Try to get rid of this. Function calls in select are expensive.
3. Dont use the parallel hint and optimize. It wont get you consistent results.
4. Use of per_all_people_F is expensive. The UNION again complicates things. per_all_people_f has to be scanned 2x times.
5. Where does the application get the values for department id? Whether user inputs a value or whether it is hard coded . Most likely user will input value and each time it may be different. If that is the case, then you may be hitting bind peeking. There is not much hope for this. Not much can be done. Whatever you do this can happen. Only way is to pin the plan if you can use literals instead of binds. But that is not possible I think.
6. AND DECODE(bd.disable_date,null, sysdate,bd.disable_date) >= sysdate
AND DECODE(br.disable_date,null, sysdate,br.disable_date) >= sysdate
AND DECODE(wo.disable_date,null, sysdate,wo.disable_date) >= sysdate
Those statements, if you can rewrite would be good. If there are indexes on any of those columns, they are more than likely not used.
7. Are the outer joins really required. If not required remove them.
8. There is a 'WITH' clause in 10g . Try to use that for your subqueries or main query where applicable. It will save some I/O.
9. Try to tune without any hints. Remove the first rows as well and see the difference.
I know that the sql is definately bad and can be rewritten but I am not able to exactly write it for them.
Any inputs or thoughts?
MSKHi,
Any suggestions for reading on Sql tuning
I am looking for a practical book with solutions .
And books showing the Sql internal workings ?Take a look on Amazon some Jonathan Lewis books.
I will also recommend you to take a look on the following blogs:
- http://jonathanlewis.wordpress.com/
- http://www.juliandyke.com/
- http://richardfoote.wordpress.com/
- http://tkyte.blogspot.com/
And also any good interview based good Oracle DBA books ?You can take a look on my blog for some common DBA interview questions.
http://oraclenz.com/category/interview-tips/
Regards,
Francisco Munoz Alvarez
www.oraclenz.com -
SQL Tuning using Enterprise manager in oracle 10g
Hi,
In oracle 10g you have the enterprise manager which can be used to tune sql statements using the SQL Tuning ADvisor and SQL access advisor.
I believe in oracle 10g the process of SQL Tuning is slightly easier using the Enterprise Manager ...so if some one could explain me that process...
Again thanking you in advance
regds
Manoj GokhaleHi Manoj,
Didn't you already start two other threads about this same question the SQL forum?
How do i do the SQL Statement tuning
Enterprise Manager - sql tuning advisor , Access advisor for SQL Tuning -
Hi All,
I am new to tuning.
Can somebody help me in tuning this SQL query.
SELECT pppd.productid, pppd.sequencenumber, pppd.priceareaid, pppd.startdate, pppd.qtyfrom, pppd.enddate, pppd.price,
pppd.articleid, pppd.customerid, pppd.distributorid, pppd.supplierid, pppd.adviceprice, pppd.customergroupid, pppd.dimensionvalue1, pppd.dimensionvalue2,
pppd.dimensionvalue3, pppd.dimensionvalue4, pppd.dimensionvalue5, pppd.dimensionvalue6, pppd.discountpercentage,
pppd.promotionindicator, pppd.vatindicator
FROM PPM_PRODUCTPRICE pppd WHERE
pppd.validindicator=1 AND pppd.startdate <= SYSDATE AND NVL(pppd.enddate,SYSDATE +1) >= SYSDATE
AND NOT EXISTS
(SELECT 1 FROM PPM_PRODUCTPRICE pppd2 WHERE pppd2.productid = pppd.productid
AND NOT (pppd2.sequencenumber = pppd.sequencenumber)
AND pppd2.priceareaid = pppd.priceareaid
AND (NVL(pppd2.supplierid,9999999999) = NVL(pppd.supplierid,9999999999) )
AND (NVL(pppd2.distributorid,9999999999) = NVL(pppd.distributorid,9999999999))
AND (NVL(pppd2.customerid,9999999999) = NVL(pppd.customerid,9999999999) )
AND (NVL(pppd2.customergroupid,9999999999) = NVL(pppd.customergroupid,9999999999))
AND (NVL(pppd2.articleid,9999999999) = NVL(pppd.articleid,9999999999))
AND (NVL(pppd2.dimensionvalue1,9999999999)=NVL(pppd.dimensionvalue1,9999999999))
AND (NVL(pppd2.dimensionvalue2,9999999999)=NVL(pppd.dimensionvalue2 ,9999999999))
AND (NVL(pppd2.dimensionvalue3,9999999999)=NVL(pppd.dimensionvalue3 ,9999999999))
AND (NVL(pppd2.dimensionvalue4,9999999999)=NVL(pppd.dimensionvalue4 ,9999999999))
AND (NVL(pppd2.dimensionvalue5,9999999999)=NVL(pppd.dimensionvalue5 ,9999999999))
AND (NVL(pppd2.dimensionvalue6,9999999999)=NVL(pppd.dimensionvalue6 ,9999999999))
AND pppd2.qtyfrom = pppd.qtyfrom AND pppd2.startdate BETWEEN pppd.startdate AND SYSDATE
AND NVL(pppd2.enddate,SYSDATE +1) >= SYSDATE )
AND productid= 30700At a minimum I think you should search the forums for SQL Tuning because I know there is some sort of sticked post identifying the GENERAL steps you should follow to tune a query. Us being here trying to help cannot tune a blanket SQL statement for the most part that is given to us. We don't know so many things that it is hard to form a cohesive answer. Some questions that arise are:
1. What version of Oracle are you using?
2. What are the table structures?
3. What is the question you are truly trying to answer?
4. What is the explain plan saying?
5. What is your tuning goal (faster execution? lower I/O?)?
5. etc.....
At a minimum it appears that you are using the NVL function a lot and I would probably wager a guess that it is preventing you from using indexes on all those ID columns, if there are any.
Hope this helps!
Edited by: Centinul on Sep 12, 2008 12:31 PM
Here is the link to the post I was discussing: When your query takes too long ... -
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 -
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 PMWe 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 -
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 AMHi,
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.
Maybe you are looking for
-
Trying to do BootCamp Windows-7 install on my MacBook (running 10.5.x). Detailed progress notes here. Latest: "Windows failed to load because the kernel is missing, or corrupt." (ntkrnlpa.exe) Hit `Enter` to continue, make next selection, but it come
-
How can I get my photos and all media back which got deleted while updating software
Helppppp!!!!!!
-
Hi All, I want to check appropriate error log and see what went wrong if my Java Webdynpro application deployment fails. Can anyone help me out in this? Regards, Divya
-
I've seen this post: http://forums.ni.com/ni/board/message?board.id=170&message.id=418659&query.id=2770634#M418659 But it doesn't really help in what we're trying to do. is there any known way to have multiple ROIs programatically drawn with differen
-
Routing unit of measure conversion
Dear guru , I have a different unit of measure for one operation of my routing. Which is the problem if I maintain relation 1 to 1 in the routing unit of measure conversion ? Thanks.