Query performance decreases dramatically after replacing equal clause
I have a Select statement that performs well as long as I join the project code to a fixed value in the WHERE clause.
But when this fixed value is replaced by a sub SELECT (which in fact retrieves that same fixed value) the result of the query takes 5 minutes longer.
It's Oracle 8i database.
It's not clear to me why Oracle follows a complete other execution plan and also introduces a lot of FULL table scans with such a minor change
Select statement and explain plan with fixed value in WHERE
SELECT PVN.PJT_CODE PJT_CODE
, L_PJT.DESCRIPTION PJT_DESCRIPTION
, PVN.CODE VERSION
, PVN.DESCRIPTION VERSION_DESCRIPTION
-- , NVL(L_PJT.EXRATE_TENDER, 1) EXRATE_TENDER
, KBA.BQI_CODE BOQ_ITEM
, KBA.BQI_DESCRIPTION BOQ_ITEM_DESCRIPTION
, KBA.BQI_QUANTITY BOQ_ITEM_PAID_QUANTITY
, KBA.BQI_UNIT BOQ_ITEM_UNIT
-- , KBA.PVN_CODE PVN_CODE1
-- , KBA.PJT_CODE PJT_CODE2
, KGW.ACT_CODE ACT_CODE
, KGW.DESCRIPTION ACT_DESCRIPTION
, ROUND(KGW.EXECUTED) ACT_EXECUTED_QUANTITY
, KGW.UNIT_EXEC ACT_EXECUTED_UNIT
, ROUND(KGW.PAID) ACT_PAID_QUANTITY
, NVL(KGW.UNIT_PAID, KGW.UNIT_EXEC) ACT_PAID_UNIT
, KGW.HOURS_WEEK ACT_HOURS_WEEK
, KGW.PROD_HOUR ACT_PROD_HOUR
, KGW.HOURS_WEEK * KGW.PROD_HOUR ACT_PROD_WEEK
, NVL(KGW.WEEKS, 1) ACT_TOTAL_WEEKS -- WKUI: NVL, 1 toepassen.
, KGW.MY_CODE ACT_MY_CODE
, NVL(L_EQT.DESCRIPTION, WCS.DESCRIPTION) WCS_DESCRIPTION
, IAE.WCA_PJT_CODE WCA_PJT_CODE
, IAE.WCA_CODE WCA_CODE
, IAE.QUANTITY QUANTITY
, IAE.STANDBY_IDLE
, WCS.CODE WCS_CODE
, WCS.SQT_CODE WCS_SQT_CODE
, WCA.WCA_TYPE
, Kcs_Bqm_Dml.calc_wcs_costs
( iae.wca_pjt_code
, wcs.code
, kgw.hours_week
, iae.standby_idle
, iae.quantity
, wcs.sqt_code
, Kcs_Bqm_Dml.calc_working_weeks ( kgw.my_code
, kgw.pjt_code
, kgw.act_code
, kgw.pvn_code
FROM KCS_PROJECT_VERSIONS PVN
, PRR_PROJECTS L_PJT
, KCS_BOQ_ACT_VW KBA
, KCS_GAY_WCA_VW KGW
, KCS_INTS_WCA_WCS IAE
, KCS_WEEKLY_COST_ACTIVITIES WCA
, KCS_WEEKLY_COST_SPECIFICATIONS WCS
, KCS_EQUIPMENT L_EQT
WHERE PVN.PJT_CODE = L_PJT.CODE
AND L_PJT.CODE IN ( '04.748' )
AND PVN.CODE = 'A'
AND KBA.PJT_CODE = PVN.PJT_CODE
AND KBA.PVN_CODE = PVN.CODE
AND KGW.PJT_CODE = PVN.PJT_CODE
AND KGW.PVN_CODE = PVN.CODE
AND KGW.BQI_CODE = KBA.BQI_CODE
AND KGW.ACT_CODE = WCA.CODE
AND KGW.PJT_CODE = WCA.PJT_CODE
AND IAE.WCS_CODE = WCS.CODE
AND IAE.WCS_PJT_CODE = WCS.PJT_CODE
AND WCS.EQT_CODE = L_EQT.CODE (+)
AND WCA.PJT_CODE = IAE.WCS_PJT_CODE
AND WCA.CODE = IAE.WCA_CODE
AND WCA.WCA_TYPE = 'PAY'
ORDER BY PVN.PJT_CODE
, PVN.CODE
, KBA.BQI_CODE
, KGW.ACT_CODE
, wcs.codeFast explain plan: OKAY
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 1 270
SORT ORDER BY 1 328 270
NESTED LOOPS OUTER 1 328 269
NESTED LOOPS 1 313 268
HASH JOIN 1 259 116
HASH JOIN 4 528 89
NESTED LOOPS 28 3 K 78
NESTED LOOPS 23 2 K 9
NESTED LOOPS 1 58 3
TABLE ACCESS BY INDEX ROWID PRR.PRR_PROJECTS 1 26 2
INDEX UNIQUE SCAN PRR.PRR_PJT_PK 1 1
TABLE ACCESS BY INDEX ROWID KCS.KCS_PROJECT_VERSIONS 1 32 1
INDEX UNIQUE SCAN KCS.KCS_PVN_PK 1
TABLE ACCESS BY INDEX ROWID KCS.KCS_WEEKLY_COST_SPECIFICATIONS 23 897 6
INDEX RANGE SCAN KCS.KCS_WCS_PJT_FK 23 2
TABLE ACCESS BY INDEX ROWID KCS.KCS_INTS_WCA_WCS 124 2 K 3
INDEX RANGE SCAN KCS.KCS_IAE_WCS_FK 124 2
TABLE ACCESS BY INDEX ROWID KCS.KCS_WEEKLY_COST_ACTIVITIES 18 234 10
INDEX RANGE SCAN KCS.KCS_WCA_PJT_FK 18 3
VIEW KCS.KCS_GAY_WCA_VW 3 381 27
SORT UNIQUE 3 229 27
UNION-ALL
NESTED LOOPS 1 75 9
NESTED LOOPS 1 72 9
NESTED LOOPS 1 58 7
TABLE ACCESS BY INDEX ROWID KCS.KCS_GENERAL_ACTIVITIES 1 45 4
INDEX RANGE SCAN KCS.KCS_GAY_PK 1 3
TABLE ACCESS BY INDEX ROWID KCS.KCS_GENERAL_SPECIFICATIONS 4 52 3
INDEX RANGE SCAN KCS.KCS_GSN_GAY_FK 4 2
INDEX RANGE SCAN KCS.KCS_ISC_GSN_FK 5 70 2
INDEX UNIQUE SCAN KCS.KCS_SCG_PK 20 60
NESTED LOOPS 1 66 5
NESTED LOOPS 1 63 5
TABLE ACCESS BY INDEX ROWID KCS.KCS_INTS_GAY_SCT 1 18 3
INDEX RANGE SCAN KCS.KCS_IAC_GAY_FK 1 2
TABLE ACCESS BY INDEX ROWID KCS.KCS_GENERAL_ACTIVITIES 1 45 2
INDEX UNIQUE SCAN KCS.KCS_GAY_PK 1 1
INDEX UNIQUE SCAN KCS.KCS_SCG_PK 20 60
NESTED LOOPS 1 88 7
NESTED LOOPS 1 84 6
TABLE ACCESS BY INDEX ROWID KCS.KCS_INTS_WCA_PVN 1 22 4
INDEX RANGE SCAN KCS.KCS_IAV_PVN_FK 1 3
TABLE ACCESS BY INDEX ROWID KCS.KCS_WEEKLY_COST_ACTIVITIES 71 K 4 M 2
INDEX UNIQUE SCAN KCS.KCS_WCA_PK 71 K 1
TABLE ACCESS BY INDEX ROWID KCS.KCS_SYS_COST_GROUP 20 80 1
INDEX UNIQUE SCAN KCS.KCS_SCG_PK 20
VIEW KCS.KCS_BOQ_ACT_VW 2 108
SORT UNIQUE 2 102 153
UNION-ALL
NESTED LOOPS 1 51 113
TABLE ACCESS BY INDEX ROWID KCS.KCS_BOQ_ITEMS 27 1 K 5
INDEX RANGE SCAN KCS.KCS_BQI_PJT_FK 27 3
TABLE ACCESS BY INDEX ROWID KCS.KCS_GENERAL_ACTIVITIES 1 12 4
INDEX RANGE SCAN KCS.KCS_GAY_BQI_FK 1 2
NESTED LOOPS 1 51 36
TABLE ACCESS BY INDEX ROWID KCS.KCS_INTS_WCA_PVN 1 12 34
INDEX RANGE SCAN KCS.KCS_IAV_BQI_FK 1 3
TABLE ACCESS BY INDEX ROWID KCS.KCS_BOQ_ITEMS 27 1 K 2
INDEX UNIQUE SCAN KCS.KCS_BQI_PK 27 1
TABLE ACCESS BY INDEX ROWID KCS.KCS_EQUIPMENT 1 K 17 K 1
INDEX UNIQUE SCAN KCS.KCS_EQT_PK 1 K Select statement and explain plan with subselect in WHERE
SELECT PVN.PJT_CODE PJT_CODE
, L_PJT.DESCRIPTION PJT_DESCRIPTION
, PVN.CODE VERSION
, PVN.DESCRIPTION VERSION_DESCRIPTION
-- , NVL(L_PJT.EXRATE_TENDER, 1) EXRATE_TENDER
, KBA.BQI_CODE BOQ_ITEM
, KBA.BQI_DESCRIPTION BOQ_ITEM_DESCRIPTION
, KBA.BQI_QUANTITY BOQ_ITEM_PAID_QUANTITY
, KBA.BQI_UNIT BOQ_ITEM_UNIT
-- , KBA.PVN_CODE PVN_CODE1
-- , KBA.PJT_CODE PJT_CODE2
, KGW.ACT_CODE ACT_CODE
, KGW.DESCRIPTION ACT_DESCRIPTION
, ROUND(KGW.EXECUTED) ACT_EXECUTED_QUANTITY
, KGW.UNIT_EXEC ACT_EXECUTED_UNIT
, ROUND(KGW.PAID) ACT_PAID_QUANTITY
, NVL(KGW.UNIT_PAID, KGW.UNIT_EXEC) ACT_PAID_UNIT
, KGW.HOURS_WEEK ACT_HOURS_WEEK
, KGW.PROD_HOUR ACT_PROD_HOUR
, KGW.HOURS_WEEK * KGW.PROD_HOUR ACT_PROD_WEEK
, NVL(KGW.WEEKS, 1) ACT_TOTAL_WEEKS -- WKUI: NVL, 1 toepassen.
, KGW.MY_CODE ACT_MY_CODE
, NVL(L_EQT.DESCRIPTION, WCS.DESCRIPTION) WCS_DESCRIPTION
, IAE.WCA_PJT_CODE WCA_PJT_CODE
, IAE.WCA_CODE WCA_CODE
, IAE.QUANTITY QUANTITY
, IAE.STANDBY_IDLE
, WCS.CODE WCS_CODE
, WCS.SQT_CODE WCS_SQT_CODE
, WCA.WCA_TYPE
, Kcs_Bqm_Dml.calc_wcs_costs
( iae.wca_pjt_code
, wcs.code
, kgw.hours_week
, iae.standby_idle
, iae.quantity
, wcs.sqt_code
, Kcs_Bqm_Dml.calc_working_weeks ( kgw.my_code
, kgw.pjt_code
, kgw.act_code
, kgw.pvn_code
FROM KCS_PROJECT_VERSIONS PVN
, PRR_PROJECTS L_PJT
, KCS_BOQ_ACT_VW KBA
, KCS_GAY_WCA_VW KGW
, KCS_INTS_WCA_WCS IAE
, KCS_WEEKLY_COST_ACTIVITIES WCA
, KCS_WEEKLY_COST_SPECIFICATIONS WCS
, KCS_EQUIPMENT L_EQT
WHERE PVN.PJT_CODE = L_PJT.CODE
AND L_PJT.CODE = (SELECT EMP.PJT_CODE FROM PRR_EMPLOYEES EMP WHERE EMP.INITIALS = USER) /* <-- This is the only difference with previous query, columns are indexed, and result is same as dixed value */
AND PVN.CODE = 'A'
AND KBA.PJT_CODE = PVN.PJT_CODE
AND KBA.PVN_CODE = PVN.CODE
AND KGW.PJT_CODE = PVN.PJT_CODE
AND KGW.PVN_CODE = PVN.CODE
AND KGW.BQI_CODE = KBA.BQI_CODE
AND KGW.ACT_CODE = WCA.CODE
AND KGW.PJT_CODE = WCA.PJT_CODE
AND IAE.WCS_CODE = WCS.CODE
AND IAE.WCS_PJT_CODE = WCS.PJT_CODE
AND WCS.EQT_CODE = L_EQT.CODE (+)
AND WCA.PJT_CODE = IAE.WCS_PJT_CODE
AND WCA.CODE = IAE.WCA_CODE
AND WCA.WCA_TYPE = 'PAY'
ORDER BY PVN.PJT_CODE
, PVN.CODE
, KBA.BQI_CODE
, KGW.ACT_CODE
, wcs.codeExpensive explain plan BAD
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 1 5052
SORT ORDER BY 1 328 5052
NESTED LOOPS OUTER 1 328 5051
NESTED LOOPS 1 313 5050
NESTED LOOPS 1 274 5048
NESTED LOOPS 1 252 4677
NESTED LOOPS 1 239 4675
NESTED LOOPS 1 185 3418
NESTED LOOPS 1 58 3
TABLE ACCESS BY INDEX ROWID PRR.PRR_PROJECTS 1 26 2
INDEX UNIQUE SCAN PRR.PRR_PJT_PK 1 1
TABLE ACCESS BY INDEX ROWID PRR.PRR_EMPLOYEES 1 7 1
INDEX UNIQUE SCAN PRR.PRR_EME_PK 2
TABLE ACCESS BY INDEX ROWID KCS.KCS_PROJECT_VERSIONS 41 1 K 1
INDEX UNIQUE SCAN KCS.KCS_PVN_PK 41
VIEW KCS.KCS_GAY_WCA_VW 471 58 K
SORT UNIQUE 471 40 K 3416
UNION-ALL
NESTED LOOPS 1 75 2143
NESTED LOOPS 6 366 2131
HASH JOIN 6 348 2131
TABLE ACCESS FULL KCS.KCS_GENERAL_ACTIVITIES 713 31 K 558
INDEX FAST FULL SCAN KCS.KCS_GSN_PK 5 K 74 K 1546
INDEX UNIQUE SCAN KCS.KCS_SCG_PK 20 60
INDEX RANGE SCAN KCS.KCS_ISC_GSN_FK 6 K 91 K 2
NESTED LOOPS 1 66 298
NESTED LOOPS 1 63 298
TABLE ACCESS FULL KCS.KCS_INTS_GAY_SCT 131 2 K 36
TABLE ACCESS BY INDEX ROWID KCS.KCS_GENERAL_ACTIVITIES 713 31 K 2
INDEX UNIQUE SCAN KCS.KCS_GAY_PK 713 1
INDEX UNIQUE SCAN KCS.KCS_SCG_PK 20 60
HASH JOIN 469 40 K 955
TABLE ACCESS FULL KCS.KCS_SYS_COST_GROUP 20 80 1
HASH JOIN 469 38 K 952
TABLE ACCESS FULL KCS.KCS_INTS_WCA_PVN 420 9 K 169
TABLE ACCESS FULL KCS.KCS_WEEKLY_COST_ACTIVITIES 71 K 4 M 490
VIEW KCS.KCS_BOQ_ACT_VW 1 K 62 K
SORT UNIQUE 1 K 59 K 1258
UNION-ALL
HASH JOIN 748 37 K 847
TABLE ACCESS FULL KCS.KCS_GENERAL_ACTIVITIES 713 8 K 558
TABLE ACCESS FULL KCS.KCS_BOQ_ITEMS 51 K 1 M 107
HASH JOIN 440 21 K 385
TABLE ACCESS FULL KCS.KCS_INTS_WCA_PVN 420 4 K 169
TABLE ACCESS FULL KCS.KCS_BOQ_ITEMS 51 K 1 M 107
TABLE ACCESS BY INDEX ROWID KCS.KCS_WEEKLY_COST_ACTIVITIES 35 K 454 K 2
INDEX UNIQUE SCAN KCS.KCS_WCA_PK 35 K 1
TABLE ACCESS FULL KCS.KCS_INTS_WCA_WCS 270 K 5 M 371
TABLE ACCESS BY INDEX ROWID KCS.KCS_WEEKLY_COST_SPECIFICATIONS 74 K 2 M 2
INDEX UNIQUE SCAN KCS.KCS_WCS_PK 74 K 1
TABLE ACCESS BY INDEX ROWID KCS.KCS_EQUIPMENT 1 K 17 K 1
INDEX UNIQUE SCAN KCS.KCS_EQT_PK 1 K I hope someone can give a clue
Thanks in advance
Auke Quist
In order to get more helpfull messages i used utlxpls.sql to format the plan table:
First the query where I hardcoded the assignment of the project code (this leads to fast result in 841 msecs)
Query with_assigned_project:
SELECT PVN.PJT_CODE PJT_CODE
, L_PJT.DESCRIPTION PJT_DESCRIPTION
, PVN.CODE VERSION
, PVN.DESCRIPTION VERSION_DESCRIPTION
, KBA.BQI_CODE BOQ_ITEM
, KBA.BQI_DESCRIPTION BOQ_ITEM_DESCRIPTION
, KBA.BQI_QUANTITY BOQ_ITEM_PAID_QUANTITY
, KBA.BQI_UNIT BOQ_ITEM_UNIT
, KGW.ACT_CODE ACT_CODE
, KGW.DESCRIPTION ACT_DESCRIPTION
, ROUND(KGW.EXECUTED) ACT_EXECUTED_QUANTITY
, KGW.UNIT_EXEC ACT_EXECUTED_UNIT
, ROUND(KGW.PAID) ACT_PAID_QUANTITY
, NVL(KGW.UNIT_PAID, KGW.UNIT_EXEC) ACT_PAID_UNIT
, KGW.HOURS_WEEK ACT_HOURS_WEEK
, KGW.PROD_HOUR ACT_PROD_HOUR
, KGW.HOURS_WEEK * KGW.PROD_HOUR ACT_PROD_WEEK
, NVL(KGW.WEEKS, 1) ACT_TOTAL_WEEKS -- WKUI: NVL, 1 toepassen.
, KGW.MY_CODE ACT_MY_CODE
FROM KCS_PROJECT_VERSIONS PVN
, KCS_BOQ_ACT_VW KBA
, KCS_GAY_WCA_VW KGW
, PRR_PROJECTS L_PJT
WHERE PVN.PJT_CODE = L_PJT.CODE
AND L_PJT.CODE = '04.748'
AND KBA.PJT_CODE = PVN.PJT_CODE
AND KBA.PVN_CODE = PVN.CODE
AND KGW.PJT_CODE = PVN.PJT_CODE
AND KGW.PVN_CODE = PVN.CODE
AND KGW.BQI_CODE = KBA.BQI_CODE
ORDER BY PVN.PJT_CODE
, PVN.CODE
, KBA.BQI_CODE
, KGW.ACT_CODE;The explain plan is OKAY and looks like:
Plan Table
| Operation | Name | Rows | Bytes| Cost | Pstart| Pstop |
| SELECT STATEMENT | | 1 | 242 | 212 | | |
| SORT ORDER BY | | 1 | 242 | 212 | | |
| NESTED LOOPS | | 1 | 242 | 211 | | |
| HASH JOIN | | 1 | 115 | 94 | | |
| NESTED LOOPS | | 3 | 183 | 5 | | |
| TABLE ACCESS BY INDEX ROWID |PRR_PROJECTS | 1 | 26 | 2 | | |
| INDEX UNIQUE SCAN |PRR_PJT_PK | 1 | | 1 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_PROJECT_VERSIONS | 3 | 105 | 3 | | |
| INDEX RANGE SCAN |KCS_PVN_PJT_FK | 3 | | 1 | | |
| VIEW |KCS_BOQ_ACT_VW | 30 | 1K| 89 | | |
| SORT UNIQUE | | 30 | 1K| 89 | | |
| UNION-ALL | | | | | | |
| NESTED LOOPS | | 15 | 885 | 64 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_BOQ_ITEMS | 15 | 660 | 4 | | |
| INDEX RANGE SCAN |KCS_BQI_PJT_FK | 15 | | 3 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_GENERAL_ACTIVITIES | 50 | 750 | 4 | | |
| INDEX RANGE SCAN |KCS_GAY_BQI_FK | 50 | | 2 | | |
| HASH JOIN | | 15 | 885 | 21 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_BOQ_ITEMS | 15 | 660 | 4 | | |
| INDEX RANGE SCAN |KCS_BQI_PJT_FK | 15 | | 3 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_INTS_WCA_PVN | 31 | 465 | 16 | | |
| INDEX RANGE SCAN |KCS_IAV_BQI_FK | 31 | | 3 | | |
| VIEW |KCS_GAY_WCA_VW | 33 | 4K| | | |
| SORT UNIQUE | | 33 | 3K| 118 | | |
| UNION-ALL | | | | | | |
| NESTED LOOPS | | 1 | 90 | 17 | | |
| NESTED LOOPS | | 1 | 86 | 17 | | |
| HASH JOIN | | 1 | 35 | 15 | | |
| INDEX RANGE SCAN |KCS_GSN_PK | 403 | 6K| 6 | | |
| INDEX RANGE SCAN |KCS_ISC_GSN_FK | 497 | 8K| 6 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_GENERAL_ACTIVITIES | 50 | 2K| 2 | | |
| INDEX UNIQUE SCAN |KCS_GAY_PK | 50 | | 1 | | |
| INDEX UNIQUE SCAN |KCS_SCG_PK | 20 | 80 | | | |
| NESTED LOOPS | | 1 | 78 | 24 | | |
| HASH JOIN | | 1 | 74 | 24 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_INTS_GAY_SCT | 19 | 437 | 4 | | |
| INDEX RANGE SCAN |KCS_IAC_GAY_FK | 19 | | 2 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_GENERAL_ACTIVITIES | 50 | 2K| 19 | | |
| INDEX RANGE SCAN |KCS_GAY_PVN_FK | 50 | | 3 | | |
| INDEX UNIQUE SCAN |KCS_SCG_PK | 20 | 80 | | | |
| HASH JOIN | | 31 | 3K| 71 | | |
| NESTED LOOPS | | 31 | 2K| 69 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_INTS_WCA_PVN | 31 | 837 | 7 | | |
| INDEX RANGE SCAN |KCS_IAV_PVN_FK | 31 | | 3 | | |
| TABLE ACCESS BY INDEX ROWID |KCS_WEEKLY_COST_ACTIVITI | 71K| 4M| 2 | | |
| INDEX UNIQUE SCAN |KCS_WCA_PK | 71K| | 1 | | |
| TABLE ACCESS FULL |KCS_SYS_COST_GROUP | 20 | 120 | 1 | | |
---------------------------------------------------------------------------------------------------------Secondly the query where I derived the the project code (this leads to a slow result in 10.6 minutes)
Query with_assigned_project:
SELECT PVN.PJT_CODE PJT_CODE
, L_PJT.DESCRIPTION PJT_DESCRIPTION
, PVN.CODE VERSION
, PVN.DESCRIPTION VERSION_DESCRIPTION
, KBA.BQI_CODE BOQ_ITEM
, KBA.BQI_DESCRIPTION BOQ_ITEM_DESCRIPTION
, KBA.BQI_QUANTITY BOQ_ITEM_PAID_QUANTITY
, KBA.BQI_UNIT BOQ_ITEM_UNIT
, KGW.ACT_CODE ACT_CODE
, KGW.DESCRIPTION ACT_DESCRIPTION
, ROUND(KGW.EXECUTED) ACT_EXECUTED_QUANTITY
, KGW.UNIT_EXEC ACT_EXECUTED_UNIT
, ROUND(KGW.PAID) ACT_PAID_QUANTITY
, NVL(KGW.UNIT_PAID, KGW.UNIT_EXEC) ACT_PAID_UNIT
, KGW.HOURS_WEEK ACT_HOURS_WEEK
, KGW.PROD_HOUR ACT_PROD_HOUR
, KGW.HOURS_WEEK * KGW.PROD_HOUR ACT_PROD_WEEK
, NVL(KGW.WEEKS, 1) ACT_TOTAL_WEEKS -- WKUI: NVL, 1 toepassen.
, KGW.MY_CODE ACT_MY_CODE
FROM KCS_PROJECT_VERSIONS PVN
, KCS_BOQ_ACT_VW KBA
, KCS_GAY_WCA_VW KGW
, (SELECT * FROM PRR_PROJECTS WHERE CODE = (SELECT EMP.PJT_CODE FROM PRR_EMPLOYEES EMP WHERE EMP.INITIALS = USER)) L_PJT
WHERE PVN.PJT_CODE = L_PJT.CODE
AND KBA.PJT_CODE = PVN.PJT_CODE
AND KBA.PVN_CODE = PVN.CODE
AND KGW.PJT_CODE = PVN.PJT_CODE
AND KGW.PVN_CODE = PVN.CODE
AND KGW.BQI_CODE = KBA.BQI_CODE
ORDER BY PVN.PJT_CODE
, PVN.CODE
, KBA.BQI_CODE
, KGW.ACT_CODE;The explain plan is NOT OKAY for me looks like:
Plan Table
| Operation | Name | Rows | Bytes| Cost | Pstart| Pstop |
| SELECT STATEMENT | | 1 | 242 | 411715 | | |
| SORT ORDER BY | | 1 | 242 | 411715 | | |
| NESTED LOOPS | | 1 | 242 | 411714 | | |
| HASH JOIN | | 1 | 188 | 378640 | | |
| NESTED LOOPS | | 3 | 183 | 4 | | |
| TABLE ACCESS BY INDEX ROWID |PRR_PROJECTS | 1 | 26 | 2 | | |
| INDEX UNIQUE SCAN |PRR_PJT_PK | 1 | | 1 | | |
| TABLE ACCESS BY INDEX ROWID |PRR_EMPLOYEES | 1 | 7 | 1 | | |
| INDEX UNIQUE SCAN |PRR_EME_PK | 2 | | | | |
| TABLE ACCESS BY INDEX ROWID |KCS_PROJECT_VERSIONS | 10K| 345K| 2 | | |
| INDEX RANGE SCAN |KCS_PVN_PJT_FK | 10K| | 1 | | |
| VIEW |KCS_GAY_WCA_VW | 1M| 216M| 375247 | | |
| SORT UNIQUE | | 1M| 154M| 375247 | | |
| UNION-ALL | | | | | | |
| NESTED LOOPS | | 1M| 142M| 76854 | | |
| MERGE JOIN | | 1M| 135M| 76854 | | |
| MERGE JOIN | | 1M| 55M| 64136 | | |
| SORT JOIN | | 1M| 28M| | | |
| INDEX FAST FULL SCAN |KCS_ISC_GSN_FK | 1M| 28M| 13098 | | |
| SORT JOIN | | 1M| 21M| 49492 | | |
| INDEX FAST FULL SCAN |KCS_GSN_PK | 1M| 21M| 1546 | | |
| SORT JOIN | | 164K| 7M| 12718 | | |
| TABLE ACCESS FULL |KCS_GENERAL_ACTIVITIES | 164K| 7M| 558 | | |
| INDEX UNIQUE SCAN |KCS_SCG_PK | 20 | 80 | | | |
| NESTED LOOPS | | 22K| 1M| 12764 | | |
| HASH JOIN | | 22K| 1M| 12764 | | |
| TABLE ACCESS FULL |KCS_INTS_GAY_SCT | 22K| 504K| 36 | | |
| TABLE ACCESS FULL |KCS_GENERAL_ACTIVITIES | 164K| 7M| 558 | | |
| INDEX UNIQUE SCAN |KCS_SCG_PK | 20 | 80 | | | |
| HASH JOIN | | 105K| 10M| 10662 | | |
| TABLE ACCESS FULL |KCS_SYS_COST_GROUP | 20 | 120 | 1 | | |
| MERGE JOIN | | 105K| 9M| 10503 | | |
| SORT JOIN | | 71K| 4M| 6372 | | |
| TABLE ACCESS FULL |KCS_WEEKLY_COST_ACTIVITI | 71K| 4M| 490 | | |
| SORT JOIN | | 105K| 2M| 4131 | | |
| TABLE ACCESS FULL |KCS_INTS_WCA_PVN | 105K| 2M| 169 | | |
| VIEW |KCS_BOQ_ACT_VW | 269K| 13M| 33075 | | |
| SORT UNIQUE | | 269K| 15M| 33075 | | |
| UNION-ALL | | | | | | |
| MERGE JOIN | | 164K| 9M| 7193 | | |
| SORT JOIN | | 51K| 2M| 2461 | | |
| TABLE ACCESS FULL |KCS_BOQ_ITEMS | 51K| 2M| 107 | | |
| SORT JOIN | | 164K| 2M| 4733 | | |
| TABLE ACCESS FULL |KCS_GENERAL_ACTIVITIES | 164K| 2M| 558 | | |
| MERGE JOIN | | 105K| 5M| 4841 | | |
| SORT JOIN | | 51K| 2M| 2461 | | |
| TABLE ACCESS FULL |KCS_BOQ_ITEMS | 51K| 2M| 107 | | |
| SORT JOIN | | 105K| 1M| 2380 | | |
| TABLE ACCESS FULL |KCS_INTS_WCA_PVN | 105K| 1M| 169 | | |
52 rows selected.It's a bit hard to understand for me, because:
(SELECT * FROM PRR_PROJECTS WHERE CODE = (SELECT EMP.PJT_CODE FROM PRR_EMPLOYEES EMP WHERE EMP.INITIALS = USER)) L_PJTretrieves the only project '04.748', the one I hardcoded in the first query.
But as you can guess we do not want to work with hardcode projects, but with a project that is assisgned to the user via PRR_EMPLOYEES.PJT_CODE attribute.
I hope someone can steer me in the right direction to solve this issue.
Thanks in advance
Auke Quist
Edited by: aukequist on May 2, 2010 4:38 PM
Similar Messages
-
Query performance decreases dramatically after adding 0AGE characteristic
Hi gurus,
I've added 0AGE as a free characteristic to a query based on 0PAPA_C02 cube and the query performance falls down dramatically.
In transaction RSRT I have compared statistics for two identical queries, one with 0AGE, and one without it.
Total DBTRANS changed from 1.528 to 284.342
Total DBSEL didn't change.
"OLAP: Data Selection" changed from 0,207267 to 232,879858
There is also a new line: OLAP: USER_EXIT with long duration: 289,386668 and counter: 6.840.863
And I am not using any user exit variable!!!! or anything...
What may be wrong and how can I fix that?
Regards,
DorotaFound the answer.
There is a BAPI for 0PAPA_C01 InfoCube which makes 0AGE a virtual characteristic.
It needs to be deactivated.
The BAPI name is RS_BCT_PA. -
I have iphone 5; my battery life decreased dramatically after updating to ios 6.1.2. How do I delete and go back to previous iso?
Downgrading the iOS isn't supported and wouldn't help even if you could. There have been reports of decreased battery life after every update since iOS 1.0.1.
There are lots of things that can be done including reinstalling push email accounts. basic phone reset (pressing both home and power buttons for at least 10 seconds until the Apple logo appears), and restoring the phone with and without a backup. -
SQL Query Performance downgrade rapidly after migrated to SQL2012 from SQL2000
Problem:
SQL statement
SQL 2000 (cost) SQL2012
1 customer select SQL Statement ( little long) 22 seconds
5 mins (after rebuild index)
Migration method:
1. Backup SQL2000 DB and restore to SQL2008;
2. Backup SQL2008 DB and restore to SQL2012.
Anybody can help on this case? Thanks!
Environment
SQL2000 and SQL2005 instances: 4CPU, 4GB RAM, Windows Server 2000 SP4
SQL2012 R2: 4 vitual CPU cores, 8GB RAM, Windows Server 2012R21. execution plan
|--Compute Scalar(DEFINE:([Expr1013]=isnull([Expr1011],(0.000000000000000e+000)), [Expr1014]=(0), [Expr1021]=isnull([Expr1019],(0.000000000000000e+000)), [Expr1022]=(0), [Expr1023]=(0), [Expr1028]=isnull([Expr1026],(0.000000000000000e+000)),
[Expr1033]=isnull([Expr1031],(0.000000000000000e+000)), [Expr1040]=isnull([Expr1038],(0.000000000000000e+000)), [Expr1047]=isnull([Expr1045],(0.000000000000000e+000)), [Expr1054]=isnull([Expr1052],(0.000000000000000e+000)), [Expr1061]=isnull([Expr1059],(0.000000000000000e+000)),
[Expr1068]=isnull([Expr1066],(0.000000000000000e+000)), [Expr1075]=isnull([Expr1073],(0.000000000000000e+000)), [Expr1082]=isnull([Expr1080],(0.000000000000000e+000)), [Expr1089]=isnull([Expr1087],(0.000000000000000e+000)), [Expr1096]=isnull([Expr1094],(0.000000000000000e+000)),
[Expr1103]=isnull([Expr1101],(0.000000000000000e+000)), [Expr1110]=isnull([Expr1108],(0.000000000000000e+000)), [Expr1117]=isnull([Expr1115],(0.000000000000000e+000)), [Expr1124]=isnull([Expr1122],(0.000000000000000e+000)), [Expr1131]=isnull([Expr1129],(0.000000000000000e+000)),
[Expr1138]=isnull([Expr1136],(0.000000000000000e+000)), [Expr1145]=isnull([Expr1143],(0.000000000000000e+000)), [Expr1152]=isnull([Expr1150],(0.000000000000000e+000)))),1,2,1,Compute Scalar,Compute Scalar,DEFINE:([Expr1013]=isnull([Expr1011],(0.000000000000000e+000)),
[Expr1014]=(0), [Expr1021]=isnull([Expr1019],(0.000000000000000e+000)), [Expr1022]=(0), [Expr1023]=(0), [Expr1028]=isnull([Expr1026],(0.000000000000000e+000)), [Expr1033]=isnull([Expr1031],(0.000000000000000e+000)), [Expr1040]=isnull([Expr1038],(0.000000000000000e+000)),
[Expr1047]=isnull([Expr1045],(0.000000000000000e+000)), [Expr1054]=isnull([Expr1052],(0.000000000000000e+000)), [Expr1061]=isnull([Expr1059],(0.000000000000000e+000)), [Expr1068]=isnull([Expr1066],(0.000000000000000e+000)), [Expr1075]=isnull([Expr1073],(0.000000000000000e+000)),
[Expr1082]=isnull([Expr1080],(0.000000000000000e+000)), [Expr1089]=isnull([Expr1087],(0.000000000000000e+000)), [Expr1096]=isnull([Expr1094],(0.000000000000000e+000)), [Expr1103]=isnull([Expr1101],(0.000000000000000e+000)), [Expr1110]=isnull([Expr1108],(0.000000000000000e+000)),
[Expr1117]=isnull([Expr1115],(0.000000000000000e+000)), [Expr1124]=isnull([Expr1122],(0.000000000000000e+000)), [Expr1131]=isnull([Expr1129],(0.000000000000000e+000)), [Expr1138]=isnull([Expr1136],(0.000000000000000e+000)), [Expr1145]=isnull([Expr1143],(0.000000000000000e+000)),
[Expr1152]=isnull([Expr1150],(0.000000000000000e+000))),[Expr1013]=isnull([Expr1011],(0.000000000000000e+000)), [Expr1014]=(0), [Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name],
[CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target],
[CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1013], [Expr1014],
[Expr1021], [Expr1022], [Expr1023], [Expr1028], [Expr1033], [Expr1040], [Expr1047], [Expr1054], [Expr1061], [Expr1068], [Expr1075], [Expr1082], [Expr1089], [Expr1096], [Expr1103], [Expr1110], [Expr1117], [Expr1124], [Expr1131], [Expr1138], [Expr1145], [Expr1152],NULL,PLAN_ROW,0,1
|--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,3,2,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1899,689.5999,[CRW].[Channel], [CRW].[Channel_Mapping],
[CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg],
[CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type],
[AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094], [Expr1101], [Expr1108], [Expr1115], [Expr1122],
[Expr1129], [Expr1136], [Expr1143], [Expr1150],NULL,PLAN_ROW,0,1
|--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,4,3,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1891,689.2623,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094],
[Expr1101], [Expr1108], [Expr1115], [Expr1122], [Expr1129], [Expr1136], [Expr1143],NULL,PLAN_ROW,0,1
| |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,5,4,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1883,688.9249,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094],
[Expr1101], [Expr1108], [Expr1115], [Expr1122], [Expr1129], [Expr1136],NULL,PLAN_ROW,0,1
| | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,6,5,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1875,688.5874,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094],
[Expr1101], [Expr1108], [Expr1115], [Expr1122], [Expr1129],NULL,PLAN_ROW,0,1
| | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,7,6,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1866,688.2499,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094],
[Expr1101], [Expr1108], [Expr1115], [Expr1122],NULL,PLAN_ROW,0,1
| | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,8,7,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1858,687.9124,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094],
[Expr1101], [Expr1108], [Expr1115],NULL,PLAN_ROW,0,1
| | | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,9,8,Nested Loops,Inner
Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1850,687.575,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name],
[CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast],
[CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031],
[Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094], [Expr1101], [Expr1108],NULL,PLAN_ROW,0,1
| | | | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,10,9,Nested
Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1842,687.2375,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code],
[CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast],
[CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031],
[Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094], [Expr1101],NULL,PLAN_ROW,0,1
| | | | | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,11,10,Nested
Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1834,686.9,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code],
[CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast],
[CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031],
[Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087], [Expr1094],NULL,PLAN_ROW,0,1
| | | | | | | | |--Nested Loops(Inner Join, OUTER
REFERENCES:([CRW].[Parent_Cust_Code])),1,12,11,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1826,670.2579,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code],
[CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target],
[CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005],
[Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080], [Expr1087],NULL,PLAN_ROW,0,1
| | | | | | | | | |--Nested
Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,13,12,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1818,661.1638,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name],
[CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target],
[CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1],
[Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073], [Expr1080],NULL,PLAN_ROW,0,1
| | | | | | | | | |
|--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,14,13,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1810,648.2534,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code],
[CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target],
[CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel],
[AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066], [Expr1073],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,15,14,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1801,638.7095,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code],
[CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target],
[CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel],
[AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059], [Expr1066],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,16,15,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1793,638.372,[CRW].[Channel], [CRW].[Channel_Mapping],
[CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg],
[CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type],
[AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052], [Expr1059],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,17,16,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1785,638.0345,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045], [Expr1052],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,18,17,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1777,627.3322,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038], [Expr1045],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,19,18,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1769,616.6299,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031], [Expr1038],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,20,19,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1761,605.9097,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026], [Expr1031],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | | | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,21,20,Nested Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1753,281.6566,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019], [Expr1026],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | | | | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,22,21,Nested Loops,Inner
Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1745,18.4746,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name],
[CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast],
[CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011], [Expr1019],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | | | | | | | |--Nested Loops(Inner Join, OUTER REFERENCES:([CRW].[Parent_Cust_Code])),1,23,22,Nested
Loops,Inner Join,OUTER REFERENCES:([CRW].[Parent_Cust_Code]),NULL,497.7165,0,0.002080455,1736,14.40793,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code],
[CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast],
[CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006], [Expr1011],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | | | | | | | | |--Compute Scalar(DEFINE:([Expr1005]=isnull([JDE_TEST].[dbo].[JDE_addressbook].[Area_1]
as [AB].[Area_1],N''), [Expr1006]=isnull([JDE_TEST].[dbo].[JDE_addressbook].[Local_Channel] as [AB].[Local_Channel],N''))),1,24,23,Compute Scalar,Compute Scalar,DEFINE:([Expr1005]=isnull([JDE_TEST].[dbo].[JDE_addressbook].[Area_1] as [AB].[Area_1],N''), [Expr1006]=isnull([JDE_TEST].[dbo].[JDE_addressbook].[Local_Channel]
as [AB].[Local_Channel],N'')),[Expr1005]=isnull([JDE_TEST].[dbo].[JDE_addressbook].[Area_1] as [AB].[Area_1],N''), [Expr1006]=isnull([JDE_TEST].[dbo].[JDE_addressbook].[Local_Channel] as [AB].[Local_Channel],N''),497.7165,0,4.977165E-05,1728,0.453685,[CRW].[Channel],
[CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code], [CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg],
[CRW].[Last_1y_mth_avg], [CRW].[Aug_Target], [CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo],
[CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel], [AB].[Area_1], [Expr1005], [Expr1006],NULL,PLAN_ROW,0,1
| | | | | | | | | |
| | | | | | | | | | | |--Sort(ORDER BY:([AB].[Area_1] ASC,
[AB].[Local_Channel] ASC, [CRW].[Parent_Cust_Code] ASC)),1,25,24,Sort,Sort,ORDER BY:([AB].[Area_1] ASC, [AB].[Local_Channel] ASC, [CRW].[Parent_Cust_Code] ASC),NULL,497.7165,0.01126126,0.00705794,1694,0.4536353,[CRW].[Channel], [CRW].[Channel_Mapping], [CRW].[Parent_Cust_Code],
[CRW].[Parent_Cust_Name], [CRW].[Customer_Code], [CRW].[Customer_Name], [CRW].[Rebate_Code], [CRW].[Rebate_Name], [CRW].[Ship_To_Code], [CRW].[Ship_To_Name], [CRW].[Qtr_Target], [CRW].[New_Cust], [CRW].[Last_2y_mth_avg], [CRW].[Last_1y_mth_avg], [CRW].[Aug_Target],
[CRW].[Sep_Target], [CRW].[Oct_Target], [CRW].[Nov_Target], [CRW].[Dec_Target], [CRW].[Sales_Forecast], [CRW].[RetreadFlag], [CRW].[Last_2y_mth_avg_RD], [CRW].[Last_1y_mth_avg_RD], [CRW].[報表歸屬客編], [CRW].[Memo], [CRW].[OE_Short_Name], [CRW].[Item_Type], [AB].[Local_Channel],
[AB].[Area_1],NULL,PLAN_ROW,0,1 -
Physical partitioning query performance wore than without
Hello experts,
I have copied InfoCube 0COPC_C04 to ZCPOC_C06 with a test-query and took over data from 0COPC_C04 to test the functionality of Repartitioning (~ 4 million records)
I did Repartitioning following instructions from note 1008833 for 0FISCPER (I used se38 RSDU_SET_FV_TO_FIX_VALUE to set 0FISCVARNT to constant) - starting-point is 001.2000 - end-point is 016.2010
Indexes and Statistcs are re-created.
We have Oracle 10.2.0.2.0 and SAPKW70022 on BW 700
So - from my point of view everything is fine - BUT: Queryperformance is worst than before - shown in rsrv.
Variable in Query is over 0FISCYEAR and 0FISCPER3 and NOT over 0FISCPER (a querytest with 0FISCPER brought the same bad performance result).
Even I read, that with physical partitioning the query reads PARALLEL --- I can not see any parallel things in sm50 / sm66 - I have excpected to see parallel readings due to my query - I asked for results from 001.2006 - 12.2010 - and 13 partions were created (related to se14 ).
What might be the problem?
Thanks for your answer,
Thomas
Edited by: Thomas Liebschner on Jan 4, 2011 3:28 PM#1171650 is already implemented (since 14.12.2010) --- I asked my collegaue from Basis-Team to send me the report.
> I read parallel-queryexcution in the SAP Press Galileo Press Book "SAP BW Peformanceoptimierung" written by Thomas Schröder (ISBN: 3-89842-718-8), Page 376. If you like, I can send this page as pdf to your mail stored in your business card.
Would be interesting to see that excerpt, yes.
> What I missed was to compress the F-Table.
>
> I'm wondering, that:
> 1. After Compressing 0COPC_C04 with 8 million records gave a dramatically improvement of query-performance. No partitioning.
Sure, usually a lot less data needs to be read now.
> 2. After a new Full-load from 0COPC_C04 to ZCOPC_C06 with rebuilding indices and statistics I got similar query-performance compared to 1
Also easy to understand.
The F-Facttable contains data per load. So data concerning the same business items will be in that table multiple times and need to be aggregated on-the-fly during query execution.
The E-Facttable in contrast just contains one entry per business item. Which is the same situation you'll find when you just have one single data load request.
> 3. If I compress ZCOPC_C06, then query-performance drops dramatically down (needs double time, if I use 0FISCPER, needs 8 times more in query with 0FISCYEAR and 0FISCPER3)
>
> additional information: I have merged partitions from ZCOPC_C06 to one partition --> checked by se14 /BIC/FZCOPC_C06 -- storage parameters
Hmm... ok, here we would really need to see what Oracle does with your Query and the partitioning scheme then.
What seems obvious is that as soon as you have just one partition, then there is no way for Oracle to split up work and leave uninteresting data aside (partition-pruning),
> Conclusion: it seems for me, that compression is enough - partitioning has no advantage in that dedicated scenario.
> Do I think right?
I think that compression is a must-do in 99% of all cases for SAP BI and that the partitioning of the E-Facttable should be reviewed on your system.
Up to here there is too little information available to tell whether or not it could benefit your query execution time.
Another aspect you might consider with partitioning the E-facttable is your data retention policy.
If you're about to throw away your data on, say, a yearly basis, then having the table partitioned that way can provide huge benefits.
My personal view to this is: you already payed for the most expensive and feature-rich database engine available for SAP BI - so why not go and exploit these features where possible?
best regards
Lars -
How to improve Query Performance
Hi Friends...
I Want to improve query performance.I need following things.
1.What is the process to findout the performance?. Any transaction code's and how to use?.
2.How can I know whether the query is running good or bad ,ie. in performance praspect.
3.I want to see the values i.e. how much time it is taking to run?. and where the defect is?.
4.How to improve the query performance?. After I did the needfull things to improve performance, I want to see the query execution time. i.e. it is running fast or not?.
Eg..
Eg 1. Need to create aggregates.
Solution: where can I create aggregates?. Now I'm in production system. So where I need to create? .i.e. indevelopment or in Quality or in Production system?.
Any chenges I need to do in Development?.Because I'm in Production system.
So please tell me solution for my questions.
Thanks
Ganga
Message was edited by: Ganga Nhi ganga
please refer oss note :557870 : Frequently asked questions on query performance
also refer to
Prakash's weblog
/people/prakash.darji/blog/2006/01/27/query-creation-checklist
/people/prakash.darji/blog/2006/01/26/query-optimization
performance docs on query
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/3f66ba90-0201-0010-ac8d-b61d8fd9abe9
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ce7fb368-0601-0010-64ba-fadc985a1f94
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/c8c4d794-0501-0010-a693-918a17e663cc
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/064fed90-0201-0010-13ae-b16fa4dab695
This is the oss notes of FAQ on query performance
1. What kind of tools are available to monitor the overall Query Performance?
1. BW Statistics
2. BW Workload Analysis in ST03N (Use Export Mode!)
3. Content of Table RSDDSTAT
2. Do I have to do something to enable such tools?
Yes, you need to turn on the BW Statistics:
RSA1, choose Tools -> BW statistics for InfoCubes
(Choose OLAP and WHM for your relevant Cubes)
3. What kind of tools is available to analyze a specific query in detail?
1. Transaction RSRT
2. Transaction RSRTRACE
4. Do I have an overall query performance problem?
i. Use ST03N -> BW System load values to recognize the problem. Use the number given in table 'Reporting - InfoCubes:Share of total time (s)' to check if one of the columns %OLAP, %DB, %Frontend shows a high number in all Info Cubes.
ii. You need to run ST03N in expert mode to get these values
5. What can I do if the database proportion is high for all queries?
Check:
1. If the database statistic strategy is set up properly for your DB platform (above all for the BW specific tables)
2. If database parameter set up accords with SAP Notes and SAP Services (EarlyWatch)
3. If Buffers, I/O, CPU, memory on the database server are exhausted?
4. If Cube compression is used regularly
5. If Database partitioning is used (not available on all DB platforms)
6. What can I do if the OLAP proportion is high for all queries?
Check:
1. If the CPUs on the application server are exhausted
2. If the SAP R/3 memory set up is done properly (use TX ST02 to find bottlenecks)
3. If the read mode of the queries is unfavourable (RSRREPDIR, RSDDSTAT, Customizing default)
7. What can I do if the client proportion is high for all queries?
Check whether most of your clients are connected via a WAN connection and the amount of data which is transferred is rather high.
8. Where can I get specific runtime information for one query?
1. Again you can use ST03N -> BW System Load
2. Depending on the time frame you select, you get historical data or current data.
3. To get to a specific query you need to drill down using the InfoCube name
4. Use Aggregation Query to get more runtime information about a single query. Use tab All data to get to the details. (DB, OLAP, and Frontend time, plus Select/ Transferred records, plus number of cells and formats)
9. What kind of query performance problems can I recognize using ST03N
values for a specific query?
(Use Details to get the runtime segments)
1. High Database Runtime
2. High OLAP Runtime
3. High Frontend Runtime
10. What can I do if a query has a high database runtime?
1. Check if an aggregate is suitable (use All data to get values "selected records to transferred records", a high number here would be an indicator for query performance improvement using an aggregate)
2. o Check if database statistics are update to data for the Cube/Aggregate, use TX RSRV output (use database check for statistics and indexes)
3. Check if the read mode of the query is unfavourable - Recommended (H)
11. What can I do if a query has a high OLAP runtime?
1. Check if a high number of Cells transferred to the OLAP (use "All data" to get value "No. of Cells")
2. Use RSRT technical Information to check if any extra OLAP-processing is necessary (Stock Query, Exception Aggregation, Calc. before Aggregation, Virtual Char. Key Figures, Attributes in Calculated Key Figs, Time-dependent Currency Translation) together with a high number of records transferred.
3. Check if a user exit Usage is involved in the OLAP runtime?
4. Check if large hierarchies are used and the entry hierarchy level is as deep as possible. This limits the levels of the hierarchy that must be processed. Use SE16 on the inclusion tables and use the List of Value feature on the column successor and predecessor to see which entry level of the hierarchy is used.
5. Check if a proper index on the inclusion table exist
12. What can I do if a query has a high frontend runtime?
1. Check if a very high number of cells and formatting are transferred to the Frontend (use "All data" to get value "No. of Cells") which cause high network and frontend (processing) runtime.
2. Check if frontend PC are within the recommendation (RAM, CPU MHz)
3. Check if the bandwidth for WAN connection is sufficient
REWARDING POINTS IS THE WAY OF SAYING THANKS IN SDN
CHEERS
RAVI -
Problems with Full loads/Decreased query performance in Prod
We have a table which serves as a base for a complex view. The table has roughly around 10 Million records and its a daily full load(I know, that delta loads are much better for handling large sets of data, but this information is very dynamic and with the business time constraints and project deliverables, the best decision was to do a Full load).
This is the process we follow:
> Drop Indexes (All columns individual indexes which are used inside the complex view as joins)
> Truncate table
> Load data
> Recreate indexes.
All the above steps are performed from SAP Dataservices Thru scripts and sql() function to execute the command, no manual intervention what so ever.
After the job is successfully completed, the view doesn't refresh at all(It sits there forever). The same job when run across same volume of production data in Test environment performs much faster.
Then, how do I refresh the view is manually log into SQL Developer, drop all the indexes on the parent table, and re-create all the indexes in the same order as Dataservices script. It performs very well after till the next load (the next morning).
Any suggestions would be very helpful.
My main question is why does it run faster, when I drop and recreate the indexes? and doesnt complete when the indexes are created by the SQL() from data services tool.
Tried:
Explain Plan(in dev, Test, Prod): Query cost vaired accross environments but returned results with same return times (In Production after manual Index creation)
Tuning advisor (Only in Test) DBA evaluated it to be good.
Thanks
Nash
DB Version Oracle 11.0.7
Dataservices 3.2BluShadow and Harman
Thank You!
Im using a regular view, not a materialized view. and yes the query plan is completely different from Test and Production. In test the query was completely running on Hash based joins whereas in Production its using Nested Joins in the execution plan.
Will try to gather statistics after the load and as per BluShadow, will look on the way of writing a function that makes a call to Database.
Thank you all for taking sometime. I will try to test this out starting today and will extend tests over a couple of days.
Regards
Nash -
Severe Samba performance decrease after u6 - u7 upgrade
I just upgraded my Solaris 10 x86 system from u6 (kernel 138889-08) to u7 using LiveUpgrade. I have samba sharing some ZFS filesystems, and the first thing I noticed after the upgrade was a severe performance decrease in reading files via smb.
For example, using smbget from a MacOS client to retrieve a particular test file, pre-upgrade I was getting about 30Mb/sec, but after the upgrade to u7 I'm only getting 100Kb/sec. If I boot back to my alternate boot environment that still has u6, performance returns to normal. This happened when u7 was first released, so I just ignored it and went back to u6, and now I tried u7 again yesterday and applied all of the current security and most recommended patches (including the latest samba patch) and am still experiencing the same behavior.
I don't currently have any socket options or other performance tuning in my smb.conf, it is about as simple as possible with just a couple share definitions.
Any ideas why the upgrade would cause such problems for samba? The only troubleshooting I can think to check is that the network card (e1000g) isn't getting errors all of a sudden after the upgrade, but netstat -i shows everything is working as expected; 0 errors/collisions/etc.
Any suggestions would be appreciated!
Thanks,
MatthewHi Experts,
After i tried a few times, i can successfully start prepare with upgrade asistant monitor - Administrator >> Start Prepare,
Thanks -
Performance with dates in the where clause
Performance with dates in the where clause
CREATE TABLE TEST_DATA
FNUMBER NUMBER,
FSTRING VARCHAR2(4000 BYTE),
FDATE DATE
create index t_indx on test_data(fdata);
query 1: select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
query 2: select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
query 3: select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_date('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
My questions:
1) Why isn't the index t_indx used in Execution plan 1?
2) From the execution plan, I see that query 2 & 3 is better than query 1. I do not see any difference between execution plan 2 & 3. Which one is better?
3) I read somewhere - "Always check the Access Predicates and Filter Predicates of Explain Plan carefully to determine which columns are contributing to a Range Scan and which columns are merely filtering the returned rows. Be sceptical if the same clause is shown in both."
Is that true for Execution plan 2 & 3?
3) Could some one explain what the filter & access predicate mean here?
Thanks in advance.
Execution Plan 1:
SQL> select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
COUNT(*)
283
Execution Plan
Plan hash value: 1486387033
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 9 | 517 (20)| 00:00:07 |
| 1 | SORT AGGREGATE | | 1 | 9 | | |
|* 2 | TABLE ACCESS FULL| TEST_DATA | 341 | 3069 | 517 (20)| 00:00:07 |
Predicate Information (identified by operation id):
2 - filter(TRUNC(INTERNAL_FUNCTION("FDATE"))=TRUNC(SYSDATE@!))
Note
- dynamic sampling used for this statement
Statistics
4 recursive calls
0 db block gets
1610 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
380 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
Execution Plan 2:
SQL> select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
COUNT(*)
283
Execution Plan
Plan hash value: 1687886199
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 9 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 9 | | |
|* 2 | FILTER | | | | | |
|* 3 | INDEX RANGE SCAN| T_INDX | 283 | 2547 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(TRUNC(SYSDATE@!)<=TRUNC(SYSDATE@!)+.9999884259259259259259
259259259259259259)
3 - access("FDATE">=TRUNC(SYSDATE@!) AND
"FDATE"<=TRUNC(SYSDATE@!)+.999988425925925925925925925925925925925
9)
Note
- dynamic sampling used for this statement
Statistics
7 recursive calls
0 db block gets
76 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
380 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows
Execution Plan 3:
SQL> select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_dat
e('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
COUNT(*)
283
Execution Plan
Plan hash value: 1687886199
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 9 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 9 | | |
|* 2 | FILTER | | | | | |
|* 3 | INDEX RANGE SCAN| T_INDX | 283 | 2547 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(TO_DATE('21-APR-10','dd-MON-yy')<=TO_DATE('21-APR-10
23:59:59','DD-MON-YY hh24:mi:ss'))
3 - access("FDATE">=TO_DATE('21-APR-10','dd-MON-yy') AND
"FDATE"<=TO_DATE('21-APR-10 23:59:59','DD-MON-YY hh24:mi:ss'))
Note
- dynamic sampling used for this statement
Statistics
7 recursive calls
0 db block gets
76 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
380 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processedHi,
user10541890 wrote:
Performance with dates in the where clause
CREATE TABLE TEST_DATA
FNUMBER NUMBER,
FSTRING VARCHAR2(4000 BYTE),
FDATE DATE
create index t_indx on test_data(fdata);Did you mean fdat<b>e</b> (ending in e)?
Be careful; post the code you're actually running.
query 1: select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
query 2: select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
query 3: select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_date('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
My questions:
1) Why isn't the index t_indx used in Execution plan 1?To use an index, the indexed column must stand alone as one of the operands. If you had a function-based index on TRUNC (fdate), then it might be used in Query 1, because the left operand of = is TRUNC (fdate).
2) From the execution plan, I see that query 2 & 3 is better than query 1. I do not see any difference between execution plan 2 & 3. Which one is better?That depends on what you mean by "better".
If "better" means faster, you've already shown that one is about as good as the other.
Queries 2 and 3 are doing different things. Assuming the table stays the same, Query 2 may give different results every day, but the results of Query 3 will never change.
For clarity, I prefer:
WHERE fdate >= TRUNC (SYSDATE)
AND fdate < TRUNC (SYSDATE) + 1(or replace SYSDATE with a TO_DATE expression, depending on the requirements).
3) I read somewhere - "Always check the Access Predicates and Filter Predicates of Explain Plan carefully to determine which columns are contributing to a Range Scan and which columns are merely filtering the returned rows. Be sceptical if the same clause is shown in both."
Is that true for Execution plan 2 & 3?
3) Could some one explain what the filter & access predicate mean here?Sorry, I can't. -
Oracle Query Performance While calling a function in a View
Hi,
We have a performance issue in one of our Oracle queries.
Here is the scenario
We use a hard coded value (which is the maximum value from a table) in couple of DECODE statements in our query. We would like to remove this hard coded value from the query. So we wrote a function which will return a maximum value from the table. Now when we execute the query after replacing the hard coded value with the function, this function is called four times which hampers the query performance.
Pl find below the DECODE statements in the query. This query is part of a main VIEW.
Using Hardcoded values
=================
DECODE(pro_risk_weighted_ctrl_scr, 10, 9.9, pro_risk_weighted_ctrl_scr)
DECODE(pro_risk_score, 46619750, 46619749, pro_risk_score)
Using Functions
============
DECODE (pro_risk_weighted_ctrl_scr, rprowbproc.fn_max_rcsa_range_values ('CSR'), rprowbproc.fn_max_rcsa_range_values('CSR')- 0.1, pro_risk_weighted_ctrl_scr)
DECODE (pro_risk_score, rprowbproc.fn_max_rcsa_range_values ('RSR'), rprowbproc.fn_max_rcsa_range_values ('RSR') - 1, pro_risk_score)
Can any one suggest a way to improve the performance of the query.
Thanks & Regards,
Rajidrop table max_demo;
create table max_demo
(rcsa varchar2(10)
,value number);
insert into max_demo
select case when mod(rownum,2) = 0
then 'CSR'
else 'RSR'
end
, rownum
from dual
connect by rownum <= 10000;
create or replace function f_max (
i_rcsa in max_demo.rcsa%TYPE
return number
as
l_max number;
begin
select max(value)
into l_max
from max_demo
where rcsa = i_rcsa;
return l_max;
end;
-- slooooooooooooowwwwww
select m.*
, f_max(rcsa)
, decode(rcsa,'CSR',decode(value,f_max('CSR'),'Y - max is '||f_max('CSR'),'N - max is '||f_max('CSR'))) is_max_csr
, decode(rcsa,'RSR',decode(value,f_max('RSR'),'Y - max is '||f_max('RSR'),'N - max is '||f_max('RSR'))) is_max_rsr
from max_demo m
order by value desc;
-- ssllooooowwwww
with subq_max as
(select f_max('CSR') max_csr,
f_max('RSR') max_rsr
from dual)
select m.*
, decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
, decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
, decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from max_demo m
, subq_max s
order by value desc;
-- faster
with subq_max as
(select /*+materialize */
f_max('CSR') max_csr,
f_max('RSR') max_rsr
from dual)
select m.*
, decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
, decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
, decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from max_demo m
, subq_max s
order by value desc;
-- faster
with subq_max as
(select f_max('CSR') max_csr,
f_max('RSR') max_rsr,
rownum
from dual)
select m.*
, decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
, decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
, decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from max_demo m
, subq_max s
order by value desc;
-- sloooooowwwwww
select m.*
, decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
, decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
, decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from max_demo m
, (select /*+ materialize */
f_max('CSR') max_csr,
f_max('RSR') max_rsr
from dual) s
order by value desc;
-- faster
select m.*
, decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
, decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
, decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from max_demo m
, (select f_max('CSR') max_csr,
f_max('RSR') max_rsr,
rownum
from dual) s
order by value desc; -
Dear experts,
I have a question regarding as the performance of a BW query.
It takes 10 minutes to display about 23 thousands lines.
This query read the data from an ODS object.
According to the "where" clause in the "select" statement monitored via Oracle session when the query was running, I created an index for this ODS object.
After rerunning the query, I found that the index had been taken by Oracle in reading this table (estimated cost is reduced to 2 from about 3000).
However, it takes the same time as before.
Is there any other reason or other factors that I should consider in tuning the performance of this query?K
Thanks in advanceHi David,
Query performance when reporting on ODS object is slower compared to infocubes, infosets, multiproviders etc because of no aggregates and other performance techinques in DSO.
Basically for DSO/ODS you need to turn on the BEx reporting flag, which again is an overhead for query execution and affects performance.
To improve the performance when reporting on ODS you can create secondary indexes from BW workbench.
Please check the below links.
[Re: performance issues of ODS]
[Which criteria to follow to pick InfoObj. as secondary index of ODS?;
Hope this helps.
Regards,
Haritha. -
How to improve query performance using infoset
I create one infoset that including 4 char.and 3 DSO which all are time-dependent.When query run, system show very poor perfomance, sometimes no data show in BEX anayzer. In this case I have to close BEX analyzer at first and then open it again, after that it show real results. It seems very strange. Does anybody has experience on infoset performance improvement. pls info, thanks!
Hi
As info set itself doesn't have any data so it improves Performance
also go through the below tips.
Find the query Run-time
where to find the query Run-time ?
557870 'FAQ BW Query Performance'
130696 - Performance trace in BW
This info may be helpful.
General tips
Using aggregates and compression.
Using less and complex cell definitions if possible.
1. Avoid using too many nav. attr
2. Avoid RKF and CKF
3. Many chars in row.
By using T-codes ST03 or ST03N
Go to transaction ST03 > switch to expert mode > from left side menu > and there in system load history and distribution for a particular day > check query execution time.
Statistical Records Part 4: How to read ST03N datasets from DB in NW2004
How to read ST03N datasets from DB
Try table rsddstats to get the statistics
Using cache memory will decrease the loading time of the report.
Run reporting agent at night and sending results to email. This will ensure use of OLAP cache. So later report execution will retrieve the result faster from the OLAP cache.
Also try
1. Use different parameters in ST03 to see the two important parameters aggregation ratio and records transferred to F/E to DB selected.
2. Use the program SAP_INFOCUBE_DESIGNS (Performance of BW infocubes) to see the aggregation ratio for the cube. If the cube does not appear in the list of this report, try to run RSRV checks on the cube and aggregates.
Go to SE38 > Run the program SAP_INFOCUBE_DESIGNS
It will shown dimension Vs Fact tables Size in percent.If you mean speed of queries on a cube as performance metric of cube,measure query runtime.
3. To check the performance of the aggregates,see the columns valuation and usage in aggregates.
Open the Aggregates...and observe VALUATION and USAGE columns.
"---" sign is the valuation of the aggregate. You can say -3 is the valuation of the aggregate design and usage. ++ means that its compression is good and access is also more (in effect, performance is good). If you check its compression ratio, it must be good. -- means the compression ratio is not so good and access is also not so good (performance is not so good).The more is the positives...more is useful the aggregate and more it satisfies the number of queries. The greater the number of minus signs, the worse the evaluation of the aggregate. The larger the number of plus signs, the better the evaluation of the aggregate.
if "-----" then it means it just an overhead. Aggregate can potentially be deleted and "+++++" means Aggregate is potentially very useful.
In valuation column,if there are more positive sign it means that the aggregate performance is good and it is useful to have this aggregate.But if it has more negative sign it means we need not better use that aggregate.
In usage column,we will come to know how far the aggregate has been used in query.
Thus we can check the performance of the aggregate.
Refer.
http://help.sap.com/saphelp_nw70/helpdata/en/b8/23813b310c4a0ee10000000a114084/content.htm
http://help.sap.com/saphelp_nw70/helpdata/en/60/f0fb411e255f24e10000000a1550b0/frameset.htm
performance ISSUE related to AGGREGATE
Note 356732 - Performance Tuning for Queries with Aggregates
Note 166433 - Options for finding aggregates (find optimal aggregates for an InfoCube)
4. Run your query in RSRT and run the query in the debug mode. Select "Display Aggregates Found" and "Do not use cache" in the debug mode. This will tell you if it hit any aggregates while running. If it does not show any aggregates, you might want to redesign your aggregates for the query.
Also your query performance can depend upon criteria and since you have given selection only on one infoprovider...just check if you are selecting huge amount of data in the report
Check for the query read mode in RSRT.(whether its A,X or H)..advisable read mode is X.
5. In BI 7 statistics need to be activated for ST03 and BI admin cockpit to work.
By implementing BW Statistics Business Content - you need to install, feed data and through ready made reports which for analysis.
http://help.sap.com/saphelp_nw70/helpdata/en/26/4bc0417951d117e10000000a155106/frameset.htm
/people/vikash.agrawal/blog/2006/04/17/query-performance-150-is-aggregates-the-way-out-for-me
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1955ba90-0201-0010-d3aa-8b2a4ef6bbb2
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ce7fb368-0601-0010-64ba-fadc985a1f94
http://help.sap.com/saphelp_nw04/helpdata/en/c1/0dbf65e04311d286d6006008b32e84/frameset.htm
You can go to T-Code DB20 which gives you all the performance related information like
Partitions
Databases
Schemas
Buffer Pools
Tablespaces etc
use tool RSDDK_CHECK_AGGREGATE in se38 to check for the corrupt aggregates
If aggregates contain incorrect data, you must regenerate them.
202469 - Using aggregate check tool
Note 646402 - Programs for checking aggregates (as of BW 3.0B SP15)
You can find out whether an aggregate is usefull or useless you can find out through a proccess of checking the tables RSDDSTATAGGRDEF*
Run the query in RSRT with statistics execute and come back you will get STATUID... copy this and check in the table...
This gives you exactly which infoobjects it's hitting, if any one of the object is missing it's useless aggregate.
6
Check SE11 > table RSDDAGGRDIR . You can find the last callup in the table.
Generate Report in RSRT
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/4c0ab590-0201-0010-bd9a-8332d8b4f09c
Business Intelligence Journal Improving Query Performance in Data Warehouses
http://www.tdwi.org/Publications/BIJournal/display.aspx?ID=7891
Achieving BI Query Performance Building Business Intelligence
http://www.dmreview.com/issues/20051001/1038109-1.html
Assign points if useful
Cheers
SM -
Hi
I have created a procedure that accepts two bind variables from a report. The user will select one or the other, both or neither of the variables. To return the appropriate results i have created a view with the entire result set and in the procedure are a number of if statements that determine what to place in the where clause selecting from the view, depending on what variables populated.
My concern is that the query that generates the view includes several joins and in total outputs around 150,000 records and seems to be rather slow to run.
Would you recommend another solution such as placing the query in the procedure itself repeated for every if statement?
Or should I work on the query performance?
What would be the most efficient solution for my problem?
Any advice would be greatly appreciated.
Thanks[url http://forums.oracle.com/forums/thread.jspa?threadID=501834&tstart=0]When your query takes too long
-
QUERY PERFORMANCE AND DATA LOADING PERFORMANCE ISSUES
WHAT ARE QUERY PERFORMANCE ISSUES WE NEED TO TAKE CARE PLEASE EXPLAIN AND LET ME KNOW T CODES...PLZ URGENT
WHAT ARE DATALOADING PERFORMANCE ISSUES WE NEED TO TAKE CARE PLEASE EXPLAIN AND LET ME KNOW T CODES PLZ URGENT
WILL REWARD FULL POINT S
REGARDS
GURUBW Back end
Some Tips -
1)Identify long-running extraction processes on the source system. Extraction processes are performed by several extraction jobs running on the source system. The run-time of these jobs affects the performance. Use transaction code SM37 Background Processing Job Management to analyze the run-times of these jobs. If the run-time of data collection jobs lasts for several hours, schedule these jobs to run more frequently. This way, less data is written into update tables for each run and extraction performance increases.
2)Identify high run-times for ABAP code, especially for user exits. The quality of any custom ABAP programs used in data extraction affects the extraction performance. Use transaction code SE30 ABAP/4 Run-time Analysis and then run the analysis for the transaction code RSA3 Extractor Checker. The system then records the activities of the extraction program so you can review them to identify time-consuming activities. Eliminate those long-running activities or substitute them with alternative program logic.
3)Identify expensive SQL statements. If database run-time is high for extraction jobs, use transaction code ST05 Performance Trace. On this screen, select ALEREMOTE user and then select SQL trace to record the SQL statements. Identify the time-consuming sections from the results. If the data-selection times are high on a particular SQL statement, index the DataSource tables to increase the performance of selection (see no. 6 below). While using ST05, make sure that no other extraction job is running with ALEREMOTE user.
4)Balance loads by distributing processes onto different servers if possible. If your site uses more than one BW application server, distribute the extraction processes to different servers using transaction code SM59 Maintain RFC Destination. Load balancing is possible only if the extraction program allows the option
5)Set optimum parameters for data-packet size. Packet size affects the number of data requests to the database. Set the data-packet size to optimum values for an efficient data-extraction mechanism. To find the optimum value, start with a packet size in the range of 50,000 to 100,000 and gradually increase it. At some point, you will reach the threshold at which increasing packet size further does not provide any performance increase. To set the packet size, use transaction code SBIW BW IMG Menu on the source system. To set the data load parameters for flat-file uploads, use transaction code RSCUSTV6 in BW.
6)Build indexes on DataSource tables based on selection criteria. Indexing DataSource tables improves the extraction performance, because it reduces the read times of those tables.
7)Execute collection jobs in parallel. Like the Business Content extractors, generic extractors have a number of collection jobs to retrieve relevant data from DataSource tables. Scheduling these collection jobs to run in parallel reduces the total extraction time, and they can be scheduled via transaction code SM37 in the source system.
8). Break up your data selections for InfoPackages and schedule the portions to run in parallel. This parallel upload mechanism sends different portions of the data to BW at the same time, and as a result the total upload time is reduced. You can schedule InfoPackages in the Administrator Workbench.
You can upload data from a data target (InfoCube and ODS) to another data target within the BW system. While uploading, you can schedule more than one InfoPackage with different selection options in each one. For example, fiscal year or fiscal year period can be used as selection options. Avoid using parallel uploads for high volumes of data if hardware resources are constrained. Each InfoPacket uses one background process (if scheduled to run in the background) or dialog process (if scheduled to run online) of the application server, and too many processes could overwhelm a slow server.
9). Building secondary indexes on the tables for the selection fields optimizes these tables for reading, reducing extraction time. If your selection fields are not key fields on the table, primary indexes are not much of a help when accessing data. In this case it is better to create secondary indexes with selection fields on the associated table using ABAP Dictionary to improve better selection performance.
10)Analyze upload times to the PSA and identify long-running uploads. When you extract the data using PSA method, data is written into PSA tables in the BW system. If your data is on the order of tens of millions, consider partitioning these PSA tables for better performance, but pay attention to the partition sizes. Partitioning PSA tables improves data-load performance because it's faster to insert data into smaller database tables. Partitioning also provides increased performance for maintenance of PSA tables for example, you can delete a portion of data faster. You can set the size of each partition in the PSA parameters screen, in transaction code SPRO or RSCUSTV6, so that BW creates a new partition automatically when a threshold value is reached.
11)Debug any routines in the transfer and update rules and eliminate single selects from the routines. Using single selects in custom ABAP routines for selecting data from database tables reduces performance considerably. It is better to use buffers and array operations. When you use buffers or array operations, the system reads data from the database tables and stores it in the memory for manipulation, improving performance. If you do not use buffers or array operations, the whole reading process is performed on the database with many table accesses, and performance deteriorates. Also, extensive use of library transformations in the ABAP code reduces performance; since these transformations are not compiled in advance, they are carried out during run-time.
12)Before uploading a high volume of transaction data into InfoCubes, activate the number-range buffer for dimension IDs. The number-range buffer is a parameter that identifies the number of sequential dimension IDs stored in the memory. If you increase the number range before high-volume data upload, you reduce the number of reads from the dimension tables and hence increase the upload performance. Do not forget to set the number-range values back to their original values after the upload. Use transaction code SNRO to maintain the number range buffer values for InfoCubes.
13)Drop the indexes before uploading high-volume data into InfoCubes. Regenerate them after the upload. Indexes on InfoCubes are optimized for reading data from the InfoCubes. If the indexes exist during the upload, BW reads the indexes and tries to insert the records according to the indexes, resulting in poor upload performance. You can automate the dropping and regeneration of the indexes through InfoPackage scheduling. You can drop indexes in the Manage InfoCube screen in the Administrator Workbench.
14)IDoc (intermediate document) archiving improves the extraction and loading performance and can be applied on both BW and R/3 systems. In addition to IDoc archiving, data archiving is available for InfoCubes and ODS objects.
Hope it Helps
Chetan
@CP.. -
Query Performance issue in Oracle Forms
Hi All,
I am using oracle 9i DB and forms 6i.
In query form ,qry took long time to load the data into form.
There are two tables used here.
1 table(A) contains 5 crore records another table(B) has 2 crore records.
The recods fetching range 1-500 records.
Table (A) has no index on main columns,after created the index on main columns in table A ,the query is fetched the data quickly.
But DBA team dont want to create index on table A.Because of table space problem.
If create the index on main table (A) ,then performance overhead in production.
Concurrent user capacity is 1500.
Is there any alternative methods to handle this problem.
Regards,
RS1) What is a crore? Wikipedia seems to indicate that it's either 10,000,000 or 500,000
http://en.wikipedia.org/wiki/Crore
I'll assume that we're talking about tables with 50 million and 20 million rows, respectively.
2) Large tables with no indexes are definitely going to be slow. If you don't have the disk space to create an appropriate index, surely the right answer is to throw a bit of disk into the system.
3) I don't understand the comment "If create the index on main table (A) ,then performance overhead in production." That seems to contradict the comment you made earlier that the query performs well when you add the index. Are you talking about some other performance overhead?
Justin
Maybe you are looking for
-
Error while deploying Planning Application
Hi. I am trying to deploy a planning application in EPMA and it gives me the following error.. Never appeared before please help Mar 4, 2013 3:10:52 PM]: Parsing Application Properties... [Mar 4, 2013 3:10:52 PM]: Application Configuration Properties
-
Procedure run order in a Package
Are procedures run in a specific order in a package? If so, what determines that order? Thanks!
-
MSI Bluetooth Dongle Chipsets?
Hi, I'm looking for a bluetooth dongle which works with skype on my bluetooth headset. I went through a bunch of cheap ones (ISSC based), and now I'm consdering one from MSI (Btoes 2.0). Can anyone tell me what chipset is in this device? I have had g
-
Executing plsql code (procedures, contexts) in APEX
Trying to create a context. Code is valid, works in PLSQL and TOAD. Can't create it in APEX and can't call it. Can't get any procedures to work for that matter. create or replace context epsb_person_ctx using epsb_person_ctx_procedure Then create the
-
Printing dunning letter per level
Hello Gurus, I hope you can help me I have a dunning procedure with 3 levels. One Smart from applies to all levels. I want to be have one print batch per level. That is 3 batches in my case. I currently get all letters in one batch. I tried using the