SAP Netweaver Business Intelligence BI / BW

Symptom

This note provides detailed information about what has changed regarding the Hierarchy/Attribute Change Run (CR) with BW7x. In combination with note 903886 (which is only valid for BW releases BW3x) it should give you a good overview of this important BW process from a technical point of view.

Other terms

attribute and hierarchy change run, ChangeRun, FAQ, Hierearchy/Attribute Changes for Reporting

Solution

What has changed:
(A)Multiple parallel Change Runs are possible
(B)Parallel processing of affected aggregates
(C)Determination of the change mode
(D)Compression of aggregates
(E)Locking concept
(F)Restart of Change Runs
(G)Change Run Monitor
(H)Aggegates are switched off for queries

(A)Multiple parallel Change Runs are possible

In contrast to BW3x systems it is possible to run multiple CRs in parallel with BW7x. This is only allowed if the CRs do not interfere with each other, meaning that the lists of master data and hierarchies to be activated are different, and that the changes affect different InfoCubes. Note 534630 (’Parallel processing of Change Run
‘) isn’t relevant any longer!

(B)Parallel processing of affected aggregates

The system collects all affected aggregates and then sorts them according to the estimated runtime. For each aggregate a seperate job is started, the name is made up of BICHNG_ and a long technical ID. Before the job gets executed it is checked whether the maximum number of parallel processes is already reached. In addition it’s verfied whether the ‘parant aggregate’ isn’t adapted right now and can be used as a ’source’.
The number of parallel processes can be customized with transaction RSBATCH. In case of process chains, it can be customized per chain. If nothing is maintained the default number 3 is taken.

(C)Determination of the change mode

As discussed in note 903886, there are three different modes how aggreagtes can be adapted. In the so called delta mode D, the aggregates are adjusted using a delta request that contains the changes. The way how the system estimates the percentange share of data in the aggregate which will change, has been improved with BW7x. In BW3x releases only the master data was taken into accout. With BW7x it is determined how often the changed values are booked in the cube.
Let’s discuss the details with the help of a simple example:
You have changed master data to 3 navigation attributes (B,C,G) of the two infoobjects A and D:
A__B was changed for 10 records
A__C was changed for 20 records
We assume that in total 25 data records were changed (in the P-table) of the infoobject A (meaning that there are 5 data records where both attributes were changed).
D__G was changed for 30 records
Aggregate AGGR1 uses the following navigation attributes (with * in the definition):
A__B
D__G
In general, two dimensions are affected in the corresponding cube: DIMA and DIMD. Lets assume that in both dimensions we have a total of 1000 records. Then its checked how often the changed values are booked in the dimensions. If we assume that the 25 values of the infoobject A are booked 50 times and the 30 values of infoobject B are booked 100 times, the following calculation is carried out:
%T = (50 / 1000)*100 + (100 / 1000)*100 = 15%
If %T is larger than the ‘DELTALIMIT’ the aggregate will be reconstructed. Please note that regarding A the total of 25 (and not 10) was taken.
Changes to Hierarchies are treated the same way and added to %T.

(D)Compression of aggregates

In contrast to BW3x, the aggreagtes are now compressed automatically at the end of the Change Run (up to the required request, e.g. see the field COMPR_AGGR of table RSMDATASTATE for the affected cube). For each aggregate a seperate job is started, the name is made up of BICOND_ and a long technical ID. As for the adjustment of aggregates, all this jobs are executed in parallel.
Please note that its still possible to avoid the compression by setting an RSADMIN paramter, for more details see note 1117724.

(E)Locking concept

Note 825927 describes in detail the two locks CHNGRUN_ST and CHANGERUN set during the change run. The main concept has remained the same with BW7x, but please take into account the following points:
- as already mentioned above, it’s possible to execute more CRs in parallel with BW7x (so more than one can be in the phase ‘WORK’).
- if a change run does not get the lock CHANGERUN it releases the lock CHNGRUN_ST as well. Then the system waits 30 seconds and tries it again. This is done as long as the time defined with the parameter CR_MAXWAIT has not been exceeded.

(F)Restart of Change Runs

If you want to restart a canceled Change Run CR1 you can do this e.g. in the Change Run Monitor. It might happen that another Change Run CR2 is executed in the meantime which contains one of the characteristics (or hierarchies) of the terminated one. In such a case CR1 (instead of CR2) is executed and you get a warning (RSDD117) in the log that not all characteristics and hierarchies were processed of CR2.
Please see notes 1326211 and 1085914 for further details to this topic.

(G)Change Run Monitor

The Change Run Monitor (transaction changerunmoni or program
RSDDS_CHANGERUN_MONITOR) has been improved as well with BW7x. In addition to many details to the current situation on the system you can now also get information displayed to already finished CRs (button ‘Details of earlier Change Run’).
If there is a canceled CR you can restart it by clicking on the button ‘Restart Change Run’. In case this canceled change run hasn’t yet adjusted any aggregate, the button ‘Reset Status’ appears. By using this feature you can restore the original status and immediately release the locks on processes like ‘loading master data’ and ‘roll up’.
As in BW3x systems, this monitr provides the information about which which aggregates have already been adapted and which are still waiting (regarding a certain running or terminated CR). In case of a terminated CR it might be reasonable to deactivate all the remaining aggregates and then start the CR again – for more details please see note 903886.
Another important point hasn’t changed either: please never ‘close’ a CR manually since this may lead to an inconsistent state (see note 1053605).

(H)Aggegates are switched off for queries

During the time when the aggregates are adjusted they are not used by any queries. In transaction RSDDV you then can see that these aggreagtes are switched off (grey light). For more details please see note 994005.