Skip Headers
Oracle® Data Guard Broker
10g Release 2 (10.2)

Part Number B14230-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

Glossary

apply instance

In an Oracle Real Application Clusters (RAC) databases environment, the apply instance is the one instance applying archived redo log files to a standby database.

broker

A distributed management framework that automates and simplifies most of the complex operations required to create, control, and monitor a Data Guard configuration.

broker configuration

A logical grouping of the primary and standby databases (including redo transport services and log apply services) of a Data Guard configuration.

See also Data Guard configuration.

configuration object

A named collection of database objects. It is an abstraction of a Data Guard configuration.

database guard

The database guard controls whether or not modifications can be made to the tables in a logical standby database. You can override the database guard to allow changes to the logical standby database by executing the ALTER SESSION [ENABLE | DISABLE] GUARD statement.

database object

A named object that corresponds to a primary or standby database in a Data Guard configuration. The broker uses this object to manage and control the state of a single database and to associate properties with the database.

Data Guard command-line interface

The Data Guard command-line interface (DGMGRL) enables you to control and monitor a Data Guard configuration from the DGMGRL prompt or within scripts.

Data Guard configuration

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).

See also broker configuration.

Data Guard environment

The physical configuration of the primary and standby databases. The environment depends on many factors, including the:

The Data Guard environment can be managed manually by a DBA, automatically using Enterprise Manager or the Data Guard command-line interface (DGMGRL) or a combination of all of these.

default state

The initial runtime state in which the database object will run when you enable broker management of the configuration. The actual default state can vary depending on the role (primary or standby) in which the database is running.

See also intended state.

failover

Failover changes a standby database into the role of a primary database and disables the old primary database.

See also fast-start failover and manual failover.

fast-start failover

Enables a failover automatically when the primary database becomes unavailable. When fast-start failover is enabled, the broker determines if a failover is necessary and automatically, quickly, and reliably fails over to a designated, synchronized standby without requiring that you perform any manual steps to invoke the failover and with no loss of data.

See also manual failover.

instance

A named object; a database object is a collection of one or more named instances. The broker uses this object to manage and control the state of the database with which the instance is associated, and to associate instance-specific properties with this instance of the database.

intended state

The runtime state of a database object while it is enabled for management by the broker.

See also default state.

lights out computing

Refers to computing equipment or software whose operations are automated, requiring little to no intervention by human administrators.

The term "lights out" originated from when computing centers were located in one room and contained a number of servers that were kept under lock and key and in the dark. Under normal operation, the room was not not entered by human administrators, and all operations in the room were automated.

logical standby database

A logical standby database takes standard Oracle archived redo log files, transforms them back into SQL transactions, and then applies them to an open standby database. Although changes can be applied concurrently with end-user access, the tables being maintained through regenerated SQL transactions allow read-only access to users of the logical standby database. Because the database is open to allow application of reconstructed SQL transactions, it is physically different from the primary database. The database tables can have different indexes and physical characteristics from their primary database peers, but the tables must maintain logical consistency from an application access perspective, to fulfill their role as a standby data source.

manual failover

A failover that is initiated by the DBA who first determines a failover is necessary and then invokes one by clicking FAILOVER in Enterprise Manager or by issuing the DGMGRL FAILOVER command. The word manual is used to contrast this type of failover with a fast-start failover.

See also fast-start failover.

observer

A DGMGRL client that continuously monitors the primary and target standby databases, evaluates whether failover is necessary, and initiates a fast-start failover when conditions warrant.

physical standby database

A physical standby database is physically identical to the primary database. While the primary database is open and active, a physical standby database is either performing recovery (by applying online redo log files), or open for reporting access. A physical standby database can be queried (read-only mode) when not performing recovery while the primary database continues to archive redo logs.

primary database

A production database from which one or more standby databases is created and maintained. Every standby database is associated with one and only one primary database. A single primary database can, however, support multiple standby databases. The Data Guard broker monitor (DMON) maintains the master copy of the binary configuration file with the primary database, ensuring that each standby database's copy of the file is kept up to date as changes are made.

The broker refers to this database using the value in the DB_UNIQUE_NAME initialization parameter which is defined to be globally unique.

profiles

The description of a database object including its current state (on or off), properties, and current status (for example, its health). This description is maintained persistently by the broker in its binary configuration file.

read-only mode

A physical standby database mode that is initiated using the following SQL statement:

ALTER DATABASE OPEN READ ONLY;

The read-only mode enables you to query a physical standby database, but does not allow you to make changes to it. While in this mode, online redo log files are archived but are not applied until the physical standby database reenters Redo Apply mode.

Redo Apply

A physical standby database is kept synchronized with the primary database through Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database.

SQL Apply

A logical standby database is kept synchronized with the primary database through SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executes the SQL statements on the standby database.

standby database

A copy of a primary database created using a backup of your primary database. Standby databases are kept synchronized with the primary database by applying archived redo log files over time from the primary database to each standby database. The standby database can take over processing from the primary database, providing nearly continuous database availability. A standby database has its own server parameter file, control file, and datafiles. It also has a copy of the broker's configuration file, kept up to date at the direction of the DMON process running in the primary database instance.

The broker refers to a standby database by its globally unique name that is stored in its DB_UNIQUE_NAME initialization parameter.

See also logical standby database and physical standby database.