Zero Downtime Backup of MaxDB database with HP Data Protector

* If pre-exec script execution or creation of the replica fails, you can forcibly resume the MaxDB

logwriter process by setting the omnirc variable ZDB_ALWAYS_POST_SCRIPT=1. See Set the

ZDB_ALWAYS_POST_SCRIPT omnirc variable on page 26 for more details, and the complete DP

Session report on the benefit of deploying the omnirc variable, ZDB_ALWAYS_POST_SCRIPT, on

application server in Appendix C

on page 50.

The process in detail

 BSM starts on CM and parses the Backup Specification.

 SMISA is started and purges the ZDB database on the backup server.

 SMISA resolves backup objects on the application server.

 SMISA resolves the EVA units that control storage volumes on the backup server.

 SMISA verifies if the snapshot type and policy requirements are complied with.

 SMISA executes the suspend_db.cmd application level pre-exec script. The script authenticates

and logs onto MaxDB’s Database Manager via dbmcli.

 On the application server, MaxDB’s dbmcli command suspends MaxDB’s logwriter process.

– This pre-exec script is executed at the application level.

– By this time, resolution of volumes has taken place and so the MaxDB data volumes are consistent

before the split occurs.

– The logwriter process remains suspended just for the time needed to resolve and create a replica

off the original. During this suspension, no end-user I/O takes place on the data volume,

achieving data consistency.

– The logwriter process remains suspended until the replica is split, and then resumes.

– The time difference between the execution of the pre-exec and post-exec scripts, both at

application-level, constitutes the effective downtime of the backup.

 A message is displayed in Data Protector Backup session that the logwriter process has successfully

completed.

 The script exits successfully. If the MaxDB’s logwriter process was already suspended then the pre-

exec script will report with the following error message:

ERR

 24988,ERR_SQL: SQL error

 104,DBM command impossible at this time

The pre-exec script will not fail the Data Protector session, but will continue to complete from where

BSM will take over. Since the prerequisites for splitting are correct, the BSM will continue to split,

and then run the backup normally.

See the complete Data Protector session report of such a scenario in

Appendix B

on page 44. Also,

compare this against the impact of resuming the MaxDB logwriter process on an already working

logwriter process (see Appendix C

on page 45).

 SMISA splits the MaxDB data volume that has been made consistent through the logwriter process

suspension, and from it creates a replica of the consistent MaxDB data volume.

 SMISA executes the resume_db.cmd application level post-exec script. The script authenticates

and logs onto MaxDB’s Database Manager via dbmcli.