Active Data Guard Concepts, Read-Only Workloads, Backup Offload, and Licensing Awareness

Learning outcomes

ServiceHub spends heavily on a disaster-recovery standby that sits mounted most of the year. Management asks to run reports and backups there. Basic Data Guard already permits important standby backup workflows, but Active Data Guard (ADG) adds separately licensed capabilities—most visibly real-time query, where a physical standby is open read-only while Redo Apply continues. That distinction must be enforced by architecture and license policy, not by whether a command happens to work.

1. Basic Data Guard protects; Active Data Guard also serves live read workloads during apply

A basic physical standby can be mounted while Redo Apply keeps it current. It can also be opened read-only when apply is stopped. The Active Data Guard real-time query feature allows the physical standby to remain open read-only while Redo Apply is active, so read workloads can use current applied data with a measurable apply lag.

SELECT  database_role,  open_mode,  protection_mode,  protection_levelFROM v$database;SELECT  name,  value,  time_computed,  datum_timeFROM v$dataguard_statsWHERE name IN ('transport lag','apply lag')ORDER BY name;SELECT name,role,applyFROM v$dataguard_processORDER BY name;

An expected ADG real-time-query state is DATABASE_ROLE='PHYSICAL STANDBY', OPEN_MODE='READ ONLY WITH APPLY', with MRP/redo apply active.

2. Current multitenant licensing has an important root/PDB distinction

The 26ai licensing manual explicitly says the standby CDB$ROOT may be opened read-only without an Active Data Guard license. However, opening any pluggable database (PDB) in the standby for reads requires Active Data Guard. Since ServiceHub data lives in FREEPDB1/application PDBs, useful application read offload is an ADG-licensed activity.

3. Read offload must include currency semantics

A standby query can be read-consistent at its own applied SCN yet still trail the primary. An application that writes to primary and immediately reads from standby can therefore observe an older business state unless the application/connection layer enforces a currency contract.

SELECT  name,  value,  datum_timeFROM v$dataguard_statsWHERE name IN ('transport lag','apply lag')ORDER BY name;SELECT current_scnFROM v$database;

Do not create a universal “apply lag must be less than 1 second” rule. Each read workload needs an explicit staleness tolerance, and critical read-after-write flows may need to stay on the primary or wait for a defined apply point.

4. RMAN backup offload is broader than real-time query

RMAN understands physical Data Guard environments. With a recovery catalog, backups created on a physical standby can be usable on the primary and vice versa, subject to media accessibility/association. This lets organizations offload backup I/O without requiring application queries on the standby.

rman target /BACKUP DATABASE  PLUS ARCHIVELOG  TAG 'SERVICEHUB_STANDBY_BACKUP';

The standby state determines whether a backup is consistent/inconsistent and therefore whether recovery is required. Keep the recovery catalog/media/key path synchronized across sites.

5. “Fast Incremental Backup on Physical Standby” is an ADG feature

Do not conflate ordinary standby RMAN backup with the separately licensed Active Data Guard Fast Incremental Backup on Physical Standby capability. The current licensing manual lists that optimization inside the ADG option. The same option also includes automatic block repair, Far Sync, real-time cascade, Global Data Services, Application Continuity and rolling-upgrade automation.

6. Automatic block repair is another ADG value proposition

With Active Data Guard real-time query, Oracle can transparently use a good copy of a corrupted block from the peer database for automatic block repair in supported scenarios. This is not a replacement for storage diagnosis or RMAN validation; it is an online repair capability layered on top of the HA topology.

7. Free licensing-awareness lab: prove the local environment is not a standby

SELECT  db_unique_name,  database_role,  open_mode,  protection_mode,  protection_levelFROM v$database;SELECT COUNT(*) AS dg_process_rowsFROM v$dataguard_process;SELECT COUNT(*) AS dg_lag_rowsFROM v$dataguard_stats;

On the ordinary Free primary you should see PRIMARY; lag rows are not expected on a primary. This lab teaches how to identify role/feature state without attempting to enable an unlicensed feature.

8. Design a read-service contract before offloading

9. Deliberately wrong: route every SELECT to the standby because “it's read-only”

Some requests depend on data just committed on primary; others invoke packages, sequences, temporary objects, session state or features whose behavior must be tested on read-only standby. Blind SQL routing can produce stale business decisions even while every query succeeds. Route by workload contract, not by SQL verb alone.

10. Production judgment

Use basic Data Guard for data protection and role transition where licensed. Add Active Data Guard when read/offload/repair/Far Sync/advanced HA capabilities justify the option cost. License both the primary and every standby using ADG features as required by Oracle's licensing rules; basic standbys that do not use ADG features do not automatically need the ADG option.

The mandatory course path stays Free and does not open a standby PDB. Lesson 5 now addresses the operational risk that remains even after topology/licensing are correct: determining when a failure is real, preventing two primaries, routing clients, and measuring failover/reintegration.

Authoritative references

• Getting Started with Oracle Data Guard — physical standby read-only and real-time-query distinction
• Oracle Active Data Guard Overview — ADG offload/repair capabilities
• Using RMAN in Data Guard Configurations — standby backup interchangeability
• Managing Physical Standbys — read-only/apply and block repair
• Licensing Information — ADG option contents and CDB$ROOT/PDB licensing rule