Performance issue with a particular query
Hi Experts,
OS version : Sun solaris 5.10
DB version : 10.1.0.4
We have a report designed in SAP BO and for which we have below SQL query written
SELECT
SNOW_DIM.SERV_REP_INCIDENT.INCIDENT_NUMBER,
ISAC_GL_APPL_HIERARCHY_SERVIMP.SOL_NAME
ISAC_GL_APPL_HIERARCHY_SERVIMP.SOL_DOMAIN_NAME
Count(DISTINCT SNOW_DIM.SERV_REP_INCIDENT.INCIDENT_NUMBER),
Count(DISTINCT case when SNOW_DIM.SERV_REP_INCIDENT.STATE_ID=3 then SNOW_DIM.SERV_REP_INCIDENT.INCIDENT_NUMBER end),
SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_GROUP,
case when SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_SUPPORT_GROUP_LEVEL=1 then 'Level 1' when SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_SUPPORT_GROUP_LEVEL=2 then 'Level 2' when SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_SUPPORT_GROUP_LEVEL=3 then 'Level 3' else to_char(SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_SUPPORT_GROUP_LEVEL) end,
SNOW_DIM.SERV_REP_INCIDENT.SHORT_DESCRIPTION,
SNOW_DIM.SERV_REP_INCIDENT.PRIORITY,
SNOW_DIM.SERV_REP_INCIDENT.STATE,
SNOW_DIM.SERV_REP_INCIDENT.OPENED_AT,
BU_EMPLOYEES_INC_AS.BUSINESS_NAME,
TO_CHAR(SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT,'Month'),
TO_CHAR(SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT,'MM'),
TO_CHAR(SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT,'SYYYY'),
SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT
FROM
SNOW_DIM.SERV_REP_INCIDENT,
SNOW_DIM.ISAC_GL_APPL_HIERARCHY ISAC_GL_APPL_HIERARCHY_SERVIMP,
SNOW_DIM.BU_EMPLOYEES BU_EMPLOYEES_INC_AS,
SNOW_DIM.SERV_REP_CONTRACT_SLA,
SNOW_DIM.SERV_REP_TASK_SLA
WHERE
( SNOW_DIM.SERV_REP_INCIDENT.ASSIGNEE_GPN=BU_EMPLOYEES_INC_AS.GPN(+) )
AND ( SNOW_DIM.SERV_REP_INCIDENT.INCIDENT_SYS_ID=SNOW_DIM.SERV_REP_TASK_SLA.TASK(+) )
AND ( SNOW_DIM.SERV_REP_TASK_SLA.SLA=SNOW_DIM.SERV_REP_CONTRACT_SLA.SYS_ID(+) )
AND ( ISAC_GL_APPL_HIERARCHY_SERVIMP.APPL_ID(+)=SNOW_DIM.SERV_REP_INCIDENT.SERVICE_ID )
AND
ISAC_GL_APPL_HIERARCHY_SERVIMP.APPL_ENVIRONMENT
= 'PROD'
AND
SNOW_DIM.SERV_REP_INCIDENT.TYPE_X = 'Incident'
AND
case
WHEN SNOW_DIM.SERV_REP_INCIDENT.DUPLICATE_INCIDENT = 1 then 'Yes'
WHEN SNOW_DIM.SERV_REP_INCIDENT.DUPLICATE_INCIDENT = 0 then 'No'
end = 'No'
AND
SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_GROUP IN ( 'WMSB_IT_CH_Business_Support_1_L2','WMSB_IT_CH_Business_Support_2_HW_L2','WMSB_IT_CH_Business_Support_2_L2','WMSB_IT_CH_Business_Support_3_L2','WMSB_IT_CH_Business_Support_4_CEFS_L2','WMSB_IT_CH_Business_Support_4_L2','WMSB_IT_CH_Business_Support_5_L2','WMSB_IT_APAC_Production_Support_L2','WMSB_IT_EMEA_ESS_CLAS_Team_L2','WMSB_IT_US_Production_Support_L2','WMSB_IT_CH_AoC_Decentral_L2','WMSB_IT_CH_AoC_Mainframe_L2','WMSB_IT_GLOB_AoC_Decentral_L2' )
OR
SNOW_DIM.SERV_REP_CONTRACT_SLA.TYPE_X = 'SLA'
AND
SNOW_DIM.SERV_REP_TASK_SLA.STAGE IN ( 'in_progress','achieved','breached','completed','paused' )
OR
SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_GROUP NOT IN ( 'WMSB_IT_CH_Business_Support_1_L2','WMSB_IT_CH_Business_Support_2_HW_L2','WMSB_IT_CH_Business_Support_2_L2','WMSB_IT_CH_Business_Support_3_L2','WMSB_IT_CH_Business_Support_4_CEFS_L2','WMSB_IT_CH_Business_Support_4_L2','WMSB_IT_CH_Business_Support_5_L2','WMSB_IT_APAC_Production_Support_L2','WMSB_IT_EMEA_ESS_CLAS_Team_L2','WMSB_IT_US_Production_Support_L2','WMSB_IT_CH_AoC_Decentral_L2','WMSB_IT_CH_AoC_Mainframe_L2','WMSB_IT_GLOB_AoC_Decentral_L2','WMSB_IT_GLOB_Service_Desk_L1','WMSB_IT_EMEA_ESS_CLAS_Team_L1' )
AND
SNOW_DIM.SERV_REP_TASK_SLA.ASSIGNMENT_GROUP_NAME IN ( 'WMSB_IT_CH_Business_Support_1_L2','WMSB_IT_CH_Business_Support_2_HW_L2','WMSB_IT_CH_Business_Support_2_L2','WMSB_IT_CH_Business_Support_3_L2','WMSB_IT_CH_Business_Support_4_CEFS_L2','WMSB_IT_CH_Business_Support_4_L2','WMSB_IT_CH_Business_Support_5_L2','WMSB_IT_APAC_Production_Support_L2','WMSB_IT_EMEA_ESS_CLAS_Team_L2','WMSB_IT_US_Production_Support_L2','WMSB_IT_CH_AoC_Decentral_L2','WMSB_IT_CH_AoC_Mainframe_L2','WMSB_IT_GLOB_AoC_Decentral_L2' )
AND
SNOW_DIM.SERV_REP_TASK_SLA.STAGE IN ( 'in_progress','achieved','breached','completed','paused' )
AND
ISAC_GL_APPL_HIERARCHY_SERVIMP.SOL_DOMAIN_NAME
IN ('Partner, Product & Contract Management')
AND
SNOW_DIM.SERV_REP_INCIDENT.STATE IN ( 'Assigned','Closed','In Progress','New','On Hold','Resolved' )
AND
( ( SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT ) between (ADD_MONTHS(trunc(sysdate,'MM'),-6)) AND (trunc(sysdate,'MM')-0.0002/24)
GROUP BY
SNOW_DIM.SERV_REP_INCIDENT.INCIDENT_NUMBER,
ISAC_GL_APPL_HIERARCHY_SERVIMP.SOL_NAME
ISAC_GL_APPL_HIERARCHY_SERVIMP.SOL_DOMAIN_NAME
SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_GROUP,
case when SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_SUPPORT_GROUP_LEVEL=1 then 'Level 1' when SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_SUPPORT_GROUP_LEVEL=2 then 'Level 2' when SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_SUPPORT_GROUP_LEVEL=3 then 'Level 3' else to_char(SNOW_DIM.SERV_REP_INCIDENT.ASSIGNED_SUPPORT_GROUP_LEVEL) end,
SNOW_DIM.SERV_REP_INCIDENT.SHORT_DESCRIPTION,
SNOW_DIM.SERV_REP_INCIDENT.PRIORITY,
SNOW_DIM.SERV_REP_INCIDENT.STATE,
SNOW_DIM.SERV_REP_INCIDENT.OPENED_AT,
BU_EMPLOYEES_INC_AS.BUSINESS_NAME,
TO_CHAR(SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT,'Month'),
TO_CHAR(SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT,'MM'),
TO_CHAR(SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT,'SYYYY'),
SNOW_DIM.SERV_REP_INCIDENT.CLOSED_AT;
Users reporting that the report is running slow and I have generated explain plan for the same and it is as below
PLAN_TABLE_OUTPUT
Plan hash value: 2068297582
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 13216 | 38M| | 245K (1)| 00:13:02 |
| 1 | SORT GROUP BY | | 13216 | 38M| 103M| 245K (1)| 00:13:02 |
|* 2 | FILTER | | | | | | |
| 3 | NESTED LOOPS OUTER | | 13216 | 38M| | 232K (1)| 00:12:21 |
|* 4 | FILTER | | | | | | |
| 5 | NESTED LOOPS OUTER | | 508 | 1495K| | 232K (1)| 00:12:21 |
|* 6 | FILTER | | | | | | |
| 7 | NESTED LOOPS OUTER | | 508 | 1477K| | 232K (1)| 00:12:21 |
|* 8 | HASH JOIN | | 96 | 270K| | 232K (1)| 00:12:21 |
|* 9 | MAT_VIEW ACCESS FULL | ISAC_GL_APPL_HIERARCHY | 6 | 4230 | | 3884 (1)| 00:00:13 |
|* 10 | TABLE ACCESS BY INDEX ROWID| SERV_REP_INCIDENT | 802K| 1669M| | 228K (1)| 00:12:08 |
|* 11 | INDEX RANGE SCAN | I7_SERV_REP_INCIDENT_N | 1368K| | | 3437 (3)| 00:00:11 |
| 12 | TABLE ACCESS BY INDEX ROWID | SERV_REP_TASK_SLA | 5 | 455 | | 1 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | I6_SERV_REP_TASK_SLA | 5 | | | 0 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | SERV_REP_CONTRACT_SLA | 1 | 37 | | 1 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | I1_SERV_REP_CONTRACT_SLA | 1 | | | 0 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID | BU_EMPLOYEES | 26 | 858 | | 1 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | I01_BU_EMPLOYEES | 26 | | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(ADD_MONTHS(TRUNC(SYSDATE@!,'fmmm'),-6)<=TRUNC(SYSDATE@!,'fmmm')-.000011574074074074074074074074074
07407407407)
4 - filter("SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_APAC_Production_Support_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_AoC_Decentral_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_AoC_Mainframe_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_Business_Support_1_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_Business_Support_2_HW_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_Business_Support_2_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_Business_Support_3_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_Business_Support_4_CEFS_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_Business_Support_4_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_CH_Business_Support_5_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_EMEA_ESS_CLAS_Team_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_GLOB_AoC_Decentral_L2' OR
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"='WMSB_IT_US_Production_Support_L2' OR "T"."TYPE_X"='SLA' AND
("SERV_REP_TASK_SLA"."STAGE"='achieved' OR "SERV_REP_TASK_SLA"."STAGE"='breached' OR
"SERV_REP_TASK_SLA"."STAGE"='completed' OR "SERV_REP_TASK_SLA"."STAGE"='in_progress' OR
"SERV_REP_TASK_SLA"."STAGE"='paused') OR ("SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_APAC_Production_S
upport_L2' OR "SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_AoC_Decentral_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_AoC_Mainframe_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_Business_Support_1_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_Business_Support_2_HW_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_Business_Support_2_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_Business_Support_3_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_Business_Support_4_CEFS_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_Business_Support_4_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_CH_Business_Support_5_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_EMEA_ESS_CLAS_Team_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_GLOB_AoC_Decentral_L2' OR
"SERV_REP_TASK_SLA"."ASSIGNMENT_GROUP_NAME"='WMSB_IT_US_Production_Support_L2') AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_Business_Support_1_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_Business_Support_2_HW_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_Business_Support_2_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_Business_Support_3_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_Business_Support_4_CEFS_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_Business_Support_4_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_Business_Support_5_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_APAC_Production_Support_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_EMEA_ESS_CLAS_Team_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_US_Production_Support_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_AoC_Decentral_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_CH_AoC_Mainframe_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_GLOB_AoC_Decentral_L2' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_GLOB_Service_Desk_L1' AND
"SERV_REP_INCIDENT"."ASSIGNED_GROUP"<>'WMSB_IT_EMEA_ESS_CLAS_Team_L1')
6 - filter("SERV_REP_TASK_SLA"."STAGE"='achieved' OR "SERV_REP_TASK_SLA"."STAGE"='breached' OR
"SERV_REP_TASK_SLA"."STAGE"='completed' OR "SERV_REP_TASK_SLA"."STAGE"='in_progress' OR
"SERV_REP_TASK_SLA"."STAGE"='paused')
8 - access("ISAC_GL_APPL_HIERARCHY_SERVIMP"."APPL_ID"="SERV_REP_INCIDENT"."SERVICE_ID")
9 - filter("ISAC_GL_APPL_HIERARCHY_SERVIMP"."APPL_ENVIRONMENT"='PROD' AND
"ISAC_GL_APPL_HIERARCHY_SERVIMP"."SOL_DOMAIN_NAME"='Partner, Product & Contract Management')
10 - filter("SERV_REP_INCIDENT"."TYPE_X"='Incident' AND ("SERV_REP_INCIDENT"."STATE"='Assigned' OR
"SERV_REP_INCIDENT"."STATE"='Closed' OR "SERV_REP_INCIDENT"."STATE"='In Progress' OR
"SERV_REP_INCIDENT"."STATE"='New' OR "SERV_REP_INCIDENT"."STATE"='On Hold' OR
"SERV_REP_INCIDENT"."STATE"='Resolved') AND CASE "SERV_REP_INCIDENT"."DUPLICATE_INCIDENT" WHEN 1 THEN 'Yes'
WHEN 0 THEN 'No' END ='No')
11 - access("SERV_REP_INCIDENT"."CLOSED_AT">=ADD_MONTHS(TRUNC(SYSDATE@!,'fmmm'),-6) AND
"SERV_REP_INCIDENT"."CLOSED_AT"<=TRUNC(SYSDATE@!,'fmmm')-.00001157407407407407407407407407407407407407)
13 - access("SERV_REP_INCIDENT"."INCIDENT_SYS_ID"="SERV_REP_TASK_SLA"."TASK"(+))
15 - access("SERV_REP_TASK_SLA"."SLA"="T"."SYS_ID"(+))
17 - access("SERV_REP_INCIDENT"."ASSIGNEE_GPN"="T"."GPN"(+))
From above plan I could analyze that indexes on table SERV_REP_INCIDENT are not being used on columns ASSIGNED_GROUP, STATE, STAGE etc as they are using IN and NOT IN clauses in where condition and because of this reason cost at id 10 increased to 228k.
now, i would like to know the advise from you people what can be done to make it better. also I read that IN clause can use indexes if data is more. In my case is there any way that I can force those IN and NOT IN clauses to use index? (we have indexes created on all those columns used by SERV_REP_INCIDENT table)
Thanks in advance.
From above plan I could analyze that indexes on table SERV_REP_INCIDENT are not being used on columns ASSIGNED_GROUP, STATE, STAGE etc as they are using IN and NOT IN clauses in where condition and >because of this reason cost at id 10 increased to 228k.Good job isolating the (estimated) spike in resources by high estimates! You can try to minimize the work for this step in several ways, some simple and some extreme:
Try a composite function-based index on SERV_REP_INCIDENT for the IN clauses.
Another long-term possiblity is to partition the SERV_REP_INCIDENT table by the IN values if you have the license. This may not be the best partionining option; partitioning needs to be conisdered carefully before implementation.
How long does the query take to execute? Another possiblity is to to create a materialized view on the query you posted, using the automated query rewrite to automatically use it (possibly indexed).
Similar Messages
-
Performance issue with the Select query
Hi,
I have an issue with the performance with a seclet query.
In table AFRU - AUFNR is not a key field.
So i had selected the low and high values into s_reuck and used it in Where condition.
Still i have an issue with the Performance.
SELECT SINGLE RUECK
RMZHL
IEDD
AUFNR
STOKZ
STZHL
FROM AFRU INTO table t_AFRU
FOR ALL ENTRIES IN T_ZSCPRT100
WHERE RUECK IN S_RUECK AND
AUFNR = T_ZSCPRT100-AUFNR AND
STOKZ = SPACE AND
STZHL = 0.
I had also cheked by createing an index for AUFNR in the table AFRU...it does not help.
Is there anyway that we can declare Key field while declaring the Internal table....?
ANy suggestions to fix the performance issue is apprecaited!
Regards,
KittuHi,
Thank you for your quick response!
Rui dantas, i have lill confusion...this is my code below :
data : t_zscprt type standard table of ty_zscprt,
wa_zscprt type ty_zscprt.
types : BEGIN OF ty_zscprt100,
aufnr type zscprt100-aufnr,
posnr type zscprt100-posnr,
ezclose type zscprt100-ezclose,
serialnr type zscprt100-serialnr,
lgort type zscprt100-lgort,
END OF ty_zscprt100.
data : t_zscprt100 type standard table of ty_zscprt100,
wa_zscprt100 type ty_zscprt100.
Types: begin of ty_afru,
rueck type CO_RUECK,
rmzhl type CO_RMZHL,
iedd type RU_IEDD,
aufnr type AUFNR,
stokz type CO_STOKZ,
stzhl type CO_STZHL,
end of ty_afru.
data : t_afru type STANDARD TABLE OF ty_afru,
WA_AFRU TYPE TY_AFRU.
SELECT AUFNR
POSNR
EZCLOSE
SERIALNR
LGORT
FROM ZSCPRT100 INTO TABLE T_ZSCPRT100
FOR ALL ENTRIES IN T_ZSCPRT
WHERE AUFNR = T_ZSCPRT-PRTNUM
AND SERIALNR IN S_SERIAL
AND LGORT IN S_LGORT.
IF sy-subrc <> 0.
MESSAGE ID 'Z2' TYPE 'I' NUMBER '41'. "BDCG87
stop."BDCG87
ENDIF.
ENDIF.
SELECT RUECK
RMZHL
IEDD
AUFNR
STOKZ
STZHL
FROM AFRU INTO TABLE T_AFRU
FOR ALL ENTRIES IN T_ZSCPRT100
WHERE RUECK IN S_RUECK AND
AUFNR = T_ZSCPRT100-AUFNR AND
STOKZ = SPACE AND
STZHL = 0.
Using AUFNR, get AUFPL from AFKO
Using AUFPL, get RUECK from AFVC
Using RUEKC, read AFRU
In other words, one select joining AFKO <-> AFVC <-> AFRU should get what you want.
This is my select query, would you want me to write another select query to meet this criteria..
From AUFNR> I will get AUFPL from AFKO> BAsed on AUFPL I will get RUECK, based on RUEKC i need to read AFRU..but i need to select few field from AFRu based on AUFNR....
ANy suggestions wil be appreciated!
Regards
Kittu -
Performance issue with this complex query
Please ignore this thread(post)
This query fetches a lot of data and takes more than 4 t0 5 hrs to retrieve them.
I have tried to get the explain plan the display cursor and the TKPROF for the same but then the query utilizes more than 100GB temp space and it fails to generate any.
What I have is the spool file which is pasted below along with the query.
Database version: 11g
I'm looking forward for suggestions how to improve the performance of this statement
Please ignore this thread(post)
Edited by: user13319084 on May 30, 2011 12:34 AMYou provide no information that can be used in answering your question on how to improve the query.
In absence of technical information, all that we can discuss is conceptual issues. Like why is the query that complex? A common answer is that the underlying data model lacks the intelligence and this now requires the intelligence to be build into the query.
You need to look at the data model and the query in order to address this performance problem - and make sure that the actual business requirements is clearly identified and understood. -
Performance issues with respect scheme registration,select & insert query
I am facing performance issues with respect to schema registration,Select & insert query towards 10.2.0.3 version.It is taking around 45 minutes to register schema and it is taking around 5 min to insert a single document into xml db where as it was taking less than min to insert a single document into xml db of 9.2.0.6 version.Would like to know the issue and solution to resolve this issue.Please help me out on this as it is very urgent for me
Since it appears that this is an XML DB specific question, you're probably better off posting in the XML DB. The folks over there have much more experience with the ins and outs of that particular product.
Justin -
Performance issues with pipelined table functions
I am testing pipelined table functions to be able to re-use the <font face="courier">base_query</font> function. Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? The <font face="courier">processor</font> function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
Many thanks in advance.
CREATE OR REPLACE PACKAGE pipeline_example
IS
TYPE resultset_typ IS REF CURSOR;
TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
TYPE table_typ IS TABLE OF row_typ;
FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
RETURN resultset_typ;
c_default_limit CONSTANT PLS_INTEGER := 100;
FUNCTION processor (
p_source_data IN resultset_typ,
p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
RETURN table_typ
PIPELINED
PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
PROCEDURE with_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ);
PROCEDURE no_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ);
END pipeline_example;
CREATE OR REPLACE PACKAGE BODY pipeline_example
IS
FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
RETURN resultset_typ
IS
o_resultset resultset_typ;
BEGIN
OPEN o_resultset FOR
SELECT colC, colD, colE
FROM some_table
WHERE colA = ArgA AND colB = argB;
RETURN o_resultset;
END base_query;
FUNCTION processor (
p_source_data IN resultset_typ,
p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
RETURN table_typ
PIPELINED
PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
IS
aa_source_data table_typ;-- := table_typ ();
BEGIN
LOOP
FETCH p_source_data
BULK COLLECT INTO aa_source_data
LIMIT p_limit_size;
EXIT WHEN aa_source_data.COUNT = 0;
/* Process the batch of (p_limit_size) records... */
FOR i IN 1 .. aa_source_data.COUNT
LOOP
PIPE ROW (aa_source_data (i));
END LOOP;
END LOOP;
CLOSE p_source_data;
RETURN;
END processor;
PROCEDURE with_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ)
IS
BEGIN
OPEN o_resultset FOR
SELECT /*+ PARALLEL(t, 5) */ colC,
SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
FROM TABLE (processor (base_query (argA, argB),100)) t
GROUP BY colC
ORDER BY colC
END with_pipeline;
PROCEDURE no_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ)
IS
BEGIN
OPEN o_resultset FOR
SELECT colC,
SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
SUM (CASE WHEN colD = colE AND colD != '0' THEN 1 END) de_one,
SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
FROM (SELECT colC, colD, colE
FROM some_table
WHERE colA = ArgA AND colB = argB)
GROUP BY colC
ORDER BY colC;
END no_pipeline;
END pipeline_example;
ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
Edited by: Earthlink on Nov 14, 2010 11:31 AM
Edited by: Earthlink on Nov 14, 2010 11:32 AM
Edited by: Earthlink on Nov 20, 2010 12:04 PM
Edited by: Earthlink on Nov 20, 2010 12:54 PMEarthlink wrote:
Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701 -
Performance Issues with large XML (1-1.5MB) files
Hi,
I'm using an XML Schema based Object relational storage for my XML documents which are typically 1-1.5 MB in size and having serious performance issues with XPath Query.
When I do XPath query against an element of SQLType varchar2, I get a good performance. But when I do a similar XPath query against an element of SQLType Collection (Varray of varchar2), I get a very ordinary performance.
I have also created indexes on extract() and analyzed my XMLType table and indexes, but I have no performance gain. Also, I have tried all sorts of storage options available for Collections ie. Varray's, Nested Tables, IOT's, LOB's, Inline, etc... and all these gave me same bad performance.
I even tried creating XMLType views based on XPath queries but the performance didn't improve much.
I guess I'm running out of options and patience as well.;)
I would appreciate any ideas/suggestions, please help.....
Thanks;
Ramakrishna ChintaAre you having similar symptoms as I am? http://discussions.apple.com/thread.jspa?threadID=2234792&tstart=0
-
Performance issues with version enable partitioned tables?
Hi all,
Are there any known performance issues with version enable partitioned tables?
Ive been doing some performance testes with a large version enable partitioned table and it seems that OCB optimiser is choosing very expensive plans during merge operations.
Tanks in advance,
Vitor
Example:
Object Name Rows Bytes Cost Object Node In/Out PStart PStop
UPDATE STATEMENT Optimizer Mode=CHOOSE 1 249
UPDATE SIG.SIG_QUA_IMG_LT
NESTED LOOPS SEMI 1 266 249
PARTITION RANGE ALL 1 9
TABLE ACCESS FULL SIG.SIG_QUA_IMG_LT 1 259 2 1 9
VIEW SYS.VW_NSO_1 1 7 247
NESTED LOOPS 1 739 247
NESTED LOOPS 1 677 247
NESTED LOOPS 1 412 246
NESTED LOOPS 1 114 244
INDEX RANGE SCAN WMSYS.MODIFIED_TABLES_PK 1 62 2
INDEX RANGE SCAN SIG.QIM_PK 1 52 243
TABLE ACCESS BY GLOBAL INDEX ROWID SIG.SIG_QUA_IMG_LT 1 298 2 ROWID ROW L
INDEX RANGE SCAN SIG.SIG_QUA_IMG_PKI$ 1 1
INDEX RANGE SCAN WMSYS.WM$NEXTVER_TABLE_NV_INDX 1 265 1
INDEX UNIQUE SCAN WMSYS.MODIFIED_TABLES_PK 1 62
/* Formatted on 2004/04/19 18:57 (Formatter Plus v4.8.0) */
UPDATE /*+ USE_NL(Z1) ROWID(Z1) */sig.sig_qua_img_lt z1
SET z1.nextver =
SYS.ltutil.subsversion
(z1.nextver,
SYS.ltutil.getcontainedverinrange (z1.nextver,
'SIG.SIG_QUA_IMG',
'NpCyPCX3dkOAHSuBMjGioQ==',
4574,
4575
4574
WHERE z1.ROWID IN (
(SELECT /*+ ORDERED USE_NL(T1) USE_NL(T2) USE_NL(J2) USE_NL(J3)
INDEX(T1 QIM_PK) INDEX(T2 SIG_QUA_IMG_PKI$)
INDEX(J2 WM$NEXTVER_TABLE_NV_INDX) INDEX(J3 MODIFIED_TABLES_PK) */
t2.ROWID
FROM (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j1,
sig.sig_qua_img_lt t1,
sig.sig_qua_img_lt t2,
wmsys.wm$nextver_table j2,
(SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j3
WHERE t1.VERSION = j1.VERSION
AND t1.ima_id = t2.ima_id
AND t1.qim_inf_esq_x_tile = t2.qim_inf_esq_x_tile
AND t1.qim_inf_esq_y_tile = t2.qim_inf_esq_y_tile
AND t2.nextver != '-1'
AND t2.nextver = j2.next_vers
AND j2.VERSION = j3.VERSION))Hello Vitor,
There are currently no known issues with version enabled tables that are partitioned. The merge operation may need to access all of the partitions of a table depending on the data that needs to be moved/copied from the child to the parent. This is the reason for the 'Partition Range All' step in the plan that you provided. The majority of the remaining steps are due to the hints that have been added, since this plan has provided the best performance for us in the past for this particular statement. If this is not the case for you, and you feel that another plan would yield better performance, then please let me know and I will take a look at it.
One suggestion would be to make sure that the table was been recently analyzed so that the optimizer has the most current data about the table.
Performance issues are very hard to fix without a reproducible test case, so it may be advisable to file a TAR if you continue to have significant performance issues with the mergeWorkspace operation.
Thank You,
Ben -
Performance issues with BAPI_PROJECT_MAINTAIN
Hi,
We are facing Performance issues with BAPI_PROJECT_MAINTAIN.Would like to know any suggestions for improving performance.
I would also like to know statistics regarding how much time is required to create a project with 3000 activities, 100 WBS etc.
RegardsYes, I have. But didnt find any one relevant. If you can share time reqd for particular number of objects or suggest any solutions.
Regards -
Performance issue with HRALXSYNC report..
HI,
I'm facing performance issue with the HRALXSYNC report. As this is Standard report, Can any body suggest me how to optimize the standard report..
Thanks in advance.
Saleem Javed
Moderator message: Please Read before Posting in the Performance and Tuning Forum, also look for existing SAP notes and/or send a support message to SAP.
Edited by: Thomas Zloch on Aug 23, 2011 4:17 PMSreedhar,
Thanks for you quick response. Indexes were not created for VBPA table. basis people tested by creating indexes and gave a report that it is taking more time with indexes than regular query optimizer. this is happening in the funtion forward_ag_selection.
select vbeln lifnr from vbpa
appending corresponding fields of table lt_select
where vbeln in ct_vbeln
and posnr eq posnr_initial
and parvw eq 'SP'
and lifnr in it_spdnr.
I don't see any issue with this query. I give more info later -
Performance Issue with VL06O report
Hi,
We are having performance issue with VL06O report, when run with forwarding agent. It is taking about an hour with forwarding agent. The issue is with VBPA table and we found one OSS note, but it is for old versions. ours is ECC 5.0. Can anybody know the solution? If you guys need more information, please ask me.
Thanks,
SuryaSreedhar,
Thanks for you quick response. Indexes were not created for VBPA table. basis people tested by creating indexes and gave a report that it is taking more time with indexes than regular query optimizer. this is happening in the funtion forward_ag_selection.
select vbeln lifnr from vbpa
appending corresponding fields of table lt_select
where vbeln in ct_vbeln
and posnr eq posnr_initial
and parvw eq 'SP'
and lifnr in it_spdnr.
I don't see any issue with this query. I give more info later -
Performance Issue Executing a BEx Query in Crystal Report E 4.0
Dear Forum
I'm working for a customer with big performance issue Executing a BEx Query in Crystal via transient universe.
When query is executed directly against BW via RSRT query returns results in under 2 seconds.
When executed in crystal, without the use of subreports multiple executions (calls to BICS_GET_RESULTS) are seen. Runtimes are as long as 60 seconds.
The Bex query is based on a multiprovider without ODS.
The RFC trace shows BICS connection problems, CS as BICS_PROV_GET_INITIAL_STATE takes a lot of time.
I checked the note 1399816 - Task name - prefix - RSDRP_EXECUTE_AT_QUERY_DISP, and itu2019s not applicable because the customer has the BI 7.01 SP 8 and it has already
domain RSDR0_TASKNAME_LONG in package RSDRC with the
description: 'BW Data Manager: Task name - 32 characters', data
type: CHAR; No. Characters: 32, decimal digits: 0
data element RSDR0_TASKNAME_LONG in package RSDRC with the
description 'BW Data Manager: Task name - 32 characters' and the
previously created domain.
as described on the message
Could you suggest me something to check, please?
Thanks en advance
Regards
RosaHi,
It would be great if you would quote the ADAPT and tell the audience when it is targetted for a fix.
Generally speaking, CR for Enteprise isn't as performant as WebI, because uptake was rather slow .. so i'm of the opinion that there is improvements to be gained. So please work with Support via OSS.
My onlt recommendations can be :
- Patch up to P2.12 in bi 4.0
- Define more default values on the Bex query variables.
- Implement this note in the BW 1593802 Performance optimization when loading query views
Regards,
H -
Performance issue with two unbanalnced hierarchies in a single report
Hi All
We are facing the performance issue with one of the report which houses two unbalanced hierarchies (having 18 levels) - skipped & ragged. Basically its a part of OBIAPPS financila analytics .
The query is below :
Could anyone let me know how to improve the performane. Any parameter that should be looked at while using unbalanced hierarchies.
WITH SAWITH0
AS ( SELECT SUM (T91707.OTHER_LOC_AMT) AS c1,
MAX (T314768.HIER2_CODE) AS c2,
MAX (T314768.HIER3_CODE) AS c3,
MAX (T314768.HIER4_CODE) AS c4,
MAX (T314768.HIER5_CODE) AS c5,
MAX (T314768.HIER6_CODE) AS c6,
MAX (T314768.HIER7_CODE) AS c7,
MAX (T314768.HIER8_CODE) AS c8,
MAX (T314768.HIER9_CODE) AS c9,
MAX (T314768.HIER10_CODE) AS c10,
MAX (T314768.HIER11_CODE) AS c11,
MAX (T314768.HIER12_CODE) AS c12,
MAX (T314768.HIER13_CODE) AS c13,
MAX (T314768.HIER14_CODE) AS c14,
MAX (T314768.HIER15_CODE) AS c15,
MAX (T314768.HIER16_CODE) AS c16,
MAX (T314768.HIER17_CODE) AS c17,
MAX (T314768.HIER18_CODE) AS c18,
MAX (T314768.HIER19_CODE) AS c19,
MAX (T314768.HIER20_CODE) AS c20,
T314768.HIER1_NAME AS c21,
T314768.HIER1_CODE AS c22,
T314914.HIER1_NAME AS c24,
T314914.HIER10_NAME AS c25,
T314914.HIER11_NAME AS c26,
T314914.HIER12_NAME AS c27,
T314914.HIER13_NAME AS c28,
T314914.HIER14_NAME AS c29,
T314914.HIER15_NAME AS c30,
T314914.HIER16_NAME AS c31,
T314914.HIER17_NAME AS c32,
T314914.HIER18_NAME AS c33,
T314914.HIER19_NAME AS c34,
T314914.HIER2_NAME AS c35,
T314914.HIER20_NAME AS c36,
T314914.HIER3_NAME AS c37,
T314914.HIER4_NAME AS c38,
T314914.HIER5_NAME AS c39,
T314914.HIER6_NAME AS c40,
T314914.HIER7_NAME AS c41,
T314914.HIER8_NAME AS c42,
T314914.HIER9_NAME AS c43,
T314914.HIER20_CODE AS c44,
T314914.HIER1_CODE AS c45,
T314914.HIER10_CODE AS c46,
T314914.HIER11_CODE AS c47,
T314914.HIER12_CODE AS c48,
T314914.HIER13_CODE AS c49,
T314914.HIER14_CODE AS c50,
T314914.HIER15_CODE AS c51,
T314914.HIER16_CODE AS c52,
T314914.HIER17_CODE AS c53,
T314914.HIER18_CODE AS c54,
T314914.HIER19_CODE AS c55,
T314914.HIER2_CODE AS c56,
T314914.HIER3_CODE AS c57,
T314914.HIER4_CODE AS c58,
T314914.HIER5_CODE AS c59,
T314914.HIER6_CODE AS c60,
T314914.HIER7_CODE AS c61,
T314914.HIER8_CODE AS c62,
T314914.HIER9_CODE AS c63
FROM W_HIERARCHY_D T314768 /* Dim_W_HIERARCHY_D_Segment11 */
W_GL_SEGMENT_D T315677 /* Dim_W_GL_SEGMENT_D_Segment11 */
W_HIERARCHY_D T314914 /* Dim_W_HIERARCHY_D_Segment13 */
W_GL_SEGMENT_D T315731 /* Dim_W_GL_SEGMENT_D_Segment13 */
W_GL_ACCOUNT_D T91397 /* Dim_W_GL_ACCOUNT_D */
W_GL_OTHER_F T91707 /* Fact_W_GL_OTHER_F */
WHERE ( T91397.ROW_WID = T91707.GL_ACCOUNT_WID
AND T91397.ACCOUNT_SEG11_CODE = T315677.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_CODE = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG11_ATTRIB = T315677.SEGMENT_LOV_ID
AND T91397.ACCOUNT_SEG13_ATTRIB = T315731.SEGMENT_LOV_ID
AND T314768.HIER_CODE = T315677.SEGMENT_LOV_ID
AND T314768.HIER_NAME = T315677.SEGMENT_LOV_NAME
AND T314768.HIERARCHY_ID = T315677.SEGMENT_VAL_CODE
AND T314914.HIER_CODE = T315731.SEGMENT_LOV_ID
AND T314914.HIER_NAME = T315731.SEGMENT_LOV_NAME
AND T314914.HIERARCHY_ID = T315731.SEGMENT_VAL_CODE
AND T315677.SEGMENT_LOV_NAME =
'Responsibility_Centre_Functional'
AND T315677.SEGMENT_LOV_ID = 1000163
AND T315731.SEGMENT_LOV_NAME = 'Account_Master'
AND T315731.SEGMENT_LOV_ID = 1000165
AND ( T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER11_CODE IS NULL)
AND (T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER12_CODE IS NULL)
AND ( T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER8_CODE IS NULL)
AND ( T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER9_CODE IS NULL)
AND ( T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER10_CODE IS NULL)
AND ( T314914.HIER1_CODE IN ('ALL_LI')
OR T314914.HIER2_CODE IN ('S000000001')
OR T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022'))
AND ( T314914.HIER2_CODE IN ('S000000001')
OR T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER2_CODE IS NULL)
AND ( T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER3_CODE IS NULL)
AND ( T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER4_CODE IS NULL)
AND ( T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER5_CODE IS NULL)
AND ( T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER6_CODE IS NULL)
AND ( T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER7_CODE IS NULL)
AND T314768.HIER1_CODE IS NOT NULL
AND T314914.HIER20_CODE IS NOT NULL
AND T314914.HIER13_CODE IS NULL
AND T314914.HIER14_CODE IS NULL
AND T314914.HIER15_CODE IS NULL
AND T314914.HIER16_CODE IS NULL
AND T314914.HIER17_CODE IS NULL
AND T314914.HIER18_CODE IS NULL
AND T314914.HIER19_CODE IS NULL)
GROUP BY T314768.HIER1_CODE,
T314768.HIER1_NAME,
T314914.HIER1_CODE,
T314914.HIER1_NAME,
T314914.HIER2_CODE,
T314914.HIER2_NAME,
T314914.HIER3_CODE,
T314914.HIER3_NAME,
T314914.HIER4_CODE,
T314914.HIER4_NAME,
T314914.HIER5_CODE,
T314914.HIER5_NAME,
T314914.HIER6_CODE,
T314914.HIER6_NAME,
T314914.HIER7_CODE,
T314914.HIER7_NAME,
T314914.HIER8_CODE,
T314914.HIER8_NAME,
T314914.HIER9_CODE,
T314914.HIER9_NAME,
T314914.HIER10_CODE,
T314914.HIER10_NAME,
T314914.HIER11_CODE,
T314914.HIER11_NAME,
T314914.HIER12_CODE,
T314914.HIER12_NAME,
T314914.HIER13_CODE,
T314914.HIER13_NAME,
T314914.HIER14_CODE,
T314914.HIER14_NAME,
T314914.HIER15_CODE,
T314914.HIER15_NAME,
T314914.HIER16_CODE,
T314914.HIER16_NAME,
T314914.HIER17_CODE,
T314914.HIER17_NAME,
T314914.HIER18_CODE,
T314914.HIER18_NAME,
T314914.HIER19_CODE,
T314914.HIER19_NAME,
T314914.HIER20_CODE,
T314914.HIER20_NAME),
SAWITH1
AS (SELECT SUM (D1.c1) OVER () AS c1,
MAX (D1.c2) OVER (PARTITION BY D1.c22) AS c2,
MAX (D1.c3) OVER (PARTITION BY D1.c22) AS c3,
MAX (D1.c4) OVER (PARTITION BY D1.c22) AS c4,
MAX (D1.c5) OVER (PARTITION BY D1.c22) AS c5,
MAX (D1.c6) OVER (PARTITION BY D1.c22) AS c6,
MAX (D1.c7) OVER (PARTITION BY D1.c22) AS c7,
MAX (D1.c8) OVER (PARTITION BY D1.c22) AS c8,
MAX (D1.c9) OVER (PARTITION BY D1.c22) AS c9,
MAX (D1.c10) OVER (PARTITION BY D1.c22) AS c10,
MAX (D1.c11) OVER (PARTITION BY D1.c22) AS c11,
MAX (D1.c12) OVER (PARTITION BY D1.c22) AS c12,
MAX (D1.c13) OVER (PARTITION BY D1.c22) AS c13,
MAX (D1.c14) OVER (PARTITION BY D1.c22) AS c14,
MAX (D1.c15) OVER (PARTITION BY D1.c22) AS c15,
MAX (D1.c16) OVER (PARTITION BY D1.c22) AS c16,
MAX (D1.c17) OVER (PARTITION BY D1.c22) AS c17,
MAX (D1.c18) OVER (PARTITION BY D1.c22) AS c18,
MAX (D1.c19) OVER (PARTITION BY D1.c22) AS c19,
MAX (D1.c20) OVER (PARTITION BY D1.c22) AS c20,
D1.c21 AS c21,
D1.c22 AS c22,
SUM (
D1.c1)
OVER (
PARTITION BY D1.c46,
D1.c47,
D1.c48,
D1.c49,
D1.c50,
D1.c51,
D1.c52,
D1.c53,
D1.c54,
D1.c55,
D1.c45,
D1.c44,
D1.c56,
D1.c57,
D1.c58,
D1.c59,
D1.c60,
D1.c61,
D1.c62,
D1.c63,
D1.c22)
AS c23,
D1.c24 AS c24,
D1.c25 AS c25,
D1.c26 AS c26,
D1.c27 AS c27,
D1.c28 AS c28,
D1.c29 AS c29,
D1.c30 AS c30,
D1.c31 AS c31,
D1.c32 AS c32,
D1.c33 AS c33,
D1.c34 AS c34,
D1.c35 AS c35,
D1.c36 AS c36,
D1.c37 AS c37,
D1.c38 AS c38,
D1.c39 AS c39,
D1.c40 AS c40,
D1.c41 AS c41,
D1.c42 AS c42,
D1.c43 AS c43,
D1.c44 AS c44,
D1.c45 AS c45,
D1.c46 AS c46,
D1.c47 AS c47,
D1.c48 AS c48,
D1.c49 AS c49,
D1.c50 AS c50,
D1.c51 AS c51,
D1.c52 AS c52,
D1.c53 AS c53,
D1.c54 AS c54,
D1.c55 AS c55,
D1.c56 AS c56,
D1.c57 AS c57,
D1.c58 AS c58,
D1.c59 AS c59,
D1.c60 AS c60,
D1.c61 AS c61,
D1.c62 AS c62,
D1.c63 AS c63
FROM SAWITH0 D1)
SELECT DISTINCT
38 AS c1,
D1.c24 AS c2,
D1.c25 AS c3,
D1.c26 AS c4,
D1.c27 AS c5,
D1.c28 AS c6,
D1.c29 AS c7,
D1.c30 AS c8,
D1.c31 AS c9,
D1.c32 AS c10,
D1.c33 AS c11,
D1.c34 AS c12,
D1.c35 AS c13,
D1.c36 AS c14,
D1.c37 AS c15,
D1.c38 AS c16,
D1.c39 AS c17,
D1.c40 AS c18,
D1.c41 AS c19,
D1.c42 AS c20,
D1.c43 AS c21,
D1.c21 AS c22,
NULL AS c23,
NULL AS c24,
NULL AS c25,
NULL AS c26,
NULL AS c27,
NULL AS c28,
NULL AS c29,
NULL AS c30,
NULL AS c31,
NULL AS c32,
NULL AS c33,
NULL AS c34,
NULL AS c35,
NULL AS c36,
NULL AS c37,
NULL AS c38,
NULL AS c39,
NULL AS c40,
NULL AS c41,
D1.c44 AS c42,
D1.c45 AS c43,
D1.c46 AS c44,
D1.c47 AS c45,
D1.c48 AS c46,
D1.c49 AS c47,
D1.c50 AS c48,
D1.c51 AS c49,
D1.c52 AS c50,
D1.c53 AS c51,
D1.c54 AS c52,
D1.c55 AS c53,
D1.c56 AS c54,
D1.c57 AS c55,
D1.c58 AS c56,
D1.c59 AS c57,
D1.c60 AS c58,
D1.c61 AS c59,
D1.c62 AS c60,
D1.c63 AS c61,
NULL AS c62,
D1.c22 AS c63,
NULL AS c64,
NULL AS c65,
NULL AS c66,
NULL AS c67,
NULL AS c68,
NULL AS c69,
NULL AS c70,
NULL AS c71,
NULL AS c72,
NULL AS c73,
NULL AS c74,
NULL AS c75,
NULL AS c76,
NULL AS c77,
NULL AS c78,
NULL AS c79,
NULL AS c80,
NULL AS c81,
D1.c23 AS c82,
CASE WHEN 1 = 1 THEN 1 ELSE 0 END AS c83,
CASE
WHEN D1.c2 IS NULL
AND D1.c3 IS NULL
AND D1.c4 IS NULL
AND D1.c5 IS NULL
AND D1.c6 IS NULL
AND D1.c7 IS NULL
AND D1.c8 IS NULL
AND D1.c9 IS NULL
AND D1.c10 IS NULL
AND D1.c11 IS NULL
AND D1.c12 IS NULL
AND D1.c13 IS NULL
AND D1.c14 IS NULL
AND D1.c15 IS NULL
AND D1.c16 IS NULL
AND D1.c17 IS NULL
AND D1.c18 IS NULL
AND D1.c19 IS NULL
AND D1.c20 IS NULL
THEN
1
ELSE
0
END
AS c84
FROM SAWITH1 D1
WHERE ( D1.c44 IS NOT NULL
AND D1.c50 IS NULL
AND D1.c49 IS NULL
AND D1.c22 IS NOT NULL
AND D1.c51 IS NULL
AND D1.c52 IS NULL
AND D1.c53 IS NULL
AND D1.c54 IS NULL
AND D1.c55 IS NULL)
/* Formatted on 12/17/2012 7:49:44 PM (QP5 v5.139.911.3011) */
WITH OBICOMMON0
AS (SELECT T156337.ROW_WID AS c2,
T156337.MCAL_PERIOD_WID AS c3,
ROW_NUMBER ()
OVER (PARTITION BY T156337.MCAL_PERIOD_WID
ORDER BY T156337.MCAL_PERIOD_WID DESC)
AS c4,
T156337.MCAL_PERIOD_NAME AS c5,
T156337.MCAL_PER_NAME_YEAR AS c6
FROM W_MCAL_DAY_D T156337 /* Dim_W_MCAL_DAY_D_Fiscal_Day */
WHERE (T156337.MCAL_CAL_NAME = 'Accounting')),
SAWITH0
AS (SELECT CASE
WHEN CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END
IS NOT NULL
THEN
RANK ()
OVER (
ORDER BY
CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END ASC NULLS LAST)
END
AS c1,
D1.c2 AS c2,
D1.c3 AS c3
FROM OBICOMMON0 D1),
SAWITH1
AS (SELECT DISTINCT
MIN (D1.c1) OVER (PARTITION BY D1.c3) AS c1, D1.c2 AS c2
FROM SAWITH0 D1),
SAWITH2
AS (SELECT CASE
WHEN CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END
IS NOT NULL
THEN
RANK ()
OVER (
ORDER BY
CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END ASC NULLS LAST)
END
AS c1,
D1.c3 AS c2,
D1.c5 AS c3,
D1.c6 AS c4
FROM OBICOMMON0 D1),
SAWITH3 AS (SELECT DISTINCT MIN (D1.c1) OVER (PARTITION BY D1.c2) AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4
FROM SAWITH2 D1),
SAWITH4
AS ( SELECT SUM (T91707.TD_OTHER_REP_AMT) AS c1,
T314914.HIER1_NAME AS c2,
D2.c3 AS c3,
T314914.HIER1_CODE AS c4,
D2.c2 AS c5
FROM W_HIERARCHY_D T314914 /* Dim_W_HIERARCHY_D_Segment13 */
W_GL_SEGMENT_D T315731 /* Dim_W_GL_SEGMENT_D_Segment13 */
W_GL_ACCOUNT_D T91397 /* Dim_W_GL_ACCOUNT_D */
W_GL_OTHER_F T91707 /* Fact_W_GL_OTHER_F */
SAWITH1 D4,
SAWITH3 D2
WHERE ( T314914.HIER_CODE = T315731.SEGMENT_LOV_ID
AND T314914.HIER_NAME = T315731.SEGMENT_LOV_NAME
AND T91397.ROW_WID = T91707.GL_ACCOUNT_WID
AND T91707.ACCT_PERIOD_END_DT_WID = D4.c2
AND T314914.HIERARCHY_ID = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_CODE = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_ATTRIB = T315731.SEGMENT_LOV_ID
AND T315731.SEGMENT_LOV_NAME =
'Account_Retail_Distribution'
AND T315731.SEGMENT_LOV_ID = 1000165
AND D2.c1 = D4.c1
AND (D2.c4 IN ('2011', '2012')))
GROUP BY T314914.HIER1_CODE,
T314914.HIER1_NAME,
D2.c2,
D2.c3)
SELECT D1.c1 AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4,
D1.c5 AS c5,
D1.c6 AS c6
FROM ( SELECT DISTINCT 0 AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4,
D1.c1 AS c5,
D1.c5 AS c6
FROM SAWITH4 D1
ORDER BY c2 NULLS FIRST, c4 NULLS FIRST, c3) D1
WHERE ROWNUM <= 65001Hello Gurus, Experts
Any help/tips here ... -
Performance issue with using MAX function in pl/sql
Hello All,
We are having a performance issue with the below logic wherein MAX is being used in order to get the latest instance/record for a given input variable ( p_in_header_id).. the item_key is having the format as :
p_in_header_id - <number generated from a sequence>
This query to fetch even 1 record takes around 1 minutes 30 sec..could someone please help if there is a better way to form this logic & to improve performance in this case.
We want to get the latest record for the item_key ( this we are getting using MAX (begin_date)) for a given p_in_header_id value.
Query 1 :
SELECT item_key FROM wf_items WHERE item_type = 'xxxxzzzz'
AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id
AND root_activity ='START_REQUESTS'
AND begin_date =
(SELECT MAX (begin_date) FROM wf_items WHERE item_type = 'xxxxzzzz'
AND root_activity ='START_REQUESTS'
AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id);
Could someone please help us with this performance issue..we are really stuck because of this
regardsFirst of all Thanks to all gentlemen who replied ..many thanks ...
Tried the ROW_NUMBER() option but still it is taking time...have given output for the query and tkprof results as well. Even when it doesn't fetch any record ( this is a valid cased because the input header id doesn't have any workflow request submitted & hence no entry in the wf_items table)..then also see the time it has taken.
Looked at the RANK & DENSE_RANK options which were suggested..but it is still taking time..
Any further suggestions or ideas as to how this could be resolved..
SELECT 'Y', 'Y', ITEM_KEY
FROM
( SELECT ITEM_KEY, ROW_NUMBER() OVER(ORDER BY BEGIN_DATE DESC) RN FROM
WF_ITEMS WHERE ITEM_TYPE = 'xxxxzzzz' AND ROOT_ACTIVITY = 'START_REQUESTS'
AND SUBSTR(ITEM_KEY,1,INSTR(ITEM_KEY,'-') - 1) = :B1
) T WHERE RN <= 1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 1.57 0 0 0 0
Fetch 1 8700.00 544968.73 8180 8185 0 0
total 2 8700.00 544970.30 8180 8185 0 0
many thanks -
SAP DS 1.3: Performance issues with crosstab planning (IE only)
Hi everyone,
because im currently developing a custom component for DS 1.3, I got in touch with the planning feature of design studio. Planning currently only works in a crosstab.
Here I recognized a significant performance issue with the internet explorer:
If you simply type in a new value into a cell in a crosstab, it takes ~10s to confirm it (not constant! Sometimes it takes 2s, sometimes 15s). During this 10s, it seems like the IE crashed - no response at all. Sometimes there is also a warning message on bottom ('... script is slowing down the application ...').
Tested the same scenario with Chrome and FF - takes less than 1s to confirm.
Whats going on here ...? Anyone experienced the same issues?
My testing environment:
Windows 8.1
IE 11 (also tested emulated Ie 10 and IE 9 - same problem)
DS 1.3.0.3.201405141058
Local mode
Application only contained a simple crosstab, data source based on BW 7.3 query
Of course I deactivated all custom components while testing...
Kind regards
WladimirHi Tammy,
Thanks for your reply. Of course, my IE is updated to latest version (11.0.9600.17207).
Hopefully SP1 will fix this bug...
Kind regards
Wladimir -
Performance issue with a Custom view
Hi ,
I am pretty new to performance tuning and facing a performance issue with a custom view.
Execution time for view query is good but as soon as I append a where caluse to view query ,the execution time increases.
Below is the view query:
CREATE OR REPLACE XXX_INFO_VIEW AS
SELECT csb.system_id license_id,
cst.name license_number ,
csb.system_type_code license_type ,
csb.attribute3 lac , -- license authorization code
csb.attribute6 lat , -- license admin token
csb.attribute12 ols_reg, -- OLS Registration allowed flag
l.attribute4 license_biz_type ,
NVL (( SELECT 'Y' l_supp_flag
FROM csi_item_instances cii,
okc_k_lines_b a,
okc_k_items c
WHERE c.cle_id = a.id
AND a.lse_id = 9
AND c.jtot_object1_code = 'OKX_CUSTPROD'
AND c.object1_id1 = cii.instance_id||''
AND cii.instance_status_id IN (3, 510)
AND cii.system_id = csb.system_id
AND a.sts_code IN ('SIGNED', 'ACTIVE')
AND NVL (a.date_terminated, a.end_date) > SYSDATE
AND ROWNUM < 2), 'N') active_supp_flag,
hp.party_name "Customer_Name" , -- Customer Name
hca.attribute12 FGE_FLAG,
(SELECT /*+INDEX (oklt OKC_K_LINES_TL_U1) */
nvl(max((decode(name, 'eSupport','2','Enterprise','1','Standard','1','TERM RTU','0','TERM RTS','0','Notfound'))),0) covName --TERM RTU and TERM RTS added as per Vijaya's suggestion APR302013
FROM OKC_K_LINES_B oklb1,
OKC_K_LINES_TL oklt,
OKC_K_LINES_B oklb2,
OKC_K_ITEMS oki,
CSI_item_instances cii
WHERE
OKI.JTOT_OBJECT1_CODE = 'OKX_CUSTPROD'
AND oklb1.id=oklt.id
AND OKI.OBJECT1_ID1 =cii.instance_id||''
AND Oklb1.lse_id=2
AND oklb1.dnz_chr_id=oklb2.dnz_chr_id
AND oklb2.lse_id=9
AND oki.CLE_ID=oklb2.id
AND cii.system_id=csb.system_id
AND oklt.LANGUAGE=USERENV ('LANG')) COVERAGE_TYPE
FROM csi_systems_b csb ,
csi_systems_tl cst ,
hz_cust_accounts hca,
hz_parties hp,
fnd_lookup_values l
WHERE csb.system_type_code = l.lookup_code (+)
AND csb.system_id = cst.system_id
AND hca.cust_account_id =csb.customer_id
AND hca.party_id= hp.party_id
AND cst.language = USERENV ('LANG')
AND l.lookup_type (+) = 'CSI_SYSTEM_TYPE'
AND l.language (+) = USERENV ('LANG')
AND NVL (csb.end_date_active, SYSDATE+1) > SYSDATE)
I have forced an index to avoid Full table scan on OKC_K_LINES_TL and suppressed an index on CSI_item_instances.instance id to make the view query fast.
So when i do select * from XXX_INFO_VIEWit executes in a decent time,But when I try to do
select * from XXX_INFO_VIEW where active_supp_flag='Y' and coverage_type='1'
it takes lot of time.
Execution plan is same for both queries in terms of cost but with WHERE clause Number of bytes increases.
Below are the execution plans:
View query:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
10 COUNT STOPKEY
9 NESTED LOOPS
7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
28 SORT AGGREGATE Bytes: 169 Cardinality: 1
27 NESTED LOOPS
25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
41 NESTED LOOPS
39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
35 HASH JOIN
33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918
Execution plan for view query with WHERE clause:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
10 COUNT STOPKEY
9 NESTED LOOPS
7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
28 SORT AGGREGATE Bytes: 169 Cardinality: 1
27 NESTED LOOPS
25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
44 VIEW VIEW APPS.WRS_LICENSE_INFO_V Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
41 NESTED LOOPS
39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
35 HASH JOIN
33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918Hi,
You should always try using primary index fields, if not possible then secondary index fields.
Even if you cannot do anything from either of the two then try this,
Use Less distinct fields on the top.
In your case , you can use bukrs ,gjahr ,werks on the top in the where condition..then followed by less distinct values..
Even when you use secondary index if you have 4 fields in your sec index and you are using only two fields from the top then the index is useful only upto that two fields provided they are in sequence.
Maybe you are looking for
-
This is terrible. I need all of these contacts back. Is there a way to revert to a previous state on my phone/icloud/computer?
-
How to search with multiple constraints in the new java API?
I'm having a problem using the new MDM API to do searches with multiple constraints. Here are the classes I'm trying to use, and the scenario I'm trying to implement: Classes: SearchItem: Interface SearchGroup: implements SearchItem, empty construct
-
Unable to complete step 2 (drag icon into applications folder) when upgrading Firefox
I am trying to upgrade from Firefox 3.6.11 to 3.6.12. Step 2 of the process says "Drag the Firefox icon into your applications icon. First problem: I don't have an applications icon. Second problem, being creative I open Finder on my Mac and try to d
-
Hello, The thumbnails in the list view of the project panel are so small that I need a magnifying glass to see the picture. In the setup I have already selected the large icon. To see something, this thumbnail has to be minimum twice the size of the
-
Time management status and Payroll
Experts, We are using TMS as 9 (Time evaluation of planned time) in IT0007. What does it mean in TM? What is it's impact in Payroll. Regards Sk Edited by: s k on Nov 17, 2008 10:24 AM