Oracle databases are well-known as a mainstream enterprise-grade database solution. Building a highly reliable, high-performance, and highly secure database environment is critical for ensuring the success of IT operations. Oracle 11g Active Data Guard is Oracle’s solution for database management and disaster recovery. Data Guard brings many benefits: on one hand, it enables disaster recovery and high availability for Oracle databases, comprehensive data protection, efficient utilization of system resources, automatic fault detection and resolution, a centralized and easy-to-use management model, automated role transitions, and a more flexible balance between high availability and high performance (meaning database operations and maintenance will become increasingly automated); on the other hand, Oracle 10g will no longer receive technical support starting July 2013, making subsequent bugs and vulnerabilities difficult to patch. Although the 12c version was released in 2013, it is still relatively unstable and not recommended for production use. However, in cross-database environments, we recommend using Oracle OGG in conjunction with Data Guard, as OGG offers sub-second data transfer capabilities.
I. Oracle 11g Data Guard Concepts
II. Configuring Oracle 11g Active Data Guard
III. Active Data Guard Implementation Summary
IV. Active Data Guard Concepts
Prior to Oracle 11g, the primary-standby relationship, typically formed by two mirrored data nodes, was used to achieve fast database switching and disaster recovery. This was referred to as Data Guard. Data Guard synchronization worked by having the standby database continuously copy primary database files and apply the redo logs transmitted from the primary database to maintain physical structural consistency with the primary. Standby databases are categorized into physical standby and logical standby. The primary and standby databases communicate via the SSL protocol, which uses RSA public-key cryptography and symmetric key encryption to provide authentication, encryption, and data integrity. With the Oracle 11g version, the Active Data Guard feature was introduced, enabling read-write separation for Oracle databases. Active Data Guard technically allows the database to be opened in read-only mode while logs are being recovered and data is being synchronized. Users can perform queries, reporting, and other operations on the standby database, which is similar to the query capabilities of a logical Data Guard standby database. However, its data synchronization efficiency is higher and its hardware resource requirements are lower. This allows for the more effective utilization of the physical standby database’s hardware resources. Data Guard provides three protection modes:
Maximum Protection Mode:
This mode offers the highest level of data protection: it requires that the redo log is received by at least one physical standby database before a primary database transaction can commit. If the primary database cannot find a suitable standby database to write to, the primary database will automatically shut down to prevent unprotected data from appearing. The advantage is that this mode guarantees zero data loss on the standby database. The disadvantage is that the primary database’s automatic shutdown impacts its availability, and transactions can only be committed after the standby database recovers, placing very high demands on the network and other external conditions. The primary database’s performance will be significantly impacted as a result. This also means that Data Guard can only open the database in read-only mode, but the process of synchronizing data using logs stops at that point. If the physical standby database is in the recovery process, the database cannot be opened for queries.
Maximum Performance Mode:
This is the default mode, which ensures the highest availability of the primary database. It guarantees that the primary database’s operation is unaffected by the standby database. Primary database transactions commit normally, and no issues with the standby database will affect the primary database’s operation. The advantage is that it avoids any impact from the standby database on the primary database’s performance and availability. The disadvantage is that if the recovery data related to committed primary database transactions is not sent to the standby database, these transaction records will be lost. However, in general, disaster recovery can be performed by extracting database logs and applying them to the physical standby. Typically, we recommend using Maximum Performance mode to achieve the highest efficiency while ensuring data security.
Maximum Availability Mode:
This mode provides a level of data protection second only to “Maximum Protection” mode: it requires that the redo log is received by at least one physical standby database before a primary database transaction can commit. If the primary database cannot find a suitable standby database to write to, it will not shut down but will instead temporarily downgrade to “Maximum Performance” mode until the issue is resolved. The advantage is that this mode can guarantee zero data loss on the standby database when no problems occur, representing a compromise method.
Configuring Oracle 11g Active Data Guard
Active Data Guard does not require component installation or the purchase of related accessories; it only needs to be configured. In most cases, it can be used on Oracle RAC, Grid Infrastructure, OGG, and ASM environments to maximize overall efficiency.
Below are the steps for configuring a single-instance Active Data Guard on the primary database of an Oracle RAC cluster:
1. Primary Database Preparation
鈶?The RAC primary database must be set to ARCHIVELOG mode;
鈶?The RAC primary database must be set to Force Logging mode;
鈶?Perform a full RMAN backup of the RAC primary database;
鈶?Create a physical standby control file from the RAC primary database;
鈶?Create a physical standby initialization parameter file from the RAC primary database;
鈶?Modify the password file on the RAC primary database to make the SYS user passwords consistent across both nodes;
2. Physical Standby Database Preparation:
鈶?FTP the primary database backup files + standby control file + standby parameter file to the physical standby database server;
鈶?Create a password file for the physical standby database;
鈶?Modify the physical standby database initialization parameter file;
鈶?Configure the tnsnames.ora file for both the RAC primary database and the physical standby database;
3. Creating the Physical Standby Database
鈶?Start the physical standby database in the NOMOUNT state;
鈶?Restore the standby control file using RMAN;
鈶?MOUNT the physical standby database;
鈶?RMAN restore the physical standby database;
鈶?Create