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 LOGGING
RECOVER 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
filespec
SET 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
]
filespec
ADD [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
]
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}
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:
NODELAY
CANCEL [IMMEDIATE] [NOWAIT]
[DISCONNECT [FROM SESSION]]
[FINISH [NOWAIT]]
[PARALLEL [
integer
]]
NEXT
EXPIRE
DELAY
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:
AFFIRM
ALTERNATE
ARCHIVER
ASYNC_BLOCKS
DELAY_MINS
DEPENDENCY
FAILURE_COUNT
LOG_SEQUENCE
MANIFEST
(This column name was new in Oracle9i release 1; it was changed to REGISTER
in Oracle9i release 2.)MAX_FAILURE
MOUNTID
PROCESS
QUOTA_SIZE
QUOTA_USED
REGISTER
(This column name was new in Oracle9i release 1; it was changed to REMOTE_TEMPLATE
in Oracle9i release 2.)SCHEDULE
TRANSMIT_MODE
TYPE
ALTERNATE
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_COUNT
STANDBY_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. |
|