If
hierarchies and attributes for characteristics have changed, then it is
necessary to make structural changes to the aggregates in order to
adjust the data accordingly.
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.When a master data is modified or
changed it gets loaded into the master data table as version "M". It is
only after a attribute change run that the master data becomes activated
i.e. version "A".If hierarchies and attributes of characteristics
belonging to an Info Cube have been changed, It is a necessary to make
structural changes to the aggregates in order to modify the data
accordingly.
Attribute change run replace activating of master data ? Yes, Both do the same function- make "M" status records to "A" status.
ACR will do the activation of master data if and only if the characteristic’s attributes are used in the Aggregate. And also it refreshes the Aggregate with new attributes. That why you cannot see all available characteristics (in the system) in the list of characteristics in the screen of ACR.And ACR is not required and of course you cannot use ACR for activating the Characteristics whose attributes are not used in any aggregate.
USE: When we load Master data, the attribute change run is run to activate
and adjust the master data with the existing data.Unless the change run
is run, chances are transaction data loads may fail for lack of master
data and reports may not display correctly even if the master data is
loaded.If we have aggregates on the cubes, then the new or changed
master data is adjusted with the aggregate tables during the change run.
Debug:
I would suggest double click on the cancelled job(in SM37), and view the Job Log to find out the reason for the failure of the job.You can also restart the change run using transaction CHANGERUNMONI, refer to Note 915515 for more details.
Or
look at SM50 if process is still active and check also with ST22 if there are dumps.
Or
there could be a lock situation. remember SAP doesn't allow 2 attr changeruns at the same time.
I would suggest double click on the cancelled job(in SM37), and view the Job Log to find out the reason for the failure of the job.You can also restart the change run using transaction CHANGERUNMONI, refer to Note 915515 for more details.
Or
look at SM50 if process is still active and check also with ST22 if there are dumps.
Or
there could be a lock situation. remember SAP doesn't allow 2 attr changeruns at the same time.
No comments:
Post a Comment