0000903886 change run 1

7/25/2019 0000903886 change run 1

http://slidepdf.com/reader/full/0000903886-change-run-1 1/4

SAP Note

Header Data

Symptom

This note provides detailed information about the hierarchy/attribute change run in BW3.X.This information should help you to better understand this important BW process from a technicalpoint of view and it should therefore also simplify the analysis of problems.

Other Terms

Attribute and hierarchy change run, ChangeRun, FAQ

Reason and Prerequisites

If you change master data (navigation attributes) or hierarchies of a characteristic that iscontained in aggregates, you must adjust these aggregates. This ensures that queries that access theInfoCube or assigned aggregates are consistent. Unlike in the aggregates, no data that refers tonavigation attributes or hierarchies is stored in the InfoCube. The master data or the hierarchytables are joined with the tables of the cube when the query is executed.Regardless of whether or not aggregates exist, the system does not automatically transfer masterdata record changes, rather you must activate this master data explicitly. If aggregates areinvolved, you must adjust them using the change run before you can 'release' the data record changes(the corresponding InfoObjects or hierarchies are registered for the next change run: Transaction

RSA1 -> Tools -> Apply Hierarchy/Attribute Change -> InfoObject List or Hierarchy List).

Solution

Point [I] outlines the most important process steps and point [2] describes how you can analyzeproblems that may occur when you execute the change run.

l [I] Change run

(A)-(F) Important process steps(1) Restarting a change run that was interrupted (2) Multiple parallel change runs (3) Adjusting time-dependent aggregates(4) 'Blockwise reading' (5) In which cases can you not use the delta procedure? (6) Table RSDDAGGRMODSTATE

l [II] Analyzing problems

(A) Obtaining more information (B) Canceling a change run manually (C) Change run monitor (D) Performance

l [I] Change run

You can use the Administrator Workbench or process chains to start a change run.The most important parts are processed in the RSDDS_AGGREGATES_MAINTAIN function module.

(A) First, the system collects all relevant InfoObjects and hierarchies and then it determines therelevant aggregates and cubes.During this time ('start phase'), the system must be locked so that the master data, hierarchies andaggregates (rollup, filling new aggregates) cannot be changed. For more information, see Note 825927(Note 730980).

(B) The actual 'processing phase' of the change run is started. A new detailed lock (SM12:CHANGERUN) is set and the first lock (CHNGRUN_ST) is released. For more information, see Note825927.

903886 - Hierarchy and attribute change run

Version 3 Validity: 08.04.2011 - active Language English

Released On 08.04.2011 14:22:37

Release Status Released for Customer

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

Priority Recommendations / Additional InfoCategory Consulting

7/25/2019 0000903886 change run 1


(C) A 'loop' across all relevant Infocubes is run and one InfoCube after the other is processed. Youcan process the InfoCubes in parallel to improve performance. For more information, see Note 534630.

(D)One aggregate after the other is changed for a specific InfoCube. This process is carried outfollowing the aggregate hierarchy (aggregate tree). There are three different adjustment modes:

(D1) D delta mode: In this mode, the aggregates are adjusted using a delta request that containsthe changes. You can define a value for this in Customizing to specify a percentage of changes (tomaster data or hierarchies) as of which the delta procedure should be switched to reconstruction:Transaction SPRO: BW Customizing - BW - General BW Settings - Parameter for aggregates ortransaction RSCUSTV8 (corresponds to field DELTALIMIT in table RSADMINC).Zero means that all the aggregates are always reconstructed (this normally has a negative impact onperformance). We recommend that you start with a value of approximately 20%. However, you may alsowant to test other values.

(D2) R rollup: If you have adjusted the 'parent aggregate' using the D mode, you can use a rollupto transfer the corresponding request to the 'child aggregate'.

(D3) N reconstruction: When the delta limit is exceeded, the aggregate is reconstructed. Duringthis process, fact tables (without contents) of the relevant aggregate are copied (forexample, /BIC/F100001 and /BIC/E100001 are copied to /BIC/F200001 and /BIC/E200001) and filledagain. The 'old' tables are deleted later and the /BIC/F,E2 tables are renamed.

(E)Once you have processed all the aggregates of all relevant InfoCubes, you can release the newdata in the aggregates and activate the new master data (hierarchies). This occurs in one logicalunit of work, that is, if the program terminates, the system executes a rollback and neither thechanged aggregates (new data in the aggregates), nor the new master data is 'visible'.Releasing the aggregate changes depends on the mode you are using. If you use D and R, thecorresponding requests are released for reporting. If you use the N mode, the /BIC/F,E2 shadowtables are renamed (and the 'old' fact tables are deleted).

(F)If you choose this, the system compresses the aggregates. For more information, see Note 583202.

Important note:

(1) If the change run terminates (or if the administrator cancels it), not much work has to berepeated when the change run is started again. The system starts with the last aggregate that wasbeing adjusted when the process terminated. All changes to the other aggregates are saved inthe /BIC/F,E2 tables or in the requests that have not been released yet (mode R and D).If a change with specific selections (for InfoObjects or hierarchies) is terminated and you startanother change run (with different selections), the system restarts the change run that wasterminated. This means that the system uses the selection from the process that was terminated. Youshould see the following message in the log: 'Restarting change run. Original entries are used!'

(2)You cannot execute several change runs in parallel (do not confuse this with the 'parallelprocessing' described in Note 534630). For more information, see Note 825927.

(3)There is another separate process that deals with adjusting aggregates with time-dependentnavigation attributes or hierarchies. You can only start this process using a process chain. Theprocess type is 'Adjusting time-dependent aggregates'. This change run type does not activate

changed master data, rather it adjusts the aggregates with regard to the key date. If you define anaggregate (transaction RSDDV), the system requests a key date (or a key date variable) if you areusing time-dependent objects. The query can only use an aggregate like this if the key date of thequery is the same as the key date of the aggregate. Therefore, if you do not execute a 'time-dependent change run' for a while, the queries may not be able to use certain aggregates.

(4) Blockwise reading: If numerous aggregates have to be reconstructed in a change run, theBLOCKSIZE parameter may be very important and useful. In addition to the DELTALIMIT parameter(point (D1)), you can define the BLOCKSIZE parameter (table RSADMINC) in Customizing. If the E or Ftable of the source for the aggregate construction is larger than this parameter, the system doesnot read the source in one go, rather it divides it into blocks. This ensures that the temporaryPSAPTEMP tablespace does not overflow if the cubes are very large. Since, if the blockwise procedureis used, all data records are processed by the application server before they are written to thefact tables (unlike when you use the 'direct' construction), this may cause longer runtimes.The division into blocks is based on a characteristic, the value range of which is divided intointervals. The system only reads the data from such an interval from the source and writes it to theaggregate.

If you have not maintained a value for the BLOCKSIZE parameter in Customizing (or if the value iszero), the system uses the default value, which is 100,000,000 (for ORACLE).The program tries to use a partitioning characteristic (for example, request ID for the F table ifyou are using ORACLE or a corresponding time characteristic for the E table) as a blockcharacteristic. If not enough blocks can be created with this, the system tries to find anothersuitable characteristic. If the block characteristic is NOT the partitioning characteristic, thismay increase the runtime because the system must read ALL partitions each time it reads a block.(See Note 653469).If you are using ORACLE, we recommend that you choose the largest BLOCKSIZE as possible.

(5) D delta mode: The delta procedure is only used for aggregates that have InfoCubes that containkey figures that can be summarized or non-cumulative key figures. If there are key figures with theMINIMUM or MAXIMUM aggregation in the InfoCube, the aggregates must be reconstructed completely.

(6) RSDDAGGRMODSTATE: If a change run is running or was terminated, the system displays acorresponding entry (CNSID) for which the CLOSEDFL field is empty in the RSDDAGGRMODSTATE table.Once the change run has been completed successfully, the system sets the value of this field to X.DO NOT manually change this table (if problems occur) to 'artificially' end a change run. Thiscauses inconsistencies in the system and in the aggregates.

l [II] Analyzing problems

If a change run terminates, you can restart it without problems and the system does not have torepeat much work. Only when this process has been completed successfully does the system release thelock and processes such as the rollup are possible again. (For more information, see Note 825927).Only then is the current master data active and available for reporting.

7/25/2019 0000903886 change run 1


(A) If you do not yet know the why the termination occurred, use transactions SM37, SM21, ST22, ST04(alert log), SLG1 and SM50 ('devtrace') to see if you can find out more information. If, forexample, there is a database error message in the syslog (transaction SM21), this may already helpyou to find the reason for the termination. There are also other error messages that may help you,for example to find hints regarding the reason of the problem.

(B)If the process 'hangs' (that is, if the system does not seem to be doing anything for a longperiod of time), you can use transaction SM50 (without core) to terminate the process and restart itafter you have carried out an analysis. The job details (transaction SM37) for a change run help youto find the application server and the work process number, which will then enable you to correctlyidentify the process in transaction SM50. If you execute the change run in parallel (Note 534630),there may be further dialog processes in addition to the batch job. For example, if there are twocubes and you have selected parameter CR_MAXWPC >= 2, there are two more dialog processes inaddition to the batch process. If you want to cancel the change run, you must first cancel the batchprocess and then all (assigned) dialog processes that are still running.

(C) The change run monitor (transaction changerunmoni or program RSDDS_CHANGERUN_MONITOR or RSA1 -> Tools -> Hier.Attr.ChangeRun -> 'Change Run Monitor') displays the current status (for example,the change run has been terminated) and it provides other interesting information about the changerun that is currently running. Here you can see which InfoObjects or hierarchies are to be activatedand which InfoCubes and aggregates are affected by this. The system also displays the number ofchanged data records for each InfoObject. This enables you to estimate the scope of the changes andthe runtime. Furthermore, you can see which of the aggregates have already been adjusted and thushow far the process has progressed. If you do not execute the processes in parallel (that is, youexecute them for each InfoCube separately, see Note 534630), you can see directly which aggregate iscurrently being processed. If there are parallel processes, the system assigns a dialog process toeach InfoCube. This means that the overall process is more complicated. For more information, seeNote 825927.If you know which aggregate causes the problem, you can deactivate this aggregate (RSDDV) andrestart the change run. If this is not sufficient (and you must finish the change run as soon aspossible), deactivate all aggregates that have not yet been adjusted that you can find in the changerun monitor. Once you have done this, the change run should finish quite quickly because it only hasto release the changed aggregates for reporting and then activate the master data or hierarchies.

After this process has been completed, you can reconstruct all deactivated aggregates.

(D) If performance problems occur, note that the runtime of the change run depends on the followingfactors, in particular:-The scope of the changes to master data or hierarchies.-The size of the relevant InfoCubes and aggregates.-Database-dependent factors, such as the status of the statistics and the corruption of indexes.-The values of parameters BLOCKSIZE and DELTALIMIT.-The number of partitions of F and E tables of the InfoCube and the aggregates.-Whether or not the change run is executed in parallel.-The general system load.If a change run takes longer than you expect, use the monitor to check whether there are more masterdata changes than usual. You can use transaction RSRV to check statistics and indexes. If you haveactivated the BW statistics for the relevant InfoCubes, the system stores important informationabout the runtime of the change run for each aggregate in the RSDDSTATAGGR table. For example, youcan find information about the mode that is used and how much time was required to set up the indexand statistics. Furthermore, the table also specifies the time if aggregates are compressed. All

this information may be very useful when analyzing performance problems.If you are using an ORACLE database, check if there not already too many partitions for the Ftables of the cubes and aggregates. In ORACLE, the system creates a separate partition for eachrequest that is loaded and this often and leads to an unacceptable situation without you noticing.Read Note 590370 and compress the cubes as far as possible. This note also mentions the RSORAVDVreport that provides a quick overview of the situation.

Validity

References

This document refers to:

SAP Notes

This document is referenced by:

Software Component From Rel. To Rel. And SubsequentSAP_BW 30B 30B

310 310

350 350

1388570 BW Change Run

825927 The BW Changerun: CR_MAXWAIT 730980 Realignment run blocked when started

653469 Pre-analysis of aggregate filling

590370 Too many uncompressed request (f table partitions)

583202 Realignment run and condensing

534630 Parallel processing of Change Run

7/25/2019 0000903886 change run 1


SAP Notes (7)

653469 Pre-analysis of aggregate filling

825927 The BW Changerun: CR_MAXWAIT

1388570 BW Change Run

590370 Too many uncompressed request (f table partitions)

730980 Realignment run blocked when started

534630 Parallel processing of Change Run

583202 Realignment run and condensing

0000903886 change run 1

Documents