SAP MaxDB Standby Database 
An SAP MaxDB standby database uses a copy of the original production database on a second hardware system. It considerably improves the overall reliability of the database service. For more information about standby databases, see Standby Databases.
The following graphic shows the setup for an SAP MaxDB standby database:
SAP MaxDB Standby Database
Features
Setup overview
The original production database is copied to a second location. The work done in the original database is recorded in the log area. The log area is backed up and transferred to the second location and read in there to keep the standby database up to date.
Separation of standby system from production system
The standby system is best located at a remote site, since otherwise it might also be affected by whatever caused the production system to fail.
Standby database as a copy of original database
The standby database consists of a restored complete data backup and restored backup files of the log entries created at the primary site and moved to the standby site. The standby database does not have to be an exact physical copy of the original database. Database name, directory structures, and file names might be different.
RecommendationThe structure of the original database can be different to the structure of the standby database. We recommend that the number and size of the log volumes for both databases are the same.
End of the recommendation.Structural database changes
Changes to the structure of the original databases might affect the standby database. Certain changes can be applied on the standby database. A discussion of potential problems with structural changes follows.
Standby database runs in ADMIN state
Once the standby database has restored the complete backup of the original database, it is put in recovery mode and performs recovery steps. The backup files of the log backups at the production site have to be shipped to the remote site and read in there using the database recovery mechanisms. This performs a “redo” of all work done in the original database in the standby database by repeating all transactions that changed data. The standby database always lags slightly behind because the log area used by the original database needs to be shipped first.
An accidental restart to operational state ONLINE invalidates the standby database.
What happens when the production database fails?
If the original production database becomes unavailable, the standby database has to be restarted to operational state ONLINE. When the original database fails, some committed transactions might be lost, because the current log area that the original database was using at the time of the disaster might be inaccessible. The standby database can then only be recovered to the state reflected in the last saved backup file (log backup).
Before activating the standby database, always try to save the current log area in the original database, ship it to the standby site and apply it.
CautionMake sure that you immediately perform a backup of the standby database once it is in operational state ONLINE. If no backup is performed and problems occur in the standby database, all work done since the activation is lost. This backup is also important to enable you to subsequently restore the database at the production site.
End of the caution.What happens if the original database becomes available again?
If the original production site becomes available again, we recommend you not to use (that is, start) the original database. The reason for this is that it is impossible to apply newly made transactions from the now productive standby database to the original database. These transactions are lost when you revert to the original configuration (see next point below).
Reverting to the original configuration
If the standby database is put into production operation due to a disaster, it should then be considered the production system. Once you have resolved the disaster situation at the production site, you should use the former original database as standby database or you have to decide on how to switch back to the original configuration, if that is desired.
Activities
When you plan to set up a standby database, note the following:
Structural database changes
A data volume added to the original database is not automatically added to the standby database. However, you can add a data volume to the standby database as follows:
Stop the log recovery in the standby database.
In operational state ADMIN, add the data volume to the standby database.
The fill level of the data area of the standby database can become too high if you forget to add data volumes in time, causing the recovery process to abort.
Resume the recovery
A log volume added to the original database does not affect the standby database. You can add the log volume to the standby database while it is in operational state ADMIN.
Structural changes should not cause major problems. For more information, see the appropriate SAP MaxDB documentation.
Copy of backup files not automated
SAP MaxDB does not provide automated procedures to copy the saved log as backup files from the original database to the standby database. You have to manage this yourself. For more information, see the link at the end of this section.
Recovery of standby database not automated
SAP MaxDB does not provide a mechanism to automatically start the permanent recovery of the standby database. For more information, see the link at the end of this section.
I/O errors and disk failures
I/O errors and disk failures on the standby database can cause an emergency shutdown. If this occurs, resolve the disk problems and reinitialize the standby database.
Data corruption during transfer
Compression utilities used to electronically transfer files from one computer to another might cause data corruption. Make sure that the data backups and the backup files are transferred in such a way that no corruption or loss of files can occur.
More Information
SAP MaxDB: Replication and High Availability