Show TOC

Hot Standby System (With Shared Log Area)Locate this document in the navigation structure

Use

In this hot standby solution, the hot standby system consists of a master and one or more standby databases. Master and standby databases share one log area, to which the standby databases only have read access. Apart from the log area, master database and standby databases share no other system resources.

The data areas and the shared log area of all databases are located in a storage system. We recommend that you mirror the data and log areas in the storage system.

The standby database is in a continuous restart mode (STANDBY operational state). To apply the changes that are made in the master database, the standby database performs redo operations of all changes in committed transactions using the redo log entries from the shared log area.

Users can only read data in the standby database, but cannot change data. Note that no isolation of transactions is possible in the standby database, and therefore there is a risk of dirty reads (see Concepts of the Database System, Isolation Level).

The database computers are usually part of a cluster. The cluster software monitors the master database and triggers the takeover by the standby database if the master database fails. Outwardly, the hot standby system behaves like a single database. To access the hot standby system externally, you need the database name and the name of the virtual server (identifies the computer that currently has the role of master database).

Example

The following graphic shows a hot standby system consisting of a master database on the computer GENUA and a standby database on the computer PARMA. The computers GENUA and PARMA are part of a cluster. The name of the database is DEMODB, and the virtual server name is HSC_1. The data and log areas of the databases are located in a storage system, while the cluster software is installed on a separate computer.

Figure 1: Example Hot Standby System (With Shared Log Area)
  1. Data changes are written to the data area of the master database.

  2. Log entries are written to the shared log area.

  3. Log entries from the shared log are used for redo operations to update the standby database.

  4. Data changes are written to the data area of the standby database.

Prerequisites

Hardware

  • The master and standby computers use hardware with the same amount of memory and the same type and number of processors.

  • Every computer has a unique name.

Operating System

You have administrator rights on the master and standby computers.

Cluster Software

The master and standby computers are part of a cluster. The cluster software is responsible for monitoring the master database and initiating the takeover of the master role by the standby database if the master database fails.

For information about setting up a cluster, see the manufacturer's documentation.

Cluster software requirements:

  • Fail-over mechanism that allows the master and standby databases to switch roles in case of errors

  • IP switching

    Master and standby databases each have their own IP address

Setting up of a hot standby system with shared log area for SAP MaxDB was tested for the following cluster software: IBM High Availability Cluster Multiprocessing for AIX clustering.

Storage System

The data and log areas of the master and standby databases are located in a storage system. For information about setting up the storage system, see the manufacturer's documentation.

Storage system requirements:

  • All databases can access the shared log area simultaneously.

    Ideally, the storage system offers two different authorizations for access to the log area: read-only and read and write.

  • Every data volume of each database has its own physical storage area in the storage system. To avoid collisions of I/O accesses, we recommend separate hard disks in the storage system.

    The data volumes of each database have the same access path on their respective computers; alternatively, you can set up a corresponding symbolic link.

    You can create consistent copies of the data volumes (split) that can be read and written-to independently of one another after the split. While a copy is being created, the master database can continue to write to its data volume so that downtimes remain minimal. After the split, the data volumes of the master and standby databases are completely independent of each other.

  • Fast copying of data within the storage system

    When you initialize standby databases or after a failure of the master database, large amounts of data may have to be copied.

  • Fast transmission of data between the storage system and the computers on which the databases are located

The following storage systems fulfill these requirements and support the setting up of a hot standby system with shared log area for SAP MaxDB: EMC Symmetrix, IBM TotalStorage Enterprise Storage Server (ESS), IBM TotalStorage SAN Volume Controller (SVC).

Database Software

  • The same database software version is installed on the master and standby computers.

  • All SAP MaxDB software paths and file names are the same for master and standby databases (run directory, volumes, trace files, and so on).

  • The global listeners and installation-specific SAP MaxDB X servers are running on the master and standby computers.

Procedure
  1. Set up the cluster consisting of the computers on which the master and standby databases are to be located.

    For information about configuring the cluster, see the documentation for your cluster software.

  2. Set up your storage system.

    For information about configuring the storage system, see the manufacturer's documentation.

  3. Create the database that will later become the master database.

    The volumes of the database must be located in the storage system.

    For more information about creating databases, see Creating Databases.

  4. Start the configuration.

    During this step, you assign the virtual server name for your cluster to the master database computer and the master database assumes the master role in the hot standby system.

    Note that the virtual server name must not be the same as the name of a computer in the cluster.

  5. Add one or more standby database to the hot standby system.

    The system creates empty standby databases.

  6. Activate the hot standby system.

    During this step, the storage system copies the complete content of the master database in a consistent state, for example, the state at the last savepoint, to the data area of the standby databases.

Result

At regular intervals, the master database informs the standby databases of the position in the log area up to which it has written new log entries to the shared log area. To configure this interval, use the HotStandbySyncInterval special database parameter.

The system regularly updates the standby databases by performing redo operations using the log entries from the shared log area. Thus the content of the standby database always corresponds to the content of the master database, though with a certain delay. To configure this delay, use the HotStandbyDelayTime? special database parameter.

Note that from now on you must send all administration commands to the master database only. The system automatically applies them to the standby database as well. Changes to database parameters in the master database that are applied in ONLINE operational state are automatically applied to the standby database as well.

For more information about these database parameters, see Special Database Parameters.

What Happens If the Master Database Fails?

If the master database of the hot standby system fails, one of the standby database automatically assumes the role of master database. The downtime is short (a restart of the master database would take much longer, for example).

When the cluster software detects a failure of the master database, the following steps are carried out:

  1. The cluster software assigns the virtual server name to the standby database computer, thus making the former standby database the new master database. This means that the application connection is now redirected to the standby database computer. Note that the connection between database and application was broken by the failure of the master database and you have to reconnect your application to the database.

  2. The storage system gives the new master database write authorization for the entire log area.

  3. The new master database imports the remaining log backups from the old master database and performs redo operations for the respective data changes.

  4. The database system transfers the new master database from the STANDBY to the ONLINE operational state.

Once you have eliminated the error in the master database, you can add the old master database as a standby database to the hot standby system.