Attribute Change Run (ACR)

Why Attribute Change Run?

A change run refers to the:

• Activate master data changes to attributes and hierarchies
• Realign aggregates containing navigational attributes
• Realign aggregates defined on hierarchy levels

To activate new master data, a change run must be performed, even though the attribute or hierarchy is not used in any aggregate.

Note :

Master data activation can be done in two ways : 

1) Go to RSA1 >> Right click on the infoobject >> Activate Master data. But this method is only possible if no Aggregates are existing.


2) Automatic activation by Change Run.This method is recommemded.

New master data is available for reporting only if the change run has finished successfully.

The change run:

• If changes are made to attributes or hierarchies from characteristics used in aggregates, the structure of the aggregates also needs to be changed. Generates all aggregates that are affected (in all InfoCubes) with a new change ID (CNSID). This ensures that queries that access to the InfoCube or assigned aggregates are consistent.

• Activates all hierarchies and attributes (updates the data records).

• Sets the pointers to the right change ID, so that reporting can use the new structures and the modified aggregates.

Strategies to Adapt Aggregates : 

There are different strategies to adapt aggregates in a changerun:

• Rebuild the aggregate
• Delta Mode
• Rollup from previously adapted aggregate (Parent ->Child Aggregates)

For InfoCubes containing key figures with aggregation MIN/MAX,  the only way to adapt the aggregates in a changerun is rebuilding them.

Look into  the following figure....................The value 'Limit with Delta' determines the percentage of master data  changes at which the delta mode is to be switched to reconstruction. Aggregates are not completely rebuilt if the percentage of changes is below a certain threshold. This value can be changed.

SPRO >> SAP Reference IMG  >> SAP Customizing Implementation Guide >> SAP NetWeaver >> Business Intelligence >> Performance Settings >> Parameters for Aggregates. (Tcode : RSCUSTV8)

It depends on the requirement. Rebuilding of Aggregates will take more time.



Block Size : This parameter use to determine the block size when building aggregates. If the E or F table of the source for the aggregate structure is larger than the BLOCKSIZE parameter in table RSADMINC, the source is not all read at once, but is divided into blocks. This prevents an overflow of the temporary table space PSAPTEMP. A characteristic whose value range is divided into intervals is used to divide the source into blocks. Data from the source is read from these intervals only and is then written to the aggregate.

There is no recommended size for the BLOCKSIZE, since the various databases that the BI system supports differ significantly.

If no value is maintained for the BLOCKSIZE parameter in Customizing (activity in IMG: Parameters for Aggregates), or if the value is 0, the BI default value of 100,000,000 is used.

Wait Time: An immediate Change Run start may not be possible  because other processes hold  necessary locks (e.g Master Data Loading, Roll Up, ...).

The Wait Time specifies the time in minutes how long a Change Runs waits before terminating.

New since NetWeaver 2004s:

- Change Runs are executed only with background processes
- The parallel degree can be set in Customizing or transaction RSBATCH 
Or, Go to RSA1 >> Tools >> Apply Hierarchy/Attribute Change ...>> there click on Parallelism and set "Number of Processes"

• The Change Run combines different steps which are processed sequentially
• Each of the steps is restricted by the maximum number of parallel jobs (N) chosen in Change Run Customizing
• There is 1 Managing job
• There are maximal N-1 working job

Monitoring Change Run :

If an Attribute change run is run using a Process Chain, then the Job name will be BI_PROCESS_ATTRIBCHAN. In NetWeaver 2004 all the Child Jobs of the main Job run in Background. We can monitor these Jobs in SM37. 

Sequence of these Childs jobs are as follows :

          1)    BICHNG_* >> Rebuilt Job
          2)    BIACTI_*  >> For master data activation
          3)    BIROLL_*  >> Aggregate Roll up Job
          4)    BICOND_* >> Compression Job

         This facility is not available in BW 3.X. 

         Here we have to use the Program : RSDDS_CHANGERUN_MONITOR.

         Otherwise u can go to the Change Run Monitor through RSA1.

         RSA1 >> Tools à Apply Hierarchy/Attribute Change ...>> there you    
         will get  the  Tab "Monitor and Start Terminated Change Run".

• In RSA1 you can also check the Change Run Log...

          RSA1 >> Tools à Apply Hierarchy/Attribute Change ...>> Select the required Change run and click on the "Log" Tab.

• If a Change Run is executed through RSA1, then the Job name will be BI_STRU*.

          For this......Go to RSA1 >> Tools à Apply Hierarchy/Attribute Change ...>> Here from the Infoobject List select the desired infoobjects for which you want to run the     Change run >> Then click on Execute.

You can access the same screen through........RSA1 >> Administration >> Change     Run.

• We can also execute the Change Run using the Program : RSDDS_AGGREGATES_MAINTAIN, there enter the list of Infoobjects à In the top "Program" Tab à Execute in Background.Always execute in background, bcoz then only you will be able to monitor the Job using SM37.If you just press F8 and execute the Change run, then you will not be able to trace the Job.In this case the Job name will be RSDDS_AGGREGATES_MAINTAIN.

      We can monitor all these jobs through SM37.

Technical details about Change Run :

Step 1(usually less than 1min):

 When the Change Run starts a global SAP enqueue lock is set.
 This global lock is hold just for a short time until the affected
 infocubes are identified. This global enqueue lock doesn't allow

• any master data loads to InfoObjects
• starting another Change Run
• rollup to an aggregate

Step 2:

After the global lock was removed just a smaller enqueue lock is set. It locks just the affected Infoobjects and the InfoCubes where the infoobject is used. Furthermore some activities are not allowed during the Change Run works

• master data loads to the affected InfoObjects, but master dataload to other InfoObjects
• rollup for InfoCubes having aggregates affected by the Change Run

Attribute Change Run Collision :

Major problem with Attribute Change Run is that In any SAP System only One attribute change run can run at one point of time. i.e. If one attribute change run is running in system from any process chain or for any project and 2nd one fails, if start at same time due to locking problem. Due to this entire data load fails.( In NetWeaver 2004 two or more Change Runs in WORK-Phase can run in parallel , provided if the Change Runs process different objects )  

Solution : 

1. Shift Change runs from info package level to global level and/or process chain level in order of priority. Means instead of keeping ACR after each infopackage update we can accumulate all in one ACR at end of Process Chain or in a separate chain, if this data is not dependent for next loads(means no look ups). 

2. Increase CR_MAXWAIT time ( In NetWeaver 2004 by default CR_MAXWAIT = 1 min) . CR_MAXWAIT is to create a delay for second attribute change run while the first attribute change run is running in the system. At any single point in time, there can only be one CR in the start phase . Every other CR will immediately fail when unsuccessfully trying to acquires the start lock. No wait is done here.

Above option is helpful When the running CR is in the work phase , only then will a second CR enter the start phase and wait as long as specified in CR_MAXWAIT. And when the second CR is in the startphase, all other CRs trying to start will again immediately fail. 

For more info : SAP Note : Note 825927 - The BW Changerun: CR_MAXWAIT .This is not 100% solution. 

3. Created an ABAP Program and included before each Attribute Change Run in Process Chains. This Program checks if any ACR running in the system or not. If any ACR is running it delays 10 Secs. Recursively it checks and delays 10 secs every time. Program execution finishes only when there is not ACR running in the system and allows next process(Attribute Change Run) to trigger in Process Chain. After implementation of this program no ACR failures in our system. Check the coding at end of this blog in appendix.   

How to implement:

Step1: Create an ABAP program(eg: ZRSDDS_CHANGERUN_MONITOR), coding available at Appendix. create a variant aswell for no of sces neets to wait at max.

Step2: Include this ABAP program in Process Chains between infopackage and Attribute Change runs as shown in the screenshot.

Step3: Goto Process Chain(TCode: RSPC) and choose perticular process chain, then goto processes and choose ABAP program provide technical name and description. Provide created ABAP program and Variant save and activate Process Chain.

Also Check the following Notes :

Note 903886 - Hierarchy and attribute change run
Note 825927 - The BW Changerun: CR_MAXWAIT         

Attribute Change Run in Process Chain :

If you assign the process type Attribute Change run to a process chain, you must define a variant. With this variant, you have to define the InfoObjects for which you want to activate the master data. There are four different possibilities:    

• HIERARCHY: Direct selection of the hierarchy, which need to be activated 

• INFOOBJECT: Direct selection of the infoObjects, which need to be    activated

• LOADING: Indirect selection: Reference to an InfoPackage, which must   be loaded before in the process chain. Combined with the metadata of    these objects and the instance information the system derives the affected InfoObjects and hierarchies. If the chosen LOADING object is not in the process chain, the system automatically inserts the chosen infopackage in the process chain.

• REPORTVARIANT: Indirect selection: Reference to a change run variant  which you can define with RSDDS_AGGREGATES_MAINTAIN (SE38) or TCode RSATTR → Executing the Attribute/hierarchy change run with Variant.

Note : 

Instead of applying the InfoObjects or hierarchies directly to the process variant in RSPC you can create a central variant for the report RSDDS_AGGREGATES_MAINTAIN. You can assign InfoObjects and hierarchies to this report variant. This central variant could be used by several process variants in RSPC. The benefits are central maintenance. Using a reference object like LOADING or REPORTVARIANT is sometimes more flexible.

Terminated Change Run :

We should not cancel any Change run.Because if we manually cancel any change run,lock will never get released, until we repeat the terminated Change run(Change Run id should be same).

Also when a Change Run get cancelled automatically ,we should check the Job Log. If it is a Terminated Change Run, then again we should repeat the Terminated Change Run, then only lock will get Released.

For this......

Go to RSA1 >> In the top TOOLS tab >> Select Apply Hierarchy/Attribute Change  >> Click on Monitor and Start terminated Change run >> there click on Start Change run with Set Filters.........it will restart the Terminated Change run.....

We can also use the Program : RSDDS_CHANGERUN_MONITOR