Oracle 19c: PDB‑to‑PDB Clone & Refresh Using Database Links (SE2)



A Practical Way to Refresh DEV and TEST from PROD

Refreshing DEV or TEST databases from PROD is something every DBA does regularly.

Traditionally, this meant using RMAN duplicate or Data Pump. Both approaches work, but they take time, consume storage, and often feel heavier than the problem itself.

From Oracle 12.2 onwards, a better option exists.

Refreshable PDB allows you to clone one PDB into another using a database link and keep it updated using redo. This feature is fully supported in Oracle 19c Standard Edition 2.

In this post, I walk through PDB to PDB cloning and refresh, along with the mistakes that usually cost the most time.

Why Use Refreshable PDB

Refreshable PDB changes how you think about cloning.

Instead of rebuilding environments repeatedly, you create once and refresh when needed.

It gives you

Faster refresh compared to RMAN or Data Pump
No export or import cycle
Minimal impact on production
Ideal for DEV, TEST, QA, and reporting
Works even in Oracle 19c Standard Edition

It behaves like a simplified version of Data Guard, without continuous synchronization.

Architecture Overview

Source database

CDB
PDB_PROD

Target database

CDB
PDB_CLONE which is refreshable

The clone is created from one PDB to another using a database link. During refresh, redo from the source is applied to keep the clone updated.

Prerequisites

Source Database

Oracle 19c running in CDB architecture
Source PDB must be in ARCHIVELOG mode
LOCAL_UNDO_ENABLED must be TRUE
PDB service must be configured

Run the following to validate

ARCHIVE LOG LIST;
SHOW PARAMETER local_undo_enabled;

Target Database

Oracle 19c CDB
Enough storage for the cloned PDB

Storage can be managed using either

Oracle Managed Files
or
FILE_NAME_CONVERT mapping

The Most Common Mistake

Common User Requirement

This is where most setups fail.

For remote PDB cloning, Oracle requires a common user. A local PDB user will not work, even if it has DBA privileges.

Why this matters

PDB cloning touches container level metadata
It interacts with control files
Redo is applied at container level

Because of this, the user must exist across the entire container.

Create Common User on Source

Connect to the source database as SYS

sqlplus / as sysdba
ALTER SESSION SET CONTAINER = CDB$ROOT;

CREATE USER C##PDBCLONE IDENTIFIED BY password CONTAINER = ALL;

GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE
TO C##PDBCLONE CONTAINER = ALL;

This user is now available in

CDB root
PDB seed
Source PDB

Configure TNS on Target Server

The database link must connect to the source PDB service, not the CDB.

Example entry in tnsnames.ora

MYPRD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = prod-host)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = pdb_prod.company.com)
)
)

Test connectivity

tnsping myprd

If this step fails, nothing else will work.

Create Database Link on Target

Connect to target CDB root as SYS

CREATE DATABASE LINK myprd
CONNECT TO C##PDBCLONE IDENTIFIED BY password
USING 'myprd';

Test the link

SELECT sysdate FROM dual@prod_link;

Create Refreshable PDB

Option 1 Using Oracle Managed Files

ALTER SYSTEM SET db_create_file_dest = '+DATA' SCOPE = BOTH;

CREATE PLUGGABLE DATABASE PDB_CLONE
FROM PDB_PROD@myprd
REFRESH MODE MANUAL;

Option 2 Using File Name Convert

CREATE PLUGGABLE DATABASE PDB_CLONE
FROM PDB_PROD@myprd
FILE_NAME_CONVERT
('/opt/oradata/PDB_PROD/', '/opt/oradata/PDB_CLONE/')
REFRESH MODE MANUAL;

Open the Clone

ALTER PLUGGABLE DATABASE PDB_CLONE OPEN READ ONLY;

A refreshable PDB must stay in read only mode while refreshing.

Refresh the PDB

ALTER PLUGGABLE DATABASE PDB_CLONE CLOSE;

ALTER PLUGGABLE DATABASE PDB_CLONE REFRESH;

ALTER PLUGGABLE DATABASE PDB_CLONE OPEN READ ONLY;

Check refresh status

SELECT * FROM v$pdb_refresh;

Alert Log Behavior

Refresh activity appears almost immediately once it starts.

Logs are written in the CDB alert log, not the PDB alert log.

You will typically see entries related to media recovery and foreign archive logs.

If nothing appears, the refresh likely never started.

Final Cutover if Needed

If you want to make the cloned database writable

ALTER PLUGGABLE DATABASE PDB_CLONE OPEN READ WRITE;

ALTER PLUGGABLE DATABASE PDB_CLONE REFRESH MODE NONE;

Important point

Once opened in read write mode, refresh is permanently disabled.

To refresh again, the PDB must be dropped and recreated.

SE2 Limitations to Keep in Mind

Maximum of three user PDBs per CDB

Not a replacement for Data Guard

No continuous synchronization

Cannot use refresh when the PDB is read write

Lessons Learned

Database link user must be common

Database link must point to the PDB service

Local users will fail with ORA errors

Oracle Managed Files makes life easier

Most errors are not bugs, they are design rules

Closing Thought

Refreshable PDB is one of those features that quietly improves your workflow.

Once the common user and database link are set up correctly, everything else becomes predictable.

Cloning becomes lighter
Refreshing becomes faster
And your environments stay closer to reality without repeated effort.

Jay

Comments

Popular posts from this blog

ASM Integrity check failed with PRCT-1225 and PRCT-1011 errors while creating database using DBCA on Exadata 3 node RAC

Lock Tables in MariaDB

Life is beautiful