0001388570 change run

7/25/2019 0001388570 Change Run

http://slidepdf.com/reader/full/0001388570-change-run 1/3

SAP Note

Header Data

Symptom

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

Other Terms

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

Reason and Prerequisites

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(I)Performance

l (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 onlyallowed if the CRs do not interfere with each other, meaning that the lists of master data andhierarchies to be activated are different, and that the changes affect different InfoCubes. Note534630 ('Parallel processing of Change Run') isn't relevant any longer!

l (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 technicalID. Before the job gets executed it is checked whether the maximum number of parallel processes isalready reached. In addition it's verfied whether the 'parant aggregate' isn't adapted right now andcan be used as a 'source'.The number of parallel processes can be customized with transaction RSBATCH. In case of processchains, it can be customized per chain. If nothing is maintained the default number 3 is taken.

l (C)Determination of the change mode

As discussed in note 903886, there are three different modes how aggreagtes can be adapted. In theso 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 BW7xit 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 (meaningthat 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__BD__GIn general, two dimensions are affected in the corresponding cube: DIMA and DIMD. Lets assume thatin both dimensions we have a total of 1000 records. Then its checked how often the changed values

1388570 - BW Change Run

Version 3 Validity: 16.05.2011 - active Language English (Master)

Released On 18.05.2011 14:18:43

Release Status Released for Customer

Component BW-BEX-OT-AGGR Aggregates (Definition and Filling)

Priority Recommendations / Additional InfoCategory Consulting

7/25/2019 0001388570 Change Run


are booked in the dimensions. If we assume that the 25 values of the infoobject A are booked 50times and the 30 values of infoobject B are booked 100 times, the following calculation is carriedout:

%T = (50 / 1000)*100 + (100 / 1000)*100 = 15%

If %T is larger than the 'DELTALIMIT' the aggregate will be reconstructed. Please note thatregarding A the total of 25 (and not 10) was taken.Changes to Hierarchies are treated the same way and added to %T.

l (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 longtechnical 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, formore details see note 1117724.

l (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 thanone 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 thesystem waits 30 seconds and tries it again. This is done as long as the time defined with theparameter CR_MAXWAIT has not been exceeded.

l (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. Itmight happen that another Change Run CR2 is executed in the meantime which contains one of thecharacteristics (or hierarchies) of the terminated one. In such a case CR1 (instead of CR2) isexecuted and you get a warning (RSDD117) in the log that not all characteristics and hierarchieswere processed of CR2.Please see notes 1326211 and 1085914 for further details to this topic.

l (G)Change Run Monitor

The Change Run Monitor (transaction changerunmoni or program RSDDS_CHANGERUN_MONITOR) has beenimproved as well with BW7x. In addition to many details to the current situation on the system youcan now also get information displayed to already finished CRs (button 'Details of earlier ChangeRun').

If there is a canceled CR you can restart it by clicking on the button 'Restart Change Run'. In casethis canceled change run hasn't yet adjusted any aggregate, the button 'Reset Status' appears. Byusing this feature you can restore the original status and immediately release the locks onprocesses like 'loading master data' and 'roll up'.As in BW3x systems, this monitr provides the information about which which aggregates have alreadybeen adapted and which are still waiting (regarding a certain running or terminated CR). In case ofa terminated CR it might be reasonable to deactivate all the remaining aggregates and then start theCR again - for more details please see note 903886.Another important point hasn't changed either: please never 'close' a CR manually since this maylead to an inconsistent state (see note 1053605).

l (H)Aggegates are switched off for queries

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

l (I)Performance

Please read the chapter D of note 903886 where you can find already a good summary of all factorshaving an impact on the runtime of this important process. This should help you to figure out theroot cause of an unexpected time consumimg change run. In case you analyze an active (running)change run its always recommended to take a look at the status of the process in the monitor. Thereyou can immediatley see how far the program got and whether there is still some progress(see alsotransaction SM50).The following points could be relevant as well:

¡ as emphasized in note 903886, many uncompressed requests in the F-table of a cube may leadto a bad peformance in various ways (see note 590370)! Please also note the following: thedelta mode D can create many requests in the F-table of an aggregate which in turn may causeperformance issues during compression or index/statistic updates. If e.g. a cube has 500

uncompressed requests and the change run involves 2 infoobjects, up to 1000 requests (the'delta' for each request and each infoobject) could be created for the aggregate. Thesituation can become even worse for big cubes as the delta update is done in packages with asize of 500000 records. Each of these packages get a seperate value for the technicalinfoobject 0CHNGID (part of the package dimension) and hence may even create more requestsin the F-table of the aggregate. For BW on MAXDB too many requests in an aggregate couldlead to the dump DBIF_RSQL_INVALID_RSQL(invalid marker count)in the form CHECK_CACHE_SIZE.In this case the affected aggregate(s) must be deactivated before you can restart thechangerun. Hence, please assure that the cubes are always compressed as far as possible!

¡ In case of InfoObjects with big master data tables (more than about 10 million records) it's

7/25/2019 0001388570 Change Run


important to assure that not too many changes are carried out in one run. Otherwise thehandling of such big changes can lead to performance problems or even to the memory relateddump EXPORT_TOO_MUCH_DATA in the function RSDDS_ATTRCHANGES_EXPORT. If you already have sucha situation in your system all affected aggregates must be deactivated in order to finishthe change run successfully. Afterwards the aggregates can be activated and filled again.Please note that the change run is not designed for such mass data changes (in the range ofmillions of records) and therefore the described workaround is necessary. This also improvesthe overall runtime since all aggreagtes have to be rebuilt (change mode N) anyway (but thehandling of the change is simplified).

Validity

References

This document refers to:

SAP Notes

This document is referenced by:

SAP Notes (9)

Software Component From Rel. To Rel. And Subsequent

SAP_BW 700 701

1326211 BW change run: Repairing a terminated predecessor

1117724 Change run and condensing (BW 7.X) 1085914 Restarting a change run results in error RSDD 85

1053605 Termination 'GET_STATE_OF_AGGREGATES_CR-2-' in change run

994005 Poor query performance when using aggregate

903886 Hierarchy and attribute change run

825927 The BW Changerun: CR_MAXWAIT

590370 Too many uncompressed request (f table partitions)

534630 Parallel processing of Change Run

1326211 BW change run: Repairing a terminated predecessor

825927 The BW Changerun: CR_MAXWAIT

994005 Poor query performance when using aggregate

903886 Hierarchy and attribute change run

590370 Too many uncompressed request (f table partitions)

1053605 Termination 'GET_STATE_OF_AGGREGATES_CR-2-' in change run

1085914 Restarting a change run results in error RSDD 85

1117724 Change run and condensing (BW 7.X)

534630 Parallel processing of Change Run

0001388570 change run

Documents