|Oracle9i Data Guard Concepts and Administration
Release 2 (9.2)
Part Number A96653-01
A range of archived redo logs created whenever you are unable to apply the next archived redo log generated by the primary database to the standby database.
A copy of one of the filled members of an online redo log group made when the database is in ARCHIVELOG mode. As the LGWR process fills each online redo log with redo records, log transport services copy the log to one or more offline archive log destinations. This copy is the archived redo log, also known as the offline redo log.
The mode of the database in which log transport services archive filled online redo logs to disk. Specify the mode at database creation or by using the SQL
ALTER DATABASE ARCHIVELOG statement. You can enable automatic archiving either dynamically using the SQL
ALTER SYSTEM ARCHIVE LOG START statement or by setting the initialization parameter
Running your database in ARCHIVELOG mode has several advantages over NOARCHIVELOG mode. You can:
To protect your database that is in ARCHIVELOG mode in case of failure, back up your archived logs.
On the primary database location, the process (or a SQL session performing an archival operation) that creates a copy of the online redo logs, either locally or remotely, for standby databases. On the standby database location, the ARCn process archives the standby redo logs to be applied by the managed recovery process (MRP).
The operation in which the ARCn background process copies filled online redo logs to offline destinations. You must run the primary database in ARCHIVELOG mode to archive redo logs.
The measure of the ability of a system or resource to provide the desired service when required. Measured in terms of the percentage of time the device is accessible out of the total time it is needed. Businesses that require uninterrupted computing services have an availability goal of 100%, or 24x365. The sum of availability and downtime equals 100%.
A backup of the control file. Make the backup by:
copycommand. Never create a backup control file by using operating system commands.
ALTER DATABASE BACKUP CONTROLFILE TO
Typically, you restore backup control files when all copies of the current control file are damaged; sometimes you restore them before performing certain types of point-in-time recovery.
A physical file in a format specific to RMAN. The file belongs to only one backup set. A backup set usually contains only one backup piece. The only time RMAN creates more than one backup piece is when you limit the piece size using the
MAXPIECESIZE option of the RMAN
An RMAN-specific logical grouping of one or more physical files called backup pieces. The output of the RMAN
backup command is a backup set. Extract the files in a backup set by using the RMAN
restore command. You can multiplex files into a backup set, that is, intermingle blocks from input files into a single backup set.
There are two types of backup sets:
A distributed management framework that automates and simplifies most of the operations associated with the creation, control, and monitoring of a Data Guard configuration. The broker includes two user interfaces: Oracle Data Guard Manager (a graphical user interface) and the Data Guard command-line interface.
A standby database that receives its redo logs from another standby database, not from the original primary database.
A log transport services archiving destination that is configured to receive redo logs from the primary database and depends on the successful completion of archival operations for the parent destination.
A backup of one or more database files taken while the database is closed. Typically, a closed backup is also a whole database backup (a backup of the control file and all datafiles that belong to a database). If you closed the database cleanly, then all the files in the backup are consistent. If you shut down the database using a
SHUTDOWN ABORT statement or the instance terminated abnormally, then the backups are inconsistent.
See also consistent backup
See closed backup
A whole database backup (a backup of the control file and all datafiles that belong to a database) that you can open with the
RESETLOGS option without performing media recovery. In other words, you do not need to apply redo logs to datafiles in this backup for it to be consistent. All datafiles in a consistent backup must:
You can only make consistent backups after you have made a clean shutdown of the database. The database must not be opened until the backup has completed.
See also closed backup
A binary file associated with a database that maintains the physical structure and timestamps of all files in that database. The Oracle database server updates the control file continuously during database use and must have it available for writing whenever the database is mounted or open.
The environment in which each instance in a Real Application Clusters configuration directs its archived redo logs to a single instance of the cluster. This single instance is known as the recovery instance.
See also recovery instance
The control file on disk for a primary database; it is the most recently modified control file for the current incarnation of the database. For a control file to be considered current during recovery, it must not have been restored from backup.
The online redo log file in which the LGWR background process is currently logging redo records. Those files to which LGWR is not writing are called inactive.
When LGWR gets to the end of the file, it performs a log switch and begins writing to a new log file. If you run the database in ARCHIVELOG mode, then the ARCn process or processes copy the redo data into an archived redo log.
The management, monitoring, and automation software that works with a production database and one or more standby databases to protect your data against errors, failures, and corruptions that might otherwise destroy your database.
The loss of data. Data loss occurs when you fail over to a standby database whose corresponding primary database is in the data divergence state.
See also graceful database failover
A physical operating system file on disk that was created by the Oracle database server and contains data structures such as tables and indexes. A datafile can only belong to one database.
See also tablespace
Configuring log transport services so that archiving redo logs to a specified destination is dependent upon the success or failure of archiving redo logs to another destination.
Log transport services allow the primary database to be configured to archive redo logs to up to 10 local and remote locations called destinations.
The measure of the inability of a system or resource to provide the desired service when required. Measured in terms of the percentage or amount of time the device is not accessible out of the total time it is needed. The sum of availability and downtime equals 100%.
A period of time for performing routine maintenance tasks, such as hardware and software upgrades and value-added services is planned downtime. The computing system is not available for productive operations during such scheduled maintenance tasks.
An unplanned event resulting from system or software failure.
If standby redo logs are present on the standby database, the failover is graceful and can occur with no data loss or with minimal data loss. If standby redo logs are not present on the standby database, the failover is forced and may result in the loss of application data.
A background Oracle database server process. The initialization parameter for the FAL client is set on the standby database. The FAL client pulls archived redo logs from the primary location and initiates and requests the transfer of archived redo logs automatically when it detects an archive gap on the standby database.
See also fetch archive log (FAL) server
A background Oracle database server process that runs on the primary or other standby databases and services the fetch archive log (FAL) requests coming from the FAL client. For example, servicing a FAL request might include queuing requests (to send archived redo logs to one or more standby databases) to an Oracle database server that runs the FAL server. Multiple FAL servers can run on the same primary database at one time. A separate FAL server is created for each incoming FAL request. The initialization parameter for the FAL server is set on the standby database.
See also fetch archive log (FAL) client
Failover is an unplanned event resulting from system or software failure. If standby redo logs are not present, the failover is forced. A forced database failover changes one of the standby databases into the role of primary database, but may result in the loss of application data even when standby redo logs are configured on the standby database. You must reinstantiate the original primary database and all other standby databases after a forced database failover.
Ensures supplemental logging is set up correctly by performing log switches and then invoking the
See also supplemental logging
Failover is an unplanned event resulting from system or software failure. If standby redo logs are present, the failover is graceful. A graceful database failover changes one of the standby databases into the role of primary database, and automatically recovers some or all of the original primary data. Therefore, it is necessary to reinstantiate only the primary database. The other standby databases in the configuration do not need to be reinstantiated. A graceful database failover can occur with no data loss or with minimal data loss.
See open backup
An application that receives requests by clients and redirects them to the appropriate server.
The component of the Data Guard environment that is responsible for maintaining the physical standby database in either a managed recovery mode or an open read-only mode and for maintaining the logical standby database in SQL apply mode.
The point at which LGWR stops writing to the active redo log and switches to the next available redo log. LGWR switches when either the active log is filled with redo records or you force a switch manually.
If you run your database in ARCHIVELOG mode, log transport services archive the redo data in inactive logs into archived redo logs. When a log switch occurs and LGWR begins overwriting the old redo data, you are protected against data loss because the archived redo log contains the old data. If you run in NOARCHIVELOG mode, log transport services overwrite old redo data at a log switch without archiving it. Hence, you lose all old redo data.
See also redo log
The component of the Data Guard environment that is responsible for the automated transfer of primary database online redo logs. Log transport services provide for the management of archived redo log permissions, destinations, transmission, reception, and failure resolution. In a Data Guard environment, the log transport services component coordinates its activities with the log apply services component.
The background process that collects transaction redo and updates the online redo logs. The log writer process can also create local archived redo logs and transmit online redo logs to standby databases.
A standby database that is logically identical to the primary database and can be used to take over processing if the primary database is taken offline. A logical standby database is the logical equivalent of the primary database; they share the same schema definition.
The LSP applies archived redo log information to the logical standby database.
An environment in which the primary database automatically archives redo log files to the standby location, initiated by entering the following SQL statement:
When a standby database runs in managed recovery mode, it automatically applies redo logs received from the primary database.
The process that applies archived redo log information to the standby database.
An environment in which the primary database does not automatically archive redo log files to the standby location. In this environment, you must manually transfer archived log files to the standby location and manually apply them by issuing the following SQL statement:
This mode allows you to recover a standby database manually.
A log transport services data availability mode that can be set to ensure that redo logs are available at a standby database before the current database transaction is committed. Maximum availability does not protect against data divergence.
See also no data loss
A log transport services data availability mode that offers the lowest level of data protection. In this mode, the archiver process writes redo log data asynchronously to a standby database with as little effect as possible on the performance of the primary database. In a failover operation, it is possible to lose data from one or more logs that have not yet been transmitted. This is the default protection mode.
See also no data loss
A log transport services data availability mode that can be set to ensure that redo logs are available at a standby database before primary database processing can continue. Maximum protection mode protects against data divergence. This is also known as protected mode. This mode is not supported on logical standby databases because standby redo logs are required for this mode.
A log transport services option that can be configured to ensure that the primary and standby databases are always synchronized by prohibiting access to the primary database if connectivity to at least one standby database becomes unavailable.
A log transport services option that can be configured to ensure that data modifications made to the primary database are not acknowledged until those data modifications are also available on (but not necessarily applied to) the standby database.
The mode of the database in which log transport services do not require filled online redo logs to be archived to disk. Specify the mode at database creation or change it by using the SQL
ALTER DATABASE statement. Oracle Corporation does not recommend running in NOARCHIVELOG mode because it severely limits the possibilities for recovery of lost data.
See also ARCHIVELOG mode
A set of two or more files that records all changes made to datafiles and control files. Whenever a change is made to the database, the Oracle database server generates a redo record in the redo buffer. The LGWR process flushes the contents of the redo buffer into the online redo log.
Every database must contain at least two online redo log files. If you are multiplexing your online redo log, LGWR concurrently writes the same redo data to multiple files. The individual files are called members of an online redo log group.
A backup of one or more datafiles taken while a database is open. This is also known as hot backup.
A log transport services archiving destination that has a child destination associated with it.
A standby database that is physically identical to the primary database because recovery applies changes block-for-block using the physical row ID.
In a Data Guard configuration, a production database is referred to as a primary database. A primary database is used to create a standby database. Every standby database is associated with one and only one primary database. A single primary database can, however, support multiple standby databases.
See also standby database
A database opened with the SQL statement
ALTER DATABASE OPEN READ ONLY. As their name suggests, read-only databases are for queries only and cannot be modified. A standby database can be run in read-only mode, which means that it can be queried while still serving as an up-to-date emergency replacement for the primary database.
See also read-only mode
A standby database mode initiated by issuing the following SQL statement:
This mode allows you to query the standby database, but not to make changes to it.
See also read-only database
When you use a standby database in a Real Application Clusters configuration, any instance can receive archived logs from the primary database; this is the receiving instance.
See also recovery instance
A set of tables and views used by Recovery Manager (RMAN) to store information about Oracle databases. RMAN uses this data to manage the backup, restore, and recovery of Oracle databases. If you choose not to use a recovery catalog, RMAN uses the target database control file. You should not store the recovery catalog in your target database.
An Oracle database that contains a recovery catalog schema.
See also recovery catalog
The node where managed recovery is performed. Within a Real Application Clusters configuration, each primary instance directs its archived redo logs to this node of the standby cluster.
A utility that backs up, restores, and recovers Oracle databases. You can use it with or without the central information repository called a recovery catalog. If you do not use a recovery catalog, RMAN uses the database's control file to store information necessary for backup and recovery operations. You can use RMAN in conjunction with a media manager, which allows you to back up files to tertiary storage.
A file containing redo records. There are three types of redo logs: online redo logs, standby redo logs, and archived redo logs.
The online redo log is a set of two or more files that records all changes made to datafiles and control files. The LGWR process records the redo records in the log. The current online redo log is the one to which LGWR is currently writing.
The standby redo log is an optional location where the standby database can store the redo data received from the primary database. This redo data can be stored on the standby location using either standby redo logs or archived redo logs.
The archived redo log, also known as the offline redo log, is a copy of the online redo log that has been copied to an offline destination. If the database is in ARCHIVELOG mode, the ARCn process or processes copy each online redo log to one or more archive log destinations after it is filled.
The ability of a computing system or software to operate without failing.
The remote file server process on the standby location receives archived redo logs from the primary database.
The component of the Data Guard environment that is responsible for the changing of database roles. Database role transitions include switchover and switchback, as well as failover if the primary database is unavailable due to an unplanned shutdown.
A database can be in one of two mutually exclusive roles: primary or standby. You can change these roles dynamically as a planned transition (switchover) or you can change these roles as a result of an unplanned failure (failover).
A software installation technique that allows a clustered system to continue to provide service while the software is being upgraded to the next release. This process is called a rolling upgrade because each database or system in the cluster is upgraded and rebooted in turn, until all databases or systems have been upgraded.
In a Data Guard configuration, this term is sometimes used to refer to the local or geographically remote location of a primary or standby database.
In a Data Guard broker configuration, a site is a managed unit of failover.
The mode in which log apply services automatically apply archived redo log information to the logical standby database by transforming transaction information into SQL statements (using LogMiner technology) and applying the SQL statement to the logical standby database.
See also log apply services
An identical copy of a primary database that you can use for disaster protection. You can update your standby database with archived redo logs from the primary database to keep it current. Should a disaster destroy or compromise the primary database, you can fail over to the standby database and make it the new primary database. A standby database has its own initialization parameter file, control file, and datafiles.
The physical configuration of the primary and standby databases. The environment depends on many factors, including the:
A configuration in which a primary database automatically archives redo logs to a standby location is a managed standby environment. If the standby database is in managed recovery mode, it automatically applies the logs received from the primary database to the standby database. Note that in a managed standby environment, a primary database continues to transmit archived logs even if the standby database is not in managed recovery mode.
The standby redo log is an optional set of log files where the standby database can store the redo data received from the primary database. (Redo data can also be stored on the standby location using archived redo logs.) Standby redo logs are created using the
ADD STANDBY LOGFILE clause of the SQL
ALTER DATABASE statement. Additional log group members can be added later to provide another level of reliability against disk failure on the standby location. Standby redo logs are required if you are using the maximum protection mode. Standby redo logs are not supported for logical standby databases.
See also redo log
The ability to log additional information in the redo log stream to enable LogMiner to group and merge the redo streams related to a row change during log mining, and also to be able to identify the row using an identification key.
See also full supplemental logging
A switchover performed in reverse that results in the original primary database becoming a new primary database. Once you have performed a database switchover operation, you can switch back to your original Data Guard configuration.
See also switchover
The process of intentionally switching a database role from primary to standby, as well as from standby to primary, without resetting the online redo logs of the new primary database. This is a switchover operation, instead of a failover operation, because there is no loss of application data, and there is no need to reinstantiate the standby databases, including other standby databases not involved in the switchover operation. You cannot use a switchover operation to perform a rolling upgrade of Oracle software. However, it may be possible to use a switchover operation to perform a hardware-based rolling upgrade.
A stamp that defines a committed version of a database at a point in time. The Oracle database server assigns every committed transaction a unique SCN.
One or more logical storage units into which a database is divided. Each tablespace has one or more physical datafiles exclusively associated with it.
See also datafile
In RMAN, the database that you are backing up or restoring.
A file that belongs to a temporary tablespace, and is created with the
TEMPFILE option. Temporary tablespaces cannot contain permanent database objects such as tables, and are typically used for sorting. Because tempfiles cannot contain permanent objects, RMAN does not back them up.
See also temporary tablespace
Tablespace of temporary tables created during the processing of a SQL statement. This allows you to add tempfile entries in read-only mode for the purpose of making queries. You can then perform on-disk sorting operations in a read-only database without affecting dictionary files or generating redo entries.
The ability of client applications to automatically reconnect to a database and resume work after a failover occurs.