SAP MaxDB Standby System (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. Until MaxDB 7.9.10.06 there was 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 shortcoming’s 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).
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.
Every time 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 database studio) are designed to perform disaster recoveries most efficiently, make sure not to click the buttons to set the database ONLINE after the recovery!
Scripts / Files used in setting up the Stand-By System
Shipping of the redo log backups from PRIMARY to Stand-By serverStart ScriptRecovery builder python scriptImport file [list of DMB commands file auto generated by builder script]Recovery Apply script
1. Shipping of the redo log backups from PRIMARY to Stand-By server
Once the standby databases data is recovered with 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 complete data backup [which is user for recovery] had been moved and are applied in Stand-by in the sequence of the log backups where created.
!!! If any log is missing in the sequence no further logs can be applied to the standby database !!!
Copying files from server to sever may vary depend upon the OS, In my case I have windows flavours where I have user ROBOCOPY utility to copy my files from PRIMARY server to DR server
2. Start Script
As the name says the Start script is going to call the Recovery builder script, In backend the start script is scheduled based on the Operating system used “Task Scheduler” for Windows and “Crontab’s” for Linux.
|| Start script code ||
<installation_dir><SID>dbbinx_python.exe <path_to_the_recovery_builder_script_file>recovery_builder.py
3. Recovery builder python script
The python utility will be available in the MaxDB binaries, using that python binaries we are going to execute the builder script, we don’t need to install any other modules/packages
Here we are using the SAP MaxDB Python modules to access SAP MaxDB databases from Python scripts.
The below SAP MaxDB python modules were utilized in the python script,
sdb.dbm
sdb.dbm is a Python module for SAP MaxDB databases. we can use this module to execute DBM commands for creating and managing databases in Python scripts.
sdb.dbm.DBM
DBM is a class of the sdb.dbm module. You can use the methods of this class to execute DBM commands for creating and managing databases. An object of this class represents a connection to a DBM server.
cmd (cmd_string)
cmd is a method of the DBM class (sdb.dbm module). You can use this method to send a DBM command to the DBM server.
sdb.sql
sdb.sql is a Python module for SAP MaxDB databases. You can use this module to execute SQL statements in Python scripts.
SapDB_Session
SapDB_Session is a class of the sdb.sql module. You can use the methods of this class to execute SQL statements.
An object of this class corresponds to a database session. To generate an object of this class, use the connect method (sdb.sql module). After the last reference to an object of this class has been deleted, the system closes the database session with a ROLLBACK of the transaction.
The high level working of recovery builder script for generating the import command file
Recovery builder source code:
[In the below source code, the areas to be replaced with the system specific values are mentioned using the tag <–content–>, replace the whole tag with the specific content]
#———————————-
# Import Python modules
# ———————————-
import sys
import os
#———————————-
# Import Max DB Python modules
# ———————————-
import sdb.dbm
import sdb.sql
#————————————-
#function definition
#————————————-
def get_pg(i,list):
pg=[]
temp=list.splitlines()
pg=temp[i].split(“t”)
return pg[1]
#————————————-
#Log file & Import file
#————————————-
log_file=open(“<–path_to_log_file–>log”, “a”)
imp_file=open(“<–path_to_import_file–>imp”, “w”)
#————————————————————
# Call up the Database Manager and log on to a database
# ———————————————————–
session = sdb.dbm.DBM (”, “<–SID–>”, ”, “<–DB_USER_NAME–>” + ‘,’ + “<–PASSWORD–>”)
_cmd = “db_admin”
_result = session.cmd (_cmd)
_cmd = “db_restartinfo”
_result = session.cmd (_cmd)
log_file.write(“n” + _result)
#————————————-
#returns in string format
#————————————-
_current=0
_current=get_pg(0,_result)
#————————————————————————————-
#read the directory where the primary log files were shipped in Stand-By server
#————————————————————————————–
_log_list=[]
_prim_log_path=”<–path_to_primary_log_file_dir–>”
_dir_list = os.listdir(_prim_log_path)
for i in _dir_list:
_log_list.append(i.split(‘.’))
#—————————————————-
# Identify pages for the log files to be applied
#—————————————————-
_log_pg_list=[]
i=0
while i < len(_log_list):
j=1
#———————————————————–
# Here LOG is used to define the type not the medium name
#———————————————————–
_cmd=”medium_label “+”LOG “+ _log_list[i][j]
i+=1
_result=session.cmd (_cmd)
_log_pg_list.append(get_pg(14,_result))
#————————————-
# Find the first log page
#————————————-
int(i)
for i in _log_pg_list:
if _current > i:
max_ind=_log_pg_list.index(i)
#————————————-
# DBM start command generation
#————————————-
imp_file.write(“db_connect”)
imp_file.write(“ndb_admin”)
#———————————————————————
# leave a space after the log_template_name_in_stand-By_DB below
#———————————————————————
_log_template_name = “<–log_template_name_in_stand-By_DB–> “
start_cmd=str(“recover_start ” + _log_template_name + _log_list[max_ind][1])
imp_file.write(“n” + start_cmd)
#————————————————————–
#adding the generated cmd in Log file for troubleshooting
#————————————————————–
log_file.write(“n” + start_cmd)
max_ind+=1
#————————————-
# DBM replace command generation
#————————————-
_abs_prim_log_path=”<–path_to_primary_log_file_dir–><–log_file_name_w/o_extentsion–>”
while max_ind < len(_log_list):
replace_cmd=”recover_replace “+ _log_template_name + _abs_prim_log_path+”.”+_log_list[max_ind][1]
max_ind+=1
#————————————————————–
#adding the generated cmd in Log file for troubleshooting
#————————————————————–
log_file.write(“n” + replace_cmd)
imp_file.write(“n” + replace_cmd)
imp_file.write(“ndb_offline”)
#—————————————————-
# Close the connection to the DBM and files
# —————————————————
session.release ()
log_file.close()
imp_file.close()
4. Import file
As a result of recovery builder script execution, the import file will get generated in the mentioned path in the above source code
5. Recovery Apply script
Ensure the Import file is generated successfully with required DBM commands, use the below code to execute the import file, you can schedule the script once to run once the recovery builder script is completed
<–installation_path–>programspgmdbmcli.exe -d <–SID–> -u <–DB_user–>,<–Password–> -i “<–path_to_import_file–>”
Feature Scope:
We are working on the automation for identifying the error/failure status and to notify the appropriate recipients.
Reference:
HowTo – Standby System (Recovery from Log Backup) | SAP Help Portal
Kindly post your valuable comments and suggestion on the same!
Thank you
SAP MaxDB Standby System (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. Until MaxDB 7.9.10.06 there was 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 shortcoming’s 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).Scripts for automating standby database handlingTo 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.Every time 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 database studio) are designed to perform disaster recoveries most efficiently, make sure not to click the buttons to set the database ONLINE after the recovery!Scripts / Files used in setting up the Stand-By SystemShipping of the redo log backups from PRIMARY to Stand-By serverStart ScriptRecovery builder python scriptImport file [list of DMB commands file auto generated by builder script]Recovery Apply script1. Shipping of the redo log backups from PRIMARY to Stand-By serverOnce the standby databases data is recovered with 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 complete data backup [which is user for recovery] had been moved and are applied in Stand-by in the sequence of the log backups where created.!!! If any log is missing in the sequence no further logs can be applied to the standby database !!!Copying files from server to sever may vary depend upon the OS, In my case I have windows flavours where I have user ROBOCOPY utility to copy my files from PRIMARY server to DR server2. Start ScriptAs the name says the Start script is going to call the Recovery builder script, In backend the start script is scheduled based on the Operating system used “Task Scheduler” for Windows and “Crontab’s” for Linux.|| Start script code || <installation_dir><SID>dbbinx_python.exe <path_to_the_recovery_builder_script_file>recovery_builder.py 3. Recovery builder python scriptThe python utility will be available in the MaxDB binaries, using that python binaries we are going to execute the builder script, we don’t need to install any other modules/packagesHere we are using the SAP MaxDB Python modules to access SAP MaxDB databases from Python scripts.The below SAP MaxDB python modules were utilized in the python script,sdb.dbmsdb.dbm is a Python module for SAP MaxDB databases. we can use this module to execute DBM commands for creating and managing databases in Python scripts.sdb.dbm.DBMDBM is a class of the sdb.dbm module. You can use the methods of this class to execute DBM commands for creating and managing databases. An object of this class represents a connection to a DBM server.cmd (cmd_string)cmd is a method of the DBM class (sdb.dbm module). You can use this method to send a DBM command to the DBM server.sdb.sqlsdb.sql is a Python module for SAP MaxDB databases. You can use this module to execute SQL statements in Python scripts.SapDB_Session SapDB_Session is a class of the sdb.sql module. You can use the methods of this class to execute SQL statements.An object of this class corresponds to a database session. To generate an object of this class, use the connect method (sdb.sql module). After the last reference to an object of this class has been deleted, the system closes the database session with a ROLLBACK of the transaction.The high level working of recovery builder script for generating the import command fileRecovery builder source code:[In the below source code, the areas to be replaced with the system specific values are mentioned using the tag <–content–>, replace the whole tag with the specific content]#———————————-
# Import Python modules
# ———————————-
import sys
import os
#———————————-
# Import Max DB Python modules
# ———————————-
import sdb.dbm
import sdb.sql
#————————————-
#function definition
#————————————-
def get_pg(i,list):
pg=[]
temp=list.splitlines()
pg=temp[i].split(“t”)
return pg[1]
#————————————-
#Log file & Import file
#————————————-
log_file=open(“<–path_to_log_file–>log”, “a”)
imp_file=open(“<–path_to_import_file–>imp”, “w”)
#————————————————————
# Call up the Database Manager and log on to a database
# ———————————————————–
session = sdb.dbm.DBM (”, “<–SID–>”, ”, “<–DB_USER_NAME–>” + ‘,’ + “<–PASSWORD–>”)
_cmd = “db_admin”
_result = session.cmd (_cmd)
_cmd = “db_restartinfo”
_result = session.cmd (_cmd)
log_file.write(“n” + _result)
#————————————-
#returns in string format
#————————————-
_current=0
_current=get_pg(0,_result)
#————————————————————————————-
#read the directory where the primary log files were shipped in Stand-By server
#————————————————————————————–
_log_list=[]
_prim_log_path=”<–path_to_primary_log_file_dir–>”
_dir_list = os.listdir(_prim_log_path)
for i in _dir_list:
_log_list.append(i.split(‘.’))
#—————————————————-
# Identify pages for the log files to be applied
#—————————————————-
_log_pg_list=[]
i=0
while i < len(_log_list):
j=1
#———————————————————–
# Here LOG is used to define the type not the medium name
#———————————————————–
_cmd=”medium_label “+”LOG “+ _log_list[i][j]
i+=1
_result=session.cmd (_cmd)
_log_pg_list.append(get_pg(14,_result))
#————————————-
# Find the first log page
#————————————-
int(i)
for i in _log_pg_list:
if _current > i:
max_ind=_log_pg_list.index(i)
#————————————-
# DBM start command generation
#————————————-
imp_file.write(“db_connect”)
imp_file.write(“ndb_admin”)
#———————————————————————
# leave a space after the log_template_name_in_stand-By_DB below
#———————————————————————
_log_template_name = “<–log_template_name_in_stand-By_DB–> “
start_cmd=str(“recover_start ” + _log_template_name + _log_list[max_ind][1])
imp_file.write(“n” + start_cmd)
#————————————————————–
#adding the generated cmd in Log file for troubleshooting
#————————————————————–
log_file.write(“n” + start_cmd)
max_ind+=1
#————————————-
# DBM replace command generation
#————————————-
_abs_prim_log_path=”<–path_to_primary_log_file_dir–><–log_file_name_w/o_extentsion–>”
while max_ind < len(_log_list):
replace_cmd=”recover_replace “+ _log_template_name + _abs_prim_log_path+”.”+_log_list[max_ind][1]
max_ind+=1
#————————————————————–
#adding the generated cmd in Log file for troubleshooting
#————————————————————–
log_file.write(“n” + replace_cmd)
imp_file.write(“n” + replace_cmd)
imp_file.write(“ndb_offline”)
#—————————————————-
# Close the connection to the DBM and files
# —————————————————
session.release ()
log_file.close()
imp_file.close() 4. Import fileAs a result of recovery builder script execution, the import file will get generated in the mentioned path in the above source code5. Recovery Apply scriptEnsure the Import file is generated successfully with required DBM commands, use the below code to execute the import file, you can schedule the script once to run once the recovery builder script is completed<–installation_path–>programspgmdbmcli.exe -d <–SID–> -u <–DB_user–>,<–Password–> -i “<–path_to_import_file–>”Feature Scope:We are working on the automation for identifying the error/failure status and to notify the appropriate recipients.Reference:HowTo – Standby System (Recovery from Log Backup) | SAP Help PortalKindly post your valuable comments and suggestion on the same!Thank you Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
+ There are no comments
Add yours