SAP MaxDB Standby System (Recovery from Log Backup)This page provides information about how to setup a Standby System with Recovery from Log Backup
The current versions of SAP DB/MaxDB (7.3 - 7.9) allow the setup of Standby System by recovering from log backups created by the primary database.
However there is no build-in functionality for the transfer of the redo log backups from the primary to the standby server. There is also no option to automatically apply the redo log backups (once these are available on the standby server). Moreover there is no functionality to easy switch over from the primary to the standby server in case of a failure.
Every step has to be done manually and there is no connection between the primary and the standby database, so in case the standby database stops the recovery for any reason, there won't be any warnings in the monitoring of the primary database.
Anyhow, despite of the mentioned shortcommings a SAP MaxDB standby database still provides a fallback system that can be brought online very quickly (compared to a full database recovery based on the latest backups).
Notice: the mentioned constraints do only apply to the out-of-the-box functionality of SAP MaxDB. By using third party tools (like the one of Libelle, DBShadow for MaxDB Databases) or cluster/storage solutions there are much more advanced standby features available.
See also information in SAP MaxDB documentation about Standby System in Standby Database.
Scripts for automating standby database handling
To run a standby database there are several tasks that need to be performed:
Setup a standby database
The SAP MaxDB software on the standby server needs to be on the exact same version as it is on the primary server.
Everytime the software is patched or upgraded on the primary server, this is also necessary on the standby server.
As soon as the software is installed on the standby server, the standby database has to be created and a complete data backup of the primary database should be restored to this database. It's not necessary that the standby database has the same name or the same volume layout as the primary database.
It is however important that the standby databases data area is able to contain the whole data area of the primary database.
Also, it is essential that the standby database is never set to ONLINE operational state as long as log files should be applyable.
Once the standby database was set to ONLINE (via db_online/db_warm) no further logs can be applied!
Since the recovery wizards of the database tools (for example daatabase studio) are designed to perform desaster recoveries most efficiently, make sure not to click the buttons to set the database ONLINE after the recovery!
Shipping of the redo log backups
Once the standby databases data area containt a complete data backup of the primary database, the standby database can be updated by recovering log backups of the primary database.
This is only possible if all redo log backups that had been created after the initial data backup had been done are applied in the order the backups where created.
If any log is missing in the sequence no further logs can be applied to the standby database.
In the SCN SAP MaxDB forum users posted script based solutions for shipping and applying log backups for Unix and Micrososft Windows platforms. The credits for these scripts go to Daniel Rajmanovich (Unix script) and Oliver Johnston (Microsoft Windows script). Attention: These scripts are NOT an SAP solution! You can use these scripts on your own risk only, no support is provided in case of errors using these scripts.
Both scripts have been adapted to make use of the XUSER logon mechanism (dbmcli -U w/c) instead of specifying the logon credentials explicitly for each dbmcli-call (dbmcli -n <computer_name> -d <database_name> -u <dbm_operator>,<password>). This improves security and makes the script less dependend to the databases they are used for. Anyhow, to make this work, the XUSER data have to be setup appropriately for the os-user(s) that run the scripts.
Well here it is, it consist in 2 files: restore.txt and restore_script.
It only restores 1 log backup on each run.
So you probably add it to a cron. It was made in Solaris 5.10.
the logbackups should have 666 rights on it so prdadm can delete them after restore.
Restore.txt has the commands that the dbmcli should execute once inside the dbmcli.
Contents of restore.txt
The restore_script has the logic for changing restore.txt before executing it.
Micrososft Windows script
Script 1 (Standby.bat) - Top level script to call the others and delete any previous import script file.
Script 2 (Recovery_Builder.bat) - Sets DB to Admin mode and then builds the import list and exports to script file.
Script 3 (Recovery_Apply.bat) - Imports the generated script and then sets the DB back to offline.
Failover from the primary to the standby database
To perform a switch (or failover) from the primary database to the standby database, it's necessary that all remaining log entries since the last applied log backup are transfered to the standby database and applied there.
To do so, just create a log backup (which is also possible when the data area is not accessible anymore and the database can only started up to admin state) and make it available on the standby server. After the recovery of this last log backup the standby database can be opened.
Finally the applications that should access the standby database need to have the connection data so that the new server is accessed (e.g. change of hostname and database name).
If the application use the XUSER mechanism to logon to the database, only the XUSER data need to be changed to redirect the application to the standby database.