| Oracle Data Guard Concepts and Administration Release 2 (9.2) Part Number A96653-02 |
|
|
View PDF |
| Oracle Data Guard Concepts and Administration Release 2 (9.2) Part Number A96653-02 |
|
|
View PDF |
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.
See also ARCHIVELOG mode, online redo log, and 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 LOG_ARCHIVE_START to TRUE.
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.
See also archived redo log, NOARCHIVELOG mode, and redo log
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%.
See also downtime and switchover
A backup of the control file. Make the backup by:
backup or copy command. Never create a backup control file by using operating system commands.ALTER DATABASE BACKUP CONTROLFILE TO 'filename'.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.
See also control file and current control file
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 ALLOCATE or CONFIGURE command.
See also backup set and Recovery Manager (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:
See also backup piece and Recovery Manager (RMAN)
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.
See also destination dependency, destinations, and 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.
See also backup control file and current control file
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.
See also backup control file and control file
The online redo log in which the LGWR background process is currently logging redo records. Those logs to which LGWR is not writing are called inactive.
When LGWR gets to the end of the log, it performs a log switch and begins writing to a new log. If you run the database in ARCHIVELOG mode, then the ARCn process or processes copy the redo data into an archived redo log.
See also online redo log and 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.
See also primary database and standby database
Data loss occurs when you fail over to a standby database that has not received all redo data from the primary database.
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.
See also child destination, destinations, and parent 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.
See also child destination, destination dependency, and parent destination
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.
See also availability and switchover
An irreversible role transition in which a standby database transitions to the primary role, and the old primary database is rendered unable to participate in the configuration. Depending on the protection mode under which the old primary database was operating before the failover, there might be no or some data loss during a failover. A failover is typically used only when a primary database becomes incapacitated (for example, due to a system or software failure), and there is no possibility of performing a switchover or of successfully repairing the primary database within a reasonable amount of time.
See also role transition and switchover
See fetch archive log (FAL) client
See fetch archive log (FAL) server
See fetch archive log (FAL) client and fetch archive log (FAL) server
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
Ensures supplemental logging is set up correctly by performing log switches and then invoking the DBMS_LOGMNR_D.BUILD procedure.
See also supplemental logging
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 applying archived redo logs on the standby database to maintain transactional synchronization with the primary database.
See also log transport services, role management services, and 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 data. 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.
See also log apply services, no data loss, and role management services
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.
See full supplemental logging and supplemental logging
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.
See also physical standby database and standby database
The LSP applies archived redo log information to the logical standby database.
An environment in which the primary database automatically archives redo logs to the standby location, initiated by entering the following SQL statement:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
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.
See standby database environment
An environment in which the primary database does not automatically archive redo logs to the standby location. In this environment, you must manually transfer archived logs to the standby location and manually apply them by issuing the following SQL statement:
ALTER DATABASE RECOVER STANDBY DATABASE;
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.
See also no data loss, log transport services, maximum performance mode, and maximum protection mode
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, log transport services, maximum availability mode, and maximum protection mode
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. This mode is not supported on logical standby databases because standby redo logs are required for this mode.
See also no data loss, log transport services, maximum availability mode, and maximum performance mode
See managed recovery process (MRP)
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.
See also log transport services, maximum availability mode, and maximum protection mode
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
See site
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 logs. 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.
See also archived redo log, current online redo log, redo log, and standby redo log
A backup of one or more datafiles taken while a database is open. This is also known as a hot backup.
A log transport services archiving destination that has a child destination associated with it.
See also child destination, destination dependency, and destinations
A standby database that is physically identical to the primary database because recovery applies changes block-for-block using the physical row ID.
See also logical standby database and standby database
See availability, downtime, and switchover
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 physical standby database mode initiated by issuing the following SQL statement:
ALTER DATABASE OPEN READ ONLY;
This mode allows you to query the physical 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, restoration, 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.
See also recovery catalog database and Recovery Manager (RMAN)
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.
See also cross-instance archival environment and receiving instance
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 control file of the database 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.
See also backup piece, backup set, and recovery catalog
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.
See also archived redo log, ARCHIVELOG mode, current online redo log, log switch, online redo log, and standby redo log
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 failover if the primary database is unavailable due to an unplanned shutdown.
See also log apply services and log transport services
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).
See also failover and switchover
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 a logical standby database by transforming transaction information into SQL statements and then executing 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.
See also logical standby database, physical standby database, and primary database
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 redo logs even if the standby database is not in managed recovery mode.
The standby redo log is an optional set of logs 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 reversible role transition between the primary database and one of its standby databases. The primary database and standby database involved in the switchover operation exchange roles with no loss of application data and no need to restart or re-create any of the other standby databases in the configuration. You cannot use a switchover operation to perform a rolling upgrade of Oracle software. However, it might be possible to use a switchover operation to perform a hardware-based rolling upgrade.
See also availability, downtime, failover, and role transition
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
See transparent application failover (TAF)
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.
See also tablespace and tempfile
The ability of client applications to automatically reconnect to a database and resume work after a failover occurs.
|
 Copyright © 1998, 2002 Oracle Corporation. All Rights Reserved. |
|