Oracle Multitenant: Managing CDBs and PDBs in Production

Oracle Multitenant changed how we run databases. With the non-CDB architecture desupported, every database you create today is a container database — and knowing how to administer CDBs and PDBs cleanly is no longer optional. After consolidating dozens of single-purpose databases into multitenant containers for pharma, ERP, and banking workloads, this is the field guide I give my own teams: the concepts that matter, the commands you'll actually type, and the mistakes that bite in production.

1. The Core Idea: One Container, Many Databases

Before 12c, every Oracle database was a standalone instance with its own dictionary, background processes, and memory. Consolidating ten applications meant ten full databases — ten sets of overhead. Multitenant flips that:

• CDB (Container Database): the top-level container. It owns the shared redo, undo (in shared mode), background processes, and the Oracle-supplied data dictionary.
• PDB (Pluggable Database): a portable, self-contained database — your schemas, your data, your application — that plugs into a CDB and behaves like an independent database to the app.

One set of memory and processes now serves many databases. That is the consolidation win: lower overhead, faster provisioning, and simpler patching (patch the CDB once, every PDB benefits).

2. Anatomy of a CDB

Inside every CDB live a few special containers:

• CDB$ROOT — container 1. Holds Oracle metadata and common users. You don't put application data here.
• PDB$SEED — container 2. A read-only template Oracle uses to stamp out new PDBs quickly.
• Your PDBs — containers 3, 4, 5… each an application database.

Check where you are and what exists:

SHOW CON_NAME
SHOW CON_ID

SELECT con_id, name, open_mode FROM v$containers ORDER BY con_id;
SELECT pdb_id, pdb_name, status FROM cdb_pdbs ORDER BY pdb_id;

3. Moving Between Containers

The single most important habit: always know which container your session is in. Switching is instant:

-- connect to the root
ALTER SESSION SET CONTAINER = CDB$ROOT;

-- switch into an application PDB
ALTER SESSION SET CONTAINER = SALES_PDB;

-- or connect directly via a service / TNS entry that points at the PDB
sqlplus app_user@SALES_PDB

Each PDB registers its own service with the listener, so applications connect straight to their PDB without ever touching the root.

4. Creating PDBs

The fastest way is from the seed:

CREATE PLUGGABLE DATABASE sales_pdb
  ADMIN USER pdbadmin IDENTIFIED BY "StrongPass#2026"
  FILE_NAME_CONVERT = ('/u02/oradata/CDB1/pdbseed/',
                       '/u02/oradata/CDB1/sales_pdb/');

ALTER PLUGGABLE DATABASE sales_pdb OPEN;

On Oracle Managed Files (OMF) you can skip FILE_NAME_CONVERT entirely — Oracle places the files for you.

5. Cloning PDBs — the DBA's Superpower

Need a test copy of production? Clone it. This is where Multitenant earns its keep:

-- hot clone (source stays open) — great for refreshing test from prod
CREATE PLUGGABLE DATABASE sales_test FROM sales_pdb;

-- remote clone over a database link
CREATE PLUGGABLE DATABASE sales_test FROM sales_pdb@prod_link;

ALTER PLUGGABLE DATABASE sales_test OPEN;

On storage that supports snapshot/thin clones, add SNAPSHOT COPY and the clone is near-instant and space-efficient — you can hand developers a full copy of production data in seconds instead of hours.

6. Unplug and Plug: True Portability

A PDB can be unplugged from one CDB and plugged into another — even on a newer Oracle version, which makes it a clean upgrade and migration tool.

-- unplug to a manifest XML
ALTER PLUGGABLE DATABASE sales_pdb CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE sales_pdb UNPLUG INTO '/tmp/sales_pdb.xml';
DROP PLUGGABLE DATABASE sales_pdb KEEP DATAFILES;

-- plug into the target CDB
CREATE PLUGGABLE DATABASE sales_pdb USING '/tmp/sales_pdb.xml' NOCOPY;
ALTER PLUGGABLE DATABASE sales_pdb OPEN;

Always run the compatibility check before opening on a new CDB by querying PDB_PLUG_IN_VIOLATIONS — it tells you about version, option, or parameter mismatches before they bite.

7. Open, Close, and Save State

A classic rookie surprise: after a CDB restart, PDBs come up in MOUNTED state, not OPEN — unless you tell Oracle to remember.

ALTER PLUGGABLE DATABASE sales_pdb OPEN;
-- make it auto-open on every CDB startup
ALTER PLUGGABLE DATABASE sales_pdb SAVE STATE;

-- open / close all at once
ALTER PLUGGABLE DATABASE ALL OPEN;
ALTER PLUGGABLE DATABASE ALL EXCEPT sales_pdb CLOSE IMMEDIATE;

8. Multitenant on RAC

In a RAC environment you manage PDB open state per instance through services. Create a service bound to the PDB and let Clusterware manage where it runs:

srvctl add service -db CDB1 -service sales_oltp -pdb sales_pdb \
       -preferred CDB11 -available CDB12
srvctl start service -db CDB1 -service sales_oltp
srvctl status service -db CDB1

Applications connect to the sales_oltp service, never to an instance directly — that's what gives you transparent failover across nodes.

9. Resource Management Between PDBs

Consolidation means PDBs share CPU and I/O. Without guardrails, one noisy PDB starves the others. Use CDB Resource Manager shares and limits:

• Shares — relative CPU weighting between PDBs.
• Utilization limit — a hard CPU ceiling per PDB.
• Memory & sessions — per-PDB SGA_TARGET, PGA_AGGREGATE_LIMIT, and MAX_PDB_STORAGE caps.

Set a sensible CDB plan early. Retrofitting resource limits after a runaway PDB has already caused an incident is a much harder conversation.

10. Backup, Recovery, and the Data Dictionary

RMAN is fully container-aware. You can back up the whole CDB or individual PDBs, and recover a single PDB without touching the others:

RMAN> BACKUP PLUGGABLE DATABASE sales_pdb;
RMAN> RESTORE PLUGGABLE DATABASE sales_pdb;
RMAN> RECOVER PLUGGABLE DATABASE sales_pdb;

Remember the dictionary split: CDB_* views show objects across all containers (with a CON_ID column), while DBA_* views show only the current container. When a query "returns nothing," nine times out of ten you're simply in the wrong container.

11. Common Pitfalls

• Forgetting SAVE STATE — PDBs stay mounted after restart and apps fail to connect.
• Creating objects in CDB$ROOT — application objects belong in a PDB, never the root.
• Local vs common users — common users (prefixed C##) live across all PDBs; local users exist in one PDB. Mixing them up causes privilege confusion.
• Ignoring plug-in violations — always check PDB_PLUG_IN_VIOLATIONS after a plug or upgrade.
• No resource plan — one PDB monopolises CPU and the whole container suffers.

12. Production Best Practices

• One application per PDB — clean isolation, easy clone/refresh, simple chargeback.
• Use OMF — let Oracle manage file placement; fewer path mistakes.
• Standardise naming — PDB names, services, and TNS entries with a clear convention.
• Always SAVE STATE after opening a production PDB.
• Set a CDB resource plan before you consolidate, not after.
• Patch at the CDB level and use datapatch to apply SQL changes to all PDBs in one pass.
• Hot-clone for non-prod — give developers real data quickly and safely.

Final Thoughts

Multitenant is not "the same database with extra syntax" — it's a consolidation platform. Treated well, it slashes overhead, makes provisioning a one-line command, and turns upgrades into an unplug-and-plug exercise. Treated carelessly, it concentrates many applications onto one shared engine where a single misconfiguration affects everyone. The DBAs who thrive with Multitenant are the ones who respect the container boundary, plan resources up front, and always know which container their session is in.

If your team is consolidating onto Multitenant, migrating non-CDBs, or sizing a CDB for several workloads, let's talk. I've architected and operated multitenant consolidations across pharma, ERP, and banking environments and can help you do it without the usual surprises.

Related Articles