Understanding Cascade Snapshot Cloning in Oracle Multitenant

Oracle Exascale supports sparse snapshots and fast cloning at the block level.

With Cascade Snapshot Cloning, you can create a clone from another clone:

Base PDB → Clone A → Clone B → Clone C

This is useful when you need many database copies for development, testing, or migration.

In this article, we will look at:

• How to create a cascade clone
• How to check the clone relationship
• How much storage the clones use
• What happens when an intermediate clone is deleted

Step 1: Create a Cascade Clone Chain

You can create a snapshot clone from an existing snapshot clone using the normal Oracle command:

CREATE PLUGGABLE DATABASE PDB01_A
FROM PDB01
SNAPSHOT COPY
KEYSTORE IDENTIFIED BY "xxxx";
CREATE PLUGGABLE DATABASE PDB01_B
FROM PDB01_A
SNAPSHOT COPY
KEYSTORE IDENTIFIED BY "xxxx";
CREATE PLUGGABLE DATABASE PDB01_C
FROM PDB01_B
SNAPSHOT COPY
KEYSTORE IDENTIFIED BY "xxxx";

The result is:

PDB01
   |
   +-- PDB01_A
          |
          +-- PDB01_B
                 |
                 +-- PDB01_C

Each clone can be used as the source for the next clone.

Check the Clone Relationship

You can use DBA_PDBS to see the relationship:

SELECT pdb_name,
       snapshot_mode,
       source_pdb_name
FROM dba_pdbs
WHERE pdb_name LIKE 'PDB01%';

Example:

PDB_NAME    SNAPSHOT_MODE    SOURCE_PDB_NAME
----------  ---------------  ----------------
PDB01       MANUAL           PDB01
PDB01_A     MANUAL           PDB01
PDB01_B     MANUAL           PDB01_A
PDB01_C     MANUAL           PDB01_B

This shows the complete chain:

PDB01 → PDB01_A → PDB01_B → PDB01_C

Step 2: How Much Storage Does a Clone Use?

One of the main benefits of Exascale snapshot cloning is low storage usage.

When you create a snapshot clone, Exascale does not copy the complete datafile.

Instead, the clone shares the existing blocks with its parent. New storage is used when blocks are changed.

You can check the storage usage with V$EXA_FILE:

SELECT con_id,
       full_path,
       space_used
FROM v$exa_file
WHERE full_path LIKE '%USER%'
ORDER BY con_id;

Example:

CON_ID  FULL_PATH                         SPACE_USED
------  ------------------------------   ----------
     4  .../DATAFILE/USERS.OMF...        3,221,250,048
     5  .../DATAFILE/USERS.OMF...          322,161,867
     6  .../DATAFILE/USERS.OMF...          322,161,867
     7  .../DATAFILE/USERS.OMF...          322,161,867

In this example:

• PDB01 uses about 3.2 GB.
• PDB01_A, PDB01_B, and PDB01_C use about 322 MB each.

The clones are much smaller because they do not contain a full copy of the original data.

Only the blocks that need to be different are stored separately.

Step 3: Change Data in the Downstream Clone

A snapshot clone works like a normal PDB.

For example, we can connect to PDB01_C and create a table:

ALTER SESSION SET CONTAINER = PDB01_C;
CREATE TABLE test_c (
    id INT
) TABLESPACE users;
INSERT INTO test_c VALUES (1);
COMMIT;

The change is made only in PDB01_C.

It does not change:

• PDB01
• PDB01_A
• PDB01_B

This means every clone can be used independently.

Step 4: What Happens When We Drop an Intermediate Clone?

Now we have:

PDB01 → PDB01_A → PDB01_B → PDB01_C

A common question is: What happens if we delete PDB01_B while PDB01_C still exists?

Let’s test it.

First, close PDB01_B:

ALTER PLUGGABLE DATABASE PDB01_B CLOSE IMMEDIATE;
DROP PLUGGABLE DATABASE PDB01_B INCLUDING DATAFILES;

Check the Remaining PDBs

SQL> show pdbs
    CON_ID CON_NAME  OPEN MODE  RESTRICTED
---------- ---------- ---------- ----------
...
         4 PDB01      READ WRITE NO
         5 PDB01_A    READ WRITE NO
         7 PDB01_C    READ WRITE NO

As you can see:

• PDB01_B is gone.
• PDB01_C is still available.
• PDB01_C is still READ WRITE.

We can also check the data that we created earlier:

ALTER SESSION SET CONTAINER = PDB01_C;
SELECT * FROM test_c;
ID
----------
1

The data is still there.

Why Does PDB01_C Still Work?

This is an important part of Exascale snapshot cloning.

When PDB01_B is deleted, Exascale does not simply delete every storage block related to PDB01_B.

Some of those blocks may still be needed by PDB01_C.

Exascale keeps the blocks that are still required by the downstream clone.

So, from a simple point of view:

Before:
PDB01
   |
PDB01_A
   |
PDB01_B
   |
PDB01_C

After dropping PDB01_B:

PDB01
   |
PDB01_A
   |
PDB01_C

PDB01_C can continue to use the blocks that it needs.

This is why deleting an intermediate clone does not automatically break the downstream clone.

Why Is This Useful?

Cascade snapshot cloning can be very useful for development and test environments.

For example, you can create:

Production-like PDB
       |
       +-- DEV
       |
       +-- TEST
       |
       +-- QA
       |
       +-- DEV → DEV_CLONE → DEV_TEST

You don’t need a full copy of the database for every environment.

This gives you several benefits:

• Fast cloning — new PDBs can be created quickly.
• Less storage — clones share existing blocks.
• Independent databases — each clone can be changed independently.
• Flexible cloning — a clone can become the source of another clone.
• Easy cleanup — an intermediate clone can be removed while downstream clones continue to work.

Monitoring the Clones

Two views are especially useful.

DBA_PDBS

Use DBA_PDBS to understand the clone relationship:

SELECT pdb_name,
       snapshot_mode,
       source_pdb_name
FROM dba_pdbs;

It tells you which PDB is the source of another PDB.

V$EXA_FILE

Use V$EXA_FILE to look at Exascale file information and storage usage:

SELECT con_id,
       full_path,
       space_used
FROM v$exa_file;

Key Takeaways

1. A clone can be used to create another clone.PDB01 → PDB01_A → PDB01_B → PDB01_C
2. Snapshot clones use much less storage than full clones because they share existing blocks.
3. Changes in a clone are isolated from its parent and other clones.
4. Deleting an intermediate clone does not necessarily break its child clone.In our example, deleting PDB01_B did not affect PDB01_C.
5. DBA_PDBS helps you see the clone relationship, while V$EXA_FILE helps you understand storage usage.