Know about HACR

All of us are confused with HACR most of the times. Is it that difficult.
Let us analyse the situations here:-
Why Do we need HACR?

If you change master data (navigation attributes) or hierarchies of acharacteristic that is contained in aggregates, you must adjust theseaggregates. This ensures that queries that access the InfoCube orassigned aggregates are consistent. Unlike in the aggregates, no datathat refers to navigation attributes or hierarchies is stored in theInfoCube. The master data or the hierarchy tables are joined with thetables of the cube when the query is executed.Regardless of whether or not aggregates exist, the system does notautomatically transfer master data record changes, rather you mustactivate this master data explicitly. If aggregates are involved, you
must adjust them using the change run before you can 'release' the datarecord changes (the corresponding InfoObjects or hierarchies areregistered for the next change run: Transaction RSA1 -> Tools -> ApplyHierarchy/Attribute Change -> InfoObject List or Hierarchy List).
Point [I] outlines the most important process steps and point [2]describes how you can analyze problems that may occur when you executethe change run.
o [I] Change run
(A)-(F) Important process steps
(1) Restarting a change run that was interrupted Page 2
(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
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). Page 3
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'.
(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. Page 4
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 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 Page 5
('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 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 Page 6
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. 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.