Our team has been advocating the use of refreshable clone PDB for non-CDB to PDB migrations using AutoUpgrade. It is a great feature and our entire team loves it – so does many of the customers we work with.
However, in a recent non-CDB to PDB migration, we encountered some issues with refreshable clone PDB and AutoUpgrade.
Can My Target Container Database Be a RAC Database?
Yes, this works perfectly fine.
Be aware that CREATE PLUGGABLE DATABASE statement scales out on all nodes in your cluster. By default, the database also uses parallel processes, so potentially, this will put quite a load on the source non-CDB. Consider restricting the use of parallel processes using the AutoUpgrade config file parameter:
upg1.parallel_pdb_creation_clause=4
Since the creation scales out on all nodes, all nodes must be able to resolve the connect identifier to the source non-CDB. If you use an alias from tnsnames.ora, be sure to add that on all nodes. Failure to do so will lead to an error during the CREATE PLUGGABLE DATABASE command:
ERROR at line 1:
ORA-65169: error encountered while attempting to copy file
+DATAC1/SRCDB/DATAFILE/system.262.1178083869
ORA-17627: ORA-12154: TNS:could not resolve the connect identifier specified
ORA-17629: Cannot connect to the remote database server
What Happens If the Source Database Extends a Data File?
If the source database extends a data file – either through AUTOEXTEND ON NEXT or manually by a user – the target database extends the matching data file as well. Here is an extract from the target alert log when it extends a data file:
2024-08-27T07:01:26.671975+00:00
PDB1(4):Media Recovery Log +RECOC1/SRCDB/partial_archivelog/2024_08_27/thread_2_seq_4.276.1178089277
2024-08-27T07:01:32.773191+00:00
PDB1(4):Resize operation completed for file# 26, fname +DATA/TGTCDB_HBZ_FRA/20A568D1FD5DB0A6E0633D01000AC89B/DATAFILE/srctbs02.290.1178089287, old size 10240K, new size 1058816K
It works with smallfile and bigfile tablespaces.
What Happens If I Create a Tablespace on the Source Database?
The target database attempts to create the same tablespace.
For this to work, one of the following must be true:
- The target database can create the data file in the same location as the source.
- The target database uses Oracle Managed Files (OMF) using
DB_CREATE_FILE_DEST. - The target database can translate the data file location using
PDB_FILE_NAME_CONVERT.
If either one of the above isn’t true, you’ll receive an error during ALTER PLUGGABLE DATABASE ... REFRESH:
ORA-00283: recovery session canceled due to errors
ORA-01274: cannot add data file that was originally created as
'+DATAC1/SRCDB/DATAFILE/srctbs04.282.1178091655'
You can use PDB_FILE_NAME_CONVERT instead.
It works with smallfile and bigfile tablespaces.
What Happens If I Add a Data File to an Existing Tablespace?
The target database attempts to add a matching data file.
The target database must be able to translate the data file location according to the section above.
2024-08-27T06:51:19.294612+00:00
PDB1(4):Media Recovery Log +RECOC1/SRCDB/partial_archivelog/2024_08_27/thread_2_seq_4.276.1178088679
2024-08-27T06:51:20.268208+00:00
PDB1(4):Successfully added datafile 25 to media recovery
PDB1(4):Datafile #25: '+DATA/TGTCDB_HBZ_FRA/20A568D1FD5DB0A6E0633D01000AC89B/DATAFILE/srctbs01.289.1178088681'
What Happens If I Set a Tablespace Read-Only?
The refreshable clone PDB does not support this. Neither is going the other way: setting a tablespace read-write.
If you do so, the database reports an error:
alter pluggable database pdb2 refresh
*
ERROR at line 1:
ORA-00283: recovery session canceled due to errors
ORA-65339: unsupported operation on the source PDB
From the alert log:
2024-08-28T05:23:02.893946+00:00
PDB2(6):Error! unsupported source PDB operation: 21
2024-08-28T05:23:02.994035+00:00
PDB2(6):Media Recovery failed with error 65339
Operation 21 is setting a tablespace read-only. If you set a tablespace read-write, the database reports operation 20 instead.
PDB2(7):Error! unsupported source PDB operation: 20
You will not be able to refresh the PDB anymore. You must re-create the refreshable clone PDB.
What Happens If I Restart the Source Database?
Refreshable clone PDB does not support restarting the source database.
When you restart the source database, the source database places a special marker in the redo stream. This even happens for a clean shutdown (SHUTDOWN NORMAL). The target CDB does not understand how to recover beyond this marker.
alter pluggable database pdb2 refresh
*
ERROR at line 1:
ORA-00283: recovery session canceled due to errors
ORA-65339: unsupported operation on the source PDB
From the alert log:
2024-08-28T05:27:00.451985+00:00
PDB2(4):Error! unsupported source PDB operation: 3
2024-08-28T05:27:00.710236+00:00
PDB2(4):Media Recovery failed with error 65339
Operation 3 is the source database restart.
You will not be able to refresh the PDB anymore. You must re-create the refreshable clone PDB.
How Do I Drain My Source Database Before Migration?
Right before the migration, when you cut the connection from the source non-CDB to the target PDB, it could be useful to restart the database. But that’s not possible.
I suggest that you:
- Ensure that the target CDB connects to the source non-CDB using a dedicated service. This applies to the database link that you establish between the two databases.
- Stop all other services and specify a drain timeout.
- Shut down the application that connects to the source non-CDB.
- Kill sessions manually.
Remember that the target database connects to the source database via a database link, so stopping the database listener is not an option. Nor is enabling RESTRICTED SESSION.
Update: Armando managed to perform the migration using restricted session. Check his comment (see below) for details.
What Happens If I Restart the Target Container Database?
You can safely restart the target CDB while you have a refreshable clone PDB. This works fine.
What About NOLOGGING Operations?
You can’t perform NOLOGGING operations on the source database.
Since refreshable clone PDB relies on redo, then a NOLOGGING operation on the source will prevent that data from going to the target. When you try to query the NOLOGGING table on the target database after the migration, you will receive an error:
SQL> select count(*) from t1
*
ERROR at line 1:
ORA-28304: Oracle encrypted block is corrupt (file # 186, block # 131)
ORA-01110: data file 186:
'+DATA/TGTCDB_HBZ_FRA/20CF181D4A925E06E0633D01000ACB50/DATAFILE/srctbs01.297.117
8266961'
ORA-26040: Data block was loaded using the NOLOGGING option
Thanks to Marcelo for leaving a comment. He suggests that you set the source non-CDB in FORCE LOGGING mode. This is a good idea to avoid this potential nightmare:
alter database force logging;
You can read more about NOLOGGING operations in The Gains and Pains of Nologging Operations (Doc ID 290161.1).
What About Hot Backups?
You can’t perform hot backup operations on the source database.
If you do so, you’ll run into the following error:
2025-11-21T14:31:06.845676+00:00
SALES(4):Error! unsupported source PDB operation: 1
2025-11-21T14:31:07.845923+00:00
SALES(4):Media Recovery failed with error 65339
Please note that I’m not referring to RMAN online backups. I’m talking about the old-school ALTER DATABASE BEGIN BACKUP and ALTER DATABASE END BACKUP commands.
Any restrictions on data types or object types?
No. The refreshable clone is a physical copy of the database, so there are no restrictions on data types or object types.
Services
You must recreate your services after the migration. Neither database managed services nor Clusterware managed services survive the migration.
Further Readin
Summary
Despite these minor restrictions, migration from non-CDB to PDB using refreshable clone PDB and AutoUpgrade is still a very handy method. Knowing the restrictions upfront ensures that you can successfully migrate the database.
Happy migrating!
Databases Are Fun 