ORA-65198 During PDB Cloning – Tablespace Resize Restriction Explained

 

Overview: 

While performing a Pluggable Database (PDB) clone in Oracle 19c, DBAs may encounter restrictions on modifying tablespaces in the source database during the cloning process. This blog explains a real-world scenario where tablespace resizing was blocked with ORA-65198, the reason behind it, and how the issue was resolved. 

Environment Details: 

Database Version: Oracle 19c (19.25) 

Architecture: Multitenant (CDB / PDB) 

Source PDB: LIVE 

Target PDB: PREPROD 

Host: Preproddb 

Storage: ASM (+DATA) 

Cloning Setup

 Step 1: Verify Environment 

SQL > show pdbs; 

  CON_ID CON_NAME                       OPEN MODE  RESTRICTED

---------- ------------------------------ ---------- ----------

         2 PDB$SEED                       READ ONLY  YES 

Only PDB$SEED was open initially. 

Step 2: Create Database Link 

SQL > CREATE DATABASE LINK TESTSRC CONNECT TO PDBCLONE IDENTIFIED BY pdbclone USING '(DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=192.20.0.13)(PORT=1521))

  (CONNECT_DATA=(SERVICE_NAME=LIVE)(INSTANCE_NAME=CDBLIVE)))'; 

Step 3: Clone the PDB 

SQL > CREATE PLUGGABLE DATABASE PREPROD FROM LIVE@TESTSRC KEYSTORE IDENTIFIED BY PRE_PROD#2012# PARALLEL 8; 

The PDB clone was successfully initiated. 

Issue Encountered 

During the cloning process, the SYSUX tablespace in the source database started running out of space. An attempt was made to add a new datafile: 

SQL > ALTER TABLESPACE sysaux ADD DATAFILE '+DATA' SIZE 10G AUTOEXTEND ON NEXT 128M MAXSIZE 30G; 

❌ Error 

ORA-65198: operation not allowed on a PDB when it is being cloned 

Why This Happens 

When a PDB is being cloned: 

Oracle places internal locks on the source PDB 

Structural changes such as: 

Adding datafiles 

Resizing tablespaces 

Modifying storage metadata are not allowed

This ensures data consistency during the clone operation 

Even though the change was intended for the source, Oracle blocks it until the clone completes or is terminated. 

Resolution: 

Since the tablespace resize was urgent, the cloning session was terminated. 

After terminating the clone, the tablespace modification was retried: 

SQL >  ALTER TABLESPACE sysaux ADD DATAFILE '+DATA' SIZE 10G AUTOEXTEND ON NEXT 128M MAXSIZE 30G;

Tablespace altered.

The operation completed successfully once the clone lock was released. 

Key Takeaways for DBAs: 

✔ During PDB cloning, tablespace modifications are restricted

✔ ORA-65198 is expected behavior, not a bug

✔ Always ensure adequate free space in critical tablespaces (SYSTEM, SYSAUX, UNDO) before starting a clone

✔ Monitor space proactively during long-running clone operations

✔ If space issues occur mid-clone, the only option is to wait or terminate the clone

 Best Practices:

 Pre-check tablespace usage before cloning

 Enable autoextend with sufficient MAXSIZE

 Monitor alert logs during clone

 Schedule cloning during low-activity windows

 Conclusion:

 

Understanding Oracle’s internal locking mechanisms during PDB cloning helps avoid confusion and unnecessary troubleshooting. ORA-65198 is a protective restriction to ensure data integrity and should be handled through proper planning and monitoring.