Home Oracle DB Oracle 19c Multitenant Architecture(CDB,PDB) – Tablespace , File Structure, Data Dictionary and...

Oracle 19c Multitenant Architecture(CDB,PDB) – Tablespace , File Structure, Data Dictionary and USER access


Data Dictionary Architecture in CDB and PDB

From the user and application perspective, the data dictionary in each container in a CDB is separate, as it would be in a non-CDB. Multitenant Architecture is built to meet following two requirements in storing data dictionary for multiple PDBs in a single CDB.

  • Reduction of Duplication.
  • Ease of Upgrade.

For example, the DBA_OBJECTS view in each PDB can show a different number of rows. This dictionary separation enables Oracle Database to manage the PDBs separately from each other and from the root.

In a CDB, the data dictionary metadata is split between the root and the PDBs. In the following figure, the employees and departments tables reside in a PDB. The data dictionary for this user data also resides in the PDB. Thus, the TAB$ table in the PDB has a row for the employees table and a row for the departments table. In the following figure, root indicates CDB.

hThe data dictionary in the PDB contains pointers to the data dictionary in the root(CDB). Internally, Oracle-supplied objects such as data dictionary table definitions and PL/SQL packages are represented only in the root(CDB)

Tablespace and Files in CDB, PDB

  1. Each PDB has its own set of tablespaces including SYSTEM and SYSAUX.

2. All PDBs share same REDO, control files, spfile, pfile and files reside at root(CDB) level. Therefore , DR site to be built from CDB level. Each PDB can’t have a separate ADG enable DR.

3. By default the CDB has a single TEMP tablespace but each PDB may create their own TEMP tablespace.

4. By default CDB has a single UNDO tablespace but each PDB may enable and create their local UNDO tablespace.

Tablespace and File structure in Multitenant Architecture

Few Important Points to remember for Multitenant Database USER

  • Multitenant architecture can currently support up to 4096 PDBs.

  • A PDB feels and operates identically to a non-CDB.

  • You cannot tell from the viewpoint of a connected client, if you’re using a PDB or a non-CDB.

  • A common user is defined in the root and is represented in every PDB.

  • A common user can log into any PDB where it has “Create Session” and can therefore administer a PDB.

  • The Oracle system is owned by common users and name will be in the format of COMMON_USER_PREFIX.

  • A common user can be granted privileges locally in a PDB (or root) and therefore it will be different in each container.

  • A common user can, alternatively, be granted a system privilege commonly – the grant is made in root and every PDB, present and future

  • You can create a common role. A common role can be granted to a common user.

  • Authorization is checked in the container where the SQL is attempted considering only the privileges that the user has in that container

  • Best practice: Don’t create objects in common user’s schema