Pluggable Database Snapshots with Oracle 21c

By Mouhamadou Diaw

In a previous blog , I talked about refreshable PDB technology which can be used to refresh a target PDB. The target PDB can be in mounted state (mandatory to be refreshed) or can be opened in a read only mode.

One application is to use the target refreshable PDB as a master to provide PDB snapshots.

A PDB snapshot is copy of a PDB at a given time. The source PDB can be open read-only or read/write while the snapshot is created.
The taken snapshot can be used to clone a full standalone PDB or can be materialized.

I am using the same configuration as in my previous blog (VM with XFS FS)
An Oracle 21c source CDB : DB21 with a source PDB PDB1
An Oracle 21c target CDB : TEST21 which will contain the refreshable clone of PDB1

From the refreshable PDB PDB1FRES, we can create for example 2 PDB snapshots
-DEVSNAP for the developers
-TESTSNAP for testing

Let’s do some change in PDB1

On TEST21 CDB, let’s do a refresh of PDB1FRES

We can verify that new changes on PDB1 are present on PDB1FRES

OK now let’s create the DEVSNAP snapshot from PDB1FRES

As specified in the documentation , the parameter cloned must be set to TRUE (as I am not using Exadata and a filesystem not supporting snapshots).
If the file system supports storage snapshots, then CREATE PLUGGABLE DATABASE … FROM … SNAPSHOT COPY copies a PDB from a source PDB, which can be read/write during the operation. The snapshot copy PDB files use copy-on-write technology. Only modified blocks require extra storage on disk. If the file system does not support storage snapshots or use Oracle Exadata sparse files, then the CLONEDB initialization parameter must be true, and the source PDB must be read-only for as long as the snapshot copy PDB exists.

Let’s set the parameter cloned to TRUE.

And let’s try to recreate the DEVSNAP

It works.

Now let’s do some basic operations on the snapshot DEVSNAP

-Open DEVSNAP on RW

-Query the table test

-Create a table on DEVSNAP

While DEVSNAP is open in RW,let’s open the source PDB1FRES in a RO mode

Let’s close again PDB1FRES and let’s refresh it with changes in PDB1 (remember that PDB1FRES is a refreshable PDB)

What happens? Let’s look the permissions files for PDB1FRES

If we compare these permissions to other PDBS

we can see that the permissions change for PDB1FRES datafiles since we create the snapshot.
Yes it’s a normal behavior. Looking into the following document

How To Safely Revert Back Datafile Permissions For Source PDB After Removing All Snapshot Clones (Doc ID 2627975.1)

We can read following lines

When a snapshot copy PDB is created from a source PDB using create snapshot copy pdb, the permissions of datafiles of the source PDB are changed to read only mode.
These datafile permissions are set to prevent accidental modification of the source PDB datafiles. Any modification of these datafiles will prevent snapshot copy PDBs depending on these datafiles from working correctly and consistently.

So if we want to refresh PDB1FRES after snapshot creation, let’s follow these steps

1-Remove all snapshot for this PDB1FRES

2-Restore datafiles permissions of PDB1FRES

We can verify that permissions are reverted

3-And then refresh

We can then recreate snapshots from PDB1FRES after refresh and so on.
Ok we saw that we can open the snapshots in RW and work on it as a normal PDB. What else we can do with the snapshots

1-We can use a snapshot as a source to clone a full PDB

And then drop the DEVSNAP

2-Materialize a snapshot copy

Materializing a snapshot copy PDB copies all data blocks. We can materialize a snapshot copy PDB by running an ALTER PLUGGABLE DATABASE statement with the MATERIALIZE clause.
When materialized, the snapshot copy will be transformed into a full pluggable database and will be no longer dependent of the source PDB

Conclusion

We have seen how refreshable PDB technology can be used with snapshots in a multitenant environment to provide PDBS for developers, for testing …
Hope this blog helps