Ansicht
Dokumentation

APO-CA: liveCache Recovery ( RELNAPO_30A_SP1_CA_LCR )

General Material Data   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.

Short text

APO-CA: liveCache Recovery

Use

As of APO Release 3.0A (First Customer Shipment and Support Package 1), you can reactivate the liveCache in the event of a crash using liveCache Recovery. Up to now, you could only restore the liveCache condition of the last checkpoint. Any changes performed between two checkpoints (with an interval of 60 minutes) were therefore lost. If programs now transfer changes to transaction data by means of the interface, the system asynchronously saves a copy of the changes in the liveCache log area (LCLB). If the liveCache crashes, the system imports the data from the liveCache log area to the liveCache. You do not have to perform a complete data transfer of the transaction data changed since the last checkpoint.

The log area is created on two levels. Only one area is ever active between two checkpoints, while the second is deleted. This ensures that the log area is not infinitely large, and that the duration of a data transfer in the event of a recovery is not unnecessarily long.

A distinction is made between synchronous liveCache logging and CIF / BAPI-based (asynchronous) liveCache logging.

If synchronous liveCache logging occurs, all changes in the liveCache are logged synchronously, in other words, logged in the current transaction. If asynchronous CIF/BAPI-based liveCache logging occurs, the data is only logged if the APO System receives the data from a linked OLTP System or has sent data to such a system.

The performance of the APO System is better overall if CIF/BAPI-based liveCache logging occurs as opposed to asynchronous liveCache logging. However, in this case you cannot restore data changes that have not (yet) been sent to a linked OLTP System in the liveCache. Because this is not valid for data that was exchanged with a linked OLTP System before the liveCache crashed, a consistent condition is guaranteed between the APO System and all linked OLTP Systems after a recovery.

The system does not take changes to master data into consideration when applying the recovery function. As a result, changes to the transaction data that are caused by changes to the master data are not recorded. Before execution of the recovery function, therefore, the active plan version 000 is compared with the status in the APO database.

Effects on Data Transfer

A normal program run is not possible in SAP APO when you execute the recovery function. This means that changes to the transaction data cannot be recorded. This should prevent any changes to transaction data that occur during the recovery from being lost. A continuous program run is possible in the R/3 System, as changes are buffered.

Effects on System Administration

Because the recovery function can execute changes to the transaction data immediately in SAP APO, this function is reserved for system administrators. Moreover, objects with a possible influence on the support package strategy must be modified in SAP APO 2.0. You can configure logging behavior without any modifications by means of a report in APO 3.0.

Effects on Customizing

In the standard SAP APO system, liveCache logging is normally switched off. In order to activate it, you must activate the include /sapapo/om_liveCache_log. Activating the include in SAP APO 2.0 is regarded as a modification. For this reason, you should note that this include is not overwritten when subsequent support packages are imported. Otherwise, live Cache logging would be switched off once again after importation of the support package. Moreover, you must configure the system periodically and on an hourly basis using the report /sapapo/om_checkpoint_write in order to start generation of the checkpoints.

CPI1466 during Backup   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 3956 Date: 20240425 Time: 145048     sap01-206 ( 109 ms )