Certain forms of PDB creation could become a little complicated in Data Guard configurations prior to 18c. Two of the most common provisioning operations – creating a new PDB from seed and creating a local cold clone work absolutely fine with Data Guard. Let’s walk through an illustration of this to understand what’s going on, as illustrated in Figure 1.

Here we see a high availability configuration with a primary CDB at the top, and a standby CDB at the bottom, with replication managed by Data Guard. We begin with a “new” CDB, with no customer-created PDBs. Only PDB$Seed is present in this initial state.

When we create a new PDB (from Seed), the create pluggable database operation replays successfully on the standby. This is possible because PDB$Seed – including its data files – is already present on the standby. The new PDB is created successfully on both the primary and the standby.

Similarly, a local cold clone (that is, a clone of a PDB already present in the primary and open read-only) will succeed – and replay successfully on the standby – because it is already present in the standby including all the data files necessary to process the operation.

However, for various reasons, some other provisioning operations are more complicated.

For example, a hot clone – that is, a clone of a PDB performed while the source PDB remains online (or in other words open read-write) – is complicated by the fact that there are two “recovery” operations involved at the same time. One is to ensure that the hot clone itself is transactionally consistent. The other is the application of redo on the standby, performed by Data Guard. These two “recovery” operations would interfere with each other, and to avoid that, a hot clone to a Data Guard primary will have no standby replica. This may be viewed as the functional equivalent to including the clause “standbys=none” in the hot cloning operation on the primary.

No issues with simple provisioning; additional steps required in more complex cases. 1. Create new PDB from Seed PDB$Seed present on standby Operation replays successfully 2. Local Cold Clone of PDB1 PDB1 present on standby Operation replays successfully 3. Hot Clone Implicitly performed with no standby 4. Plug-in or remote cold clone Source DataFiles not present on standby so operation cannot replay successfully PDB3 visible but unusable on standby(DataFiles offline) Data Guard recovery is halted

Figure 1. Provisioning operations in Data Guard configurations prior to 18c

For the purposes of this discussion, a remote cold clone, that is, a cold clone of a PDB in another CDB, is comparable to a plug-in of an unplugged PDB. In both cases, unlike creating a new PDB from Seed, or performing a local cold clone, by definition the data files for the newly created PDB are not already in the CDB. Therefore the complication in these cases is that, not only do we need to copy the data files for the new PDB into the primary CDB, we also need to copy them on to the remote CDB. Prior to 18c, there was no simple way to automate this transport of these data files to the standby. Therefore, prior to 18c, unless the data files are carefully pre-positioned on the standby, manually, although the PDB is created successfully on the primary, it is not successfully created on the standby and Data Guard recovery was halted until the situation could be rectified by manual intervention.

The complications just described are greatly simplified in 18c. This involves some additional one-time steps in the process of setting up the Data Guard environment and a simple procedure to follow in each of these formerly somewhat more complicated provisioning cases.

First, let’s discuss the additional one-time steps involved in Data Guard setup, as illustrated in Figure 2.

  1. We start by creating a self-referencing database link on the primary. This replays successfully on the standby to create a database link referencing the primary.
  2. Next, we set a parameter on the standby. This is named standby_PDB_source_file_DBLink and it should reference the database link created in the previous step.
  3. Finally, CDB$Root of the standby should be opened read-only. (Note that no Active Data Guard license is required if only CDB$Root is opened read-only on the standby.) This allows Data Guard to read the value of the parameter just specified. When a create pluggable database operation is replayed on the standby, but the required data files are not already present on the standby, those data files may be copied from the primary via this database link.

Additional one-time Data Guard setup steps enable standby to access files on primary. 1. Create self-referencing DB Link on primary Replays on standby to create DB Link which references primary 2. New parameter to set on standby: standby_PDB_source_file_DBLink Identifies DB Link created in previous step 3. Open standby CDB$Root read-only When a create PDB operation is replayed on standby, and required data files are not on standby, they are copied from primary across this link Standby CDB$Root may be read-only without requiring Active Data Guard

Figure 2. Additional one-time steps in Data Guard Setup

Now we introduce a simple new procedure employing what we refer to as a “transient no-standby PDB”. Following this procedure reduces what were formerly more complex provisioning operations to a few trivial steps.

For example, let’s say that our intention is to plug-in an unplugged PDB or to perform a remote cold clone. We want this new PDB to be named PDB3.

  1. We start by creating what is referred to as a “transient no-standby PDB”. To do this, simply include the clause “standbys=none” in the create pluggable database statement. The result of this is that on the standby, the transient PDB will be visible in mounted state but its data files will show as unnamed or offline.
  2. Next, we create the desired PDB – PDB3 – as a local cold clone of the transient no-standby PDB. This replays successfully on the standby by copying the PDB’s data files across the database link Identified by the parameter standby_PDB_source_file_DBLink.
  3. The transient no-standby PDB may now be dropped.

So, what was formerly a relatively complicated procedure is reduced to this simple 1-2-3, illustrated in Figure 3.

Plug-in or remote clone PDB as PDB3 1. Create “transient no-standby PDB” Either as PDB plug-in or remote clone Important: Include clause “standbys=none”

Figure 3. Simple PDB plug-in or remote clone using “transient no-standby PDB” with Data Guard

Follow this same, simple, 1-2-3 procedure for hot clones in high availability configurations protected by Data Guard.

  1. As before, the first step is to create the “transient no-standby PDB”, this time as a hot clone. Again, it’s important to include the clause “standbys=none” in the create pluggable database statement. Remember, the intention of a hot clone is to take the clone while the source remains online. Clearly, this requirement is met in this case.
  2. Next, we create the desired PDB as a local cold clone of the transient no-standby PDB. This replays successfully on the standby by copying the PDB’s data files across the database link Identified by the parameter standby_PDB_source_file_DBLink.
  3. The transient no-standby PDB may now be dropped.

As you see, now in 18c we can use this same, simple procedure, employing the “transient no-standby PDB” technique for provisioning operations which were formerly relatively complicated in Data Guard configurations.