Oracle Data Guard: A Key Player in Enterprise-Level DR

RAC, Data Guard, and Stream are three tools in Oracle’s high availability system. Each tool can be used independently or in combination. They have different focuses and are applicable in different scenarios.

RAC excels at addressing single point of failure and load balancing. Therefore, RAC is commonly employed in 24/7 critical systems. However, in the RAC solution, data exists in only one copy. Although storage failures can be avoided through mechanisms like RAID, the data itself lacks redundancy, making it susceptible to single point failures.

Data Guard provides data protection through redundant data. By utilizing log synchronization mechanisms, Data Guard ensures synchronization between redundant data and the primary data. This synchronization can be achieved in various forms such as real-time, delayed, synchronous, or asynchronous. Data Guard is commonly used in remote disaster recovery and high availability solutions for small enterprises. While it allows read-only queries on the standby machine to alleviate the performance pressure on the primary database, Data Guard is not primarily intended as a performance solution.

Streams, built upon Oracle Advanced Queue, enables data synchronization and offers flexible configurations at multiple levels. Since Oracle provides extensive development support, including rich APIs, Streams are more suitable for data sharing at the application level.

What is Data Guard?

In a Data Guard environment, there are at least two databases: one in an open state providing services externally, known as the Primary Database, and the other in a recovery state, known as the Standby Database. During runtime, the Primary Database serves clients, and user operations are recorded in online and archived logs, which are then transmitted to the Standby Database over the network. These logs are replayed on the Standby Database to achieve data synchronization between the two.

Oracle Data Guard further optimizes this process, automating and streamlining log transmission and recovery tasks, while providing a range of parameters and commands to simplify the work of database administrators (DBAs).

If there are anticipated factors that require the Primary Database to be shut down, such as software or hardware upgrades, the Standby Database can be switched to become the Primary Database and continue serving clients. This minimizes service downtime and ensures data integrity. In the event of unexpected issues rendering the Primary Database unavailable, the Standby Database can be forcibly switched to become the Primary Database and continue serving clients. The level of data loss in such cases depends on the configured data protection level. Therefore, Primary and Standby databases are conceptual roles that are not fixed to specific databases.

Data Guard Architecture

The Data Guard architecture can be divided into three functional parts:

1) Redo Send:

During the runtime of the Primary Database, redo logs are continuously generated and need to be sent to the Standby Database. This sending action can be performed by the LGWR or ARCH processes of the Primary Database. Different destinations for archiving can use different methods, but for a specific destination, only one method can be selected. The choice of the process has a significant impact on data protection capabilities and system availability.

2) Redo Receive:

The RFS (Remote File Server) process in the Standby Database receives the logs and writes them to either the Standby Redo Log or Archived Log files, depending on the Primary Database’s log transport method and the location of the Standby Database. If the logs are written to the Standby Redo Log files, then when a log switch occurs on the Primary Database, it triggers a log switch on the Standby Database’s Standby Redo Log and archives that Standby Redo Log. If the logs are written to Archived Logs, this action can be regarded as an archiving operation itself.

3) Redo Apply:

The redo apply service is responsible for replaying the Primary Database’s logs on the Standby Database, thereby achieving data synchronization between the two databases.

Depending on how the Standby Database replays the logs, there are two types: Physical Standby and Logical Standby.

Based on when Redo Apply occurs, there are also two types :

a) Real-Time Apply: This method requires the usage of Standby Redo Log. Whenever a log is written to the Standby Redo Log, it triggers recovery. The benefit of this method is that it reduces the time required for database switchover since the remaining logs are already recovered in real-time.

b) Apply at Archival: This method applies the logs when a log switchover occurs on the Primary Database and triggers archiving on the Standby Database. The recovery is initiated after the archiving process is completed. This is the default recovery mode as well.

Physical Standby vs. Logical Standby

There are two types of Standby Databases: Physical Standby and Logical Standby.

1. Physical Standby:

A Physical Standby database is the same as a Primary database. Data Guard maintains the Physical Standby database through REDO apply. Generally, when the Physical Standby is not applying REDO, it can be opened in READ ONLY mode. If a Flashback Area is specified in the database, it can even be temporarily switched to READ WRITE mode for operations. After completing the necessary operations, the database can be restored back to its state before READ WRITE mode using the Flashback Database feature, allowing the application of REDO data from the Primary database to continue.

Note: The application functionality of Physical Standby has been enhanced in Oracle 11g. In this version, Physical Standby can continue applying REDO data while being in OPEN READ ONLY mode. This greatly enhances the usability of Physical Standby databases.

Features of Physical Standby:

1) Disaster recovery and high availability: Physical Standby provides a robust and efficient solution for disaster recovery and high availability. It simplifies the management of switchover/failover and reduces planned or unplanned downtime.

2) Data protection: With a Physical Standby database, Data Guard ensures data loss is minimized, even in the face of unforeseen disasters.

3) Offload Primary database workload: By offloading certain tasks, such as backups and read-only queries, to the Physical Standby database, CPU and I/O resources on the Primary database can be conserved.

4) Improved performance: The REDO apply mechanism used in Physical Standby databases operates at the lowest level of recovery, bypassing SQL code execution. This results in the highest efficiency and performance.

2. Logical Standby:

A Logical Standby database is also created based on the Primary database (or its backups or replicas, such as Physical Standby). Therefore, initially, it is similar to a Physical Standby database at the beginning. However, since a Logical Standby applies REDO data through SQL execution, its physical file structure and even the logical structure of the data can be different from the Primary database.

Unlike Physical Standby, a Logical Standby is normally opened in READ WRITE mode, allowing users to access it at any time. In other words, SQL execution takes place while the Logical Standby is in an OPEN state. This has advantages and disadvantages. Due to the nature of SQL execution, there are operational limitations on certain data types and some DDL/DML statements in a Logical Standby. You can check the unsupported data types in the DBA_LOGSTDBY_UNSUPPORTED view. If such data types are used, ensuring complete consistency in the database cannot be guaranteed.

Opening READ WRITE mode of a Logical Standby makes it suitable for use as a reporting system, relieving the system’s workload.

Features of Logical Standby:

In addition to the characteristics mentioned earlier for Physical Standby, such as disaster recovery, high availability, and data protection, Logical Standby has the following features:

1) Efficient utilization of hardware resources on the standby server: A Logical Standby database can be used to create additional indexes, materialized views, and satisfy specific business needs. It can also create new schemas (which do not exist in the Primary database) and execute DDL or DML operations that are not appropriate on the Primary database.

2) Offload Primary database workload: By keeping the Logical Standby database open while remaining synchronized with the Primary database, it can serve both data protection and reporting operations. This relieves the Primary database from reporting and query tasks, saving valuable CPU and I/O resources.

3) Smooth upgrades: Logical Standby can be used for operations such as cross-version upgrades and patching of the database.

Data Protection Modes

Data Guard allows three data protection modes: Maximum Protection, Maximum Availability, and Maximum Performance.

1. Maximum Protection:

This mode ensures zero data loss. To achieve this, all transactions must not only be written to the local Online Redo Logs before commit but also simultaneously written to the Standby Redo Logs in the Standby database. The REDO data needs to be accessible in at least one Standby database (if multiple exist) before it can be committed on the Primary database. In case the Standby database becomes unavailable due to a failure (e.g., network interruption), the Primary database will be shutdown to prevent data loss.

Enabling this mode requires the Standby Database to be configured with Standby Redo Logs, and the Primary Database to use the LGWR, SYNC, AFFIRM mode for archiving to the Standby Database.

2. Maximum Availability:

This mode provides the highest level of data protection strategy without impacting the availability of the Primary database. It follows a similar implementation as Maximum Protection, where local transactions must be written to at least one Standby database’s Standby Redo Logs before commit. However, the difference is that if a failure occurs that renders the Standby database inaccessible, the Primary database will automatically switch to Maximum Performance mode instead of shutting down. Once the Standby database recovers, the Primary database will automatically switch back to Maximum Availability mode.

Although this mode aims to minimize data loss, it cannot guarantee absolute data consistency. Like Maximum Protection, this mode requires the Standby Database to be configured with Standby Redo Logs, and the Primary Database to use the LGWR, SYNC, AFFIRM mode for archiving to the Standby Database.

3. Maximum Performance:

This mode provides the highest level of data protection strategy without impacting the performance of the Primary database. Transactions can be committed at any time, and the REDO data from the current Primary database needs to be written to at least one Standby database, although this can be done asynchronously. Under ideal network conditions, this mode can provide data protection similar to Maximum Availability while having only a slight impact on the performance of the Primary database. This is the default protection mode when creating a Standby database. It can be achieved using either LGWR ASYNC or ARCH processes, and Standby Redo Logs are not required for the Standby Database.

Steps to Modify the Data Protection Mode:

1. Shut down the database and restart it in Mount state. If it is a RAC setup, shut down all instances and start only one instance in Mount state.

2. Modify the mode using the following syntax:

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};

For example: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

3. Open the database: ALTER DATABASE OPEN;

4. Confirm the modified data protection mode:

SQL>select protection_mode,protection_level from v$database;

Log Apply Services

Data Guard ensures consistency between the Primary database and Standby databases by applying REDO. Behind the scenes, quietly supporting this process, are the renowned Log Apply Services. There are two types of Log Apply Services:

1. REDO Apply: Exclusive to physical Standby databases, it keeps them synchronized with the Primary database through media recovery.

2. SQL Apply: Exclusive to logical Standby databases, its core functionality involves analyzing SQL statements through LogMiner and executing them on the Standby side.

Therefore, when applying REDO data, physical Standby database must be in a MOUNT state, while logical Standby database is opened in READ WRITE mode for REDO data application. However, the objects being maintained are set to read-only by default and cannot be directly modified on the logical Standby side.

Protect Oracle database with a professional solution

Oracle Data Guard is a robust solution for high availability, data protection, and disaster recovery. It's a critical tool for businesses that can’t afford significant downtime or data loss. However, to further protect your database environment, it is recommended to backup your Oracle database with a professional backup and disaster recovery solution.

Vinchin Backup & Recovery delivers powerful functionality to protect your databases in both virtual machines and physical servers, which is quite automatic, flexible and efficient. It provides multi-type database protection of Oracle DB, MySQL, SQL Server, Postgres Pro and MariaDB, supporting database compression, centralized job management, smart backup strategies, hot database backup and advanced SQL Server/Oracle support. Besides, it also supports powerful ransomware protection feature and V2V migration across 10+ virtual platforms.

Vinchin Backup & Recovery has been selected by thousands of companies and you can also start to use this powerful system with a 60-day full-featured trial! Also, contact us and leave your needs, and then you will receive a solution according to your IT environment.

Conclusion

Oracle Data Guard is a critical component for any enterprise-level Oracle database deployment, providing a comprehensive solution for disaster recovery, high availability, data protection, and workload balancing. Its flexible architecture and various modes of operation make it adaptable to a wide range of business needs and operational requirements.

You can choose Vinchin Backup & Recovery to easily backup and recover your Oracle databases. Don’t miss the free trial!