A MaxDB standby database uses a copy of the original production database instance on a second hardware system, so greatly improving the overall reliability of the database service. For more information about standby databases in general, see Standby Databases.
The following graphic shows the setup for a MaxDB standby database:
MaxDB Standby Database
· Setup overview
The original production database instance is copied to a second location. The work done in the original instance 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 instance up to date.
· Separation of standby system from production system
The standby system is normally located at a remote site, since otherwise it too might be affected by whatever destroyed the production system.
· Standby instance as a copy of original instance
The standby instance consists of a restored complete data backup and restored version files of the log entries created at the primary site and moved to the standby site. The standby instance does not have to be an exact physical copy of the original instance. The instance name, directory structures, and file names might be different.
The structure of the original instance can be different to the structure of the standby instance. We recommend that the number and size of the log volumes for both instances are the same.
· Structural database changes
Changes to the structure of the original instance might affect the standby instance. Certain changes can be applied on the standby instance. A discussion of potential problems with structural changes follows.
· Standby instance runs in ADMIN state
Once the standby instance has restored the complete backup of the original instance, it is put in recovery mode and performs recovery steps. The version 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 instance in the standby instance by repeating all transactions that changed data. The standby instance always lags slightly behind, because the log area used by the original instance cannot be shipped yet.
An accidental restart to operational state ONLINE invalidates the standby instance.
· What happens when the production instance fails?
If the original production instance becomes unavailable, the standby instance has to be restarted to operational state ONLINE. When the original instance fails, some committed transactions might be lost, because the current log area that the original instance was using at the time of the disaster might be inaccessible. The standby instance can then only be recovered to the state reflected in the last saved version file (log backup).
Before activating the standby instance, always try to save the current log area in the original instance, ship it to the standby site and apply it.
It is important to immediately perform a backup of the standby instance once it is in operational state ONLINE. If no backup is performed and problems occur in the standby instance, 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.
· What happens if the original instance becomes available again?
If the original production site becomes available again, SAP recommends not to use (that is, start) the original database instance. The reason for this is that it is impossible to apply newly made transactions from the now productive standby database instance to the original database instance. These transactions are lost when you revert to the original configuration (see next point below).
· Reverting to the original configuration
If the standby instance is put into production operation due to a disaster, it should then be considered the production system. Once the disaster situation is resolved at the production site, you should use the former original instance as standby instance or you have to decide on how to switch back to the original configuration, if that is desired.
When you plan to set up a standby instance, note the following:
· Structural database changes
Ў A data volume added to the original instance will not be automatically added to the standby instance. However, you can add a data volume to the standby instance as follows:
i. Stop the log recovery in the standby instance.
ii. Add the data volume to the standby instance in operational state ADMIN.
The fill level of the data area of the standby instance can become too high if you forget to add a data volume. The recovery process aborts in this case. You can now add the data volume and resume the recovery.
Ў A log volume added to the original instance does not affect the standby instance. You can add the log volume to the standby instance when it is in operational state ADMIN.
In general, structural changes should not cause major problems. Refer to the appropriate MaxDB documentation for more detailed descriptions.
· Copy of version files not automated
MaxDB does not provide automated procedures to copy the saved log as version files from the original instance to the standby instance. You have to manage this yourself. For more information, see the link at the end of this section.
· Recovery of standby instance not automated
MaxDB does not provide a mechanism to automatically start the permanent recovery of the standby instance. 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 instance can cause an emergency shutdown. If this occurs, resolve the disk problems and reinitialize the standby instance.
· Data corruption during transfer
Compression utilities used to electronically transfer files from one machine to another might cause data corruption. Make sure that the data backups and the version files are transferred in such a way that no corruption or loss of files can occur.
Concepts of the Database System,