Customers migrating large Oracle databases to Multitenant often choose refreshable PDB clones because they provide a low-downtime migration path. AutoUpgrade is especially helpful in this scenario because it automates much of the refresh and cutover workflow, reducing operational complexity. In addition, this approach keeps the source environment intact, providing a reliable fallback option if needed.

You can use this technique to migrate to a multitenant architecture while remaining on Oracle Database 19c, or while upgrading from 19c to 26ai and migrating to a multitenant architecture within the same downtime window. You can also use it simply to move a PDB to another container database, and want to reduce downtime and keep the source intact.

A recent customer case highlighted this perfectly:

• CLONEDB phase was completed in about 10–11 hours
• Each REFRESHPDB iteration took 7–12 hours
• Customer requirement was < 1 hour cutover
• The source workload continuously generated large amounts of archive redo logs

The root cause was not AutoUpgrade itself. The bottleneck was redo apply during refresh operations. AutoUpgrade automated the process correctly, but the refreshable clone still had to apply all generated redo before synchronization could complete.

Understanding the Problem

Refreshable PDB clones work by continuously applying redo from the source database to the target PDB.

During each refresh cycle:

1. Source archive logs are accessed
2. Redo is applied to the refreshable clone
3. Recovery catches the target PDB up to the source

In environments with:

• Heavy OLTP workloads
• ETL jobs
• High redo generation
• Continuous batch activity

…the refresh cycle can become extremely slow.

In the customer case:

“REFRESHPDB one iteration takes around 7–8 hours to complete with applying media recovery.”  

The alert log showed serial media recovery activity:

CAMP(4): Serial Media Recovery started

Why This Happens in 19c

In Oracle Database 19c, redo apply for refreshable PDB clones is effectively serial.

For the CREATE PLUGGABLE DATABASE command, there is the PARALLEL clause, and AutoUpgrade can control this using the parameter parallel_pdb_creation_clause.

There is no option to use PARALLEL with ALTER PLUGGABLE DATABASE REFRESH.

• AutoUpgrade does not control recovery parallelism
• The refresh operation depends entirely on the Multitenant media recovery behavior

This means:

More redo generated = More archive logs to process = Longer refresh windows.

Initial Customer Guidance

For 19c environments, the practical recommendations were:

Reduce Redo Generation – Not Always Feasible

Schedule refresh windows during:

• Weekends
• Maintenance windows
• Reduced batch activity

Pause:

• ETL jobs
• Reporting workloads
• Bulk data loads

Before final synchronization.

Consider Alternative Migration Paths – Using Data Guard (best approach for this use case)

Instead, for 19c with high redo log generation, customers can:

• Build a physical standby using Data Guard
• Perform a switchover/cutover
• Migrate to Multitenant using AutoUpgrade afterward

This avoids the refreshable clone redo bottleneck, since Data Guard can apply redo logs with parallelism.

What Changed in Oracle Database 23ai / 26ai

The good news is that Oracle engineering improved this behavior in newer releases.

Parallel recovery workers for refreshable PDB clone recovery were introduced beginning in the 23ai/26ai generation.

The recovery process now automatically uses parallel workers based on:

• CPU count
• Available slaves
• System resources

Meaning redo apply is no longer strictly serial for PDB Refreshable clones.

Hidden Parameter: _pdb_media_rcv_parallelism

There is also an internal parameter that controls PDB media recovery parallelism, and it’s on by default.

Important note:

• This is an underscore parameter
• It is undocumented
• Customers should not modify it without Oracle Support guidance

Why This Matters

This enhancement dramatically improves refreshable clone scalability for:

• Exadata migrations
• Multitenant conversions
• AutoUpgrade workflows
• Large redo generation environments

Summary

19c

Refreshable PDB clone redo apply is effectively serial.

Large redo generation can cause:

• Multi-hour refresh cycles
• Large lag accumulation
• Extended cutover windows

Recommended approach for high redo systems:

• Use Data Guard
• Cut over
• Migrate to Multitenant with AutoUpgrade

23ai / 26ai

Refresh operations now leverage parallel recovery workers automatically.

Benefits:

• Faster redo apply
• Reduced lag
• Improved refresh throughput
• Better scalability for large workloads