Maximum Availability Architecture with

Oracle Active Data Guard 21c

Ljiljana Perica
Principal Solutions Specialist Engineer

ljiljana.perica@oracle.com
Oracle (Active) Data Guard & MAA

2
 High Availability and Disaster Recovery
Protect data and systems from outages

3
Impact of database downtime

$350K $10M
average cost of downtime average cost of unplanned data
per hour center outage or disaster

87 hours 91%
average amount of downtime percentage of companies that have
per year experienced an unplanned data
center outage in the last 24 months

4 Copyright © 2022, Oracle and/or its affiliates

 Oracle Maximum Availability Architecture (MAA)
Key goal: to achieve optimal HA, data protection and DR for Oracle customers at the lowest cost and complexity

Continuous availability

Customer insights and expert recommendations

Platinum

Application Continuity Global Data Services

Data protection

Reference 24/7 HA features,

architectures configurations
Replication and operational Flashback RMAN + ZDLRA
practices
Gold

Active replication
Production site Replicated site

Active Data Guard GoldenGate

Deployment choices
Silver

Scale out

Generic Systems Engineered Systems DBCS ExaCS/ExaCC Autonomous DB

Bronze

RAC ASM Sharding

5
MAA reference architectures
Availability service levels

Bronze Silver Gold Platinum

Dev, test, prod Prod/departmental Business critical Mission critical

Bronze + Silver + Gold +

Single instance DB Database HA with RAC DB replication with Active GoldenGate

Data Guard
Restartable Application Continuity
Edition based redefinition
Backup/restore

All tiers exist with on-premises and cloud. However, platinum currently must be
configured manually while bronze to gold are covered with cloud tool automation for
the most part depending on the desired RTO (i.e. FSFO & multiple standby databases
still must be manually configured for example)

6 Copyright © 2022, Oracle and/or its affiliates

Oracle Active Data Guard vs Storage Replication

To Mirror or not to Mirror

That is the question.

7
Data Corruptions Happen All the Time
Fundamental shortcoming of Storage Replication: inadequate isolation, zero application-level validation

Any component in the systems stack can fail and cause data
corruptions*
• Software: applications, middleware, database
• Hardware: disk drives / controllers, HBAs, memory
• Network: routers, switches, cables
• Operational: human errors, bad installs & upgrades
Increasing data volumes and complex I/O subsystems:
• Impact of data corruptions is disastrous
• Very hard to debug and diagnose

•Ref. “Hard Disk Drives – the Good, the Bad & the Ugly”, ACM Queue, Sep/Oct 2007,
http://queue.acm.org/detail.cfm?id=1317403

•* Ref. “Silent Corruptions, CERN”,

http://fuji.web.cern.ch/fuji/talk/2007/kelemen-2007-C5-Silent_Corruptions.pdf
 Storage Remote Mirroring Architecture
Mirrors every write to every file including those that are corrupted or encrypted by ransomware

Primary Site Standby Site

Primary Database • No Oracle validation
• Unusable destination
• 7x network volume
• 27x network I/O

DATAFILES DATAFILES

SYNC or ASYNC
LOGFILES LOGFILES

block replication
CONTROLFILES CONTROLFILES

Primary Volumes Mirrored Volumes

9
 Data Guard is optimized for the database
It efficiently maintains a physical copy of production and guarantees its integrity
• Validation end to end
Primary Site
• Ransomware Protection
Online • Only the essential information (Redo) is replicated
Redo Logs
• Efficient and performant

Standby Site

SGA LGWR

REDO
BUFFER NSS/
SYNC or ASYNC RFS MRP
TT Redo transport
Primary Standby
Redo Logs
Standby
Database Database

10
Active Data Guard Does What Storage Mirroring Can’t
Automatic Block Repair - Transparently repairs corrupted blocks

• Oracle will detect if block is corrupt when read at primary

• Corruption is automatically repaired using good copy from standby
• In same way, corruption detected at standby will also be repaired
using good copy from primary

11
Oracle Data Guard Overview

12
What is Oracle Data Guard?
Primary (production) Standby
database Database(s) (sync. copy of Pdb, max 30 Sdb)
Redo transport
SYNC / ASYNC

Oracle Net

Database Database
copy

Works with a production db and one or more standby dbs to protect your data against failures, errors, and
corruptions that might otherwise destroy your db
 Types of Standby Databases

• Physical standby database:

‐ Is identical to the primary database on a block-for-block basis
‐ Is synchronized with the primary database through application of redo data received from the primary database
‐ Can be used concurrently for data protection and reporting

• Logical standby database:

‐ Shares the same schema definition
‐ Is kept synchronized with the primary database by transforming the data in the redo received from the primary
database into SQL statements and then executing the SQL statements
‐ Can be used concurrently for data protection, reporting, and database upgrades

• Snapshot standby database:

‐ Is a fully updatable standby database
‐ Is created by converting a physical standby database
‐ Can be used for updates, but those updates are discarded before the snapshot standby database is converted back
into a physical standby database
‐ Can be used for testing

14
Role Transitions: Switchover and Failover

Data Guard provides supports 2 role-transition operations:

• Switchover
‐ Planned role reversal
‐ Used for OS or hardware maintenance
• Failover
‐ Unplanned role reversal
‐ Emergency use
‐ Zero or minimal data loss (depending on choice of dataprotection mode)
‐ Can be initiated automatically when fast-start failover is enabled

15
Oracle Data Guard: Architecture (Overview)

16
Physical Standby Database: Redo Apply Architecture
How is your physical standby database synchronized with a primary database

17
Logical Standby Database: SQL Apply Architecture
How is your logical standby database synchronized with a primary database

18
Automatic Gap Detection and Resolution

19
Data Guard Data Protection Modes
Different Configurations that Balance Data/Transaction Protection with Performance and Availability

Mode Risk of data loss Transport If no acknowledgement from standby:

Zero Data Loss

Maximum Stall primary until acknowledgement is
Double Failure SYNC
Protection received from replica
Protection

Zero Data Loss Stall primary until acknowledgement is

Maximum
Single Failure SYNC received or timeout threshold period
Availability
Protection expires – then resume processing

Maximum Potential for Primary never waits for standby

ASYNC
Performance Minimal Data Loss acknowledgement
Advanced Features with Oracle Active Data Guard

21
 Oracle Active Data Guard (ADG)

• Increases performance, availability, data protection, and ROI wherever DG is used for real-time data
protection and availability
• Is an option for Oracle Database Enterprise Edition
• Enhances quality of service by offloading resource intensive activities from a Production db to a Standby db
• Includes the following features:
‐ Physical Standby with Real-time Query
‐ Fast Incremental Backup on Physical Standby
‐ Automatic Block Repair
‐ Active Data Guard Far Sync
‐ Global Data Services
‐ Real-Time Cascade
‐ Application Continuity
‐ Rolling Upgrade using Active Data Guard
‐ Active Data Guard DML Redirection (not available in Authorized Cloud Environments)

• Licensing Guide:
‐ https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-
AB354617-6614-487E-A022-7FC9A5A08472

• Demos:
‐ https://www.oracle.com/database/technologies/high-availability/dataguard-activedataguard-demos.html

22
 Dynamic: Activate Active Data Guard per database as demand requires it
With Data Guard Broker
• Connect to the Standby db with SQL*Plus and execute the following command:
• ALTER DATABASE OPEN;

Without Data Guard Broker

• Connect to the Standby db with SQL*Plus and execute the following commands:
• ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
• ALTER DATABASE OPEN;
• ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT FROM SESSION;

• No extra installation required.

• No change in your Data Guard configuration.
• Beware of license activations by mistake!

Active Data Guard

23
ADG: Real-Time Query

24
Real-Time Query
Read-only Standby while Recovery is Active

Activation

Primary Secondary With Data Guard Broker:

Site Site SQL> ALTER DATABASE OPEN;

Without Data Guard Broker:

RW RW RW RW RO RO RO RO ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE OPEN;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Beware of license activations by mistake!

25 Copyright © 2022, Oracle and/or its affiliates

 ADG
Offload Read-Only Workloads
Increase Performance and ROI – Standby is a Production System

Any read-only workload

Data extracts and backups

Production Offload to
Active Data Guard Standby
EBS - Oracle Reports
PeopleSoft - PeopleTools
Siebel CRM
OBIEE, Hyperion, TopLink

26
 ADG
Real-Time Query
Not just Selects for your Application Workloads!

SQL Performance Analyzer Sequences

Oracle Database In-Memory Updates on ADG (DML Redirect) NEW in 19c

Global Temporary Tables Standby Result Cache preservation NEW in 21c

R/O Connections Preserved

27
ADG: DML Redirection

28
 NEW IN

Bigger Footprint of ADG Applications 19c

DML on Active Data Guard

DML Re-direction is automatically performed from

an Active Data Guard standby to the primary without compromising ACID compliance

• New documented parameter ADG_REDIRECT_DML controls DML Redirection

• New alter {session|system} ADG_REDIRECT_DML
• New ADG_REDIRECT_PLSQL commands

Supported with Oracle Database 19c

Targeted for “Read-Mostly,
Occasional Updates” applications

29 Copyright © 2022, Oracle and/or its affiliates

 NEW IN

DML Replication 19c

Easy and ready to use

By default DMLs are not possible on the standby

SQL> update hr.employee set salary=salary+100 where employee_id=1;
ERROR at line 1:
ORA-16000: database or pluggable database open for read-only access

Enable DML redirection on the standby

SQL> connect / as sysdba
Connected.
SQL> alter system set ADG_REDIRECT_DML=true;

DMLs work seamlessly

SQL> connect hr/***
Connected.
SQL> update hr.employee set salary=salary+100 where employee_id=1;
1 row updated.
SQL> commit;
Commit complete.

30 Copyright © 2022, Oracle and/or its affiliates

ADG: Fast Incremental Backup on Physical Standby

31
Fast Incremental Backup on Physical Standby
Enable the Block Change Tracking to speed up backups and avoid unnecessary I/O

Primary Standby

No Block Change Tracking on the Standby

BCT Incremental backups require full data file reads

32 Copyright © 2022, Oracle and/or its affiliates

 ADG
Fast Incremental Backup on Physical Standby
Enable the Block Change Tracking to speed up backups and avoid unnecessary I/O

Block Change Tracking on the Standby:

Incremental backups read only the blocks modified since the last Level 0
Requires Active Data Guard

Primary Standby

BCT BCT

33 Copyright © 2022, Oracle and/or its affiliates

ADG: Far Sync

34
 ADG
The Zero Data Loss Challenge
Trade-off Performance for Protection

ASYNC

PRIMARY STANDBY

SYNC is not an option with high network latency

35 Copyright © 2022, Oracle and/or its affiliates

 ADG
Active Data Guard Far Sync
Zero Data Loss Protection at Any Distance

FAR ASYNC
SYNC Optional RedoCompression (*)
SYNC STANDBY

PRIMARY

* Requires Advanced Compression Option

36 Copyright © 2022, Oracle and/or its affiliates

 ADG
Active Data Guard Far Sync
Trade-off Performance for Protection
Far Sync
Standby Site
• Requires ADG Option on the DB nodes
• The Far Sync nodes do not require licenses *
Primary Nearby Site
• Special instance:
ASYNC • No datafiles
FAR
• No Media Recovery
SYNC • Only control files, archives and standby logs
STANDBY • Up to 30 direct destinations
• Offload transport compression (Advanced Compression)
SYNC

SYNC
• Supports FSFO in MaxAvailavility
• Supports FSFO in MaxPerformance (new in 21c)
Primary Site Standby Nearby Site

ASYNC FAR Use different Datacenters or Availability Domains!

SYNC • Upon failover, the standby will fetch the very last
redo from the Far Sync
PRIMARY

* The Far Sync nodes do not require any license, provided that all the other nodes running databases in the configuration are
licensed with Enteprise Edition and Active Data Guard

37 Copyright © 2022, Oracle and/or its affiliates

ADG: Real-Time Cascade Standbys

38
Active Data Guard: up to 30 direct standbys and 253 total members ADG
Far Sync and Cascading Standby open endless possibilities

• Disaster Recovery
• Query & Reporting Offload
BACK • DML Redirection
UP • Snapshot Standby for tests
Snapshot
Standby • Rolling Maintenance
• Rolling Upgrade
Primary DML • Migration to new Hardware
Redirect
• Source for thin clones
BACK
• Backup Offload
UP
• GoldenGate Extract Offload
• Recovery Appliance
FAR
SYNC

Thin Clones
39 Copyright © 2022, Oracle and/or its affiliates
 ADG
Real-Time Cascade Standby
Offload multiple redo transports to a first-level standby

BOSTON
RedoRoutes=
(LOCAL : ( NASHUA SYNC PRIORITY=1, NEWYORK ASYNC PRIORITY=8, NEWARK ASYNC PRIORITY=8 ))
(NASHUA : NEWYORK ASYNC, NEWARK ASYNC ))

NASHUA
RedoRoutes=
(LOCAL : ( BOSTON SYNC PRIORITY=1, NEWYORK ASYNC PRIORITY=8, NEWARK ASYNC PRIORITY=8 ))
(BOSTON : NEWYORK ASYNC, NEWARK ASYNC ))
ALTERNATE

NEWYORK

NEWARK • Explicit “ASYNC” in the cascading member means “Real-Time Cascade”. Such configuration
requires Active Data Guard.
• If not specified, the redo is shipped at log switch.

40 Copyright © 2022, Oracle and/or its affiliates

 ADG
Real-Time Cascade Standby
Offload multiple redo transports to a first-level standby

BOSTON
RedoRoutes=
(LOCAL : ( NASHUA SYNC PRIORITY=1, NEWYORK ASYNC PRIORITY=8, NEWARK ASYNC PRIORITY=8 ))
(NASHUA : NEWYORK ASYNC, NEWARK ASYNC ))

NASHUA
RedoRoutes=
(LOCAL : ( BOSTON SYNC PRIORITY=1, NEWYORK ASYNC PRIORITY=8, NEWARK ASYNC PRIORITY=8 ))
(BOSTON : NEWYORK ASYNC, NEWARK ASYNC ))

NEWYORK
ALTERNATE

NEWARK
• RedoRoutes is an efficient way to route the redo properly in any situation.
• The Broker takes care of all the complex LOG_ARCHIVE_DEST_n modifications.

41 Copyright © 2022, Oracle and/or its affiliates

ADG: Rolling Maintenance and Upgrades

42
 Original version
Reduce Planned Downtime
New version
General Process for Database Rolling Maintenance
Database A Database B
Install new version in separate Oracle
homes and defer transport REDO

Upgrade or perform other maintenance on B

then synchronize with production REDO
STBY

Switch production to B, outage limited SWITCHOVER

to the time needed to switch roles

Upgrade A via redo stream

REDO
and synchronize STBY
Oracle Patch Assurance - Data Guard Standby-First Patch Apply (Doc ID 1265700.1)
43 Copyright © 2022, Oracle and/or its affiliates
Rolling Upgrade | DBMS_ROLLING

Use a logical standby database to upgrade

with very little downtime.

The only downtime is as little

as it takes to perform a switchover.

Pro tip: Also useful for other

maintenance activities

44 Copyright © 2022, Oracle and/or its affiliates

 Rolling Upgrade | Concept
Guaranteed restore point
Users are
Start in new Flashback
Build LogMiner
connected here Primary
Oracle Home directory
Convert to physical standby
Upgrade
19c LOGMINER
via redo
INSERT INTO ORDERS VALUES ...
Applies SQL
TIME
Upgrade
REDO

REDO
DELETE FROM CUSTOMERS WHERE ...
Switchover
SQL

SQL
REDO
UPDATE TRANSACTIONS SET ...

19c
Start in new OPTIONAL
Oracle Home
Physical
Redo Convert to
Standby SQL> alter database recover
Logical Standby to logical standby keep identity;

45 Copyright © 2022, Oracle and/or its affiliates

Rolling Upgrade | DBMS_ROLLING

SQL> exec dbms_rolling.init_plan;

SQL> exec dbms_rolling.build_plan;
SQL> exec dbms_rolling.start_plan;

6 SIMPLE STEPS Upgrade database

SQL> exec dbms_rolling.switchover;

SQL> exec dbms_rolling.finish_plan;

46 Copyright © 2022, Oracle and/or its affiliates

 ...
Get current redo branch of the primary database
Wait until recovery is active on the primary's redo
branch
Rolling Upgrade | DBMS_ROLLING Reduce to a single instance if database is a RAC
Verify only a single instance is active if future
primary is RAC
Stop media recovery
Execute dbms_logstdby.build
Convert into a transient logical standby
Open database including instance-peers if RAC
Verify logical standby is open read/write
Get redo branch of transient logical standby
Get reset scn of transient logical redo branch
Configure logical standby parameters
Start logical standby apply
SQL> exec dbms_rolling.init_plan; Enable compatibility advance despite presence of GRPs
SQL> exec dbms_rolling.build_plan; Log pre-switchover instructions to events table
SQL> exec dbms_rolling.start_plan; Record start of user upgrade of PROD2

86+ INSTRUCTIONS OR CHECKS

Verify database is in OPENRW mode
Record completion of user upgrade of PROD2
Upgrade database Scan LADs for presence of PROD1 destination
Test if PROD1 is reachable using configured TNS service
Call broker to enable redo transport to PROD2
SQL> exec dbms_rolling.switchover; Archive all current online redo logs
SQL> exec dbms_rolling.finish_plan; Archive all current online redo logs
Stop logical standby apply
Start logical standby apply
Wait until apply lag has fallen below 600 seconds
Notify Data Guard broker that switchover to logical
standby database is starting
Log post-switchover instructions to events table
Switch database to a logical standby
Notify Data Guard broker that switchover to logical
standby database has completed
47 Copyright © 2022, Oracle and/or its affiliates
Wait until end-of-redo has been applied
...
Summary

48
 Benefits of Implementing Oracle Active Data Guard

• Most comprehensive and economical solution

• Continuous service

• Simple to implement and manage

• Efficient network utilization

• Complete data protection

• Elimination of idle standby systems

• Flexible configurations

• Centralized management:

• Excellent ROI

49
 Oracle Active Data Guard
Actively protecting data towards the future both on-premises and in the cloud

• Active Data Guard Real-Time Cascade • Updates on ADG (DML Redirect)

• Fast Sync • Finer granularity Supplemental Logging
• Broker for Cascaded Standby Databases • Flashback Standby when Primary database is flashed back
• Resumable Switchover Operations • In-Memory Column Store on Multi-Instance Redo apply
• Rolling Upgrade Using Active Data Guard • Observe only mode for FSFO 21c
• Single Command Role Transitions • Propagate Restore Points from Primary to Standby site
• Data Guard Broker PDB Migration or Failover • Simplified Database Parameter Management
• Multi-Instance Redo Apply • Dynamically Change FSFO target
• Zero Data Loss at any distance – Far Sync
• Protection During Database Rolling Upgrade • Standby Result Cache preservation
• Password Files Synchronization
• Oracle Database In-Memory on Oracle Active Data Guard
19c • Fast Start Failover Configuration
Validation & Call Outs
• Preserving Application Connections During Role Changes • Data Guard Broker Client Side
• Application Continuity (ADG or RAC) Standardized Directory Structure
18c • Data Guard Broker Far Sync Instance
Creation
12c • Fast Start Failover Lag Allowance in Max
11.2 • Automatic Correction of Non-logged Blocks
Availability Mode
• FarSync for Max Performance Mode
at a Data Guard Standby Database
• PDB recovery isolation
• RMAN recover standby simplification
• Configurable Real-Time Query Apply Lag Limit • Shadow Lost Write Protection
• Integrated Support for Application Failover • Transparent Application Continuity
• SPA Support for Active Data Guard Environment
• AWR reports for the standby workload
• Support Up to 30 Standby Databases

50 Copyright © 2022, Oracle and/or its affiliates

Thank you

51 Copyright © 2022, Oracle and/or its affiliates