Oracle DBA Lesson 4 — Why Pluggable Databases Exist

Oracle DBA · Lesson 4

Why Pluggable Databases Exist

Separate application databases each want their own instance — memory, background processes, and admin. A CDB packs several PDBs behind one instance without merging their tables.

Watch on YouTube

Oracle DBA Lesson 4 — Why Pluggable Databases Exist

AI Ops Pro

The separate-database tax

When each application owns a complete Oracle database, each one needs an instance — SGA, background processes, and its own admin surface.

Repeat that for many applications and the memory, process overhead, and separate maintenance add up fast.

Container and pluggable databases

A container database (CDB) is an Oracle database that can hold several application databases.

A pluggable database (PDB) is one of those application databases. It keeps its own application data and object definitions (tables, columns, and the rest).

In the single-instance picture this series uses, one instance runs the whole CDB. Shared memory and background processes serve every PDB — without merging their tables. Each PDB keeps its own data, definitions, and local settings.

Root and seed

CDB$ROOT holds Oracle’s common system definitions that support the database as a whole.

PDB$SEED is a read-only template for creating new PDBs. Applications do not store their tables there.

What changes in operations

Adding another application PDB uses the existing instance. It adds data and workload — not another complete instance.

PDBs share the same Oracle software, so you can manage much of the infrastructure together (including software maintenance). A patch still needs the required database updates and checks for each PDB; updating binaries and restarting is not the whole job.

Applications still share resources. A busy PDB can affect the others, so capacity planning and resource limits stay on the checklist.

You can move a PDB to a compatible CDB, carrying its application data and definitions, without moving every other application with it.

Your session has a current container. Before you change a user, object, or setting, check whether you are in the root or the application’s PDB.

Commands to try

SHOW CON_NAME

Confirms the current container for this session (root vs a named PDB).

SELECT name, open_mode, restricted
FROM   v$pdbs
ORDER  BY name;

Lists PDBs visible to this instance and how each one is open.

ALTER SESSION SET CONTAINER = salespdb;

Moves the session into a named PDB (use your real PDB name). Work then applies in that container.

Gotchas

• Sharing an instance does not merge applications — each PDB keeps separate contents.
• Adding a PDB is not “another Oracle install”; it rides the existing CDB instance.
• Patching software is shared work; per-PDB database updates and checks still matter.
• Always know your current container before DDL, user changes, or parameter tweaks.

Quick quiz

Choose one answer per question, then submit. You’ll see the correct answer and a short why.

1. What is a pluggable database (PDB)?

A second instance that shares one SGA with the first An application database held inside a container database A read-only standby of CDB$ROOT Another name for PDB$SEED only

2. A single-instance CDB already has four application PDBs. You add a fifth. Do you need another complete Oracle instance?

Yes — one instance per PDB always Yes, unless you enable RAC No — the new PDB uses the existing instance Only if the PDB is named PDB$SEED

3. Where should an application store its tables in a CDB?

In its own application PDB Only in PDB$SEED Only in CDB$ROOT Split half in root and half in seed

4. Before changing a user, object, or setting in a CDB, what should you verify?

That PARALLEL is YES That undo is offline That every PDB is closed Whether the session is in the root or the application’s PDB

AIOps Pro

https://www.apps-dba.com/ https://x.com/AIOpsPro https://www.youtube.com/@AIOpsPro