Restoring the SAP Database after Disk Crash

Use the procedure described here to restore the database if one of the following applies:

• The SAP database disk system is damaged
• 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 SAPdatabase, one for the SAPtransaction logs and one for all other files. For more information, seeDisk Configuration.

Process Flow

The following figure shows the phases a database restore is comprised of.

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, seeBacking Up the Current Transaction Log with SQL Server Management Studio.

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 seeRestoring the Database and Log Backups

   The following figure shows how to restore the database backup and apply transaction logs: