Oracle AI Database 26ai: Data Guard at the PDB Level

Oracle AI Database 26ai introduces important enhancements to Data Guard for Pluggable Databases (DG PDB), making PDB-level disaster recovery easier to configure and manage. Instead of protecting only an entire Container Database (CDB), DBAs can configure Data Guard protection for individual PDBs across two CDBs that remain primary databases at the container level.

This is particularly useful for multitenant environments where individual applications or business services require independent disaster recovery.

Oracle introduced PDB-level Data Guard in an earlier release; 26ai builds on it with simplified management, DBCA support, new DBMS_DG APIs, and additional operational capabilities.

Reference: Oracle-Base — Data Guard Setup Using Broker in Oracle AI Database 26ai | Oracle Documentation — DG PDB Scenarios

1. Architecture: Protect an Individual PDB

In this example, we will use p_deeds_pd1 as the PDB name.

Source CDB: aicdb
Target CDB: aicdrdb
Protected PDB: p_deeds_pd1
Management: Oracle Data Guard Broker (DGMGRL)
Replication: Redo transport and apply at the PDB level

Both CDBs remain primary databases. Data Guard protects the selected source PDB by maintaining its corresponding target PDB in the other CDB as a physical standby. This allows other PDBs in either CDB to operate independently of the protected PDB’s Data Guard role.

2. Prepare the Data Guard Broker Configurations

First, configure and enable a Data Guard Broker configuration for each CDB using the standard database-level setup described in the Oracle-Base article.

At a high level, the environment requires:

Network connectivity and working Oracle Net connect identifiers.
Compatible Oracle Database versions and configurations.
Appropriate logging, recovery, and storage configuration.
Data Guard Broker enabled on both CDBs.
A broker connection between the two configurations.

For example, on each CDB:

ALTER SYSTEM SET DG_BROKER_START = TRUE SCOPE = BOTH;

Create and enable the broker configurations for the source and target CDBs, then establish the connection between them using the DG PDB broker workflow.

3. Prepare Both CDBs for PDB-Level Protection

Connect to the broker and prepare the configurations for DG PDB operations.

DGMGRL> EDIT CONFIGURATION PREPARE DGPDB;

This operation prepares the broker-managed infrastructure required for PDB-level protection. Follow the prompts for the internal DGPDB_INT account on the respective CDBs.

Important: The broker configurations must already be created, connected, and enabled. This is not the same workflow as simply adding a conventional physical standby CDB.

4. Configure Data Guard for `p_deeds_pd1`

On the source CDB, use the broker to instantiate the target PDB and associate it with the source PDB.

The general command structure is:

			
DGMGRL> ADD PLUGGABLE DATABASE p_deeds_pd1
         AT aicdrdb
         SOURCE IS p_deeds_pd1 AT aicdb
         PDBFILENAMECONVERT IS
         "'<source_file_path>','<target_file_path>'";

		

Replace the example file paths with the actual source and target storage locations. Configure any required keystore credentials and other PDB creation options for your environment.

The broker validates the source and target configuration and manages the target PDB’s Data Guard relationship.

Note: The command above illustrates the structure. Validate the exact syntax, storage conversion, and credential requirements against your installed 26ai release before executing it.

5. Enable Redo Apply and Verify the PDB

Once the target PDB has been instantiated, enable managed apply:

			
DGMGRL> EDIT PLUGGABLE DATABASE p_deeds_pd1
         AT aicdrdb
         SET STATE = 'APPLY-ON';

You can inspect the protected PDB directly:

			
DGMGRL> SHOW PLUGGABLE DATABASE
         p_deeds_pd1 AT aicdrdb;

The output should identify the PDB’s Data Guard role, source, transport lag, apply lag, intended state, and apply status.

For a healthy physical standby, look for:

			
Data Guard Role: Physical Standby
Intended State:  APPLY-ON
Apply State:     Running
Pluggable Database Status:
SUCCESS

		

Actual lag values and other output fields depend on workload, redo transport, and the state of the environment.

6. Validate the PDB Open Mode in SQL*Plus

Connect to the appropriate CDB and verify the PDB’s open mode:

			
SELECT name, open_mode
FROM   v$pdbs
WHERE  name = 'P_DEEDS_PD1';

For the source PDB, the expected mode is typically READ WRITE.

On the target CDB, a physical standby PDB can be mounted while redo is applied, or available for read-only access where the supported configuration and licensing permit it.

In an environment with Active Data Guard support, the target can be open read-only while redo apply continues. Verify the actual mode and apply state rather than assuming that READ ONLY alone confirms active recovery.

7. Monitor the Data Guard Configuration

Use these broker commands during routine DBA operations:

			
DGMGRL> SHOW CONFIGURATION;
DGMGRL> SHOW ALL PLUGGABLE DATABASE
         AT aicdb;
DGMGRL> SHOW ALL PLUGGABLE DATABASE
         AT aicdrdb;
DGMGRL> SHOW PLUGGABLE DATABASE
         p_deeds_pd1 AT aicdrdb;

		

Monitor the following indicators:

Data Guard Role: Confirms whether the PDB is primary or standby.
Transport Lag: Indicates the delay in transporting redo.
Apply Lag: Indicates how far recovery is behind the source.
Apply State: Confirms whether managed redo apply is running.
Pluggable Database Status: Reports whether the broker considers the PDB configuration healthy.

A successful status check is a good starting point, but DBAs should also validate redo transport, application connectivity, and recovery behavior.

8. PDB-Level Switchover and Failover

One of the key benefits of DG PDB is that a role transition can be performed for the protected PDB without requiring a role transition of the entire CDB.

Before a planned switchover, validate the target PDB:

			
DGMGRL> VALIDATE PLUGGABLE DATABASE
         p_deeds_pd1 AT aicdrdb;

Review the validation results before proceeding. For an actual switchover or failover, use the corresponding SWITCHOVER TO PLUGGABLE DATABASE or FAILOVER TO PLUGGABLE DATABASE broker operation supported by the installed release.

Test these procedures in a non-production environment first, including application reconnection, service placement, recovery lag, and post-transition protection of the former source.

Conclusion

Oracle AI Database 26ai makes PDB-level Data Guard operations more practical for multitenant architectures. With Data Guard Broker, DBAs can configure, monitor, and transition protection for an individual PDB such as p_deeds_pd1, while the containing CDBs remain primary databases.

For organizations hosting multiple applications in a shared CDB, this provides a more granular disaster-recovery approach than treating the entire container as a single protection unit.

DBADEEDS