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
Post a Comment