Note 903886 - Hierarchy and attribute change run
Note Language: English Version: 2 Validity: Valid from 06.12.2006
Summary
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 technical point of view and it should therefore also
simplify the analysis of problems.
More Terms
Attribute and hierarchy change run, ChangeRun, FAQ
Cause and Prerequisites
If you change master data (navigation attributes) or hierarchies of a
characteristic that is contained in aggregates, you must adjust these
aggregates. This ensures that queries that access the InfoCube or assigned
aggregates are consistent. Unlike in the aggregates, no data that refers to
navigation attributes or hierarchies is stored in the InfoCube. The master
data or the hierarchy tables 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 master data record changes, rather you must activate
this master data explicitly. If aggregates are involved, 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 analyze problems that may occur when you execute the change
run.
o [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?
31.05.2007 Page 1 of 6
Note 903886 - Hierarchy and attribute change run
(6) Table RSDDAGGRMODSTATE
o [II] Analyzing problems
(A) Obtaining more information
(B) Canceling a change run manually
(C) Change run monitor
(D) Performance
o [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 the relevant aggregates and cubes.
During this time ('start phase'), the system must be locked so that the
master data, hierarchies and aggregates (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 Note 825927.
(C) A 'loop' across all relevant Infocubes is run and one InfoCube after
the other is processed. You can 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 out following 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 contains the changes. You can define a value for this in
Customizing to specify a percentage of changes (to master 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 or transaction RSCUSTV8 (corresponds to field DELTALIMIT in
table RSADMINC).
Zero means that all the aggregates are always reconstructed (this normally
has a negative impact on performance). We recommend that you start with a
value of approximately 20%. However, you may also want to test other
values.
(D2) R rollup: If you have adjusted the 'parent aggregate' using the D
mode, you can use a rollup to transfer the corresponding request to the
'child aggregate'.
31.05.2007 Page 2 of 6
Note 903886 - Hierarchy and attribute change run
(D3) N reconstruction: When the delta limit is exceeded, the aggregate is
reconstructed. During this process, fact tables (without contents) of the
relevant aggregate are copied (for example, /BIC/F100001 and /BIC/E100001
are copied to /BIC/F200001 and /BIC/E200001) and filled again. 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 new data in the aggregates and activate the new master
data (hierarchies). This occurs in one logical unit of work, that is, if
the program terminates, the system executes a rollback and neither the
changed 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, the corresponding requests are released for reporting. If you
use the N mode, the /BIC/F,E2 shadow tables 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 be repeated when the change run is started again. The
system starts with the last aggregate that was being adjusted when the
process terminated. All changes to the other aggregates are saved in the
/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 start another change run (with different selections),
the system restarts the change run that was terminated. This means that the
system uses the selection from the process that was terminated. You should
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 'parallel processing' described in Note 534630). For more
information, see Note 825927.
(3) There is another separate process that deals with adjusting aggregates
with time-dependent navigation attributes or hierarchies. You can only
start this process using a process chain. The process 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 an aggregate (transaction RSDDV), the system requests a key
date (or a key date variable) if you are using time-dependent objects. The
query can only use an aggregate like this if the key date of the query 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, the BLOCKSIZE 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 F table of
the source for the aggregate construction is larger than this parameter,
the system does not read the source in one go, rather it divides it into
31.05.2007 Page 3 of 6
Note 903886 - Hierarchy and attribute change run
blocks. This ensures that the temporary PSAPTEMP tablespace does not
overflow if the cubes are very large. Since, if the blockwise procedure is
used, all data records are processed by the application server before they
are written to the fact 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 into intervals. The system only reads the data from such
an interval from the source and writes it to the aggregate.
If you have not maintained a value for the BLOCKSIZE parameter in
Customizing (or if the value is zero), 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 if you are using ORACLE or a corresponding time
characteristic for the E table) as a block characteristic. If not enough
blocks can be created with this, the system tries to find another suitable
characteristic. If the block characteristic is NOT the partitioning
characteristic, this may 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 contain key figures that can be summarized or non-cumulative
key figures. If there are key figures with the MINIMUM 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 a corresponding 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. This causes inconsistencies in the system and in the
aggregates.
o [II] Analyzing problems
If a change run terminates, you can restart it without problems and the
system does not have to repeat much work. Only when this process has been
completed successfully does the system release the lock 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.
(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, for example, there is a
database error message in the syslog (transaction SM21), this may already
help you 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 long period of time), you can use transaction SM50
(without core) to terminate the process and restart it after you have
carried out an analysis. The job details (transaction SM37) for a change
31.05.2007 Page 4 of 6
Note 903886 - Hierarchy and attribute change run
run help you to find the application server and the work process number,
which will then enable you to correctly identify 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 two cubes and you have selected parameter CR_MAXWPC >= 2, there
are two more dialog processes in addition to the batch process. If you want
to cancel the change run, you must first cancel the batch process 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
change run that is currently running. Here you can see which InfoObjects or
hierarchies are to be activated and which InfoCubes and aggregates are
affected by this. The system also displays the number of changed data
records for each InfoObject. This enables you to estimate the scope of the
changes and the runtime. Furthermore, you can see which of the aggregates
have already been adjusted and thus how far the process has progressed. If
you do not execute the processes in parallel (that is, you execute them for
each InfoCube separately, see Note 534630), you can see directly which
aggregate is currently being processed. If there are parallel processes,
the system assigns a dialog process to each InfoCube. This means that the
overall process is more complicated. For more information, see Note 825927.
If you know which aggregate causes the problem, you can deactivate this
aggregate (RSDDV) and restart the change run. If this is not sufficient
(and you must finish the change run as soon as possible), deactivate all
aggregates that have not yet been adjusted that you can find in the change
run monitor. Once you have done this, the change run should finish quite
quickly because it only has to 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 following factors, 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 master data changes than usual. You can use
transaction RSRV to check statistics and indexes. If you have activated the
BW statistics for the relevant InfoCubes, the system stores important
information about the runtime of the change run for each aggregate in the
RSDDSTATAGGR table. For example, you can find information about the mode
that is used and how much time was required to set up the index and
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 F tables of the cubes and aggregates. In ORACLE, the
system creates a separate partition for each request that is loaded and
this often and leads to an unacceptable situation without you noticing.
31.05.2007 Page 5 of 6
Note 903886 - Hierarchy and attribute change run
Read Note 590370 and compress the cubes as far as possible. This note also
mentions the RSORAVDV report that provides a quick overview of the
situation.
Header Data
Note Number: 903886
Note Language: English
Master Language: German
Version of Master Language: 2
Valid from: 06.12.2006
Release Status: Released for Customer
Released on: 07.12.2006 16:03:11
Released by: Nora Roch
Priority: Recommendations/additional info
Author: Peter Stockinger
Entered by: Peter Stockinger
Processed by: Nora Roch
Last Changed by: Nora Roch
On: 07.12.2006 16:03:12
Category: Consulting
Standard Note: No
Main Component BW-BEX-OT-AGGR Aggregates (Definition and Filling)
Valid Releases
Software Component Release From To Release and Following
Release
SAP_BW 30 30B 30B
SAP_BW 310 310 310
SAP_BW 35 350 350
Related Notes
Number Short Text
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
31.05.2007 Page 6 of 6
