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
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.
Tablespace and Files in CDB, PDB
- 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.
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