Let’s quickly check what is required to achieve this together.

What is required to create a refreshable ?

Well, to create a remote (refreshable) clone you need at least a database link (whatever you are cloning from a single instance, Oracle RAC and/or Oracle Data Guard standby database). ideally, created though an isolated database user with appropriate CREATE SESSION and CREATE PLUGGABLE DATABASE system privileges.

To be more precise until Oracle RDBMS 19.27 a PUBLIC database link was even required because of

Bug 34723488  PDB REFRESH USING A NON-PUBLIC DB LINK FAILING WITH ERROR "ORA-04054"

Before you, ask … Yes, the database link is required even if you clone locally within the same container (formerly called a loopback database link) but this is not the subject for today’s post 🙂

How to provision a (refreshable) clone from standby?

This post does not replace the Oracle manuals! But tries to summarize some challenges we faced over the past years with this Oracle features.
Please refer to https://www.dbi-services.com/blog/managing-refreshable-clone-pluggable-databases-with-oracle-21c/ for for conceptual details about the refreshable clone feature.

Provisioning (or refreshing) a refreshable clone from a single-instance, RAC works out-of-the-box as long as you run it from primary database. However, when started on a standby it fails:

CREATE PLUGGABLE DATABASE PDB_TMR_001P FROM PDB_APP_001P@"CDB999_19e1298295ca4e68460d28d0cc00304a@CDB999_SITE2"
KEYSTORE IDENTIFIED BY "…#secret#..." INCLUDING SHARED KEY
PARALLEL 8
SERVICE_NAME_CONVERT=('PDB_APP_001P','PDB_TMR_001P')
REFRESH MODE MANUAL
STANDBYS=NONE"
 
PY-4011: the database or network closed the connection
ORA-00600: internal error code, arguments: [kcffo_init_df_hdr:badfuzzysrcfile], [262], [6010], [], [], [], [], [], [], [], [], []

According, to Oracle support we are trying to clone while an “hot backup” is running as explained by following article:

ORA-00600 [kcffo_init_df_hdr:badfuzzysrcfile] On Create Pluggable Database (Doc ID 2878586.1)

As we are cloning from an Oracle Data Guard Active standby, with ongoing recovery process all our database files are “FUZZY” except PDB$SEED as of it’s “immutable” state which correlates with the ORA-00600 first argument.

This can be verified through Oracle data dictionary dynamic performance view V$DATAFILE_HEADER:

SQL> SELECT database_role, open_mode FROM v$database;

DATABASE_ROLE		             OPEN_MODE
------------------------------ ------------------------------
PHYSICAL STANDBY	             READ ONLY WITH APPLY

SQL> SELECT con_id, fuzzy, checkpoint_change# FROM v$datafile_header;


    CON_ID FUZZY      CHECKPOINT_CHANGE#
---------- ---------- ------------------
         1 YES                   39212441
         1 YES                   39212441
         1 YES                   39212441
         1 YES                   39212441
         2 NO                    1683111
         2 NO                    1683111
         2 NO                    1683111
         3 YES                   39212441
         3 YES                   39212441
         3 YES                   39212441
         3 YES                   39212441
         3 YES                   39212441
         3 YES                   39212441

So. let’s try to cancel the recovery process using Data Groker command “SET STATE”

EDIT DATABASE 'CDB999_SITE2" SET STATE='APPLY-OFF'

Cancelling recovery process, leaves the database files in a consistent state

2025-08-18T09:20:46.148023+00:00
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
2025-08-18T09:20:46.149836+00:00
PR00 (PID:90495): MRP0: Background Media Recovery cancelled with status 16037
2025-08-18T09:20:46.149938+00:00
Errors in file /u01/app/oracle/diag/rdbms/cdb999_site/CDB999/trace/CDB999_pr00_90495.trc:
ORA-16037: user requested cancel of managed recovery operation
PR00 (PID:90495): Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 39213769
Stopping change tracking
2025-08-18T09:20:46.290601+00:00
Errors in file /u01/app/oracle/diag/rdbms/cdb999_site/CDB999/trace/CDB999_pr00_90495.trc:
ORA-16037: user requested cancel of managed recovery operation
2025-08-18T09:20:47.406889+00:00
Background Media Recovery process shutdown (CDB999)
2025-08-18T09:20:48.151897+00:00
Managed Standby Recovery Canceled (CDB999)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL

From now on, the database files are consistent as visible in V$DATAFILE_HEADER

SQL> SELECT con_id, fuzzy, checkpoint_change# FROM v$datafile_header;

    CON_ID FUZZY      CHECKPOINT_CHANGE#
---------- ---------- ------------------
         1 NO                   39213769
         1 NO                   39213769
         1 NO                   39213769
         1 NO                   39213769
         2 NO                    1683111
         2 NO                    1683111
         2 NO                    1683111
         3 NO                   39213769
         3 NO                   39213769
         3 NO                   39213769
         3 NO                   39213769
         3 NO                   39213769
         3 NO                   39213769

As per the attached evidences the database datafiles are consitent as of Oracle System Change Number 39213769 (alert*log “Recovered data files to a consistent state at change 39213769”) which matches (V$DATAFILE_HEADER.CHECKPOINT_CHANGE#)

From now on, any cloning tentative to provision a fresh clone from Oracle Data Guard Active standby database works. However, it requires comprehensive measures to disable and re-active recovery process.

As alternative; Daniel Overby Hansen proposes to convert the standby database to a snapshot standby. but this may not work to start a refresh at later stage (not tested).

How to refresh the refreshable clone ?

Well, same story as for provision a clone from standby, except that the error message is a bit more silly

ALTER PLUGGABLE DATABASE RCLON_TMR_002I REFRESH

ORA-65345: cannot refresh pluggable database

Alert*log snipped records recovery attempt but not “real error” message to identify the root cause:

Pluggable database PDB_TMR_001P closed
2025-08-18T10:01:20.246104+00:00
Applying media recovery for pdb-4099 from SCN 39285930 to SCN 39286036
Remote log information: count-1
thr-1,seq-294,logfile-+RECO/CDB999_SITE2/ARCHIVELOG/2025_08_18/thread_1_seq_294.396.1209463231,los-39285484,nxs-39285931,maxblks-9107
PDB_TMR_001P(18):Media Recovery Start
2025-08-18T10:01:20.249993+00:00
PDB_TMR_001P(18):Serial Media Recovery started
PDB_TMR_001P(18):max_pdb is 27
2025-08-18T10:01:20.341597+00:00
PDB_TMR_001P(18):Media Recovery Log +RECO/CDB999_SITE2/ARCHIVELOG/2025_08_18/thread_1_seq_294.396.1209463231
2025-08-18T10:01:20.638622+00:00

Actually, it took me a while to understand that the requested recovery SCN 39286036 (line “Applying media recovery for pdb-4099 from SCN 39285930 to SCN” ) was not available on standby database.
Indeed, Oracle expects to get this transaction “already” on the standby archived redo log.

This can be easily reproduced on a LAB by querying V$ARCHIVED_LOG on the as follows:

SELECT sequence#, first_change#, next_change# 
  FROM v$archived_log 
WHERE &scn BETWEEN first_change# AND next_change#
     AND standby_dest='NO';

So, we can’t start an “ALTER PLUGGABLE DATABSE <PDB_NAME> REFRESH” from Oracle Active Data Guard standby database as of Oracle database piggy backing feature and lazzy checkpoints :=).
Indeed, Oracle has no feature to force a log switch on primary while being connected to standby site.

Workarround: Force log switch on Oracle Active Data Guard primary database:

ALTER SYSTEM ARCHIVE LOG CURRENT

Wrap-up

Well, after all Oracle documented the behavior 🙂 IMHO, this issue deserved more than 3 lines in a Oracle support article:

Force log switch to Avoid ORA-65345 When Refreshing PDB Sourced From Active Data Guard Standby (Doc ID 2765472.1)

Oracle is working on an enhancement request to “fix” that

"32709955 - NEED TO REFRESH THE REFRESHABLE PDB FROM THE PHYSICAL STANDBY"

Last one but not least, the current functionality with aforementioned workaround appplied is only viable as long as you do not require the “auto-refresh” feature. Indeed, who wants to disable Oracle Data Guard broker LogApply/recovery process, force a log switch on primary database and manage to get the monitoring in-line ?

L’article Creating&Refreshing a refreshable PDB (from a Standby Database) est apparu en premier sur dbi Blog.