In distributed environments you can also recover an R/3 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 the case of such point-in-time recoveries, certain documents 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.

You can use ALE recovery tools for this.

ALE recovery tools can also be used for data exchanged with non-SAP systems.

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

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.

Not all inconsistencies can be automatically put right by the recovery tools. You may have to remove some of the inconsistencies manually. This especially applies to canceling application documents.

To remove inconsistencies, you have to carry out the following R/3 transactions:

• Determine recovery objects: Transaction code BDRC
• Process recovery objects: Transaction code BDRL

• Application log for ALE recovery procedure: Transaction code BDR1

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

• The recovered objects do not need to be processed further.
• The recovered objects have already been processed.