This page provides introductory information about one of the hot standby functionality that is available for SAP MaxDB. The hot standby system concept (with shared log area) combines a high availability cluster software and a storage replication technology (in the sense of a hardware-implemented data area cloning) with the SAP MaxDB recovery mechanism (Hot Standby System (With Shared Log Area)).
Usecases and Benefits
The hot standby technology provides robust and fast failover and minimizes the failover impact on the applications that work with the SAP MaxDB. Currently, setting up a hot standby configuration is the most advanced approach to achieve high availability for a SAP MaxDB or SAP liveCache database.
The solution is particularly useful as building block of mission-critical SAP SCM scenarios in order to implement SAP liveCache high availability. The hot standby completely obsoletes long-running rollback operations that occasionally can occur with a traditional SAP liveCache restart after a system crash. It also prevents the performance degradation that occurs due to the cold-restart. While any SAP MaxDB benefits from this, it is most usable in the memory-centric SAP liveCache configurations to make the time that is required to restore the SAP liveCache business availability more predictable.
Required building blocks
The IT hardware infrastructure for a hot standby SAP MaxDB environments typically comprises of two clustered servers with shared-access storage for the log volumes and additional storage capacity for the data volumes that needs to support quick creation of a full physical data copy without denying r/w-access while the copy process is ongoing.
SAP MaxDB supports hot standby with an API specification. There is a set of DBM commands to handle hot standby databases. The hot standby concept is also integrated into the SAP MaxDB database manager. A third party vendor has to provide a library that implements the API and runs as part of the RTE (runtime environment) of SAP MaxDB. Without this library, a hot standby can not be configured. Typically the same vendor provides the cluster integration software for the SAP MaxDB in order to seamlessly integrate all building blocks.
An overview of how it works
The 3rd party library enhances the SAP MaxDB runtime environment with storage handling capabilities. It enables the following behavior: A hot standby SAP MaxDB database can be started on a secondary server. The hot standby maintains its own copy of data volumes. It will regularly consult the shared-access storage with the log volume of the master SAP MaxDB (that is running on a different server) in order to become aware of recent changes that need to be applied to keep the standby data logically in sync with the master data. If the standby can not restore its own data volumes from the information that it finds in the active (='hot') logs of the master SAP MaxDB system, it will trigger the creation of a storage-level clone via the library. This should rarely be necessary. It usually happens as part of the initial startup of a standby or as part of the first startup after the standby was offline for a longer period of time while the master SAP MaxDB system was busily running. The procedure automatically builds up a consistent copy of the master data without interrupting the master operation. Afterwards the physical copy gets split off from the master data volumes. It will eventually be synchronized logically by the standby database as described above.
Notice: There is no need to separately implement a log shipping mechanism in a hot standby configuration. There is also no need for permanent(!) hardware-based volume synchronization during SAP MaxDB runtime.
A third party implementation is available from Hewlett-Packard as part of the HP Serviceguard cluster extensions for SAP software (SGeSAP 4.51 or higher). It requires HP Integrity servers running HP-UX 11i v2 or higher. Supported storage arrays include a range of HP Storageworks XP arrays. HP Business Copy is used for the hw-based copy.