When you create a new pluggable database (PDB) in your primary, the PDB will not automatically be created in the standby. This is because all the background steps to create this PDB, like creating datafiles (this is pretty much all a PDB is), does not generate redo. That’s why you will see your PDB in your standby, but no data files live there.

Besides that, the moment you create this pluggable database your standby will get out of sync. This is because your standby sees the new PDB as an orphan PDB and misses datafiles.

In this article I will show you how to create your PDB in your standby and get it back into sync. To do this I will assume the following things:

• You are using Oracle 19c (23c with data guard will probably be different)
• The data guard pair is functioning
• Your using the data guard broker
• You’re using RMAN with a catalog (this is what is used, did not test without)

Lets get this PDB back to his standby friends. Enjoy the ride.

Create a backup

Since we will be using RMAN get the PDB in the standby, there must be a backup to request. So first create a full backup of your PDB or your CDB. I will not put the steps here, but it will be something like ‘backup (pluggable) database’

Stop standby from syncing

The standby will probably already be out of sync, so lets now stop the standby from trying to apply redo. I’m used to do this both in the CDB$ROOT and in the data guard broker.

Execute the following command in the CDB$ROOT:

SQL> alter database recover managed standby database cancel;

Execute the following command in the data guard broker:

DGMGRL> edit database <STANDBY DB> set state='APPLY-OFF'

Now the standby has been cut free from all chains of the primary. Freedom… isn’t it something.

Restore data files on the standby

The next step is to get all data files over from the primary to the standby using RMAN. I always use a catalog, so I will go into the RMAN catalog. Then you restore the pluggable database from the CDB$ROOT on the primary database. To do this we will be using the service of the primary CDB$ROOT.

$ rman target / catalog /@<RMAN service>
RMAN> run {
restore pluggable database <pdb name> from service <CDB service>;
}

RMAN does its magic and when its done, the data files will available in the standby. Coming up next: getting the band back together.

Getting the band back together

The standby has been by itself for long enough. It’s time to get the band back together. Real freedom is not always cutting off all chains. The standby knows that now.

Sign into the standby CDB$ROOT to prepare to get syncing again. Then do some things to get the data files online and enable recovery for this PDB.

SQL> alter session set container=<pdb name>;
SQL> alter pluggable database datafile all online;
SQL> alter pluggable database enable recovery;

Then get back to the CDB$ROOT and get syncing again:

SQL> alter database recover managed standby database disconnect from session USING CURRENT LOGFILE;

Last but not least, enable the APPLY again in the data guard broker:

DGMGRL> edit database <STANDBY DB> set state='APPLY-ON';

After this, the standby should be applying the pending redo logs and be back in sync. If you request the database status in data guard broker, you should see something like this:

Intended State:     APPLY-ON
Transport Lag:      0 seconds (computed 0 seconds ago)
Apply Lag:          0 seconds (computed 0 seconds ago)

That was it. Thanks for reading through this article