Split Mirror Backup 

Use

This section describes how you can use split mirror disk backup with BRBACKUP to perform an online or offline backup of your Oracle database without downtime. We recommend this especially for online backup of large databases.

We provide this information on split mirror backup for advice only. Consult your hardware partner for help in setting up split mirror backup.

It is especially important to make sure that the data on the backup database host is consistent when you perform the backup.

Integration

●      Computing Center Management System (CCMS)

○       You cannot use CCMS to schedule split mirror disk backups. This is because BRBACKUP runs on the backup database host if scheduled from the DBA Planning Calendar.

○       However, you can use CCMS to monitor backups on the production system, because BRBACKUP sends status information to the production database, which CCMS can then use.

●      The BACKINT interface is also supported in the split mirror configuration. This configuration is transparent to BACKINT and there are no extra considerations for BRBACKUP.

●      A split mirror disk backup only includes database backups with BRBACKUP. Backups of the offline redo log files using BRARCHIVE are not included because they do not place significant load on the production host. In a standard setup, you back up the offline redo log files on the database server to local or remote tape devices, on disk or with BACKINT.

If the backup device is connected to the backup server, you can use the remote device – using backup_dev_type = pipe|pipe_auto|pipe_box – or the BACKINT interface.

●      To synchronize BRBACKUP sessions with BRARCHIVE sessions, you can start a BRARCHIVE session immediately after the disks are split and not just at the end of the BRBACKUP run. When the disks have been split, Oracle regards the backup as already finished.

Features

In the split mirror configuration, the disks of the production database host are mirrored, that is, synchronized. BRBACKUP runs on a backup database host, where the backup is performed after the mirror disks have been split and mounted. On the production host, this saves processing power otherwise required for the backup, so that the production SAP System is unaffected by the backup.

BRBACKUP can be used to control the splitting and later synchronization of the disks. If you want to open the database on the backup host and use it as a "reporting server" you can perform the synchronization yourself later.

The actual splitting and later synchronization of disks is executed by a script or program supplied and supported not by SAP, but by the manufacturer of the operating system, disk subsystem, or backup software.

If the split disks do not have to be resynchronized immediately after the backup you can use the backup server along with the mirror disks to operate an independent SAP system on the backup server. For this you must install the entire Oracle server software on the backup server.

For more information, see the following:

●      To start split mirror backup on the production database server, see SAP Note 170607.

●      To divide the split mirrors, see SAP Note 378818.

Activities

There are two basic scenarios:

●      Split Command Scenario

This uses split_cmd and resync_cmd to split and resynchronize the mirror disks. BRBACKUP controls the splitting and later synchronization of the disks.

●      SPLITINT Scenario

This uses the SPLITINT interface program with split_options and split_resync to split and resynchronize the mirror disks. BRBACKUP calls SPLITINT to actually split and resynchronize the disks. SPLITINT executes the split and resync requests from BRBACKUP using the appropriate disk subsystem calls.

Database handling with the SPLITINT scenario is considerably faster than with the split command scenario. This is the recommended approach.

For each scenario, there is an online and an offline variant.

The following graphic shows in outline how split mirror backup works:

	Split mirror Online Backup	Split mirror Offline Backup
1	Tablespaces set to status BACKUP	Production database shut down
2	Mirror disks (A' and B' in the graphic) split and connected to backup server using: Split command scenario: split_cmd SPLITINT scenario: SPLITINT program
3	Tablespaces reset to normal status	Production database restarted
4	Mirror disks backed up on backup host
5	Optional: Primary and mirror disks resynchronized using: Split command scenario: resync_cmd SPLITINT scenario: SPLITINT program

Consider online split mirror disk backup if high availability is an important consideration for your system.