Release 1 (9.0.1)
Part Number A88808-01
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle9i Data Guard Concepts and Administration Release 1 (9.0.1) Part Number A88808-01 |
|
This section describes new features of Oracle9i Data Guard and provides pointers to additional information. New feature information from Oracle8i releases is retained to help those users migrating to the current release.
The following sections describe the new features in Data Guard:
The features and enhancements described in this section were added to Data Guard in Oracle9i.
Oracle8i Standby Database has been renamed to Oracle9i Data Guard.
The broker is a new management framework that simplifies the configuration and control of a Data Guard configuration, and adds the ability to monitor the configuration.
The broker provides two new interfaces:
Oracle9i Data Guard Manager is a graphical user interface that provides easy configuration of a two-site Data Guard environment, the most typical Data Guard configuration.
The Data Guard command-line interface allows you to control and monitor a Data Guard configuration directly from the command-line prompt or from within scripts.
With the no-data-loss feature, the primary database will not acknowledge primary database modifications until they have been confirmed as being available on at least one standby database. Data is protected when primary database modifications occur while there is connectivity to the standby database. Data is unprotected when primary database modifications occur while connectivity to the standby database is not available.
The database administrator (DBA) can place the database into one of the following modes:
ALTER DATABASE statement to support the no-data-loss feature is:
Data divergence occurs when the primary database is modified, but the modifications are not available to be applied to a corresponding standby database. Subsequent failover of the primary database to the standby database would result in the loss of previously committed transactions.
Note that no data divergence is different from no data loss.
Data divergence is prohibited through the concept of protected data. In this sense, the primary database's data is protected by the existence of one or more synchronized standby databases. The failure of the last standby database causes the primary database instance to shut down to avoid data divergence.
Data integration is responsible for reapplying diverged (unprotected) data to the standby databases.
The new database switchover feature provides the database administrator (DBA) with the ability to switch the role of the primary database to one of the available standby databases. The chosen standby database becomes the primary database. The original primary database then becomes a standby database. There is no need to reinstantiate any of the databases in the switchover operation. There is no data divergence between the original and the new primary database after the successful completion of the database switchover.
Archive gaps are detected and transmitted automatically. This feature is built into log transport services and log apply services. The log transport services archive gap detection is always enabled in Oracle9i on the primary database. To enable the log apply services archive gap detection on the standby database, the DBA must define the values of two new initialization parameters: FAL_CLIENT and FAL_SERVER. Oracle Corporation recommends that you always set the log apply services archive gap detection. The log transport services archive gap detection is a best-attempt-effort and does not guarantee complete archive gap detection in some cases. The log apply services archive gap detection does guarantee complete archive gap detection and transmittal for the managed recovery process.
You can add new datafiles to the primary database without having to manually add the corresponding datafile to the standby databases. The new datafile is created and added to the standby databases if the DBA has set up the STANDBY_FILE_MANAGEMENT and DB_FILE_NAME_CONVERT initialization parameters.
You can now create a background process to perform managed recovery. This frees the foreground terminal session that you used to execute the managed recovery statement.
You can execute parallel recovery using the SQL RECOVER MANAGED STANDBY DATABASE statement. This allows faster recovery on your standby databases.
You can specify up to 10 archive destinations in Oracle9i. Prior versions allowed only up to 5 archive destinations.
LOG_ARCHIVE_DEST_n
The DBA can incrementally modify individual attributes of the LOG_ARCHIVE_DEST_n initialization parameters, where n is a value from 1 to 10.
You can control where the standby database stores the redo data received from the primary site. This data can be stored on the standby site using either standby redo logs or archived redo logs.
The ARCn process is used on standby databases to archive standby redo logs. It uses the LOG_ARCHIVE_DEST_1 initialization parameter and is limited to local archival operations.
In prior releases, the current redo log had to be full before you could archive it to the standby site. In Oracle9i, it is possible to:
The following control options have been added to this release:
DELAY
Specifies an absolute apply delay interval to the managed recovery operation. The managed recovery operation waits the specified number of minutes before applying the archived redo logs.
DISCONNECT
Starts managed recovery in background mode.
EXPIRE
Specifies the number of minutes after which the managed recovery operation automatically terminates, relative to the current time. The managed recovery operation terminates at the end of the current archived redo log that is being processed.
FINISH
Completes managed recovery in preparation for a failover from the primary database to the standby database.
NEXT
Directs the managed recovery operation to apply a specified number of archived redo logs as soon as possible after the log transport services have archived them.
NODELAY
Directs the managed recovery operation to apply the archived redo logs as soon as possible after log transport services have archived them.
Oracle9i provides the ability to perform true database archival from a primary database to a standby database when both databases reside on a Real Application Cluster. This allows you to separate the log transport services processing from the log apply services processing on the standby database, thereby improving overall primary and standby database performance.
Oracle9i introduces the archive log repository, which is a standalone standby control file. This type of destination allows off-site archival of redo log files.
The DBA can now determine the following by joining the V$ARCHIVED_LOG and V$ARCHIVE_DEST fixed views:
The following initialization parameters have been added to this release for each Oracle instance:
LOG_ARCHIVE_DEST_n include:
LOG_ARCHIVE_DEST_STATE_n initialization parameters
LOG_ARCHIVE_TRACE initialization parameter
ALTER DATABASE statement:
ACTIVATE [PHYSICAL] STANDBY DATABASE
[SKIP [STANDBY LOGFILE]]
ADD [STANDBY] LOGFILE TO [THREAD integer]
[GROUP integer] filespec
ADD [STANDBY] LOGFILE MEMBER 'filename' [REUSE] TO 'logfile-descriptor'
COMMIT TO SWITCHOVER TO [PHYSICAL]
{PRIMARY | STANDBY} [[NO]WAIT]
REGISTER [PHYSICAL] LOGFILE filespec
SET STANDBY DATABASE {PROTECTED | UNPROTECTED}
RECOVER MANAGED STANDBY DATABASE statement
The features and enhancements described in this section were added to the standby database in Oracle8i.
The read-only mode option can be used to make a standby database available for queries and reporting, even while redo logs are being archived from the primary database site.
You can use the Recovery Manager utility (RMAN) to back up the primary database using the standby database.
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|