Release 2 (9.2)
Part Number A96653-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Data Guard Concepts and Administration Release 2 (9.2) Part Number A96653-01 |
|
This section describes the new Data Guard features in Oracle9i release 2 (9.2) and provides pointers to additional information. New features information from previous releases is also retained to help those users upgrading 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 release 2 (9.2).
Until now, there has been only the physical standby database implementation, in which the standby database can be in either recovery mode or in read-only mode. A physical standby database is physically equivalent to the primary database, and, while the database is applying logs it cannot be opened for reporting and vice versa. A logical standby database has the same logical schema as the primary database but may have different physical objects, such as additional indexes. With logical standby databases, you can have the database available for reporting and applying the logs to the standby log at the same time.
The database administrator (DBA) can place the database into one of the following modes:
These modes replace the guaranteed, instant, rapid, and delayed modes of data protection available in Oracle9i release 1 (9.0.1).
A cascading standby is a standby database that receives its redo information from another standby database and not from the original primary database. A physical or logical standby database can be set up to send the incoming redo information to other remote destinations in the same manner as the primary database, with up to one level of redirection.
The broker now supports:
LOG_ARCHIVE_DEST_n initialization parameter include:
[NO]TEMPLATE
Defines a directory specification and format for archived redo logs at the standby destination.
[NO]NET_TIMEOUT
Specifies the number of seconds the log writer process will wait for status from the network server of a network operation issued by the log writer process.
PARALLEL qualifier to the SYNC attribute
Indicates whether I/O operations to multiple destinations are done in parallel or in series.
ALTER DATABASE statement includes:
ACTIVATE [PHYSICAL | LOGICAL] STANDBY DATABASE [SKIP [STANDBY LOGFILE]]COMMIT TO SWITCHOVER TO {PHYSICAL | LOGICAL} {PRIMARY | STANDBY} [[WITH | WITHOUT] SESSION SHUTDOWN [WAIT | NOWAIT]][NO]FORCE LOGGINGRECOVER MANAGED STANDBY DATABASE [FINISH [SKIP [STANDBY LOGFILE] [WAIT | NOWAIT]]RECOVER MANAGED STANDBY DATABASE [THROUGH {ALL | LAST | NEXT} SWITCHOVER]RECOVER MANAGED STANDBY DATABASE [THROUGH ALL ARCHIVELOG | [ THREAD n ] SEQUENCE n ]REGISTER [OR REPLACE] [PHYSICAL | LOGICAL] LOGFILE filespecSET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}START LOGICAL STANDBY APPLY{STOP | ABORT} LOGICAL STANDBY APPLY
LOG_ARCHIVE_TRACE parameter:
The features and enhancements described in this section were added to Data Guard in Oracle9i release 1 (9.0.1).
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.
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:
|
Note: In Oracle9i release 2, these protection modes have been replaced by the maximum protection, maximum availability, and maximum performance modes. See Oracle9i Release 2 (9.2) New Features in Data Guard. |
ALTER DATABASE statement to support the no-data-loss feature:
SET STANDBY DATABASE {PROTECTED | UNPROTECTED}ADD [STANDBY] LOGFILE TO [THREAD integer]
[GROUP integer] filespecADD [STANDBY] LOGFILE MEMBER 'filename' [REUSE]
TO GROUP integer
|
Note: In Oracle9i release 2, this syntax was further revised. See Oracle9i Release 2 (9.2) New Features in Data Guard. |
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 and 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 RECOVER MANAGED STANDBY DATABASE clause of the SQL ALTER 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 initialization parameter
The DBA can incrementally modify individual attributes of the LOG_ARCHIVE_DEST_n initialization parameter, 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_n initialization parameter (where n is a value from 1 to 10). The archiver process on the standby database can archive locally and remotely to other standby databases.
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 archiving from a primary database to a standby database when both databases reside in a Real Application Clusters environment. 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 database. An archive log repository is created by using the standby control file, starting the instance, and mounting it. This type of destination allows off-site archiving 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_STATE_n initialization parameter:
LOG_ARCHIVE_TRACE initialization parameter:
ALTER DATABASE statement:
ACTIVATE [PHYSICAL] STANDBY DATABASE
[SKIP [STANDBY LOGFILE]]ADD [STANDBY] LOGFILE TO [THREAD integer]
[GROUP integer] filespecADD [STANDBY] LOGFILE MEMBER 'filename' [REUSE] TO 'logfile-descriptor'COMMIT TO SWITCHOVER TO [PHYSICAL]
{PRIMARY | STANDBY} [[NO]WAIT]REGISTER [PHYSICAL] LOGFILE filespecSET STANDBY DATABASE {PROTECTED | UNPROTECTED}
|
Note: In Oracle9i release 2, this syntax was further revised. See Oracle9i Release 2 (9.2) New Features in Data Guard. |
RECOVER MANAGED STANDBY DATABASE clause:
NODELAYCANCEL [IMMEDIATE] [NOWAIT][DISCONNECT [FROM SESSION]][FINISH [NOWAIT]][PARALLEL [integer]]NEXTEXPIREDELAY
|
Note: In Oracle9i release 2, this syntax was further revised. See Oracle9i Release 2 (9.2) New Features in Data Guard. |
V$ARCHIVE_DEST view:
AFFIRMALTERNATEARCHIVERASYNC_BLOCKSDELAY_MINSDEPENDENCYFAILURE_COUNTLOG_SEQUENCEMANIFEST (This column name was new in Oracle9i release 1; it was changed to REGISTER in Oracle9i release 2.)MAX_FAILUREMOUNTIDPROCESSQUOTA_SIZEQUOTA_USEDREGISTER (This column name was new in Oracle9i release 1; it was changed to REMOTE_TEMPLATE in Oracle9i release 2.)SCHEDULETRANSMIT_MODETYPEALTERNATE and FULL, have been added to the STATUS column.V$ARCHIVED_LOG view:
V$LOG view:
V$LOGFILE view:
V$DATABASE view:
V$ARCHIVE_DEST_STATUS view:
STANDBY_LOGFILE_COUNTSTANDBY_LOGFILE_ACTIVE
|
Note: In Oracle9i release 2, new values were added and existing columns renamed in the |
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.
|
 Copyright © 1999, 2002 Oracle Corporation. All Rights Reserved. |
|