Glossary

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

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

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

See also Data Guard configuration.

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

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.

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.

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

• Number of standby databases associated with a primary database

• Number of host systems used by the databases

• Directory structures of the machines used by the databases

• Network configuration

• Log transport services

• Log apply services

The Data Guard environment can be managed manually by a DBA, automatically using the Data Guard GUI or the Data Guard CLI, or a combination of all of these.

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 changes a standby database into the role of a primary database.

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.

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

See also default state.

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.

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.

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.

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.

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.

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.