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.
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 redo 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 a Data Guard configuration.
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.
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.
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
Redo transport services
Log apply services
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.
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 and disables the old primary database.
See also fast-start failover and manual 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.
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.
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.
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 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.
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.
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 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.
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.
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.