Checklist for Initialization of SAP APO liveCache

Version 01
27.11.2002

Dr. Volkmar A. Shner

SAP AG
GBU Development Platforms
liveCache Applications

Contents
1. Introduction ......................................................................................................................... 1
2. When is a liveCache Initialization Required? ...................................................................... 2
3. Process Flow of a liveCache Initialization ........................................................................... 2
4. Prerequisites and Procedure ............................................................................................... 4
5. Final Comments .................................................................................................................. 6
5.1 Saving the Planning Version in the APO Database ....................................................... 6
5.2 liveCache Initialization Test ........................................................................................... 6
5.3 Incomplete Initialization ................................................................................................. 7
5.4 Data Loss with a liveCache Initialization........................................................................ 7

1. Introduction
In some situations, you need to initialize the liveCache in an SAP APO system, for example,
after severe software or hardware errors, or after a failed recovery. This document explains:
- In which cases the liveCache must be initialized
- The technical consequences of a liveCache initialization
- What steps are required for a liveCache initialization
This document is valid for all current liveCache releases (that is, 7.2 and 7.4) and for SAP
APO 3.0, 3.1, and Opal. However, since this document describes underlying features, we
expect it to remain basically valid for future versions of SAP APO and liveCache.

-1-

2. When is a liveCache Initialization Required?

An initialization of the liveCache always causes long downtime for the SAP APO system.
Therefore, you should only initialize the liveCache when SAP explicitly recommends that you
do so. Normally, SAP makes such a recommendation only when there is no other way to
solve a problem.
Such a situation occurs when, for example:
-

Stored APO data (such as stock, order, ATP data, time series from Demand Planning)
or metadata (to administer APO data) is irreparably damaged or corrupt.
You were unable to perform a complete and error-free recovery after liveCache ended
abnormally.
Either you have stopped a liveCache recovery or initialization, or one of these ended
abnormally due to a runtime error, and work continued in the APO system. After an
incomplete recovery or an incomplete initialization, the APO system has an undefined
status. If you execute APO transactions in such a system, the system status remains
undefined. In this case, APO data consistency is not guaranteed. External data
consistency between APO and any attached SAP R/3 Systems and internal data
consistency between the APO database and liveCache are both at risk.

After the liveCache has ended abnormally, you need to recover the final committed state by
means of a liveCache recovery. For more information, see Checklist for Recovery of SAP
APO liveCache 7.2 or Checklist for Recovery of SAP APO liveCache 7.4. In most
situations, you do not need to initialize the liveCache and should normally avoid doing so.

3. Process Flow of a liveCache Initialization

A liveCache initialization involves the following steps, assuming you start the initialization with
transaction LC10:
Caution
Always use transaction LC10 for initialization of liveCache in an SAP APO system.
We do not recommend any other initialization method. Do not attempt to initialize
liveCache using the DBMGUI or a DBMCLI command.
1. The liveCache is stopped in the warm state. In liveCache 7.2.5, no checkpoint is
written.
2. liveCache devspaces and the log and history data in the file system of the liveCache
server are all deleted. In liveCache 7.2, if synchronous logging is active, the log areas
in the APO database are also deleted.
3. The liveCache is started
- The system tables are loaded
- The liveCache applications (COM routines) are registered
-2-

The liveCache is now in the warm state and ready for operation. The liveCache
contains no APO application data (no master data and no transaction data).
4. Deletion of the anchor tables
Transaction LC10 calls the report /SAPAPO/DELETE_LC_ANCHORS for each client
of the SAP APO system. In the APO database tables, LC10 deletes data logically
connected to data in the liveCache. This is necessary to establish consistency
between the APO database and the currently still empty liveCache. Since after
initialization the liveCache contains no data, the database should no longer contain
data connected to data in the liveCache.
Essentially the following data is deleted in APO (this list is not complete, since there
are APO release dependencies, and technical data that may be unknown to the user
is not listed):
- Change pointer (CIF)
- Operation data, especially texts of operations (PP/DS)
- Anchor for stocks (inventory management)
- Block fixing of resources (PP/DS)
- Sales order data
- Customer-specific sales order data (table /SAPAPO/ORDFLDS)
- Runtime object of iPPE (PP/DS)
- Plan transports (TP/VS)
- Anchor of the characteristics combination of the time series (Demand Planning)
- Alerts
-> Product availability (ATP)
-> Alerts from PP/DS
5. Loading of master data
The comprehensive APO master data for all planning versions is stored in the APO
database. The report /SAPAPO/DELETE_LC_ANCHORS calls APO functions, which
read master data (product-location combinations, resources including setup matrixes
and time streams, characteristic combinations, and so on) from the APO database,
converts it to liveCache structures and then constructs these in liveCache. Depending
on data volume and number of planning versions, loading the master data can take up
to several hours.
6. Loading of transaction data for the active planning version 000
After completion of the report /SAPAPO/DELETE_LC_ANCHORS, the initialization in
the narrow sense is finished. All APO master data are once again in the liveCache.
However, transaction data (orders, stock, ATP data, and so on) is lost. Therefore, the
transaction data needs to be completely transferred from the attached OLTP system to
the APO system. (If the OLTP system is an SAP R/3 System, the corresponding CIF
integration model must be activated). The runtime for this initial supply can be up to
several hours.
The initial data supply from SAP R/3 Systems only enables transaction data of the
active planning version 000 in the liveCache to be constructed, since only this
-3-

planning version can communicate with the SAP R/3 System using CIF data. (Even if
the OLTP system is not an SAP R/3 System, the initial supply generally only supplies
the active planning version.) The transaction data of the other planning versions
cannot be so restored from another system. Section 5.1 explains how you can
implement this if necessary for non-active planning versions. But first, to minimize the
downtime of the APO system, consider which non-active planning versions are worth
the effort to restore.

4. Prerequisites and Procedure

To initialize the liveCache, as described in section 3, you need to meet the following
conditions:
1. Registration of the report /SAPAPO/DELETE_LC_ANCHORS in transaction LC10
Start transaction LC10.
Enter LCA.
Choose Integration.

On the next screen, enter the report name /SAPAPO/DELETE_LC_ANCHORS in Follow-up

processing in the area Initialize liveCache:

-4-

2. RFC connection for each client

If several clients are configured in the APO system, call the liveCache initialization in any one
of these clients using transaction LC10.
The report /SAPAPO/DELETE_LC_ANCHORS then calls itself for each client. To enable this,
you must have used transaction SM59 to define a suitable RFC connection for each client, as
described in SAP Note 305634.
To check whether the RFC connections to all clients are correctly set up, in transaction
/SAPAPO/OM13 choose Checks >> RFC Destinations.
3. Definition of a suitable integration model
Since after a liveCache initialization only the transaction data from the attached SAP R/3
Systems must be transferred to the APO system, an integration model should be defined in
CIF that sends all transaction but no master data to the APO system. (This is similarly true for
-5-

non-R/3 systems). You could transfer the master data at the same time, but this would
unnecessarily lengthen the run-time.

5. Final Comments
5.1 Saving the Planning Version in the APO Database
Depending on the error situation caused by a liveCache initialization, you may be able to
save liveCache data to the APO database before the initialization, so that you can then load it
back to the liveCache after the initialization. This saves you having to transfer the transaction
data from the attached OLTP systems, so significantly reducing the APO system downtime.
The exact procedure is described in SAP Note 541644. (Note that you cannot use this
procedure with the SAP APO application Automotive / Rapid Planning Matrix.)
SAP Active Global Support recommends this procedure, but only if the error situation permits
it. Error situations are possible in which the data is so corrupt that it can no longer be read
from the liveCache. In such situations, you either cannot use this procedure or cannot use it
for all planning versions. The liveCache saves data for each planning version separately. A
single storage block (page) only contains data from one planning version. Therefore, with
corrupt blocks you may at least be able to extract the data for individual planning versions.
Planning version 000 is especially important, since it contains the active (that is, operational)
data, while the other planning versions mostly only store a snapshot of planning version 000
or are created for simulation purposes.
If you cannot save all liveCache planning versions before initialization, as described in SAP
Note 541644, try to save the planning versions one after the other to the APO database and
then load them back to the liveCache after initialization. If you can do this for the active
planning version 000, you no longer need to perform the initial data transfer from the
attached OLTP systems. If this procedure fails for a non-active planning version, it is no
longer possible to restore the transaction data of this planning version, since it cannot be
transferred from an attached OLTP system. In this case, you need to delete the planning
version, after first performing the procedure described above in section 3.
Saving the planning versions as described in SAP Note 541644 is not always possible or
advisable. Only use this procedure when SAP Active Global Support recommends it after
analysis of the acute error situation.

5.2 liveCache Initialization Test

Before starting production operation, test the initialization of the liveCache and the
subsequent data transfer from attached OLTP systems using full data volumes.

-6-

5.3 Incomplete Initialization

If the liveCache initialization ends abnormally due to an error or when the user stops it due to
long runtimes, the SAP APO system cannot be released for end users. Also, data transfer
from the OLTP systems (see section 3, point 6) is no longer applicable. If you were unable to
perform the initialization completely and without errors, the APO system is in an undefined
state. In this case, create an SAP support notification.

5.4 Data Loss with a liveCache Initialization

In the procedure to initialize the liveCache described in section 3 above, the transaction data
of the active planning version is again transferred from the attached OLTP systems following
the actual initialization. For non-active planning versions this is impossible, as already
explained.
Data loss can also occur following the transfer of transaction data from the active planning
version, because it may be that not all liveCache data is redundantly stored in the attached
OLTP systems. For example, fixed pegging relationships (that is, material flow relationships
between PP/DS or CTM orders) are not stored in the SAP R/3 System. This data only exists
in the SAP APO liveCache. Fixed pegging relationships are often used when the attached
OLTP system is not an SAP R/3 System. In this case, the fixed pegging relationships from
the non-SAP system must be transferred to the SAP APO system after initialization. Fixed
pegging relationships can also be generated by APO planning runs (for example, CTM runs).
This is configurable.
Demand Planning data is often not stored redundantly in other systems. However, you can
periodically store DP data in an APO database InfoCube.
If the attached OLTP system is a non-SAP system, other data can only exist in the liveCache.
To minimize such data losses after liveCache initialization, you need to take certain
measures after liveCache initialization. Depending on the applications used in the OLTP
system, you may be able to:
Generate the fixed pegging relationships by repeating the CTM run
Restore DP data from an InfoCube

-7-

 Copyright 2002 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The
information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft , WINDOWS , NT , EXCEL , Word , PowerPoint and SQL Server are registered trademarks of
Microsoft Corporation.

IBM , DB2 , OS/2 , DB2/6000 , Parallel Sysplex , MVS/ESA , RS/6000 , AIX , S/390 , AS/400 , OS/390 , and OS/400 are
registered trademarks of IBM Corporation.

ORACLE is a registered trademark of ORACLE Corporation.

TM

INFORMIX -OnLine for SAP and Informix Dynamic Server are registered trademarks of Informix Software Incorporated.

UNIX , X/Open , OSF/1 , and Motif are registered trademarks of the Open Group.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C , World Wide Web Consortium, Massachusetts Institute of
Technology.

JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under
license for technology invented and implemented by Netscape.
SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management
Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all
over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
Disclaimer: SAP AG assumes no responsibility for errors or omissions in these materials. These materials are provided as is without a
warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular
purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result
from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items
contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these
materials and does not endorse your use of third party Web pages nor provide any warranty whatsoever relating to third party Web pages.

-8-