Oracle8i Automated Standby Database

Oracle8i offers a variety of disaster recovery solutions that provide the ability to create and maintain a remote copy of a production database at an alternate site. In the event of a disaster, users can continue to function by accessing the remote database. The Automated Standby Database available in Oracle8i is one of the prime solutions to ensure business continuity after a disaster.

Overview

In the event of a disaster, a standby database can take over the processing and data serving responsibility from the primary production database, providing near continuous database availability. The Oracle8i Automated Standby Database feature provides the means to create, and automatically maintain, one or more copies of a production database to protect against disasters. A standby database is initially created by copying, or cloning, the production database. A standby database can reside in the same data center or a different one than the production database. If the standby database is located at a different site than the production database, recovery from a disaster is enhanced.

Figure 1: Standby Database Becomes the Production Database After a Disaster

After the standby database is created, updates and changes made to the production database must be propagated to the standby database so that the two databases remain synchronized. The primary mechanism used to ensure database recovery is the logging of changes to the database. The log files contain all the data needed to perform database recovery. The log files record every change made to data and metadata in the database and are the vehicle by which changes made at the production database are propagated to a standby database. As archived redo logs are generated on the production database, they are applied to the standby database. This enables the standby database to remain synchronized with the production database.


Figure 2: Manual Synchronization of the Production and Standby Database

Enhanced Manageability

The new Automated Standby Database in Oracle8i can automatically transfer and apply archived redo logs to a standby database placed in sustained recovery mode. As archived redo logs are generated at the production database, they are automatically transferred to the standby database via a Net8™ connection. After being received at the standby database, they are automatically applied to the standby database. There is no need to manually enter file names or locations to apply the logs. This eliminates the need for manual procedures to copy and transmit the redo logs and for the operator at the backup site to manually specify which logs to apply. While manually maintaining a standby database is still an option, automating this process eliminates a potential source of human error, and increases database and application availability.

Figure 3: Automatic Synchronization of the Production and Standby Databases

Enhanced Recoverability

If desired, multiple standby databases of a single production database can be created and automatically maintained using this technology, providing additional insurance against a data center disaster. In addition to one archived log being created on the production system, up to four other copies of the archived logs can be created either remotely or locally.

The archive log destinations are assigned user-defined attributes to implement a disaster planning policy. For example, archive log destinations can have the attributes of optional or mandatory. Optional specifies that archival to the destination is not required. Mandatory specifies the archival must succeed before the online log file can be reused. It is also possible to specify the minimum number of archive log destinations that must succeed before allowing the reuse of online log files. These attributes ensure a user-defined minimum number of copies of the archive logs that are created to assure recoverability, yet prevent networking errors or out of space conditions from stalling the production database. Another attribute can also be used to automatically retry sending the archive log to the destination. If a networking error or out of space condition prevents a successful log file creation, the Oracle database after a user specified interval, automatically re-attempts the archive operation. These capabilities ensure the standby database remains synchronized with the production database and is ready to take over in the event of a disaster.


Figure 4: Automatic Maintenance of Multiple Standby Databases

Finally, a full standby database is not required to remotely receive and store the archive logs. A compatible standby database control file at the destination site is all that is required to accept and record the fact that archived log files have been received from the production database. This can be used to automate the transmission and storage of log files at a remote site without incurring the cost of replicating the entire production database. While this ensures backups of archived log files will exist offsite, failover to the standby site would be delayed until after the database is restored and the archive logs applied.

Enhanced Performance

Maintaining a standby database imposes no overhead on the production database. Log files are normally created by the production database to recover from a system failure and no extra logging is done to maintain a standby database.

Oracle8i offers administrators the ability to create multiple ARCHiver processes. Multiple ARCHiver processes improve performance by preventing the production database from stalling when it ships logs through a network to a remote standby database. Multiple ARCHiver processes also prevent bottlenecks that can occur when log file switches occur faster than a single ARCHiver process can write the archive logs. This can occur on a database with heavy update transaction rates where redo logs entries are generated faster than a single ARCHiver process can archive them.


Figure 5: Using Multiple ARCH Processes

Running multiple ARCH processes eliminates archiving as a bottleneck and can be used on a production database independent of, or in conjunction with, a standby database.

Enhanced Usability

Oracle8i Automated Standby Database also has the capability to use a standby database as a read-only database. In the past, a standby database or an on-disk database backup could not be opened or used without subsequently re-cloning the production database. If the standby or backup database was opened,, it logically became a different database. This caused resources allocated to a standby database to be idle and unavailable for any use other than backing up the production database.

In Oracle8i, administrators can take the standby database out of recovery mode and open it in read-only mode. This can be used to temporarily offload query or report processing from the production database to the standby database. Queries against read-only databases are transactionally consistent and do not display uncommitted data. This is possible because of Oracle's read consistency architecture.


Figure 6: Read-Only Query Processing Against a Standby Database

Read-only mode allows sort segments and other data to be written to temporary tablespaces, yet prevents other modifications to the data files or redo logs that would invalidate the standby database. While in read-only mode, a standby database can continue to automatically receive the archive redo logs from the production database, so they are available if required. When the query processing is complete, the standby database can be returned to sustained or manual recovery mode, without re-cloning the production database, and the queued logs are applied. This provides more productive resource usage while maintaining high database availability.

Many mission-critical installations maintain an on-disk backup of the production database. This makes it easy to quickly restore the database in the event of a media failure or user error, without incurring a lengthy restore from tape. The read-only database functionality also allows these on-disk backups to be used for query and report processing.

Summary

The Oracle8i Automated Standby Database feature protects against site disasters and automates the maintenance of backup standby databases. This technology enhances the manageability, recoverability, performance, and usability of disaster resources and plans, and helps mitigate the effect of disasters. These features are available to every Oracle8i customer, from small workgroups to global enterprises, allowing continuity of service for critical business applications can be ensured.