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 Strategies to Adapt Aggregates : There are different strategies to adapt aggregates in a changerun: structures and the modified aggregates.

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. InNetWeaver 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) 2) 3) 4) BICHNG_* >> Rebuilt Job BIACTI_* >> For master data activation BIROLL_* >> Aggregate Roll up Job 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 LOADING: Indirect selection: Reference to an InfoPackage, which must activated 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. which you can define with

REPORTVARIANT: Indirect selection: Reference to a change run variant

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