The features and enhancements described in this section were added to Data Guard in Oracle9i.
■ Oracle9i Data Guard
Oracle8i Standby Database has been renamed to Oracle9i Data Guard. ■ Oracle9i Data Guard Broker
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 (GUI)
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.
– Data Guard command-line interface
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.
■ No Data Loss
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:
– Guaranteed protection – Instant protection – Rapid protection
– Delayed protection
■ New syntax added to the ALTER DATABASE statement to support the
no-data-loss feature is:
– SET STANDBY DATABASE {PROTECTED | UNPROTECTED}
– ADD [STANDBY] LOGFILE TO [THREAD integer]
[GROUP integer] filespec
– ADD [STANDBY] LOGFILE MEMBER ’filename’ [REUSE]
TO GROUP integer
■ No data divergence
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.
■ Database switchover
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.
See Also: Section 3.6
See Also: Chapter 9, "SQL Statements"
■ Archive gaps are automatically detected and transmitted
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.
■ Adding new datafiles
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.
■ Background managed recovery mode
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.
■ Parallel recovery
You can execute parallel recovery using the SQL RECOVER MANAGED STANDBY DATABASE statement. This allows faster recovery on your standby databases.
■ More archive destinations
See Also: Chapter 5, "Managing the Data Guard Environment"
See Also: Section 4.5
See Also: Section 4.6 and Section 5.8.1
See Also: Section 4.3.2
You can specify up to 10 archive destinations in Oracle9i. Prior versions allowed only up to 5 archive destinations.
■ Incremental change to 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.
■ Standby redo logs are introduced
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.
■ Archiver process (ARCn) available on standby databases
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.
■ Changes to archiving online redo logs
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:
– Archive the current redo log. In previous releases, you needed to perform a log switch first.
– Archive an online redo log based on the SCN (system change number) value when the database is mounted, but not open.
– Archive an online redo log when a backup control file is being used. In previous releases, a current control file was required.
See Also: Section 3.3.1
See Also: Section 3.3.1
See Also: Section 3.6.3.4
See Also: Section 3.3.1
■ New control options
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.
■ Standby Real Application Clusters support
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.
■ Archive log repository
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.
■ Relationship defined between an archived redo log and an archive
destination
The DBA can now determine the following by joining the V$ARCHIVED_LOG and V$ARCHIVE_DEST fixed views:
– Archive destination information for an archived redo log – All archived redo logs generated from a destination
■ New initialization parameters
The following initialization parameters have been added to this release for each Oracle instance: – REMOTE_ARCHIVE_ENABLE – FAL_CLIENT – FAL_SERVER – STANDBY_FILE_MANAGEMENT – ARCHIVE_LAG_TARGET
See Also: Appendix D, "Standby Database Real Application Cluster Support"
See Also: Section 1.4 and Section 3.2.2
■ New attributes for LOG_ARCHIVE_DEST_n include: – ARCH | LGWR – [NO]AFFIRM – [NO]ALTERNATE – [NO]DELAY – [NO]DEPENDENCY – [NO]MAX_FAILURE – [NO]QUOTA_SIZE – [NO]QUOTA_USED
– [NO]REGISTER | REGISTER [=registration location]
– NOREOPEN
– SYNC | ASYNC
■ New range of values and keyword have been added to the LOG_ARCHIVE_ DEST_STATE_n initialization parameters
– The variable n can be a value from 1 to 10 (versus 1 to 5 in Oracle8i). – The new keyword, ALTERNATE, has been added.
■ One to ten destinations (versus one to five in Oracle8i) must archive
successfully before the log writer process (LGWR) can overwrite the online redo logs
■ New tracing levels have been added to the LOG_ARCHIVE_TRACE
initialization parameter
See Also: Chapter 7, "Initialization Parameters"
See Also: Section 3.3.1 and Chapter 8, "LOG_ARCHIVE_DEST_n Parameters Attributes"
See Also: Section 3.3.1.2
– Tracing level of 128 allows you to track fetch archive log (FAL) server process activity.
– Tracing level 256 will be available in a future release.
– Tracing level 512 allows you to track asynchronous log writer activity.
■ New clauses have been added to the 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}
■ New keywords have been added to the RECOVER MANAGED STANDBY DATABASE statement
– NODELAY
– CANCEL [IMMEDIATE] [NOWAIT]
– [DISCONNECT [FROM SESSION]]
– [FINISH [NOWAIT]]
– [PARALLEL [integer]]
– NEXT
– EXPIRE
– DELAY
See Also: Section 4.9.5
■ New fixed views have been added:
– V$ARCHIVE_DEST_STATUS
– V$ARCHIVE_GAP
– V$MANAGED_STANDBY
– V$STANDBY_LOG
■ New columns have been added to existing fixed views:
– V$ARCHIVE_DEST view: * AFFIRM * ALTERNATE * ARCHIVER * ASYNC_BLOCKS * DELAY_MINS * DEPENDENCY * FAILURE_COUNT * LOG_SEQUENCE * MANIFEST * MAX_FAILURE * MOUNTID * PROCESS * QUOTA_SIZE * QUOTA_USED * REGISTER * SCHEDULE * TRANSMIT_MODE * TYPE
See Also: Chapter 9, "SQL Statements"
* New values, ALTERNATE and FULL, have been added to STATUS column – V$ARCHIVED_LOG view: * APPLIED * BACKUP_COUNT * COMPLETION_TIME * CREATOR * DELETED * DEST_ID * DICTIONARY_BEGIN * DICTIONARY_END * REGISTRAR * STANDBY_DEST * STATUS * END_OF_REDO * ARCHIVAL_THREAD# – V$LOG view:
* A new value, INVALIDATED, has been added to STATUS column
– V$LOGFILE view: * TYPE – V$DATABASE view: * ACTIVATION# * ARCHIVELOG_CHANGE# * DATABASE_ROLE * REMOTE_ARCHIVE * STANDBY_MODE * SWITCHOVER_STATUS – V$ARCHIVE_DEST_STATUS view:
* STANDBY_LOGFILE_COUNT
* STANDBY_LOGFILE_ACTIVE