Oracle Multitenant Architecture Explained: CDB vs PDB vs CDB$ROOT (Simple Guide)

By

Oracle Multitenant Database: What the Heck Are All These Containers?

So you're diving into Oracle multitenant databases and you keep hearing about CDB this, PDB that, and a bunch of confusing container names? Yeah, I've been there. Let me break this down in a way that actually makes sense.

The Apartment Building Analogy (Because Who Doesn't Love a Good Analogy?)

Imagine Oracle multitenant architecture like an apartment building. Seriously, just bare with me here.

When Oracle talks about a CDB (Container Database), they're talking about the whole building. It's not a room you can walk into - it's the entire structure. All the plumbing, electricity, the foundation, the roof... everything that makes the building work.

Here's the thing though: you can't just "be in the building." You're always in a specific room or apartment. The CDB is just the name for the whole setup.

CDB$ROOT - The Manager's Office

Now, CDB$ROOT is an actual place you can be. Think of it as the building manager's office. When you log in as a database administrator, this is usually where you land. It's got all the important stuff - the master keys, the building blueprints, the records of all the tenants.

Wait, so CDB and CDB$ROOT are different?

YES! This ticks people up all the time (When I say people, I mean me)
  • CDB = the concept of the whole building
  • CDB$ROOT = the actual manager's office (a specific container)
You can connect to the database instance (the building) but you'll actually be placed in CDB$ROOT (the manager's office). You can't be "nowhere" - you're always in some container.

PDB$SEED - The Model Apartment

Every apartment building has that fancy model unit they show prospective tenants, right? That's PDB$SEED.

It's a template that Oracle uses to create new databases super fast. It's read-only (just like you can't actually live in the model apartment), and it's got all the basic stuff a new database needs already set up. When you create a new PDB, Oracle basically copies this template instead of building everything from scratch.

Pretty smart, huh?

PDBs - The Actual Apartments Where People Live

Pluggable Databases (PDBs) are where the magic happens. These are your actual databases - the apartments where your applications and data actually live.

Each PDB:

  • Has its own space and privacy (your data doesn't mix with other PDBs)
  • Looks like a completely normal Oracle database from the outside
  • Can be moved around (unplugged and plugged into different CDBs)
  • Has its own users, tables, and all that good stuff

So if you're running five different applications, you might have five PDBs in one CDB. They all share the same building infrastructure but keep their own stuff separate.

Why Did Oracle Do This?

Good question! Before multitenant architecture, if you had 10 different databases, you needed 10 completely separate Oracle installations. That's like having 10 separate houses when you could just have 10 apartments in one building.

With the multitenant setup:

  • Less overhead: One set of background processes instead of 10
  • Easier maintenance: Patch the CDB once, all PDBs get updated
  • Faster provisioning: Clone the seed to create a new database in seconds
  • Better resource usage: Share memory and CPU more efficiently

The Confusing Part About Connecting

Here's where it gets interesting. You've got a couple of options:

Option 1: Connect to the CDB (land in CDB$ROOT)

sqlplus sys/password@your_cdb as sysdba

When you do this, Oracle automatically puts you in CDB$ROOT. To see where you actually are:

SHOW CON_NAME;

Then you can switch to a specific PDB:

ALTER SESSION SET CONTAINER = your_pdb_name;

Option 2: Connect directly to a PDB (skip the manager's office)

sqlplus user/password@your_pdb_name

The Bottom Line

Think of it this way:

  • CDB = The whole building (not a place, just a concept)
  • CDB$ROOT = Manager's office (an actual container you can be in)
  • PDB$SEED = Model apartment (read-only template)
  • PDBs = Regular apartments (your actual databases)

Once you get this apartment building metaphor in your head, everything else starts making a lot more sense. Oracle just wanted to pack multiple databases into one efficient structure, and that's exactly what they did.

Hope this helps! Now go forth and stop being confused about containers.

Comments

Post a Comment

Popular posts from this blog

ORDS REST-Enabled SQL Service: How to Customize Response Format (Complete Guide)

By
Hello fellas!! 👋 Today's topic: Understanding the REST-Enabled SQL Service in ORDS and How to Customize its Response Format. REST-Enabled SQL Service in ORDS What is it? The REST-Enabled SQL service is an HTTPS web service that provides access to the Oracle Database SQL engine. You can POST SQL statements to the service. The service then runs the SQL statements against Oracle Database and returns the result to the client in a JSON format. Example: Making a Request When making a request to the REST-Enabled SQL Service, you typically get a response by default that looks like this: Sample Request curl --location 'http://localhost:8086/ords/<schema_alias>/_/sql' \ --header 'Content-Type: application/json' \ -u "user:dummySecret" \ --data '{ "statementText": "select sysdate from dual" }' Default Response Format ...
Read more

Introduction to Oracle Rest Data Services (ORDS) – A Beginner’s Guide

By
Image
Hey folks! Today, I want to introduce you to a tool that’s been part of my daily grind: Oracle REST Data Services, or ORDS. So, What’s ORDS? Basically, ORDS is a tool that lets you expose your Oracle database data as RESTful APIs . Instead of wrestling with complex backend code, ORDS makes it super easy to build and deploy APIs. With ORDS, your data becomes accessible from anywhere with just a few HTTP calls. Think of it as giving your database a direct, web-friendly voice. Why ORDS? 🌟 Imagine this: You’ve got an Oracle database packed with valuable data, and you want to make it accessible to an app, a web service, or another system. Usually, you’d need a whole backend to handle data retrieval, authentication, response formatting… you name it. But with ORDS? You just set it up, map it to your database tables or procedures, and voilà—you’ve got an API that you can call from anywhere. Here’s why ORDS is a game-changer: It’s Fast ⚡: You don’t have to build a backend from scratch. It’s...
Read more

ORDS vs C# for REST APIs: Which is Easier? (Side-by-Side Comparison)

By
ORDS vs C# for Building REST APIs: Which is Easier? If you've ever built REST APIs using commonly used programming languages, you know the drill: create models, wire up a controller, connect to a database, map DTOs, validate, inject dependencies… and that's before you even touch the security aspect of the API. 😅 Being a past C# lover, I started questioning how easy it was to build REST APIs in ORDS compared to C#. Spoiler: ORDS is crazy simple for the basics. Let me show you a side-by-side comparison using the same use case — managing a Country table — without diving into security (we'll ignore auth and tokens and just focus on the REST experience). Use Case We want to expose the following operations via REST: GET /countries — list all countries GET /countries/{id} — get one country POST /countries — create a new country ...
Read more