Attribute Change Run concepts

Simple to understand ing about Attribute Change Run .

Attribute change run is nothing but adjusting the master data after its been loaded from time to time so that it can
change or generate or adjust the SID's so that u may not have any problem when loading the transaction data in to data
targets. It is used for realignment of the master data..

Whenever master data attributes or hierarchy is loaded an attribute change run need to be performed due to the
following reasons:

1. When a master data is changed/updated it gets loaded into the master data table as version "M"(modified).

It is only after a attribute change run that the master data becomes activated i.e. version "A".

2. Master data attributes and hierarchies are used in cube aggregates also. So to do update the

latest master data attributes values in the aggregates attribute change run need to be performed.

You need to schedule an attribute change run when you change master data attributes or hierarchies that are used as
navigational attributes or in aggregates.

There is a simple test to check if you need an aggregate change run.

Have a Load your attributes and look into the master data table (directly via SE16). If you only have entries with
OBJVERS = 'A' (active) then you don't need a change run.

If you have entries with OBJVERS = 'I' then you need to schedule a change run after upload. When ever your master
data changes , you can have a full or delta load .

The hierarchy/attribute change run which activates hierarchy and attribute changes and adjusts the corresponding
aggregates is divided, into 4 phases:

1. Finding all affected aggregates

2. set up all affected aggregates again and write the result in the new aggregate table.
3. Activating attributes and hierarchies
4. rename the new aggregate table. When renaming, it is not possible to execute queries.

In some databases, which cannot rename the indexes, the indexes are also created in this phase.

T.code : RSATTR

Menu path : RSA1àTools MenuàApply Hierarchy/Attribute Change Runà Select the infoobject from the
Infoobject List >> then Execute.

Program : RSDDS_ATTR_CHANGERUN

To Monitor Change Run :

ABAP Program RSDDS_CHANGERUN_MONITOR can be used to monitor the Change Run Progress.

Issues :

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.

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. 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 Change run is in the start phase, all other change
runs trying to start will again immediately fail.

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

Using ABAP Program How to avoid the Attribute Change Run :

Check this link : http://sapbwneelam.blogspot.com/2007/08/how-to-avoid-attribute-change-run.html

Useful Links :

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/17435

https://forums.sdn.sap.com/thread.jspa?threadID=397043&messageID=6992536

SAP Note : Note 825927 - The BW Changerun: CR_MAXWAIT .

Thanks

VH