CDB Root, PDBs, Application Containers, Common vs Local Users, and Containers

Learning outcomes

ServiceHub has two teams sharing one Oracle installation. One administrator connects through the FREE service, sees a successful login, and starts creating application users and objects. The session is actually in CDB$ROOT, not the application PDB. Oracle multitenant makes container identity a first-class administrative boundary: before DDL, grants, recovery, monitoring, or service work, you must know which container owns the operation.

1. A CDB is one database engine with multiple container namespaces

A container database (CDB) is the multitenant database. CDB$ROOT is its root container and owns CDB-level metadata and administration. PDB$SEED is a read-only system-supplied template used to provision ordinary pluggable databases (PDBs). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to clients as a separate database.

Oracle AI Database 21c and later supports the multitenant architecture rather than the old non-CDB deployment model. The Free installation script creates CDB FREE and PDB FREEPDB1.

SHOW CON_NAMESELECT  SYS_CONTEXT('USERENV','CON_NAME') AS con_name,  SYS_CONTEXT('USERENV','CON_ID')   AS con_id,  SYS_CONTEXT('USERENV','SESSION_USER') AS session_user,  SYS_CONTEXT('USERENV','CURRENT_SCHEMA') AS current_schemaFROM dual;

A successful SQL connection proves authentication and service resolution; the CON_NAME evidence proves where database operations are scoped.

2. CON_ID is the container discriminator in multitenant metadata

Many dynamic performance and CDB_* views expose CON_ID. Root is container 1; the seed is normally container 2; user/application containers receive other IDs. Do not hard-code application logic around a particular numeric user-PDB ID—query the current mapping.

SELECT  con_id,  name,  open_mode,  restrictedFROM v$containersORDER BY con_id;SELECT  con_id,  name,  open_mode,  restricted,  total_sizeFROM v$pdbsORDER BY con_id;SELECT  pdb_id,  pdb_name,  status,  con_uid,  guidFROM dba_pdbsORDER BY pdb_id;

V$CONTAINERS/V$PDBS show runtime open state. DBA_PDBS.STATUS describes lifecycle integration state such as NEW or NORMAL; it is not the same field as open mode.

3. Common and local identities have different reach

A local user exists only in one PDB and is the normal identity for an application schema. A common user has an identity across a CDB or application container and can receive privileges commonly with appropriate CONTAINER=ALL semantics. Common and local roles follow a similar scope distinction.

By default, common user/role names use the prefix defined by COMMON_USER_PREFIX (commonly C##). Do not invent a common application account merely to make root DDL succeed.

SELECT name, valueFROM v$parameterWHERE name='common_user_prefix';SELECT  con_id,  username,  common,  account_statusFROM cdb_usersWHERE username IN ('SYS','SYSTEM','PDBADMIN','SERVICEHUB_OWNER','SERVICEHUB_APP')ORDER BY username, con_id;

4. Deliberately wrong: create a local application user while in root

SHOW CON_NAME-- CDB$ROOTCREATE USER servicehub_ch13_localIDENTIFIED BY "DisposableOnly9";-- With the default common-user naming policy this fails with:-- ORA-65096: invalid common user or role name

The error is a protection signal. In root, CREATE USER is interpreted in the common-user administrative context. Renaming the account to C##SERVICEHUB_APP would change the identity model rather than repair the application design.

ALTER SESSION SET CONTAINER=FREEPDB1;SELECT SYS_CONTEXT('USERENV','CON_NAME') AS con_nameFROM dual;CREATE USER servicehub_ch13_localIDENTIFIED BY "DisposableOnly9"QUOTA 5M ON users;GRANT CREATE SESSION TO servicehub_ch13_local;SELECT username, commonFROM dba_usersWHERE username='SERVICEHUB_CH13_LOCAL';DROP USER servicehub_ch13_local CASCADE;

Run ALTER SESSION SET CONTAINER only as an administrative/common identity with the necessary container privileges. Application clients should reconnect through the PDB service instead of switching containers.

5. Application containers add another hierarchy when one application is replicated across PDBs

An application container has an application root plus application PDBs. It can also have an optional application seed. Shared application metadata/data can be defined in the application root and synchronized into application PDBs through application install/patch/sync operations. This is useful for SaaS-style fleets, but it adds lifecycle/version coordination and is not needed for a single ServiceHub PDB.

6. Free licensing changes scale, not the identity model

The current 26ai licensing matrix includes Oracle Multitenant in Free and permits up to 16 PDBs. That does not turn 16 PDBs into 16 independent instances: they still share the one Free installation and its 2-core/2-GB limits, while all user data across the Free database remains subject to the 12-GB cap.

7. Reproducible mandatory lab: container identity card

-- Root connection, for example: sql / as sysdbaSELECT  SYS_CONTEXT('USERENV','CON_NAME') AS con_name,  SYS_CONTEXT('USERENV','CON_ID')   AS con_idFROM dual;SELECT con_id,name,open_mode,restrictedFROM v$containersORDER BY con_id;ALTER SESSION SET CONTAINER=FREEPDB1;SELECT  SYS_CONTEXT('USERENV','CON_NAME') AS con_name,  SYS_CONTEXT('USERENV','CON_ID')   AS con_idFROM dual;SELECT username,common,account_statusFROM dba_usersWHERE username IN ('SERVICEHUB_OWNER','SERVICEHUB_APP')ORDER BY username;

Expected evidence is a different CON_NAME/CON_ID after the administrative switch. This proves container context; it does not prove that a remote client will use the same service or PDB.

8. Production judgment

Make container identity part of every DBA runbook. Root is for CDB-level/common administration; local application schemas belong in their PDB. Use local users/roles by default for application isolation and common identities only when cross-container administration genuinely requires them. Log CON_ID/CON_NAME with privileged automation.

No pack, restart, or COMPATIBLE change is required. Lesson 2 adds the operational counterpart to identity: PDB open state and Oracle Net services determine whether clients can reach the intended container after instance startup.

Authoritative references

• Multitenant Administrator's Guide — CDB, PDB, application-container and container administration
• Support for Pluggable Databases — client/PDB multitenant model
• DBA_PDBS — PDB identity and lifecycle status
• Licensing Information — current PDB limits and Multitenant entitlement
• Licensing Restrictions for Free — Free CPU/RAM/storage/runtime restrictions