Oracle Data Guard

Oracle Data Guard

Oracle Data Guard

Oracle Data Guard is Oracle’s solution for high availability, data protection, and disaster recovery for enterprise databases. It creates and maintains one or more standby databases as transactionally consistent copies of a primary database. If the primary database becomes unavailable due to planned maintenance or unplanned outage, Data Guard can quickly switch a standby into the primary role, minimizing downtime.

Data Guard services:

Redo Transport Services and Apply Services, which handle shipping of redo logs and applying changes to standbys, as well as Role Transition services to switch roles between primary and standby.

Redo Transport Services

Control how redo is sent from primary to standbys (synchronously or asynchronously, how it’s buffered, etc.). Transport services also handle networking faults by queuing redo and resolving gaps if a standby missed some logs (e.g., network outage). Data Guard automatically detects it and fetches the missing logs from the primary or another standby. It also validates redo integrity, and can compress or encrypt redo for transmission (if configured).

Apply Services

Control how redo is applied to the standby. In a physical standby, Redo Apply uses Oracle recovery (Media Recovery process) to apply redo records and recover the standby database in real-time. In a logical standby, SQL Apply uses LogMiner to transform redo into SQL statements and executes them on the standby database. Apply Services can apply redo as it arrives (real-time apply) or after it’s archived on standby. Real-time apply (with standby redo logs) is recommended to minimize lag.

Data Guard roles:

The primary role (the production database) and the standby role (copies that can take over). Standbys can operate in different modes (physical, logical, snapshot) and even be open read-only while synchronized (Active Data Guard feature).

Types of Standby Databases:

Oracle Data Guard supports three types of standby databases:

Physical Standby

An identical, block-for-block copy of the primary. Redo received from the primary is applied using Redo Apply (media recovery) to keep it in sync. The schema and data match exactly. Oracle 19c supports real-time query, meaning the standby can be open read-only for queries and still apply redo in the background (with some lag). This is accomplished by having standby redo log (SRL) files where the RFS process writes incoming redo and the apply process (MRP) can apply from SRLs as they fill, without waiting for an archived log switch. If SRLs are not configured, the standby must wait for the primary to switch log and send an archived log before apply, increasing lag. It’s a best practice to always configure standby redo logs on each standby for real-time apply and to prevent data loss. Also, when the standby is open for queries, Data Guard in Oracle 19c provides Automatic Block Media Recovery: if a query on the standby hits a corrupt block, it can automatically fetch a good copy from the primary (or another standby) to repair it. This feature improves reliability of offloaded queries.

Logical Standby

Contains the same logical data as the primary (same rows), but physical organization may differ. Redo is transformed into SQL statements via SQL Apply and executed on the logical standby, so it does not require identical structure to the primary. Logical standbys can have additional local tables, indexes, or materialized views not present on the primary – they are open read/write, which allows using the standby for reporting or even adding analytical indexes that wouldn’t be appropriate on primary.

Snapshot Standby

A physical standby temporarily converted into an updatable snapshot database. A snapshot standby receives redo from the primary but does not apply it while in snapshot mode. Instead, redo is queued. The snapshot standby database is open read-write, so you can run tests or development workload on it. Later, it can be converted back into a physical standby – at which point all accumulated redo is applied to catch up with the primary, discarding any local updates made during the snapshot period.

Far Sync Instances:

Introduced in Data Guard 12c, a far sync instance is a lightweight Oracle instance that has no user data and cannot be opened but accepts redo from the primary and forwards it to one or more standbys. Far sync instances contain only a control file and standby redo logs (to temporarily store incoming redo) – they don’t have datafiles or run recovery apply. The primary use-case is to achieve zero data loss protection over long distances without impacting primary performance: the primary ships redo synchronously to a nearby far sync, which immediately forwards it asynchronously to a far-away standby. Thus, the primary’s transaction commit wait is only as long as the round-trip to the near facility (reducing latency), yet the redo still ultimately reaches the remote standby.

Role Transitions:

It refers to changing a standby to primary or vice versa. A switchover is a controlled role swap (no data loss), typically for planned maintenance. A failover is an emergency change due to primary failure (potentially with data loss if the primary couldn’t send all redo).

Protection Modes:

Data Guard can run in three modes that balance performance and data loss protection:

  • Maximum Protection – zero data loss is guaranteed by not allowing the primary to continue unless at least one standby acknowledged the redo (synchronous transport). If no standby is available, the primary shuts down rather than run unprotected.
  • Maximum Availability – zero data loss under normal conditions (same sync requirement), but if standbys become unavailable, the primary will temporarily revert to asynchronous mode to preserve availability. When standbys catch up, it resumes sync. This mode balances no data loss with not impacting primary uptime.
  • Maximum Performance – the default mode; transactions commit without waiting for standby acknowledgments (asynchronous redo transport). This offers best primary performance at the cost that some last transactions may be lost if the primary fails.

These modes are implemented via redo transport settings (SYNC/ASYNC, AFFIRM/NOAFFIRM) on the redo destinations.

Comments

Post a Comment

Popular posts from this blog

Automating DBA Tasks with Oracle GoldenGate - Part 1

Automating DBA Tasks with Oracle GoldenGate Oracle GoldenGate is widely recognized as one of the best tools for real-time data replication. It allows seamless database migrations, schema or table replication across homogeneous and heterogeneous environments, and enhances database performance by offloading reporting workloads. Additionally, it ensures high availability by enables Bi-directional or cascading database replication configurations. Beyond these well-known benefits, GoldenGate can also be leveraged for automating routine DBA tasks, reducing manual intervention and improving efficiency by Streamline Your DBA Tasks with EVENTACTIONS. Let's explore how you can leverage its EVENTACTIONS parameter to automate routine DBA tasks, reduce manual effort, and optimize workflows. In this post, I will demonstrate how GoldenGate can assist in automating key DBA operations, such as: Starting or stopping GoldenGate processes – Automate the m...
Read more

Automating DBA Tasks with Oracle GoldenGate - Part 2

Automating DBA Tasks with Oracle GoldenGate In this post, we will explore how to automate DBA jobs with Goldengate. If you're reading this directly, I recommend checking out Part 1 first to understand how it works. If you've already read Part 1, feel free to continue from here! Or you are already familiar with goldengate you are good enough to continue. Steps to Automate User Management in Goldengate Configure Goldengate parameters and place the required shell and SQL scripts. Add the necessary input into GG_USERMGMT_TB, such as the username, database name, and granted roles. Verify that the user has been successfully created in the database. This setup is sufficient to bring your bright idea to life using your environment. Here, the E_E01_1 extract acts as the master process to automate DBA job user management operations. I have two databases, orclpdb01 and orclpdb02, with the master extract process configured and running on or...
Read more

Enhanced Guide on Importing Oracle Meta Notes

Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2) Primary Note for Oracle GoldenGate Core Product Patch Sets (Doc ID 1645495.1) Primary Note for Database Proactive Patch Program (Doc ID 888.1) Troubleshoot Grid Infrastructure Startup Issues in 12.1.0.2 and Higher (Doc ID 2801511.1) Oracle Database Advisor Webcast Schedule and Archive recordings (Doc ID 1456176.1) Creating a Physical Standby database using RMAN restore the database from service (Doc ID 2283978.1) How to Roll Forward a Standby Database Using Recover Database From Service (Doc ID 2850185.1) Making Use Deferred PDB Recovery and the STANDBYS=NONE Feature with Oracle Multitenant (Doc ID 1916648.1) Roll Forward Physical Standby Using RMAN Incremental Backup in Single Command (Doc ID 2431311.1) 12c How to Roll Forward a Standby Database Using Recover Database From Service (Doc ID 2850185.1)Dataguard F...
Read more