MaxDB (SAP DB) allows you to exploit "Split Mirror Techniques" and snapshots from storage system providers.
Some providers of storage systems offer the possibility of mirroring hard disks in a controlled manner. Mirrored hard disks can be separated in the ONLINE operation, the copy stored and hung back onto online operation.
The hard disks affected are grouped together in a consistency group. When you split, all hard disks in the group are collectively detached from the continuous I/O. The hard disks have an I/O consistent status after the split (Consistent Split).
This mechanism can be used for saving SAP DB database instance data or a liveCache instance data.
The mirror hard disks can also be used to start a second database instance, if they can be written to. For example, a database structure check may occur.
Furthermore, the mirror can be used as a system copy. If the split mirror contains the log volumes, the new database instance can be set to the operation status ONLINE after you restart. The consistency of the database is ensured on transaction level. This means that transactions that are not completed are moved back. If the mirror does not contain log volumes, you can carry out a log recovery specifying an UNTIL point in time, if required.
Take the rules for SAP system copies into account. If you want to ensure the consistency between several SAP systems, you must collectively split the hard disks of all systems.
In addition, providers of storage systems offer the option of creating snapshots. Snapshots record an I/O-consistent state. Changes to blocks are not written back to the old block position. This means that you can carry out a snapshot restore. You can use the image of a snapshot for a data recovery or as copy for a system copy.
Define all data devspaces and the system devspace (Version 7.3) and all data volumes (Version 7.4) in a consistency group. If you want to use the split mirror for a system copy without log recovery, configure the log devspaces or log volumes in the same consistency group.
When snapshots are used, log devspaces (volumes) within a snapshot group can put a high load on the fill area of the disk system. For this reason, we do not recommend that you create snapshots for log devspaces (volumes).
The storage system ensures that a split occurs simultaneously. This means that there is a defined time after which no more I/O occurs on all devspaces (volumes). The cache mechanism of the storage system ensures that all data from the cache (which was written at the defined time for database instance purposes) is written onto the hard disks.
For database instance purposes, no further actions are required for the split or for the generation of snapshots.
If the data devspaces (volumes) do not fit into a consistency group or if the storage system cannot maintain the I/O consistency for a defined time, you can suspend the log writer of the database instance. To do this, proceed as described in note 616814.
Caution: If the mirrors of the log hard disks are also separated, the log area in the ONLINE operation must, as before, be mirrored at least once. The mirrored log hard disks are not used for the recovery. The mirrored log hard disks are required if you want to start a second database instance using the mirror hard disks.
The log must still be saved using database means (save log, autosave log). To save the log area, you need an initial data backup.
The separated mirror hard disks or the snapshot can be saved using the relevant means (on tapes, for example). You must observe the known rules for keeping backup generations.
The parameter file is also saved during the data backup. The content of the parameter file is not in the database instance itself. Save the parameter file occasionally (especially after changes to the parameter) if you decide not to use data backup.
SAP recommends that you do not avoid backing up data completely. When you create data backup, the database kernel checks the check sum, which is stored in each data block. When you use split mirror or snapshots to save, these checks are not carried out.
1. Errors in the data hard disks -> data recovery
Implement a restore of the hard disks separated in the ONLINE operation on the primary hard disks. Only play back the content of the data devspaces and the system devspaces (version 7.3) or data volumes. The log devspaces (volumes) are not played back.
Set the database instance to operational state COLD (ADMIN).
a) Restart or recovery using the Database Manager GUI
When you use the Database Manager GUI, go to menu Recovery -> Database (or use the Recovery Wizard).
If the Database Manager GUI offers the option "Continue restoring pages/log", select it and recover the log backups provided in the subsequent menu. After recovery, the database instance is automatically set to operational state WARM (ONLINE).
If the option "Continue restoring pages/log" is not offered, directly implement a restart in operational state WARM (ONLINE). In this case, the log entries required are still available in the log devspaces or log volumes.
b) Restart or recovery without Database Manager GUI
If you do not use the Database Manager GUI, execute the following Database Manager CLI command:
dbmcli -d <database_name> -uUTL < dbm_user> ,< password>
Used LOG Page 23950
First LOG Page 10776
ID Restart Record p28121:DB743_20040414_153142
Id LOG Info p28121:DB743_20040414_153142
If the value for "Restartable" is 1, you can set database instance ONLINE directly with a restart. If the value for "Restartable" is 0, start the log recovery. First, specify the log backup that contains the "Used LOG Page". See the backup history as to which log page numbers belong to which log backups.
2. Errors in the log hard disks
I/O errors in the log hard disks are handled as for systems without split mirror technology. The log area is either mirrored by the database instance (log mode DUAL or LOG_MIRRORED=YES) or by the hardware (for example, RAID1).
During hardware mirroring, the I/O system must ensure that I/O errors on a log hard disk are not reported to the database instance.
Note the following: When the file system with the database software is still intact, you should not retrieve from a split or a snapshot during recovery of the relevant areas.
In the run directory, there are log files, for example, that may be required to determine the cause of the problem that triggered the recovery.
Start the mirror as a second database instance
If log hard disks are also separated during the split, the separated version of data, system and log devspaces (volumes) is restartable. Following a restart when using the separated log devspaces (volumes), changes cannot be made in the database instance to transactions which were not concluded during the split.
You can use the mirror hard disks to start a second database instance. The second instance can be started with the same name on a different server or with a different name.
1. Register the second database instance.
Versions 7.2.4 or later:
dbmcli db_create <database_name> <dbm_user>,<password>
The DBM user and its password must be the same as the values in the original database instance. If you want the second database instance to run with another instance software, you must specify the -R option.
2. Make a parameter file available. The parameter file is called
Copy file <database_name> to <new_database_name> into the same directory or into the relevant directory on the target machine.
3. Check database parameter RUNDIRECTORY:
Versions 7.2.4 or later: Database Manager GUI -> Configuration -> Parameter
Change the value if another run directory is being used in the target system. Copy the files from the original run directory into the target system run directory as required.
4. Change the names of the devspaces (volumes) if the names for the new database instance are not the same as the names for the original database instance:
Database Manager GUI -> Configuration -> Data (Log) Devspaces
5. Change the operational state of the new database instance from OFFLINE to ONLINE.