Hot Clone and CDB Resource Plan for a 40-PDB RAC CDB
CDB1 (19c) hosts 40 PDBs on a four-node RAC cluster with 32 CPU cores. Local undo is enabled. The SALES PDB is 2 TB and must be cloned to a new PDB named SALES_TEST for a weekend test. The source SALES PDB must remain open read/write during the clone, and there is no storage snapshot or Data Guard standby. The backup window is already saturated. The new PDB must live on a different ASM disk group with OMF enabled. Separately, one reporting PDB, REPORT, runs ad hoc queries that consume most of the cluster's CPU and I/O and delays SALES. You must cap REPORT at 30% CPU while guaranteeing SALES at least 50% of CPU during contention, and allow the other PDBs to share the remainder.
1. Which cloning method would you use, and what commands or options make it work while SALES is read/write?
Read the worked answer
Use a hot clone, not a cold clone or a backup-based duplicate, because SALES must stay read/write and there is no snapshot. With local undo enabled, 19c supports CREATE PLUGGABLE DATABASE sales_test FROM sales CREATE_FILE_DEST='+DATA2'; or FILE_NAME_CONVERT=('/asm/data/CDB1/SALES/','/asm/data2/CDB1/SALES_TEST/'). Run it from CDB$ROOT while SALES is open; Oracle reads a consistent image using SALES undo. OMF CREATE_FILE_DEST is the simpler choice for the different disk group. The operation still consumes I/O and CPU, so schedule it off-peak and monitor the source; a 2 TB clone is not instantaneous. If the clone must be remote, use FROM sales@clone_link; otherwise local is faster. After creation, open SALES_TEST with ALTER PLUGGABLE DATABASE sales_test OPEN;. A cold clone would require closing SALES and violate the requirement.
2. What post-clone steps are required before SALES_TEST is usable?
Read the worked answer
Verify the PDB is open read/write; check DBA_PDBS and PDB_PLUG_IN_VIOLATIONS; confirm tempfiles exist with DBA_TEMP_FILES and add one if the clone lacks a tempfile (ALTER PLUGGABLE DATABASE sales_test ADD TEMPFILE ...). Check that services, database links, directory objects, and external jobs do not point back to SALES. Because this is a PDB-to-PDB clone, do not run noncdb_to_pdb.sql; that script is for a non-CDB. If application schemas rely on fixed object IDs or environment-specific settings, adjust them in SALES_TEST only. Gather dictionary and system statistics if needed, and take a fresh backup of the new PDB before testing. Finally, assign a resource plan directive for SALES_TEST and confirm it is not accidentally using SALES' service. Test connectivity with a dedicated service and keep SALES_TEST out of production reporting until validated.
3. Design the CDB resource plan to meet the CPU and I/O constraints, and explain which parts are hard limits versus proportional.
Read the worked answer
Create a CDB resource plan in a pending area. For REPORT set UTILIZATION_LIMIT => 30 to cap CPU at 30%, and for SALES give a high SHARES value relative to REPORT and the other PDBs. Shares are proportional, not a hard 50% floor: under CPU contention SALES gets its share of the CPU, but if SALES is idle the other PDBs can use the CPU. UTILIZATION_LIMIT is the hard ceiling; SHARES is the soft priority. Activate the plan with ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='CDB_PLAN'; at the CDB level and verify with V$RSRC_PDB_METRIC. The CDB plan directly manages CPU and parallel servers; I/O limits require I/O Resource Manager, for example Exadata IORM, and are not created by SHARES. If the business truly needs a hard 50% CPU floor for SALES, use instance caging or a dedicated service and consumer group with reserved CPU, and document that shares alone cannot guarantee it.