Pluggable Standby Databases in Oracle 26ai: Redefining Disaster Recovery and High Availability

Introduction

Data is valued like gold in this day and age. Engineers are being urged by numerous organizations to devote more time to AI projects. Businesses are attempting to optimize value, particularly with frameworks like MCP, as AI technologies and models are developing at a faster rate than ever before.

However, while focusing on AI, we shouldn’t overlook a critical foundation: database availability.

To truly benefit from AI, your data must be consistently available and protected. As more businesses move to the cloud, unexpected outages can still happen. On top of that, organizations regularly perform planned downtime activities, such as disaster recovery (DR) drills. This is where Oracle Data Guard continues to play a vital role by providing robust standby database capabilities and high availability.

In recent releases, starting from Oracle 21c and continuing into 26ai, Oracle has significantly enhanced Data Guard, especially in the pluggable database (PDB) space. In older versions, Data Guard configurations were managed strictly at the Container Database (CDB) level. This meant everything was all-or-nothing.

Now, Oracle gives us the flexibility to run read-write PDBs alongside standby PDBs within the same container. This is a true game changer.

I’ve seen many organizations consolidating multiple pluggable databases into a single container for efficiency. But when it came to switchover or failover, there was no flexibility; you had to fail over the entire CDB, even if only one PDB was affected.

Up until now, standby databases have been used for moving read-only workflows or snapshot standby or active standby for reporting. However, this affects the entire CDB; with the new read-write CDB, you can also have standby and read-write pluggable databases on the standby site. That’s why I’m really excited about these new capabilities. Being able to work with pluggable standby databases gives organizations much more control. It allows them to design granular DR strategies and make better use of Oracle licensing and infrastructure.

This is a big step forward in helping organizations balance AI innovation with reliable, highly available database systems.

This is the Oracle documentation for the features of the 26ai DG broker: https://docs.oracle.com/en/database/oracle/oracle-database/26/dgbkr/scenarios-using-dgmgrl-dg-pdb-configuration-23c.html

There are also several important commands required to prepare pluggable databases (PDBs) for standby protection in a Data Guard configuration.

In this blog, I will demonstrate how to configure a standby pluggable database (PDB) using Oracle Data Guard Broker.

For detailed documentation and additional reference, you can refer to the following official Oracle resources:

• Oracle Corporation Learn Tutorial: Data Guard per PDB

• Oracle Data Guard Broker Scenario Guide: Configure Data Guard Protection for Source PDB

These guides provide step-by-step instructions and background concepts that complement the configuration covered in this article.

Architecture Overview:

• Source: ORCLCDB (Primary for ORCLPDB1)

• Target: ORCLCDBS (Standby for ORCLPDB_DG)

• Goal: Protect ORCLPDB1 on ORCLCDB by replicating it to ORCLCDBS, while ORCLCDBS continues to host its own active PDBs.

Prerequisites

• Ensure network connectivity between the source and target hosts (for example, using VCN peering in a cloud environment).

• Two Oracle read-write database environments must be available (Oracle Database 26ai is required for full Data Guard PDB support).

• A separate standby CDB is not required to configure Data Guard for a pluggable database (PDB).

Task 1: Prepare the Databases:

Perform the following steps on both the source (ORCLCDB) and target (ORCLCDBS) container databases to prepare them for Data Guard configuration.

Note: This is emphasized again because ORCLCDBS is also a read-write CDB and must be configured accordingly.

Example: Preparing the Primary Database for Data Guard

Below is an example showing how to prepare a database for Data Guard using Data Guard Broker.

Sample output:

Wallet Configuration Requirement (21c and Above)

Starting from Oracle Database 21c and continuing in 26ai, the same SYS password must be used for wallet-based authentication. This simplifies connectivity and is a required step when configuring pluggable database environments.

First create wallet:

mkstore -wrl $ORACLE_HOME/dbs/wallets/dgpdb -create

Add sys credentials for easy access:

mkstore -wrl $ORACLE_HOME/dbs/wallets/dgpdb -createCredential ORCLCDB 'sys'

Sample:

After adding both database list the credentials:

mkstore -wrl $ORACLE_HOME/dbs/wallets/dgpdb -listCredential

Some of the Data Guard configuration will fail unless we use a wallet to hold the credentials, allowing us to connect without having to specify credentials manually. Add a wallet location into the “sqlnet.ora” file on both nodes.

Restart the listener on both nodes.

lsnrctl stop
lsnrctl start

Configure Data Guard Broker

Add the standby configuration to the source database configuration.

Enable the configurations on both nodes

Prepare the Databases for DG PDB

The Oracle Data Guard broker EDIT CONFIGURATION PREPARE DGPDB The command assumes that the source and target container database configurations are configured and enabled. Unlock and reset the password for the DGPDB_INT account for each of the container databases.

DG PDB Configuration

EDIT CONFIGURATION PREPARE DGPDB;

Sample output:

Add the Standby PDB

In this step, you will create the standby version of ORCLPDB1 on the target container database ORCLCDBS.

Before proceeding, it’s important to review the current Data Guard configuration to understand the existing setup.

Execute the following commands to verify the configuration and PDB status:

• SHOW CONFIGURATION;

• SHOW ALL PLUGGABLE DATABASE AT <Source>;

These commands will display the current Data Guard configuration along with the pluggable databases that are already part of the environment.

Run this on the Source (ORCLCDB)

Verify the PDB on Target (ORCLCDBS):

Instantiate the target PDB

The standby PDB currently does not contain any datafiles. These must be manually copied between the servers before proceeding. There are several methods available for this task, including RMAN datafile copies, the DBMS_FILE_TRANSFER package, and SCP.

In this example, we will use SCP to transfer the ORCLPDB1 datafiles to the appropriate location on the standby node for the ORCLPDB_DG database.

It’s recommended to execute begin backup before transferring the file using scp.

A separate article will be published detailing how to perform this process using RMAN, which is the preferred and most robust tool for backup and recovery operations.

Update Datafile Paths in Control File

After copying the data files, you must update the datafile locations to reflect the correct path in the standby environment. This ensures the control file points to the correct physical files.

Use the following SQL to rename the datafiles:

Important Note: A separate article will cover how to perform this process using RMAN, which is the preferred and more robust approach for backup and recovery operations, especially in production environments.

As part of the standby configuration, you must create standby redo log (SRL) files on the target pluggable database (ORCLCDBS) to support real-time redo apply.

Validate Existing Online Redo Logs:

Add Standby Redo Log Files

Create standby redo log groups with the same size as the online redo logs:

Enable Redo Apply:

Start the apply process using DGMGRL:

Validate the Apply process using dgmgrl:

Alter log sample:

Validate Managed Recovery Process (MRP)

To verify that redo apply is functioning correctly on the standby database, you can query the Managed Recovery Process (MRP) status using the following SQL:

Sample Output: Read-Write and Standby Pluggable Databases

The following example demonstrates a container database hosting both a read-write PDB and a standby PDB within the same environment:

Conclusion

In today’s world, data is often referred to as the new gold. Organizations are attempting to absorb AI architecture and MCP protocols in order to maximize our data. As companies accelerate their adoption of AI and modern frameworks, there has never been a greater need for reliable, always-available data platforms. But only when the underlying data infrastructure is reliable, safe, and always available can AI reach its full potential.

While businesses are rapidly moving to the cloud and embracing innovation, challenges such as unexpected outages and planned activities like disaster recovery (DR) drills remain unavoidable. This is where Oracle Data Guard continues to prove its importance by delivering robust high availability and data protection capabilities.

With advancements introduced from Oracle Database 21c through to Oracle Database 26ai, Data Guard has evolved significantly, especially in the pluggable database (PDB) space. Previously, Data Guard operated strictly at the CDB level, forcing an all-or-nothing approach for switchover or failover scenarios.

Organizations can manage individual PDBs independently thanks to per-PDB Data Guard capabilities. This offers more granular control and lessens the overall business impact during failures by enabling read-write PDBs and standby PDBs to coexist within the same container database.

By combining workloads while preserving high availability, this method also helps businesses to create more effective and optimized licensing strategies, since Oracle Database licensing can be expensive. Contact us today to find out more.  

In the next article, I will demonstrate how to perform pluggable database (PDB) switchover and failover using Oracle Data Guard Broker.