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.
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
