Synchronize new PDB to Standby

Follow

This page provides information on how Dbvisit StandbyMP synchronizes Pluggable Databases (PDBs) from Primary database to standby database.

Adding a snapshot pluggable database to primary is not supported for this process.

1. Introduction and Concept

Oracle SE2 Supports up to three pluggable database in 19c SE2 and only one PDB in prior versions. Dbvisit Alyways synchronizes the standby database on CDB level, so any change done in PDB is automatically reflected on standby.

Dbvisit StandbyMP also automatically synchronizes newly added PDBs on primary to the standby. This feature is by default enabled and is defined by three DDC parameters with following default values:

PDB_SYNC = Y
BCKDIR = [DBVISIT_BASE]/standbymp/oracle/backup
BCKDIR_DR = [DBVISIT_BASE]/standbymp/oracle/backup

Synchronization of newly added PDB (regardless whether it’s created as clone from another PDB, clone from PDB$SEED or plugged-in) is done in several steps:

  • detection that new PDB was added on primary database (if PDB_SYNC = Y)

  • backup of newly added PDB on primary database is done according to BCKDIR DDC parameter

  • transfer of PDB backup to standby database is done according to BCKDIR_DR DDC parameter

  • restore of PDB backup on standby database

The automatic standby update (ASU) is enabled and running during all those steps and all those steps are done automatically without user intervention.

If you plan to modify PDB configuration in your environment we highly recommend that you modify the default values for parameters BCKDIR and BCKDIR_DR.

For further explanation and how to change these parameters refer to:

DDC File Maintenance

2. Automatic PDB Synchronization Process

If your DDC parameter PDB_SYNC is set to Y value (default), then any PDB added on primary wil trigger automatically the PDB sycnhronization process in the background. For the PDB sycnhronization to succeed, you must ensure that the locations of BCKDIR and BCKDIR_DR have sufficient free space for the PDB backup.

The synchronization is automatically executed on primary whenever any PDB is added, for example running on primary:

SQL> create pluggable database pdb99 from pdb2;
SQL> alter system switch logfile;

Will result in automatic trigger of PDB sync task visible in the GUI:

image-20250225-101610.png

The backup will be done on primary server to location specified in BCKDIR. The backups taken are by default compressed RMAN backup (this is driven by DDC parameter RMAN_DBF_BACKUP_TYPE).

Your standby database is still synchronized in the background by archivelogs. They are still transferred and applied. This is possible because the new PDB datafiles on standby are excluded from recovery and will be shown as missing:

SQL> select file#,error from v$datafile_header where error is not null;
       163 FILE MISSING
       164 FILE MISSING
       165 FILE MISSING

Once the export job finished, PDB backup will be transferred to standby server to directory defined as BCKDIR_DR. Once the transfer is finished, PDB will be restored during next ASU archivelog apply job.

The transfer and restore jobs are not visible in the GUI

During the synchronization, following message will appear in log gap report:

image-20250225-104338.png

Even if log gap report indicates 0 gap, the standby database is now inconsistent because of missing PDB datafiles.

Standby database will become consistent again only after the PDB restore finishes. The v$datafile_header will no longer contain “FILE MISSING” in the ERROR column and log gap report will no longer include the Warning message.

Be mindful that recovery of standby database will be always successful and log gap report will always show 0 gap even though the new PDB files are completely missing on your standby server. You must ensure manually by checking v$datafile_header that no errors are found after the job completes and also by runing log gap report.

3. Manual PDB Synchronization Process

You can also use this procedure if by any chance the automatic PDB synchronization failed previously. In this case, leave PDB_SYNC = Y and continue with steps below

If parameter PDB_SYNC is set to N (non-default value) the newly added PDB on primary is not synchronized to standby. Note that the ASU transfer and appply job behavior after you add new PDB to your primary is the same as with the PDB_SYNC = Y:

Your standby database is still synchronized in the background by archivelogs, but it is inconsistent and you will not be able to use it until you sycnhronize the PDB manually

To manually synchronize the PDB to standby you have to manually run the dbvctl refresh_pdb function. The function has following syntax:

dbvctl -f refresh_pdb -d <ddc> [-a guid=<comma separated list of PDB GUID>]

An example how to manually synchronize PDB to your standby:

A. Disable Automated Standby Update (ASU) Post Tasks - Automatic Standby Update (ASU)

B. Determine the PDB ID on primary:

SQL> select guid from v$pdbs where name='PDB99';

GUID
--------------------------------
2EF5B88B32425203E063E708A8C097C0

C. Make sure that your DDC parameters BCKDIR and BCKDIR_DR point to appropriate location

D. Run the refresh_pdb procedure

On primary server run the refresh_pdb providing it with GUID of the PDB you want to synchronize:

$ /usr/dbvisit/standbymp/oracle/dbvctl -d SLASH -f refresh_pdb -a guid=2EF5B88B32425203E063E708A8C097C0

Example output:

PDB dbvctl Export
$ /usr/dbvisit/standbymp/oracle/dbvctl -d SLASH -f refresh_pdb -a guid=2EF669CE8B9D64EAE063E708A8C0DFA2
>>> Exporting PDB PDB99 GUID=2EF669CE8B9D64EAE063E708A8C0DFA2... done

Note FORCE_LOGGING is disabled in the primary database.

>>> Transferring Log file(s) from SLASH on czlin0231 to czlin0232:

    thread 1 sequence 4164 (o1_mf_1_4164_mvv90hod_.arc)... done

>>> Dbvisit Archive Management Module (AMM)

    Config: number of archives to keep      = 15
    Config: number of days to keep archives = 0
    Config: archive backup count            = 0
    Config: diskspace full threshold        = 0%
==========

    Total number of archive logs   : 16
    Number of archive logs deleted = 1

Starting Dbvisit Standby remotely on czlin0232...
Feedback will only be given once process has completed.
This may take some time. Please wait...
  Output of Dbvisit Standby on czlin0232:
  =============================================================

  >>> Applying Log file(s) from czlin0231 to SLASH on czlin0232:

      thread 1 sequence 4164 (1_4164_1189957379.arc)... done
  >>> Restoring PDB PDB99 2EF669CE8B9D64EAE063E708A8C0DFA2... done
      thread 1 sequence 4165 (1_4165_1189957379.arc)... done
      Last applied log(s):
      thread 1 sequence 4165

      Next SCN required for recovery 222434152 generated at 2025-02-25:12:06:02 +01:00.
      Next required log thread 1 sequence 4166

  >>> Dbvisit Archive Management Module (AMM)

      Config: number of archives to keep      = 15
      Config: number of days to keep archives = 0
      Config: diskspace full threshold        = 0%
  ==========

  Processing /u01/app/oracle/dbvisit_arch/SLASH...
      Archive log dir: /u01/app/oracle/dbvisit_arch/SLASH
      Total number of archive files   : 19
      Keeping archive logs required for recovery from thread 1: 4166
      Number of archive logs deleted = 4
  =============================================================
  Dbvisit Standby on czlin0232 completed.
Completed.

Once the export finishes, archivelog transfer and apply job will run automatically. Apply job will trigger restore job.

The PDB restore happens during this prompt:

Starting Dbvisit Standby remotely on czlin0232...
Feedback will only be given once process has completed.
This may take some time. Please wait...

After the restore and apply job complete, proceed to next step

E. Enable ASU

Have more questions? Submit a request

Comments