How does pluggable database isolation work?
In a Multitenant Architecture, the biggest concern for a DBA is "noisy neighbors." If one Pluggable Database (PDB) goes rogue—running a massive report that eats all the CPU or a "Cartesian join" that hoggs all the RAM—will it crash the other PDBs in the same building?
Oracle 19c handles this through Pluggable Database Isolation. It’s a multi-layered security and resource fence that ensures what happens in PDB "A" stays in PDB "A."
Even though PDBs share the same memory and background processes, they are logically "worlds apart."
Local Data Dictionary: Each PDB has its own private dictionary. If you are logged into PDB_Sales, you cannot see the tables, views, or users in PDB_Finance—even though they sit on the same disk.
User Separation: A "Local User" created in one PDB doesn't even exist in another. To cross the boundary, you must be a "Common User" (like C##ADMIN) with specific cross-container privileges.
Path Prefixing: You can restrict a PDB so it can only "see" or write files to a specific directory on the server, preventing one database from accidentally overwriting another's backups or logs.
Oracle uses the Instance Resource Manager to act as the "policeman" for CPU and Memory.
You can assign "shares" to each PDB.
If PDB_Prod has 3 shares and PDB_Test has 1 share, and both are fighting for CPU, Oracle will give 75% of the power to Production.
If Production is idle, the Test database can temporarily use the extra power—but the moment Production wakes up, it gets its 75% back instantly.
Starting in 12.2 and refined in 19c, you can set hard limits on memory per PDB using parameters like:
SGA_TARGET: Limits how much of the shared buffer cache one PDB can hog.
PGA_AGGREGATE_LIMIT: Ensures one PDB doesn't spawn so many processes that it crashes the entire server’s RAM.
In older versions, one PDB doing a massive "Full Table Scan" could saturate the disk throughput, making all other databases sluggish.
With I/O Resource Management (IORM), you can set limits on "IOPS" (Input/Output Operations Per Second) or MB/s. This ensures that your mission-critical PDB always has a "fast lane" to the disks, regardless of what the other PDBs are doing.
If a user in a PDB runs a command that causes an error (like an ORA-00600 internal error), Oracle is designed to contain that error within the PDB.
An "Application Error" will only crash that specific PDB session.
You can unplug or close a single PDB for maintenance while the other 50 PDBs in the same Container remain online and serving customers.
| Feature | Mechanism | What it prevents |
| Data Privacy | Local Data Dictionary | Users seeing other PDBs' tables. |
| CPU Power | Resource Manager Shares | One PDB slowing down the entire server. |
| Memory | MAX_PGA_SIZE / SGA_MIN | Out-of-memory errors caused by one PDB. |
| File Access | PATH_PREFIX | A PDB overwriting another PDB's files. |
| Connectivity | Service Names | Users connecting to the wrong "Apartment." |
Peer Tip: One of the most powerful isolation features is Lockdown Profiles. You can actually disable specific "dangerous" features (like
UTL_HTTPorALTER SYSTEM) for a specific PDB, so even a PDB Administrator can't mess with the server-level settings.