| 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:
|
Bookmark