Oracle Data Guard is the solution that provides disaster recovery for the Oracle Database. Since the conception of the physical standby, Data Guard has been architected and perfected to work with the traditional (now desupported) non-CDB architecture.
The introduction of Oracle Multitenant in 12c in 2013 profoundly transformed the database architecture, unlocking new consolidation capabilities and easing the lifecycle of the databases. Multitenant architecture has evolved over the years to allow new operations, including hot clones, refreshable clones, online relocation, etc.
With the rise of highly consolidated environments, we face new challenges, typically regarding planned maintenance flexibility.
In 2022, we announced Oracle Data Guard per Pluggable Database (DGPDB), which was introduced as a preview in 21c and evolved in 23ai. It is designed to meet customers’ flexibility needs when using the most common architecture: a primary database with one asynchronous standby database.
A reminder of the traditional per-CDB architecture
Consider this picture showing classic Data Guard environments:
When a CDB is protected by Data Guard, one CDB is primary, and one CDB is a standby. Consequently, every PDB in the primary CDB will also be primary, and every PDB in the standby CDB will be a standby PDB. When the CDB transitions to a new role, all the PDBs simultaneously transition to the new role.
Planning a shared maintenance window for all the PDBs might be challenging in highly consolidated environments. Therefore, a solution that allows individual, per-PDB switchover is sometimes desirable.
What is Data Guard per Pluggable Database (DGPDB)?
As the name implies, DGPDB protects individual PDBs rather than the whole CDB.
A DGPDB configuration has two primary CDBs instead of one primary CDB and one standby CDB. Both CDBs contain primary PDBs protected by a correspondent standby PDB on the other CDB.
Having protection at the PDB level allows customers to independently switch over or fail over a PDB to the remote site.
There are four significant use cases for this configuration, all related to flexibility:
- Planned maintenance: Customers can drain a CDB for maintenance by switching over one PDB at a time.
- Workload rebalance: Customers can balance the workload between two sites with PDB granularity.
- Sick PDB protection: If a single PDB fails, it can individually fail over without impacting the current workload.
- Granular Disaster Recovery tests: The capability to fail over a single PDB makes testing the Disaster Recovery plans for individual applications easier without asking for broad downtime.
DGPDB is not a drop-in replacement for Data Guard, but a good alternative in specific situations. When should one use Data Guard vs. DGPDB?
Oracle Data Guard offers the best protection and advanced topologies for critical databases. It is a mature, feature-rich product that evolved over two decades.
DGPDB, on the other hand, is designed to provide granular PDB flexibility when using a single asynchronous standby database.
Therefore, the choice depends on recovery objectives, replication topology, database criticality, and consolidation strategy.
If RPO=0 is a strict requirement, or if the database requires protection from multiple standby databases, the classic Data Guard is the only choice.
Regarding the consolidation strategy, consider the following chart:
Mission-critical databases should be consolidated with caution or not consolidated at all. For these, Data Guard provides the best protection.
Less critical or non-production databases can have a higher consolidation. The flexibility of Data Guard per Pluggable Database is a better choice in this case.
Everything in between is a good candidate for both. The choice will fall between more comprehensive protection or higher switchover flexibility.
Curious? Try it out!
Here’s the official documentation: Scenarios for Using DGMGRL with a DG PDB Configuration