|Oracle® Data Guard Concepts and Administration
10g Release 1 (10.1)
Part Number B10823-01
The features and enhancements described in this preface were added to Oracle Data Guard in Release 10.1. The new features are described under the following main areas:
The following enhancements to Oracle Data Guard in Release 10.1 improve ease-of-use, manageability, performance, and include innovations that improve disaster recovery capabilities:
Data Guard log apply services can now apply redo data as it is received on the logical or physical standby database, without waiting for the current standby online redo log file to be archived. This allows reporting on more up-to-date data, quicker failovers and switchovers, and reduces planned and unplanned downtime.
Data Guard supports recovery through open resetlogs by allowing recovery on a standby database to react appropriately to a
RESETLOGS operation, instead of requiring the standby database to be re-created. Because an
ALTER DATABASE OPEN RESETLOGS statement is always issued after a point-in-time recovery or a Flashback Database operation, the recovery through resetlogs feature allows the standby database to resume.
Data Guard supports the new Flashback Database feature that allows a standby database to be quickly and easily flashed back to an arbitrary point in time. This feature provides the following benefits when used with Data Guard:
See Section 6.2.2 and the Oracle Database Backup and Recovery Advanced User's Guide for more information about using Flashback Database
Data Guard log transport services now use authenticated network sessions to transfer redo data among the members of a Data Guard configuration. If the Oracle Advanced Security option is installed, security can be increased still further by using encryption and integrity checksums on network transmission of redo data.
The Data Guard broker can now be used to manage Data Guard configurations that contain Real Application Clusters primary or standby databases.
It is now possible to dynamically add a standby database to a Data Guard configuration that contains a Real Applications Clusters primary database, when that primary database is operating in either the maximum protection or the maximum availability level of protection, without shutting down the primary database.
This enhancement requires using initialization parameters that are new in Oracle Database 10g Release 1:
VALID_FOR attribute of the
LOG_ARCHIVE_DEST_n initialization parameter can be used to create initialization parameter files that are role independent. This simplifies switchovers and failovers because it is no longer necessary to enable and disable role-specific archiving destinations after a performing a database role transition. This feature makes it possible to use the same parameter file whether the database is running in the primary or the standby role.
Managing files needed for backup and recovery is simplified when these files are stored in a flash recovery area. If a flash recovery area is configured, Data Guard will implicitly set the
LOG_ARCHIVE_DEST_10 initialization parameter to point to the flash recovery area and will use this destination for local archiving unless you explicitly configure another local archive destination.
The archiver process (ARCn) can now transmit redo data to remote destinations that are configured to use standby redo log files. Failovers are simplified when this feature is used, because partially filled archived redo log files no longer have to be registered before performing a failover.
The default archival processing in a Data Guard configuration has changed so that archiver processes (ARCn) on the primary database will completely and successfully archive the local online redo log files before transmitting the redo data to remote standby destinations. Before release 10.1, the default behavior was to transmit redo data to the standby destination at the same time the online redo log file was being archived to the local online redo log files. This change allows the redo log groups to be reused faster and reduces the likelihood of a database hang due to lack of available redo log groups.
Automatic archiving is now enabled by default when a database is put into archivelog mode.
Log transport services now use authenticated network sessions to transfer redo data. These sessions are authenticated using the
SYS user password contained in the password file. All databases in the Data Guard configuration must use a password file, and the
SYS password contained in this password file must be identical on all systems. This authentication can be performed even if Oracle Advanced Security is not installed, and provides some level of security when shipping redo.
The following list summarizes the new features that are specific to physical standby databases in Oracle Database 10g:
OPEN statements have new default behaviors that simplify their use with a physical standby database:
STARTUPcommand will now start, mount and open a physical standby database in read-only mode in a single step.
STANDBY DATABASEkeywords are now optional when using the
ALTER DATABASE MOUNTstatement to mount a physical standby database.
READ ONLYkeywords are now optional when using the
ALTER DATABASE OPENstatement to open a physical standby database.
Logical standby databases, first released with Oracle Database in Release 9.2, were enhanced in this release to allow rolling upgrades, improve the overall ease-of-use and manageability, expand the disaster recovery capabilities, and simplify the steps to create a logical standby database. The following list summarizes the new features for logical standby databases in Oracle Database 10g:
It is now possible to create a logical standby database without having to shut down or quiesce the primary database. This is achieved by using an online backup of the primary database and creating a logical standby control file.
In a future patchset release of Oracle Database 10g, it will be possible to do a rolling upgrade using logical standby databases. The foundation for rolling upgrades is now implemented into the SQL Apply technology so that the primary database incurs minimal downtime when you upgrade Oracle Database software on each database in the Data Guard configuration. For example, using SQL Apply and logical standby databases, you will be able to upgrade the Oracle Database software from patchset release 10.1.0.n to the next database 10.1.0.(n+1) patchset release.
Section 9.2 and the ReadMe file for the applicable Oracle Database 10g patchset release
With the introduction of support for standby redo log files, it is now possible to have a logical standby database be part of a Data Guard configuration running in maximum protection mode.