Restoring the SAP Database after Disk Crash

Purpose

The procedure described here should be followed to restore the database when:

·        The SAP database disk system is damaged

or

·        The transaction log disk system is damaged

Prerequisites

The process described here is only applicable to a configuration with three disk systems; one system for the SAP database, one for the SAP transaction logs and one for all other files. For more information, see Distribution of Files to Disk.

Process Flow

The database restore is comprised of a number of phases.

Restore Phases

...

       1.      Transaction Log Backup

If the disk system on which the SAP database resides is damaged, it is vital to immediately backup the currently active transaction log to prevent a loss of data. Without a backup of the current log, the database can only be restored to the status it had at the time of the last transaction log backup. If work has been carried out on the SAP system since then, this work will be irrevocably lost. Therefore, after the failure of your data disk, backup the current logs without delay.

For more information, see Backing Up the Current Transaction Log with Enterprise Manager

       2.      Replacement of Damaged Disks

Replacing damaged disks in a RAID disk system is normally a straightforward procedure. If you are uncertain how to proceed, refer to the documentation of your hardware vendor to find out how to handle the disks. The new disks must be formatted and assigned the same drive letter as the old ones.

       3.      Database and Transaction Log Restore

The central phase of a restore operation is the reloading of the database backup and the application of the available transaction logs. When the database backup is reloaded, the database files are automatically recreated and the data is copied from the backup device to the newly created files. Once this has been done, the transaction logs are applied in the same sequence as they were originally made. This means that changes made to the database since the database backup are redone. In a final step, open transactions that were not completed at the time of the database failure, are rolled back.

At the end of the restore operation all transactions that were completed at the time of the database failure are written to the database and all incomplete transactions have been rolled back. Work in the SAP system can be resumed.

Including Differential Backups in a Restore Operation

If you incorporated differential backups in your backup strategy, the restore process differs depending on the type of backups available. Typical restore operations could involve the following steps:

Ў        If differential backups were made after the last full database backup, you restore the last database backup followed by the most recent differential backup and then you apply all subsequent transaction logs.

Ў        If no differential backups were made since the last full database backup, you first restore the last full database backup and then apply all subsequent transaction logs. In this case no up-to-date differential backup is available for the restore process.

Ў        If several differential backups are available, but the latest one cannot be read, the process is as follows:
First you restore the most recent full database backup, then you restore the latest readable differential backup and then you apply all subsequently created transaction logs.

For more information see Restoring the Database and Log Backups

Restoring the Database Backup and Applying Transaction Logs