Disaster protection of Oracle9i Data guard

Oracle9i data Guard protects against the occurrence of a disaster by using a database called standby. It synchronizes the primary database database with the primary DB database by uploading and applying the redo logs to the standby database databases:

You can write the redo logs directly from the primary DB database to the standby database to complete disaster protection with no data loss at all. This will result in a certain performance penalty for the performance of the primary database.

The archived redo logs can be written asynchronously from primary database databases to standby database databases to minimize the loss of data in the primary database, with minimal performance loss.

If the redo log data arrives at the standby DB database and the fast tau Mei 絪 tandby database, the primary database database can be failover quickly when there is a problem with it. However, if you postpone the application of redo log data after a certain amount of time, you can avoid primary database errors from being quickly propagated to the standby database.

As shown in the following illustration, when the online redo logs are archived locally, they are also routed through Oracle Net to the standby database:

Database Data protection level

You can set up standby database databases to achieve different levels of database data protection in the following ways:

Guaranteed protection: It is stipulated that at least one standby database is valid when modifying the primary database. If the connection between the primary (Primary database) (Standby database) is interrupted, Oracle prevents data inconsistency between the primary and standby databases by disrupting the work of the main instance, guaranteeing no data loss. This pattern has a greater impact on database performance.

Instant Protection: It is stipulated that at least one standby database is valid when modifying the primary database. Unlike the guaranteed protection mode, when the connection between the primary and standby database is interrupted, data inconsistencies between the primary and standby databases are allowed, and when the connection is restored, data inconsistency is resolved. This pattern has a minor impact on the performance of the primary database.

Rapid Protection: Master database modifications are quickly applied to the standby database. Data loss can occur, but the impact on database performance is small.

Delayed protection: Master database modifications are applied to the standby database after a certain amount of time has been delayed. The Rapid protection and delayed protection modes allow the primary database to disagree with all standby databases even when the network connection is valid, and the amount of data lost is equivalent to the archive number of the primary database online redo log. This approach has little impact on database performance.

How to limit the amount of data lost

Under the Primary/standby configuration, all archived logs are sent to the standby node, which keeps the standby node's data updated. However, if the primary database is shut down unexpectedly, the logs online will be lost because they have not been archived and sent to the standby node. This makes a difference between the primary and standby databases.