Release 1 (9.0.1)
Part Number A88808-01
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle9i Data Guard Concepts and Administration Release 1 (9.0.1) Part Number A88808-01 |
|
To issue a SQL ALTER DATABASE ACTIVATE STANDBY DATABASE statement. This statement starts a forced database failover operation.
See also failover and forced database failover
Setting this attribute on the LOG_ARCHIVE_DEST_n initialization parameter indicates that the archiver process (ARCn) will create archived redo logs on the primary database and also transmit redo logs for archival at specified destinations.
See also archiver process (ARCn)
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 copies 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 archives 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 site, 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 site, the ARCn process archives the standby redo logs to be applied by the managed recovery process (MRP).
See also ARCH
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 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 destinations, destination dependency, 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 or the instance terminated abnormally, then the backups are inconsistent.
See also consistent 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 time stamps 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 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 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.
See also online redo log and redo log
Data divergence occurs when data modifications occur on the primary database and when connectivity to the standby database is not available. Data divergence also occurs when you use the LGWR or ARCn process for asynchronous standby database archival operations.
See also data loss and no data divergence
A distributed computing system that prevents or minimizes losses due to unplanned events (for example, human errors, environmental disasters, or data corruption) as well as to planned downtime (such as for routine maintenance tasks).
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 data divergence and 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
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. In a failover operation, it is possible to lose data from one or more logs that have not yet been transmitted.
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 ten 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 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.
See also activate, forced database failover, graceful database failover, role transition, and switchover
A background Oracle database server process. The initialization parameter for the FAL client is set on the standby site. The FAL client pulls archived redo logs from the primary site and initiates and requests the transfer of archived redo logs automatically when it detects an archive gap on the standby database.
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 site.
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.
See also activate, failover, and graceful database failover
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. This is also known as terminal recovery. A graceful database failover can occur with no data loss or with minimal data loss.
See also data loss, failover, forced database failover, and 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. Guaranteed protection protects against data divergence. This is also known as protected mode.
See also no data divergence and no data loss
See open backup
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. Instant protection does not protect against data divergence.
See also data divergence, no data divergence, and no data loss
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 standby database in either a managed recovery mode or an open read-only mode. The managed recovery mode automatically maintains and applies archived redo logs to maintain transactional synchronization with the primary database, and allows transactionally consistent read-only access to the data. In a Data Guard environment, the log apply services component coordinates its activities with the log transport services component.
See also log transport services and role management services
The point at which LGWR stops writing to the active redo log file and switches to the next available redo log file. LGWR switches when either the active log file 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 log files 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 archival of the 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.
See also log apply services, no data divergence, 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 to standby databases.
An environment in which the primary database automatically archives redo log files to the standby site, 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 managed recovery process 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 log files to the standby site. In this environment, you must manually transfer archived log files to the standby site 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.
See managed recovery process (MRP)
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.
See also guaranteed protection, instant protection, and log transport services
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 graceful database failover, guaranteed protection, instant protection and log transport services
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 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.
See also archived redo log, current online redo log, and redo log
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.
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 standby database
See availability, downtime, and switchover
A database 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.
The location of the primary database. Note that the primary and standby sites can be on separate hosts or on the same host.
See also site
See guaranteed protection and no data divergence
A log transport services data availability mode that can be set to ensure that redo logs are written as quickly as possible to the standby database with as little effect as possible on the performance of the primary 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:
ALTER DATABASE OPEN READ ONLY;
This mode allows you to query the standby database, but not to make changes to it.
See also read-only database
When you use the standby database on a Real Application Cluster, 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.
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 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 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.
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 site. This redo data can be stored on the standby site 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 site 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.
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 site in the cluster is upgraded and rebooted in turn, until all sites have been upgraded. While each site is temporarily offline, the other sites take over the entire workload.
A managed unit of failover in a Data Guard configuration. A database is replicated across a set of sites, one replicant per site. Dependent applications are instantiated on a site. When a site holding a primary role fails, another site holding the standby role takes over the primary role responsibility and provides the desired service to users. Sites may be one of several types of nodes, which vary from one another in the degree of hardware complexity and software management.
See also primary site and standby site
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 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 physical standby 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 site 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 standby site continues to receive 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 site. (Redo data also can be stored on the standby site 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 site.
See also redo log
The location of the standby database. The standby site can be on the same host as the primary database or on a separate host.
See also site
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.
See also availability, downtime, failover, role transition, and switchback
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.
Tablespace of temporary tables created during the processing of an 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 graceful database failover
The ability of client applications to automatically reconnect to a database and resume work after a failover occurs.
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|