Attribute Change Run: Purpose and Issues with BWA

                      The Attribute Change Run(ACR) is a prime process by which Master Data updates reflect in BW infoproviders. Once you load Master data in an infoobject via process chains it is loaded as D or M versions. These are intermediate and do not reflect in the final reports or linked to transactional data. Attribute change run exactly serves this purpose of making sure changes reflect in all relevant referenced targets and reports contain latest changes in MD.

                    Here, we have one more process which actually does something similar but not the same. The Master Data activation step(right click infoobject in RSA1-->Activate Master data) does change the version of the data from initial D/M to A. However, these changes are not reflected in the aggregates of the referenced cubes. So, it is always advisable to run ACR after MD loads.

            ACRs can be run manually by using the tcode SE38-->RSDDS_AGGREGATES_MAINTAIN click on infoobject list/hierarchy for which you have recently run the loads and then execute.

Once you run from here, you can monitor the ACR by tcode CHANGERUNMONI. Here the current ACRs are displayed along with the attributes which require an ACR to be run.

An important point here to note is that no two ACRs can run concurrently.WHY?
Lets consider two infoobject X and Y used as navigational attributes in Cube A. When ACR for X is going on, cube A is indirectly undergoing an update so at the same time, one cannot also work on infoobject Y. This is to adhere to the Isolation of the ACID properties of database.


ISSUES WITH ACR-BWA

When the cubes/infoobjects are indexed in BWA, ACR also adds/deletes modifies aggregates in BWA.ACR can clash with following processes:

1. Master Data Delta Daemon jobs
2. Rollup
3.Other running ACR

Master Data Delta Daemon jobs are periodic jobs which run every 3 minutes(this can be changed) and indexes any changes to MD in BWA. Rollup in BWA relates to the cubes aggregates indexed in BWA blades. However, the ACR does not immediately fail if these processes are on. We can set a WAITTIME parameter asking the ACR to wait before it fails due to lock issues. This can be found in tcode SPRO>>SAP Reference IMG. Follow the below hierarchy:

 Limit with Delta deals with ACR strategy. For instance, if the master data change is more than x(say 25) percent, reconstruction of aggregates is adopted. Otherwise alignment happens in existing aggregates. Block size is the default size of the data accessed as a block. This is to prevent temporary table overflow of data due to memory issues.Wait time has been described previously.

Now, ACR also fails when there is corrupt MD table indexes. For instance, if the YEMPLOYEE table is corrupt(information can be found in tcode RSDDBIAMON) in one of the blades and rebuilding also does not work. In this case, we need to restart the BWA, build Y table indexes and then re-run the ACR. This is a dangerous situation which if not taken into account can have the production hangng for hours/days.

It is also a good practice to have all BWA built before the ACR begins as the existing indexed records can be used as opposed to recreating the indexes in the ACR itself which might increase runtime.