This action might not be possible to undo. Are you sure you want to continue?
Best Practice for Solution Management
Version Date: July 2005 The newest version of this Best Practice can always be obtained through the SAP Solution Manager Contents Applicability, Goals, and Requirements ....................................................................................................2 Best Practice Procedure and Verification .................................................................................................4 Preliminary Tasks ...............................................................................................................................4 Procedure ...........................................................................................................................................4 Backup and Recovery for liveCache >= 7.4.................................................................................4 Miscellaneous.............................................................................................................................20 Further Information .................................................................................................................................22
Best Practice: Checklist for liveCache Recovery liveCache >= 7.4
Applicability, Goals, and Requirements
To ensure that this Best Practice is the one you need, consider the following goals and requirements.
Goal of Using this Service
This document contains a condensed set of instructions for a liveCache backup and recovery for all applications using SAP liveCache with the exception of Business Intelligence. The SAP liveCache is used within SAP APO 3.0, 3.1, and mySAP SCM 4.0, 4.1 and 5.0 and also for WFD Server (Software component WFMCORE 200). Some parts may be only relevant for APO/SCM or WFD Server. These sections are marked accordingly. It uses a checklist approach to describe all steps necessary before going live, during system operation, and immediately after an abnormal termination of liveCache. For detailed information on BI please see note 816730.
In general, this document is a summary of the more comprehensive document APO 3.0A Backup and Recovery. However, in some places this document also provides supplementary information.
WFD Server only
This is the standard document for backup and recovery for the WFD Server (Software component WFMCORE 200).
Staff and Skills Requirements
The IT department (liveCache and database administrator) leads in the implementation of this Best Practice. Knowledge and experience in the area of database backup and recovery are required.
Normally, APO exchanges data with one or several SAP R/3 Systems. This more complex landscape of distributed and redundantly stored data has some impact on the recovery procedure for an APO system. Therefore, it is necessary to involve the team in your company that is responsible for the Core Interface (CIF) or the interface to non-SAP systems.
WFD Server only
The WFD Server does not use the Core Interface (CIF) and therefore all sections regarding CIF can be ignored.
SAP APO 3.0 was originally delivered with liveCache 7.2. Now, liveCache 7.4.2 is available for SAP APO 3.0 – see note 610316. SAP APO 3.1 and mySAP SCM 4.0 are delivered with liveCache 7.4. mySAP SCM 4.1 is delivered with liveCache 7.5. mySAP SCM 5.0 is delivered with liveCache 7.6. WFD Server (Software component WFMCORE 200) is delivered with liveCache 7.6.
© 2004 SAP AG
How to Use this Best Practice Backup and recovery protects against loss of data in case of liveCache crashes. The best time to apply this Best Practice is during the implementation phase of your mySAP solution.Best Practice: Checklist for liveCache Recovery liveCache >= 7. © 2004 SAP AG .4 3 Duration and Timing Implementing this Best Practice including corresponding tests takes about a week. It is also important to verify the whole backup and recovery procedure before going live during an intensive test phase. it is important to read and execute carefully all steps described in this Best Practice. Therefore. The main efforts are required in testing.
Procedure Backup and Recovery for liveCache >= 7. LiveCache allows you to save data completely (Save Data) or incrementally (Save Pages). For more information. or in a pipe. you need to specify backup media.Best Practice: Checklist for liveCache Recovery liveCache >= 7. ensure that you perform the following preliminary tasks or checks in the system: • Create a backup concept that meets your general security requirements. and to save logs. Data backups can be transferred directly to external backup tools. All the actions performed in the DBMGUI can also be performed using the Database Manager Command Line Interface (DBMCLI).4 4 Best Practice Procedure and Verification Preliminary Tasks Before performing this Best Practice. You can specify backup media using the DBMGUI. Backups on parallel media are supported.4 Activities before Going Live Backup Media When you create a liveCache backup. to a tape. © 2004 SAP AG . For information about this.6. see the following documents: – – – SAP liveCache 7. see SAP Note 119863.4 Backup & Recovery and Administration MaxDB Library: Database Manager GUI MaxDB Library: Database Manager CLI This document shows you how to complete the necessary actions using the Database Manager GUI (DBMGUI) Version 7. The backup can be written to a file.
© 2004 SAP AG . This may also be an incremental data backup that writes all changes made since the last complete save to the backup media. Switch on the automatic log backup in the DBMGUI by choosing Instance >> Set AutoLog on/off and selecting a medium in the upcoming window.Best Practice: Checklist for liveCache Recovery liveCache >= 7. These version files are located in a file system and are archived using file system backup or the DBMCLI-command archive_stage.4 To define the backup media using the DBMGUI. Log Backups Log backups copy the content of the log area into version files. choose Configuration >> Backup Media 5 Data Backups It is advisable to back up your data once a day. Set up liveCache to back up the log automatically. This prevents the log volume becoming overloaded.
If you run a restore and the data backup has errors. Keep the backups available for at least four weeks. © 2004 SAP AG . Choose the liveCache instance LCA and double-click on the action item. Select the desired backup medium and define the Recurrence Pattern in the next window.Best Practice: Checklist for liveCache Recovery liveCache >= 7.6 Call transaction DB13 for the first time via transaction LC10 >> liveCache: Monitoring >> Tools >> DBA Planning Calendar. so long as it and all the log backups that were created since then are still available. you can go back to a previous data backup. liveCache >= 7.4 6 Backup History Data backup and the associated log backups should last for at least four generations. Schedule the Data Backup Transactions DB13 or DB13C support the scheduling of data backups.
Double-click the Planning Calendar and schedule the action “Complete data backup”.6 Use transaction DB13C for the data backups.4 7 liveCache < 7. Select the desired backup medium in the next window.Best Practice: Checklist for liveCache Recovery liveCache >= 7. Select the liveCache connection under Goto >> Local Calendar. Define the liveCache connection with Configuration >> Add System if it’s not yet available. © 2004 SAP AG .
© 2004 SAP AG .4 8 Use the report RSLVCBACKUP and schedule it in transaction SM36 if transaction DB13C is not available in your system.Best Practice: Checklist for liveCache Recovery liveCache >= 7.
CIF queues stopped. that is. these reports must show the same consistencies or the same inconsistencies as before the crash. During this. or (for Unix systems) use the command: dbmcli -d <lc-sid> -n <host> -u control.Best Practice: Checklist for liveCache Recovery liveCache >= 7. For both servers: Be sure to test a complete restore run including data and log. This © 2004 SAP AG .<password> db_clear Do not use the UNIX command “kill -9” to end the liveCache process (“kernel. After the recovery. After the recovery. Verify Periodically execute a “verify”.4 9 Check and Test Recovery SAP strongly advises that you test the liveCache recovery a number of times in both the test and production systems. Before the crash. boot the server.<password> db_clear Do not use the UNIX command “kill -9” to end the liveCache process (“kernel. After the recovery. The verify checks physical consistency. Schedule the action “Check database structure (all objects)” in the DBA Planning Calendar of transaction DB13 or DB13C. There are several options for carrying out a “hard” liveCache stop: Pull out the network connection. By simulating a liveCache crash with a full system load: Start a background job (MRP run. use consistency check programs (/SAPAPO/OM17. The verify is then performed in this second system. use consistency check program /SAPAPO/WFM17 to check the data consistency for WFD Server. boot the server. The data backup is imported into the second system from the production system. If you have large liveCache instances. no users in the system. these reports must show the same consistencies or the same inconsistencies as before the crash. or (for Unix systems) use the command: dbmcli -d <lc-sid> -n <host> -u control. no users in the system. There are several options for carrying out a “hard” liveCache stop: Pull out the network connection. You can do this in a number of ways. /SAPAPO/CIF_DELTAREPORT3) to check the internal and external data consistency for SAP APO. for example: APO/SCM only By simulating a liveCache crash in a system that is not being used: No transactions open. for example) and generate CIF activities (data exchange between SAP APO and SAP R/3). Before the crash. SAP recommends that you run the “verify” on a second system. verify the data using the consistency check programs mentioned above. that data pages are linked in class containers and table trees in liveCache. verify the internal and external APO data using the consistency check programs mentioned above.exe”). WFD Server only By simulating a liveCache crash in a system that is not being used: No transactions open. The “verify” can result in queues due to locks in liveCache. carry out a “hard” liveCache stop. During this. After the recovery. carry out a “hard” liveCache stop. Backup generations should not be deleted before an intermediate verify has been run successfully.exe”). By simulating a liveCache crash with a full system load: Start a background job.
take this opportunity to check the level of usage of the liveCache instance. in the DBMGUI choose Information >> Backup History. In the “Result” column for the relevant backup. To perform this check.2. © 2004 SAP AG . see SAP Note 521870. If liveCache looks like it is approaching full capacity. For information about this. you can increase its size online.4 10 procedure checks the data backup and consistency in liveCache. Activities During System Operation 2.Best Practice: Checklist for liveCache Recovery liveCache >= 7. you should see “OK”: Also.1 Check the Backups Make daily checks to see whether the required backups have been created successfully.
in the DBMGUI choose Check >> Diagnosis Files >> Utility Statements. APO/SCM only Then activate the cancelled CIF queues that could not be processed during the downtime.Best Practice: Checklist for liveCache Recovery liveCache >= 7. To view the log. Activities After a liveCache Crash If liveCache crashes. Activities after a Crash without Disk Errors After a crash. you need to determine whether the failure has been caused by disk errors or by other hardware or software problems. © 2004 SAP AG . LiveCache can be restarted if no disk errors have occurred and the server is available.4 11 Check the Verify Check when the last verify ran and if it was successful. start the liveCache instance.
you can use transaction LC10 to bring the liveCache instance back online. To do this. Use transaction LC10 (not the DBMGUI or DBMCLI) to start liveCache and to inform all the work processes about the liveCache restart.4 12 Start the liveCache Instance After a crash without disk errors. All transaction data that had been committed at the time of the crash is available after the restart. choose Administration >> Operating. Changes caused by transactions that had not been completed at the time of the crash are rolled back.Best Practice: Checklist for liveCache Recovery liveCache >= 7. The system application processes automatically reconnect to liveCache. © 2004 SAP AG . and choose pushbutton “Start liveCache”.
To view the shutdown log. The program /SAPAPO/RCIFRESTART can be used to automatically restart all relevant CIF Queues. Of course. SYSFAILs due to liveCache Crash A liveCache crash may have caused queue entries with status SYSFAIL if the processing of these entries was interrupted by the crash. type and keys of orders) into the APO database. errors not caused by the liveCache crash will result in status SYSFAIL again. A succeeding and asynchronous process reads the corresponding orders from liveCache and transfers them to R/3. If a © 2004 SAP AG . you can manually restart the CIF queues. APO and R/3. 13 If liveCache crashes for unknown reasons. You should check the status of the CIF queues in all relevant systems. APO/SCM only Activate CIF Queues After the liveCache restart the CIF queues have to be activated. Alternatively. See note 604053 for details. Depending on the queue type. The program /SAPAPO/RCIFRESTART will do this automatically. you should also execute the SYSFAIL entries in SMQ1 / SMQ2 or use the programs RSQOWKEX (outbound) and RSQIWKEX (inbound) to start several queues in parallel.e.Best Practice: Checklist for liveCache Recovery liveCache >= 7.4 You can tell that liveCache has crashed if it does not have state Admin or Online and has not been shut down. Online transfer from APO to R/3 If an APO transaction transfers changes from APO to R/3 in online mode it first writes so-called change pointers (i. these transfers can be easily re-executed. use transaction SMQ2 for inbound queues and / or SMQ1 for outbound queues (or use /SAPAPO/CQ. open an OSS message on component BC-DB-LVC. choose Check >> Diagnosis Files >> Utility Statements. After liveCache is available again. the SCM Queue Manager). If you manually restart the queues.
the CIF queues are never empty for a long period of time. it may still be possible to start the liveCache instance. However. Consequently. you can distinguish in transaction /SAPAPO/C5 between change pointers stored for online transfer from change pointers stored for periodic transfer. Activities After a Crash Caused By Disk Errors Disk or disk system errors can have a variety of effects. SNP is configured to publish its planning results periodically (once a week) rather than online. select the relevant change pointers using a time interval shortly before the liveCache crash for the creation date select-option. the change pointers would remain unprocessed in the APO database. Use checkbox ‘Interrupted online-transfers’ in order to select the online change pointers which have not been transferred due to a liveCache crash or a program termination as described in the paragraph above. Depending on the size of the CIF queues. © 2004 SAP AG . it is outdated in comparison with the R/3 data. there is a danger that transactions in R/3 will run on an unplanned or obsolete dataset. The program /SAPAPO/RCIFRESTART will reprocess the entries which were interrupted by the crash. An indicator for this is that the CIF queue entries only have time stamps after the recovery. However. the CIF queues that grew in size during the liveCache downtime should be processed until they are back to a normal size. The synchronous online ATP check from a connected SAP R/3 System bypasses the CIF queues and thus does not see any current data in APO. If SAP Note 587062 is not applied. CIF queue processing may take several hours. data is not lost if a data backup and all associated log backups and the log volumes are available. If you ignore the above recommendation and release the APO system before the CIF queues have returned to a normal size. you should note the following: The data in the APO system is not concurrent with the R/3 data. - It is the responsibility of the systems group operator for APO and the connected SAP R/3 or non-SAP systems to decide when the APO system can be released again. before you release the APO system. The APO system should not be released until the CIF queues have been processed. Since the connected SAP R/3 Systems normally send data constantly to the SAP APO system. data from individual class containers or SQL tables is then no longer accessible. This can lead to incorrect check results. The manual way is to trigger the transfer of such kind of change pointers via transaction /SAPAPO/C5 after a liveCache restart. If certain APO planning processes were not executed due to the APO downtime. Often. If SAP Note 587062 has been applied in your system.Best Practice: Checklist for liveCache Recovery liveCache >= 7. However. note that this transaction might display a lot of regular change pointers that are stored for the next periodic data transfer to R/3. If the disks of the liveCache instance have errors. They can prevent liveCache from restarting. If the structure of individual blocks on the disks is destroyed.4 14 liveCache crash interrupts the APO transaction right after the change pointers have been committed into the APO database the asynchronous process (reading and transferring the data to R/3) cannot be started. Check the knldiag file if you cannot start the instance. How Do You Recognize I/O Errors? You generally notice data volume errors when you start the instance. for instance. in the DBMGUI choose Check >> Diagnosis Files >> Database Messages. To find the file.
it is advisable to make a few preparations in the APO system: Ask all users in the system to log off as soon as possible. see the knldiag file.4 15 Error message –902 initially indicates an I/O error. particularly planning runs. Error messages related to the operating system are logged here. you can continue to transfer data from the R/3 outbound queue to the APO inbound queue during the liveCache downtime. Prepare for a liveCache Recovery Recovery usually takes quite a while. You can inform the users about the recovery using a system message (transaction SM02). it may be useful to use transaction “SMQ1” to stop the data transfer from SAP R/3 Systems to APO. These errors do not necessarily cause the liveCache instance to crash. SAP Note 505304 describes how to configure database space for stopped CIF queues. If several SAP R/3 Systems are connected to a central APO system. APO/SCM only As of SAP APO SP 17. If you have activated inbound queues in SAP APO. see the log file mentioned above. the APO inbound queue can grow very rapidly. Prevent others from logging on to the system. To find the cause of the I/O error. To find the error message with corresponding data volume. To do this. Check in the system to see whether the disk peripherals have reported any errors. the application writes a short dump. © 2004 SAP AG . Therefore. To prevent an overload of the APO inbound queue. The APO inbound queue grows accordingly. Simply use the first two pushbuttons on the initial screen of the transaction.Best Practice: Checklist for liveCache Recovery liveCache >= 7. (Via “SMQ1” the R/3 outbound queues are stopped.) This means that the data quantity is distributed over the outbound queues of the connected SAP R/3 Systems. Deschedule all programs scheduled to run in the background. use report /SAPAPO/OM_LOCKUSER to lock all users. In order to avoid that during the liveCache downtime the CIF tries to book permanently data into APO it makes sense to stop additionally the APO inbound queue via transaction “SMQ2”. If they occur. Error messages –9026 “BD Bad data page” or –9028 “BD Bad file” are displayed if individual blocks are destroyed. you can perform all these activities in transaction /SAPAPO/OM17.
Use the DBMGUI to start the liveCache instance in state Cold or Admin. Close the result window and choose Action >> Admin or click the yellow traffic light.4 These considerations also apply if non-SAP systems are connected to APO. © 2004 SAP AG .Best Practice: Checklist for liveCache Recovery liveCache >= 7. 16 Data and Log Recovery Change the defective disk. Then start the Recovery Wizard by choosing Recovery >> Recovery Wizard.
you can select “Restore a specified backup from history” to select an older data backup otherwise select “Restore last backup”.4 17 Do not mark “Initialize database instance before restore complete data backup” in the next menu. Check the recovery strategy displayed by the Recovery Wizard. If the log backups have been written to a file system and no longer exist there. Start the restore for the data backup. Log backups are only required for log entries that are no longer in the log volumes. they can be retrieved during the restoration of data. and then choose “Start” to continue.Best Practice: Checklist for liveCache Recovery liveCache >= 7. Therefore. © 2004 SAP AG . If the most recent data backup is unusable. it is possible that fewer log backups are displayed here than have been created in the meantime. The Recovery Wizard displays all the backups required.
SAP does not support synchronization using time stamps. SAP does not support synchronization using time stamps. Therefore.” This might lead to inconsistencies between liveCache and other data of WFD which are not stored in liveCache. log entries can also be recovered in parallel. It will ask you to provide log backups or change the file name of the media if not all the log backups could be retrieved. The Recovery Wizard now recovers the log entries of all displayed log backups. The recovery time depends on the hardware speed and the size of the backups. APO/SCM only Do not select “Restore database until a specified time. The liveCache instance is automatically set to state Online once all the log entries have been processed. There can be a delay displaying the last log backups when the log entries are read from the log volumes and recovered. WFD Server only Do not select “Restore database until a specified time. If online transactions are running in parallel.Best Practice: Checklist for liveCache Recovery liveCache >= 7. the load distribution of the application also influences the recovery time. if the backups are available. © 2004 SAP AG .” If the liveCache instance is not completely recovered.4 18 After the data is restored. start restoration of log backups. inconsistencies might occur between the APO database and liveCache.
3.2) or that did not start due to the downtime (you can do this in transaction /SAPAPO/WFM17) © 2004 SAP AG . In addition.1.3.Best Practice: Checklist for liveCache Recovery liveCache >= 7.3. activate the CIF queues as described in section 2.4 19 Follow-Up Work for a liveCache Recovery APO/SCM only After liveCache recovery. perform the following tasks: Remove system messages relating to liveCache recovery (SM02) Create an SAP support notification if you are unable to determine the reason for the disk failure Start/schedule background jobs and planning runs that were descheduled (as described in section 2.2) or that did not start due to the downtime (you can do this in transaction /SAPAPO/OM17) Unlock the APO users (report /SAPAPO/OM_LOCKUSER) (you can do this in transaction /SAPAPO/OM17) Unlock the APO system for the users - WFD Server only After liveCache recovery perform the following tasks: Remove system messages relating to liveCache recovery (SM02) Create an SAP support notification if you are unable to determine the reason for the disk failure Start/schedule background jobs and planning runs that were descheduled (as described in section 2.
data is lost from liveCache. Log volumes must be mirrored in production systems.03 and newer versions liveCache supports mirroring of the log volumes. it is not possible to recover all the transaction entries during the log recovery. © 2004 SAP AG . The liveCache instance will shutdown when it detects an error during an I/O to a log volume.4.Best Practice: Checklist for liveCache Recovery liveCache >= 7. Check the file knldiag and find the corrupted log volume. To find the file. In this case.4 Unlock the APO users (report /SAPAPO/OM_LOCKUSER) (you can do this in transaction /SAPAPO/WFM17) Unlock the system for the users 20 Miscellaneous Log Volume Loss Use appropriate safety measures to ensure that the log volumes are not lost. With 7. in the DBMGUI choose Check >> Diagnosis Files >> Database Messages. Change the defective disk and restore the corrupted log volume. If the log volume with the current write position is lost. Select Instance >> Command Line to get a dbmcli command line in the DBMGUI. Use the DBMCLI command “util_execute RESTORE LOG VOLUME ‘<file name of the corrupted log volume>’”.
Afterwards you can reload the data into liveCache with the program /SAPAPO/WFD_ASSIGNMENT_SYNC_LC. Alternatively. you should initialize liveCache using transaction LC10. see SAP Note 425825. you can use transaction /SAPAPO/OM17.0. LiveCache data backups are consistent because they contain the “before” images of the open transactions. that is. if available. it is likely that data inconsistencies will occur because the most recently made changes are missing from liveCache. In the case of log volume loss. To check the internal consistency of the SAP APO system. Afterwards. SAP is unable to guarantee data consistency because data has been lost. you should initialize liveCache using transaction LC10. © 2004 SAP AG .4 21 Restart the liveCache with transaction LC10. WFD Server only If you do lose the log volumes that are currently being written although they are mirrored. If you are using SAP APO 3. you can import a data backup and additional log backups. However. the data in the APO database is not completely consistent with the data in liveCache or the data in the connected OLTP systems.Best Practice: Checklist for liveCache Recovery liveCache >= 7. you can use report /SAPAPO/CIF_DELTAREPORT3. You then have to transfer all transaction data from the connected OLTP systems to the APO system in initial status. APO/SCM only If you do lose the log volumes that are currently being written although they are mirrored. To check its external consistency. you can reinstall liveCache from the DBMGUI by choosing Instance >> Create.
Background Information and References All relevant information and references are given in the sections above. proceed as follows: Click on the corresponding document from our homepage in SAP Service Marketplace. If you would like to give us feedback on a particular document.Best Practice: Checklist for liveCache Recovery liveCache >= 7. In the field "What is your feedback related to?” select "Contents". © 2004 SAP AG . Feedback and Questions The existing documents will be regularly extended and improved to make them more usable and customer-friendly.4 22 Further Information Troubleshooting If executing this Best Practice did not produce the desired results. Send us your feedback. We would therefore welcome your feedback. please create a support notification describing your problem in detail. Click on the button "Feedback" above the document page.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.