What’s new in Oracle AI Database 26ai for Oracle Data Guard

Introduction

With the release of Oracle AI Database 26ai (26ai), DG gets meaningful enhancements that speak directly to real-world pains — hybrid setups, multitenant architectures, automation, operational simplicity.

In this post we’ll walk through 04 such major new bits in Data Guard for 26ai.

What’s new – at a high level

Before we dive deeper, here’s a high-level list of major enhancements in Data Guard for 26ai:

1. Hybrid cloud redo decryption — DG now supports mixed-encryption configurations (on-prem + cloud) with redo decryption. (Oracle Docs)
2. JSON output from DGMGRL — The Data Guard Broker command-line tool (DGMGRL) now supports JSON-formatted output, making automation and tool integration easier. (Oracle Docs)
3. Per-PDB Data Guard integration enhancements — In the multitenant CDB/PDB database, you now have finer control: individual pluggable databases (PDBs) can be protected/failed-over separately. (Oracle Docs)
4. Restrict switchover/failover candidates — The Broker property PrimaryDatabaseCandidates lets you define which databases may become primary during role transitions — non-candidates will be prevented unless override. (Oracle Docs)

Now, let us look at these 04 enhancements, individually.

Hybrid cloud redo decryption

Historically, when you run Data Guard between on-premises and cloud (or across clouds), encryption differences could have existed. For example: your on-prem primary may not be encrypted via TDE, but your cloud standby is. If redo transport passes encrypted blocks/logs, the standby has to handle this cleanly. If not, you risk failure, complexity (wallets, keys), or even inability to set up the standby.

With 26ai, DG now supports redo decryption in hybrid DR configurations: that means you can have a cloud database encrypted with TDE, an on-prem primary without it (or vice-versa), and DG will handle redo decryption at transport/apply time.

In 26ai, the new parameter is:

ALTER SYSTEM SET TABLESPACE_ENCRYPTION = AUTO_ENABLE
  SCOPE = BOTH;  -- or MANUAL_ENABLE / DECRYPT_ONLY

This can be set in the CDB root. (Oracle Docs)

Best practices

• One should encrypt both sides (on-prem and cloud).
• Ensure wallets / keystores are correctly managed – the standby needs access to the master key if the primary changes keys.
• Include the redo transport network in your encryption/delay calculations.

JSON output for DGMGRL

The SHOW CONFIGURATION; or SHOW DATABASE VERBOSE; commands provides a plaintext output requiring the need of additional scripting around it to get the output in the desired format.

In 26ai, you now have support for JSON-formatted output from the Data Guard Broker (via DGMGRL). That means easier integration with automation (Ansible, Terraform, custom scripts), better parsing, easier alerts/reporting. (Oracle Docs)

You can now pipe output into jq, PowerShell etc using the OUTPUTFORMAT switch.

DGMGRL> SHOW CONFIGURATION SET OUTPUTFORMAT JSON;

Benefits

• Automation scripts become more robust (no fragile regex).
• Integrations with DevOps tooling (CI/CD pipelines, alerting) are easier.
• You can capture structured data: e.g., role, transport lag, apply lag, target lag, etc.

Per-PDB Data Guard integration enhancements

In 26ai, DG now gives more options for per-PDB protection and failover.

Benefits

• Simplified setup and validation for DG PDB operations. (Oracle Docs)
• The Database Configuration Assistant (DBCA) supports PDB operations in DG environments: for example you can create a remote PDB clone as a standby.
• New DBMS_DG APIs to support common DG PDB operations (think: add/remove PDB from config, switch/transition PDB).
• Automatic addition of temporary files for PDBs during role transitions, improved housekeeping. (Oracle Docs)
• The PDB-level target can be open for query off-loading (Real-Time Query feature at PDB level) under DG.

Best practices:

• Identify which PDBs in your CDB have different SLAs or workloads – separate them logically (even if physically in same CDB) and apply per-PDB DG accordingly.
• Test failover at the PDB level.
• Monitor PDB-specific metrics: redo lag, apply lag, transport lag at the PDB level.
• Clean housekeeping: temporary files, service registration changes, make sure standby PDBs are correctly configured.

Restricting switchover/failover candidates

In large environments with many standby databases, sometimes you want to control which standby can become primary. Maybe due to regulatory, business, or regional restrictions.

In 26ai, DG Broker introduces the PrimaryDatabaseCandidates property. You can list which databases are eligible to become primary during a switchover/failover. You can also define an override mode for emergency transitions. (Oracle Docs)

DGMGRL> EDIT CONFIGURATION SET PROPERTY PrimaryDatabaseCandidates = 'StandbyDB1,StandbyDB2';
DGMGRL> SHOW CONFIGURATION;

Then SHOW DATABASE verbose will show the current list and if a standby not on the list tries to take over, it’ll be prevented unless you invoke the override command (maybe FORCE FAILOVER OVERRIDE).

Best practices

• Review your business and compliance needs: e.g., regional sovereignty, cost centre isolation, legal jurisdiction – map that into your candidate list.
• Document the override process clearly: when you’ll allow emergency failover of a non-candidate, how you log/approve it.
• Monitor the standby candidate list and ensure only current/healthy standbys are listed.

Conclusion

With Oracle AI Database 26ai, the new features of Oracle Data Guard would help DBAs to manade the modern architectures with hybrid cloud DR, multitenant PDB granularity, DevOps/automation output, and governance controls. These new features align with real-world operational gatchas: switching between on-prem and cloud seamlessly, managing large multitenant deployments, scripting rather than manual monitoring, and enforcing failover discipline.

Here’s what I think is the brief take away:

• In a hybrid DR scenario, look at the new redo decryption/hybrid encryption support.
• If you’re automating or integrating DG into pipelines, the JSON DGMGRL output would prove to be very helpful.
• If you use multitenant architecture (CDB/PDB) — the per-PDB DG enhancements provides more flexibility.
• The candidate restriction feature provides additional control in managing multiple standbys or governed failover environments.

Hope this helps!