Oracle9i Data Guard is the management, monitoring, and automation software that works with a production database and one or more standby databases to protect your data against failures, errors, and corruptions that might otherwise destroy your database. It protects critical data by automating the creation, management, and monitoring of the databases and other components in a Data Guard configuration. It automates the otherwise manual process of maintaining a transactionally consistent copy of an Oracle production database, called a standby database, that can be used if the production database is taken offline for routine maintenance or becomes damaged.

In a Data Guard configuration, a production database is referred to as a primary database. Using a backup copy of the primary database, you can create from one to nine physical and logical standby databases and incorporate them in a Data Guard configuration. Primary and standby databases can be running on a single node or in a Real Application Clusters environment. Every standby database is associated with only one primary database. However, a single primary database can support multiple physical standby databases, logical standby databases, or a mix of both in the same configuration:


* Physical standby databases

A physical standby database is physically identical to the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. The physical standby database is updated by performing recovery. It can either be recovering data or open for read-only reporting.

* Logical standby databases

A logical standby database is logically identical to the primary database. The logical standby database is updated using SQL statements. The tables in a logical standby database can be used simultaneously for recovery and for other tasks such as reporting, summations, and queries.

Oracle9i Data Guard maintains each standby database as a transactionally consistent copy of the primary database using standard Oracle online redo logs. As transactions add data or change information stored in the primary database, the changes are also written to the online redo logs. The redo logs associated with the primary database are archived to standby destinations by log transport services and applied to the standby database by log apply services.

* Log transport services control the automated transfer of archived redo logs from the primary database to one or more standby databases. Log transport services transmit redo logs to local and remote physical and logical standby databases. You can configure log transport services to balance data protection and availability against performance.
* Log apply services apply the archived redo logs differently for physical and logical standby databases. Archived redo logs are applied:
o To a physical standby database when it is performing recovery (for example, in managed rec...

Show full text: 5,383 characters