ALE Recovery for Data Consistency 

Use

In distributed environments you can also recover an SAP system following a system failure caused by a database error. Using backup and point-in-time recovery, you can reset the database to the status at the time the system failed and continue working with it.

In this case, transactions may still have taken place after the time the system is reset to, which are subsequently lost and have to be carried out again. External interactions (for example, ALE, EDI, mail, fax, telex), possibly carried out under a different key, are duplicated and require special processing.

For example, if, a process sent a message to another system and started another process here during the time between when the error occurred and when it was discovered on the recovered system, the data related to this process will no longer exist on the recovered system. The results of the second process carried out on the receiving system still exist in this system. The inconsistent data in the two systems can be put right by canceling the data resulting from the communication in the receiving system.

In point-in-time recoveries, certain documents and messages must be canceled in the communication partners’ systems and messages sent earlier from the receiving system must be sent again. You have to determine all the actions that need to be carried out in the recovery process.

The ALE Recovery tools help you to do this.

Prerequisites

To recover a system, the following is required:

·        Database that allows a point-in-time recovery

·        Continuous database backup

·        The database of the recovered system has already been restarted at the status before the error occurred

Features

ALE Recovery tools perform the required analyses and help you carry out the necessary tasks.

...

       1.      The recovered system prompts its communication partners to provide details of the IDocs exchanged between the systems during the time affected.

       2.      The communication partners of the recovered system report back this information.

       3.      The information reported back is compared to the information in the recovered system. This process determines what further activities are required to recover a consistent status in the entire distributed environment. The status of IDocs is updated in the recovered system.

       4.      A list of documents to be canceled in the communication partner systems is created. If necessary, IDocs are sent again automatically.

The recovery tools show the inconsistencies found. You must resolve inconsistencies in application objects manually. You can resolve some inconsistencies in the IDoc messages (depending on the IDoc processing status), directly with the recovery tools.

Activities

Use the following transactions to find and resolve inconsistencies:

·        Determine recovery objects:     Transaction code BDRC

·        Process recovery objects:       Transaction code BDRL

For more information, see the program documentation.

The following functions are also available:

·         Application log for ALE recovery procedure:          Transaction code BDR1

The relevant parameters specified in the transactions Determine recovery objects and Process recovery objects, are recorded in a log. You can display the log in Transaction BDR1.

·         Reorganization of the data for recovery objects:    Transaction code BDR2

The data generated in the transactions Determine recovery objects andProcess recovery objects, is used to identify the status of the recovered objects.

This data is deleted when it is reorganized if the following conditions apply:

·         The recovered objects do not need to be processed further.

·         The recovered objects have already been processed.