Hot Standby for Disaster Tolerant Systems

Oracle Rdb Release 7 and Oracle CODASYL DBMS Version 7 introduce new Hot Standby software that physically duplicates a database as a means of providing disaster tolerance. By implementing the Hot Standby, businesses with mission-critical requirements can prevent the catastrophic loss of data and data processing capability. Failure detection and failover can be achieved with minimal interruption to database users and application processing.

The Hot Standby software prevents an Oracle Rdb database or Oracle CODASYL DBMS database from becoming a single point of failure by physically duplicating a master database at a geographically-remote standby site across a wide area network. In the event of a node or cluster failure, the "hot standby" database becomes the master database and takes over application processing.

Automated AIJ Backup and Roll-Forward Operations

The standby database is created from a backup copy of the master database. Once started, the replication operation rolls forward the group commit operations to the standby database. As database modifications are applied to the after-image journal (AIJ) for the master database, the Hot Standby option automatically applies the modification over a network connection to the after-image journal for the standby database.

Automatic Database Synchronization

The Hot Standby option automatically performs coordinated database synchronization and verification with high performance and minimal impact on system resources:

  • Starting the replication services is the only manual intervention required.
  • "Replication Governor", an optional component, coordinates the database replication operation, effectively ensuring synchronization between the master and standby databases.
  • The degree to which the master database and standby database stay synchronized can be determined by the DBA. Consistency levels range from a fully asynchronous “fire-and-forget” model to a synchronous “transaction commit” level in which data modifications are made to both databases.
  • Four server daemons, two on the master database and two on the standby database, are deployed to implement client/server relationships that are necessary to provide database replication and verification services. The four-process model means that the master database cluster resource requirements and performance impact are minimal, while all available resources on the replicated system are fully utilized.
  • No specific hardware is required to use the Hot Standby option.
  • No changes to application code are required.

Replication Commands

To start the replication operation, a Replicate command can be entered using either the Rdb Management utility (RMU) or the DBMS Database Operator (DBO) utility, as appropriate. These utilities provide syntax and semantics for the following Replicate commands:

Command Description
Replicate After_Journal Start Initiates replication operations on the master node or the standby node
Replicate After_Journal Stop Terminates replication operations for the database
Replicate After_Journal Reopen_Log Allows the opening of a new replication log file

Compatibility

The Hot Standby is completely compatible with the standard Oracle Rdb and CODASYL DBMS database components. All database DDL and DML functionality is fully supported.

Hot Standby allows users to choose from among OpenVMS operating system platforms for both the master and the standby systems, mixing and matching as follows:

  • For Oracle CODASYL DBMS databases, the master and standby databases can be implemented on systems running OpenVMS VAX, OpenVMS Alpha, or both.
  • For Oracle Rdb databases, the master and standby databases can be implemented on systems running OpenVMS VAX, OpenVMS Alpha, both.

The Hot Standby option uses the following network transport protocols:

  • TCP/IP
  • DECnet/OSI
  • DECnet for OpenVMS

Failure Handling

The standby cluster configuration is separate and distinct from the master database configuration. System failure of either the master or standby database is completely isolated from the other. Neither database is effected by the failure of the other.

Applications must be manually failed over to the hot-standby database if a failure occurs. There is no automatic failover support. However, the Hot Standby software automatically provides failover detection and notification for varying levels of failures: network, cluster, node, disk, server process, application process, database monitor, and other resources (such as process quotas, disk quotas, or disk space exhaustion).

Related Articles, Presentations, and White Papers: