Oracle 9i Data Guard for database Disaster Protection

Oracle9i Data Guard prevents Data disasters by using a database called standby database. It uploads and applies the redo logs of the primary database to the standby database to synchronize the standby database and the primary database:
You can synchronize redo logs from the primary database to the standby database to achieve disaster protection without data loss. This will cause some performance loss to the performance of the primary database.
Archive redo logs can be asynchronously written from the primary database to the standby database so that the primary database can minimize data loss without compromising performance.
If the redo log data is quickly applied to the standby database after arriving at the standby database, you can quickly failover to the standby database when a problem occurs in the primary database. However, if you wait for a certain period of time before applying redo log data, you can avoid the error of the primary database to quickly spread to the standby database.
As shown in the figure below, when online redo logs are archived locally, they are simultaneously transferred to the standby database through Oracle Net:
Database Data Protection Level
You can set the standby database in the following way to achieve different database data protection levels:
Guaranteed protection: specifies that at least one standby database is valid when you modify the primary database. If the connection between the master and slave databases is interrupted, Oracle will interrupt the work of the master instance to prevent data inconsistency between the master and slave databases and ensure no data loss. This mode has a great impact on database performance.
Instant protection: specifies that at least one standby database is valid when you modify the primary database. Unlike the Guaranteed protection mode, when the connection between the master and slave databases is interrupted, the data between the master and slave databases is allowed to be inconsistent. After the connection is restored, solve data inconsistency. This mode has a small impact on the performance of the primary database.
Rapid protection: Changes to the primary database are quickly applied to the standby database. Data loss may occur, but the impact on database performance is small.
Delayed protection: the modification of the primary database is applied to the standby database after a certain delay. The Rapid protection and Delayed protection modes allow the master database to have data differences with all the slave databases even when the network connection is valid. The loss of data is equivalent to the number of unclassified items in the online redo logs of the master database. This method has little impact on database performance.
How to limit data loss
In the primary/standby configuration, all archived logs are sent to the standby node, which keeps the data of the standby node updated. However, if the primary database is accidentally closed, online logs will be lost because they are not archived and sent to the standby node. This makes a difference between the primary and standby databases.
Oracle9i can use the following methods to limit this difference:
DBA can choose to allow LGWR to send the redo log data to the standby database while writing it to the local disk. This feature is called standby zero data loss ). In essence, this method provides remote redo log images, but the problem is that performance is greatly reduced.
Set the system initialization parameter ARCHIVE_LAG_TARGET. this parameter is the time interval from when a log file is used to be sent to the standby database. The recommended value of this parameter is 1800 seconds. Note that committed transactions that are not transmitted to the standby database will be lost, so long transactions will cause more data loss to the standby database ).
Relationship between Oracle9i Data Guard Data protection and Oracle8 Standby Database Oracle Standby Database is the most frequently used and most effective disaster solution. On the basis of previous versions, Oracle9i has made many improvements, so that its functions far exceed the basic disaster recovery requirements. By automating complex work and large-scale improvements to monitoring, warnings, and control mechanisms, standby Database and some new modules can help DBAs recover from wrong operations, paralysis, and other disasters which may destroy the Database ). In addition, the downtime caused by hardware and software upgrades can be greatly shortened by using Oracle9i Standby Database.
Oracle9i combines the improved Standby Database feature of version 8 with several new modules that prevent user errors and paralysis with Oracle9i Data Guard.
Oracle8 automatic Standby Database provides a means to create and automatically maintain copies of production databases to prevent disasters. Oracle8 automatic Standby Database has the following features:
After the primary database generates logs, the system automatically updates standby databases with the archived logs. A primary database can have up to four standby databases. the four standby databases are identical copies with the primary database, and they can all take over the processing of the primary database.
Oracle uses standard recovery methods to apply archived logs to each standby databases. These logs are automatically applied by DBAs.
Primary database is in the open and active state, while standby database is in the recovery or read-only state.
Most Oracle8-based disaster protection solutions include an Automated Standby Database. because Oracle databases can be backed up and restored using logs, any application can use the Automated Standby Database. the impact of archiving logs transmitted through Oracle Net on the performance of primary database is negligible.
Physical Standby Database and logical Standby Database
Standby databases can be divided into physical Standby databases and logical Standby databases:
Physical Standby Database. The physical Standby Database is the Oracle9i version of Oracle8 automatic Standby Database. There is only one difference between them: the log transmission service is now a separate module and supports the physical standby database and the new logical standby database.
The meaning of physical Standby Database is that the physical Standby Database is the same as the primary database. Because ROWID is used for restoration, the data block of Standby Database is as fast as that of primary database. The database mode must be the same and cannot be opened in read/write mode.
Logical Standby Database. the logical Standby Database converts archived logs into SQL transactions and applies them to the open Standby Database. because the database is opened, it is physically different from the primary database. However, logically speaking, Standby databases and primary databases are the same, so they can take over the processing of primary databases. In this case, Standby Database can also perform other tasks concurrently, such as creating indexes and materialized views different from primary database, and supporting decision-making.
Logical Standby Database is the most important data protection feature. Like a physical standby database, it uses archived logs for processing on the standby database, and there is no problem in the case of problems with the primary database.
When you choose to use physical standby database, logical standby database, or both, consider the following factors.
The logical standby database can be used for two purposes. When you want to change the logical standby database, its database can be opened.
The logical standby database requires higher DBA skills.
Solutions that maximize data protection generally include logical and physical standby databases. database Failover and Switchover when the primary database goes down and cannot be recovered in time, Oracle will discard the primary database and change the standby database to the primary database. After failover, the slave database becomes the master database, thus losing all the capabilities of the slave database. That is to say, you cannot return to the backup mode.
Failover has the following features:
The master database is offline and the slave database is online. This operation is caused by system and software failure.
Even if redo logs are applied to the standby database, data may be lost unless the standby database runs in guaranteed protection mode.
The original primary database must be reinstantiatedstart instance ).
Reinstantiated is also required for other backup databases.
When the primary database works normally, Oracle allows DBA to switch the primary database to the standby database, which is changed to the primary database and the original primary database to the standby database.
You can switch from the primary database role to the standby database role, or from the standby database role to the primary database role.
Switchover has the following features:
Deliberately offline the primary database and online the other standby database. You can use the Switchover function to smoothly upgrade the system.
Even if no redo logs are applied to the standby database, data will not be lost.
The database does not require reinstantiated. This allows the primary database to restore its functions almost immediately on the standby database, so regular maintenance can be performed without interrupting the operation.
Some parts of Oracle9i Data Guard Log Transmission Service Log Transport Services)
Log Transport Services will be used by physical and logical standby databases. It provides functions including controlling different log transmission mechanisms, log transmission error handling and reporting, and obtaining lost logs after system failure. Data protection can be ensured by using any new log transmission mode.
Oracle9i Data Guard Broker
Data Guard broker provides monitoring, control, automation, and logical and physical standby components for the log transmission service. For example, failover can be started with only one command. Data Guard broker can be used to control the entire process from the primary role to any standby database. You can select role conversion from two different interfaces to enable standby database to take over the processing of the production database from the primary database. One option is to use the new Oracle Enterprise Manager Data Guard Manager. This graphic user interface tool can perform most configuration work and operation functions. Another option is a command line tool that provides basic monitoring, changing all the commands required by the role, and the ability to configure and set the Oracle9i Data Guard environment.
Data Guard Manager is part of Oracle Enterprise Manager.
Oracle9i LogMiner
LogMiner has been greatly improved in Oracle9i. LogMiner is a relational tool that allows DBAs to use SQL to read, analyze, and interpret log files. LogMiner can view online and archived redo log files.
The LogMiner technology provides the infrastructure used by the logical standby database. The new Oracle Enterprise Manager application Oracle9i LogMiner Viewer adds a graphical operation interface to the existing command line interface.
Disaster Recovery Server) and DRMON
In today's e-commerce world, companies that do business on the Internet must have a set of strategies to restore applications and databases in case of problems. Every DBA should consider disaster recovery and planned or unexpected failover. Disaster Recovery (DR) Server is part of a product that helps DBAs achieve higher system availability.
The Disaster Recovery (DR) Server is basically composed of a series of loosely connected nodes. These nodes combine physical and logical standby solutions into a separate and manageable disaster recovery solution. Disaster Recovery (DR) Server nodes are physically dispersed and are connected through a network. Each DR Server node may be a simple instance or a complex system such as a fail safe cluster ). The DR Server manages these nodes as a separate distributed computing system, so that their availability is higher than that of individual nodes.
DR Server implements its failover system by copying data between nodes. The database administrator configures the server in this way: the database and application are activated on each node. A node is designed as a primary node, and its database is used to indicate that it is completely available, and its data is copied to other nodes in the form of logs. Other nodes are standby nodes for the primary node. They receive logs sent from the primary node and change from physically or logically) their database copies.
The standby node of the DR Server is ready to take over when a problem occurs on the primary node, so that data and applications are still available to users after a disaster occurs on the primary node.
The DR Server structure provides DBAs with two important functions:
It provides DBA logic to configure a failover Resource Group to achieve high availability.
It specifies the basic computing framework of the DR Server itself.