SAP BW Hierarchy Attribute Change Run Management

Applies to:
SAP NW2004s (BI 7.0) SAP NW2004 (BW 3.5). For more information, visit the EDW homepage.

Summary
This article explains a. the importance of HACR and its maintenance, b. focuses how to prevent HACR failures by discipline and also c. provides scenario based expert solution if there is HACR failure. Author: Kannan Natarajan

Company: IBM India Pvt. LTD. Created on: 01 July 2010

Author Bio
Kannan is a certified BI 7.0 consultant with 5 years experience in SAP BW presently. He has rich experience in both production support and implementation project. He is a SAP BW developer working in IBM for Shell client. He held responsibility of Job failure analyst in his production support project.

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 1

SAP BW Hierarchy Attribute Change Run Management

Table of Contents
Overview....................................................................................................................................................... 3 1. What is HACR? ......................................................................................................................................... 3 2. Different failures that may raise due to HACR ............................................................................................ 4 3. How to get rid of HACR clashes ................................................................................................................ 4 3.1 Making Delta Setting and Activating Parallel processing in HACR ........................................................ 4
3.1.1 Making Delta Setting ........................................................................................................................................... 4 3.1.2 Activating Parallel processing in HACR .............................................................................................................. 5

3.2 Rescheduling Process chains .............................................................................................................. 6 3.3 Maintaining Aggregate ......................................................................................................................... 6

3.3.1. Delete unused Aggregate. ................................................................................................................................. 6 3.3.2. Delete/deactivate aggregates that are not used frequently. ............................................................................... 6 3.3.3. Find aggregates with less summarization value, less usage. ............................................................................. 7

4. Do and dont when HACR job fails ............................................................................................................. 7 Scenario 1: The basic. ............................................................................................................................... 7 Scenario 2: Bypassing a terminated change run. ....................................................................................... 8 Scenario 3: Infoobject not released. ........................................................................................................... 8 Myth regarding HACR recovery ................................................................................................................. 8 Related Content ............................................................................................................................................ 9 Disclaimer and Liability Notice ..................................................................................................................... 10

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 2

SAP BW Hierarchy Attribute Change Run Management

Overview
In SAP BI support projects, handling daily failure is the primary task. HACR issue is a major hurdle in handling daily job failures. 1. In brief, Importance of HACR. 2. The different failures, which may arise during HACR. 3. How to get rid of HACR clashes? 4. Do and dont when HACR job fails

1. What is HACR?
We all know the main advantage of SAP BI/BW is its extended star schema. In extended star Schema, all data targets share the same master data table (say Material) instead of duplicating it. Master data has attributes, which are slow changing. In our example Material group is an attribute of Material. A Material 1004 may change from Material group A to B, due to new business strategy. After this change, master data is loaded from R3 to BW. Just activating these master data is not enough to report with changed master data. The aggregates build using the navigational attribute (material group) should be also adjusted accordingly. Not doing Hierarchy attribute change run (HACR), the reports will still reporting on old master data. Which gives completely different picture to present business. Imagine if this report is used for making critical business decision!!!!! For this reason HACR is a must after a master data load. (If there is change in navigational attribute or hierarchy involved)

Fig 1.0. The Cube and aggregate looks like below when Material 1004 is in-group A.

Fig 1.1. After Material 1004s Group Changes from A to B in Material Master data and activation of master data. The value in aggregate is wrong now and the report will be showing this value.

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 3

SAP BW Hierarchy Attribute Change Run Management

Fig 1.2. Our HACR program helps here by getting the values in aggregates corrected* (Check 3.1.1 for details how aggregate is corrected).

2. Different failures that may raise due to HACR

When a HACR takes a long time, any other HACR starting in that span would fail. If a HACR fails other than Lock issue. After running this only HACR other HACR can be ran. While HACR realigns an Aggregate, if rollup step runs for that cube. The rollup will fail. If HACR and any transaction Load containing respective master data run in Parallel, the load time increases as both are accessing the same table. So there is very chance of Data Package hanging and short dumps.

From the above types of failure you can see that HACR failure causes a chain reaction of failures, which can take the system into toss if not managed/ taken action promptly.

3. How to get rid of HACR clashes

3.1 Making Delta Setting and Activating Parallel processing in HACR 3.2 Rescheduling Process chains 3.3 Maintaining Aggregate 3.1 Making Delta Setting and Activating Parallel processing in HACR 3.1.1 Making Delta Setting If hierarchies and attributes of characteristics belonging to an InfoCube have been changed, it is necessary to make structural changes to the aggregates in order to modify the data accordingly. With changes beyond a certain magnitude, re-aligning the aggregate becomes more time consuming than reconstructing it. You can change this threshold value (0-99)

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 4

SAP BW Hierarchy Attribute Change Run Management

Fig.3.1. Snap shot of Transaction RSCUSTV8. 0 means that the aggregate is always reconstructed and 99 means that the aggregate is always re-aligned. Delta Setting is done in RSCUSTV8 Transaction. I.e., When Delta limit is set to zero - Even if there is no change in the navigation attribute the system does reconstruction always. When delta limit is set to 99 Even if there is 99% change in the navigation attribute the system does a delta. In both the above cases, system takes maximum time to correct the aggregate. So as optimum generally the value is set to 20. Which means if the change is less than equal to 20% a delta correction is done in the aggregate, else the system goes for reconstruction. The value 20 can be changed to get better performance. Please go through the SAP note 1388570 for more detail. 3.1.2 Activating Parallel processing in HACR During a HACR, The program goes to each required Cube and re-aligns all the required Aggregates of the Cube. The aggregates of the same cube can be realigned in Parallel. The number of parallel processes can be customized in Process chain variant or with transaction RSBATCH in BI 7.0.

Fig. 3.2. Snap shot of transaction RSBATCH.

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 5

SAP BW Hierarchy Attribute Change Run Management

In BW 3.X you can customize in table RSADMIN. Please refer the Note 534630 - Parallel processing of Change Run for detail. By default 3 parallel Dialog process can be ran.
Note: Before making this settings check the number of processors available and discuss with Basis Team.

3.2 Rescheduling Process chains In Process chains for Masterdata loads, HACR process (RSPC -> Process type tab -> Other BW processes) is added subsequent to the masterdata load job. Optimize the run time of HACR by rescheduling the process chains. Reduce the time span of HACRs by Clubbing the Master data chains. E.g.: - If 3 HACR processes are running in 3 different PCs, Scheduled at 1:00 AM, 1:30 AM and 2:00 AM. Then there is lock set in system 3 times in a span of 65 mins. Assuming each HACR takes 5 mins. If we Club the 3 PCs in single Meta chain and run only one HACR Processes. Again lock is set 3 times in the system but this time only for a span of 15 mins. By doing this we earn a span of 65 15 = 40 mins where a transaction load can run without any chance of failure due to lock issue. The best practice is to Schedule all the Masterdata chains in same cluster of time, then to run single HACR in the end. Following which transaction data shall be loaded. Constraint: Business requirement might demand HACR should run just before respective Transaction load. E.g.: - There is a lookup into material masterdata for say inventory transaction data load. 3.3 Maintaining Aggregate Objective is to reduce the no. of aggregates without affecting report performance. Aggregate maintenance is an activity to be performed at least once in 3 months. 3.3.1 Delete unused Aggregate. 3.3.2 Delete/deactivate aggregates that are not used frequently. 3.3.3 Find aggregates with less summarization value, less usage. 3.3.1. Delete unused Aggregate. In Table: RSDDAGGRDIR, aggregates with Field: No. of call-ups = 0 are not used since they are last changed. So after making the list of unused aggregates, also check the last changed date (TIMESTMP) of the aggregate before deleting it. 3.3.2. Delete/deactivate aggregates that are not used frequently. In same Table: RSDDAGGRDIR, the field Last call-up gives the last time a query or sub aggregate hit the respective aggregate. Using this field, you shall delete those aggregates if there is no report presently using this aggregate. The report might have been deleted. You shall deactivate the aggregate, where queries based on this aggregate are run yearly or half yearly. You shall schedule a process chain scheduled 2 weeks before the report requirement period.

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 6

SAP BW Hierarchy Attribute Change Run Management

Fig.3.3. Snap shot of table RSDDAGGRDIR.

Note: The format of field last call up and TIMESTMP is yyyymmddhhmmss

3.3.3. Find aggregates with less summarization value, less usage. The Next level is to find low performing aggregate and delete or redesign them. Find aggregates with less usage (No. of call-ups) and less summarization value (AVGFACTREDUCE). Both these fields are available in table: RSDDAGGRDIR. Also check Valuation field in the Aggregate maintenance. Deactivate these aggregates and test the query performance. If there is no difference and if that aggregate is not a parent aggregate, you can delete it.

4. Do and dont when HACR job fails

This section gives insight on correcting a HACR failure. I have put them in 3 scenarios and one commonly made mistake. Scenario 1: The basic. Scenario 2: Bypassing a terminated change run Scenario 3: Infoobject not released Myth regarding HACR recovery

Scenario 1: The basic. A HACR of a characteristic failed due to lock of the characteristic. When you try repeating the job it again failed. What should be done? Step 1: Check if any other change run is active in a. Transaction CHANGERUNMONI or b. In SM37 for the Batch job scheduled for HACR (If scheduled in process chain, the name is BI_PROCESS_ATTRIBCHAN). Else check for any other lock by job in SM12. Step 2: Find the job locking the characteristic. Step 3: If the locking job is running fine then wait for the job to complete. Keep on repeating the job doesnt help**. Step 4: After the locking job is completed, the lock will be realized. Run to change run now (i.e. In a time span where there is no lock). The HACR job would complete successfully now. ** The HACR job releases its lock well in advance before the actual completion of the job itself. So repeat the failed job after this lock is realized will help . Please go through the point (E) Locking concept In Sap notes 1388570.

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 7

SAP BW Hierarchy Attribute Change Run Management

Scenario 2: Bypassing a terminated change run. A Change run is terminated. By experience you know this change run takes time. As we cannot proceed to next change run (or data load in many cases) without completing this change run, what is the workaround to go ahead with critical process loads? Below is the four-step solution. Step 1: Deactivate all affected aggregates. To find the affected aggregates, select all entries in table RSDDAGGRDIR that fulfill the selection criteria: OBJVERS = A and MODCNSID <> 0 The status shouldnt be manually reset of a terminated change run (for example, by changing a database table or executing a function module). Step 2: Restart the change run. Start the terminated change run in the same way as you first started it (Process chain or batch job or running the program** in SE38). "Change run monitor" (transaction CHANGERUNMONI) can be also used. **Program to run HACR is RSDDS_AGGREGATES_MAINTAIN. Step 3: Run other data loads Other data loads/ Change runs, which were held, are now free to run. Step 4: Activate the aggregates again. In a down time after all the hustle over; activate the aggregates, which were deactivated in step 1. Scenario 3: Infoobject not released. Some times the infoobjects are not released from the previous change run. Following which any transaction loads using the infoobject will fail. How to handle it? Below is the three-step solution. Step 1: Run RSDMD_CHECKPRG_ALL (or Transaction RSRV -> All Combined tests -> the masterdata) for the characteristic and repair any errors Step 2: Run functional module RSDDS_CHANGE_CHA_MAINTAIN in transaction SE37 with the following parameters to add the characteristic to the change run list; I_CHABASNM = (Technical name of characteristic) I_RNSID = -1 Step 3: Execute the Hierarchy/attribute change run. The infoobject should be released now. Note: In case If aggregates are already inconsistent, follow the steps given for scenario 1. Myth regarding HACR recovery The below 2 incorrect solutions are used for scenario 3 which leads to inconsistency of aggregates. So better use the solution mentioned above. 1. Go to the FM RSDDS_AGGR_MOD_CLOSE and run it. This will release all the locks on the infoobjects by the HACR. Now re run the HACR. 2. If last change run was unsuccessful. Go to table RSDDAGGRMODSTATE -> there will be a with field CLOSEDFL = 'blank (false). Change this field CLOSEDFL to 'X' and the infoobjects will got unlocked. Many SAP customer thinks that above mentioned solution would resolve the issue then they land in to trouble. CUSTOMER SHOULD NOT SET THE FLAG MANUALLY TO X, as it will make the aggregate inconsistent. If customer is very sure that aggregates are consistent though the HACR is terminated then he can manually set the flag to X.

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 8

SAP BW Hierarchy Attribute Change Run Management

Related Content
Please refer below materials for more insight on the discussed topic. http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13726 Note 534630 - Parallel processing of Change Run (3.X) Note 903886 - Hierarchy and attribute change run (3.X) Note 1388570 - BW Change Run (compares Change run in 3.X and 7.X). Note 1053605 Error due to status of a terminated change run was manually set to "Completed". http://help.sap.com/saphelp_nw70/helpdata/en/48/807834109a1b5ae10000000a42189c/frameset.htm For more information, visit the EDW homepage.

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 9

SAP BW Hierarchy Attribute Change Run Management

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this do cument, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the conte nt of this document.

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 10