Zero Downtime Backup of MaxDB database with HP Data Protector

SAP MaxDB

SAP MaxDB is the database management system developed and supported by SAP AG. It has its

focus on the requirements of SAP customers and SAP applications and can be used as a less

expensive alternative to databases from other vendors for your own or third-party applications as

well. It is a competitive database management system for medium to large server configurations, and

a convincing offering for a desktop or laptop database management system since SAP MaxDB is very

easy to install and operate.

The key benefits of SAP MaxDB are its many built-in self-administering features. SAP MaxDB is

available for the most prominent operating system/hardware platforms, Microsoft Windows, Linux,

and UNIX.

You can access the complete SAP MaxDB documentation at http://maxdb.sap.com/documentation/

Zero downtime backup

The general idea behind split mirror backups is to stream the backup off the mirror instead of the

productive disk. The mirror is typically connected to a separate host with a tape device attached.

Usually, hardware mirror technologies such as Continuous Access XP or Business Copy XP are used to

create the mirror.

Before a backup off a mirror can be started, a valid point in time disk image needs to be created. It

needs to be consistent so that it can be fully restored. The mirror is not created at backup time but

needs to be established beforehand. To create the backup image, the mirror is simply split off the

productive disk.

As the application host and backup host are different, it is very important that all cached information

(database cache, filesystem cache) on the host is flushed to the disk before the mirror is split off. There

are three ways of achieving this:

 The databases are put into backup mode

 The databases are taken offline

 The filesystem is unmounted

The backup image will then be consistent.

For a plain filesystem backup, it is not essential to unmount the filesystem first. The split-mirror backup

can complete successfully with the filesystem mounted. However, a successful restore of all files and

directories cannot be guaranteed since cached data will not be written to disk prior to the split. It is

therefore recommended to unmount the filesystem before performing a spit-mirror backup.

If a database is running on a filesystem, there is no need to unmount the filesystem as the

database controls the write to the disk and ensures that data is really written to the disk and not

to the filesystem cache.

For an online database backup, the backup image cannot be restored on its own. The archive log

files from the application host are also needed. The archive log backup can be started when the

database is taken out of backup mode. This will happen immediately after the mirrors are split off

successfully their productive disks. The backup duration (from the perspective of the application) is

only the time required to perform the split, during which the consistent backup copy is created. The

backup and resynchronization of the mirrors do not affect the production database’s I/O performance

as they happen inside the XP Disk Array.