Differences between the root container and pluggable database containers

Overview of Containers in a CDB

A container is a collection of schemas, objects, and related structures in a multitenant container database (CDB) that appears logically to an application as a separate database. Within a CDB, each container has a unique ID and name.

The root and every pluggable database (PDB) is considered a container. PDBs isolate data and operations so that from the perspective of a user or application, each PDB appears as if it were a traditional non-CDB.

The Root

The root container, also called the root, is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong. Every CDB has one and only one root container, which stores the system metadata required to manage PDBs. All PDBs belong to the root. The name of the root is CDB$ROOT.

The root does not store user data. Thus, you must not add user data to the root or modify system-supplied schemas in the root. However, you can create common users and roles for database administration . A common user with the necessary privileges can switch between PDBs.

PDBs

A PDB is a user-created set of schemas, objects, and related structures that appears logically to an application as a separate database. Every PDB is owned by SYS, which is a common user in the CDB , regardless of which user created the PDB.

Purpose of PDBs

You can use PDBs to achieve the following goals:

·         Store data specific to a particular application

For example, a sales application can have its own dedicated PDB, and a human resources application can have its own dedicated PDB.

·         Move data into a different CDB

A database is "pluggable" because you can package it as a self-contained unit, and then move it into another CDB.

·         Isolate grants within PDBs

A local or common user with appropriate privileges can grant EXECUTE privileges on a package to PUBLIC within an individual PDB.

Names for PDBs

PDBs must be uniquely named within a CDB, and follow the same naming rules as service names. Moreover, because a PDB has a service with its own name, a PDB name must be unique across all CDBs whose services are exposed through a specific listener.

The first character of a user-created PDB name must be alphanumeric, with remaining characters either alphanumeric or an underscore (_). Because service names are case-insensitive, PDB names are case-insensitive, and are in upper case even if specified using delimited identifiers.

Data Dictionary Architecture in a CDB

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

Purpose of Data Dictionary Separation

In a newly created non-CDB that does not yet contain user data, the data dictionary contains only system metadata. For example, the TAB$ table contains rows that describe only Oracle-supplied tables, for example, TRIGGER$ and SERVICE$. The following graphic depicts three underlying data dictionary tables, with the red bars indicating rows describing the system:

If users create their own schemas and tables in this non-CDB, then the data dictionary now contains some rows that describe Oracle-supplied entities, and other rows that describe user-created entities. For example, the TAB$ dictionary table now has a row describing employees and a row describing departments:

In a CDB, the data dictionary metadata is split between the root and the PDBs. In Figure 18-1, 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 departmentstable.

Figure 18-1 Data Dictionary Architecture in a CDB

The preceding graphic shows that the data dictionary in the PDB contains pointers to the data dictionary in the root. Internally, Oracle-supplied objects such as data dictionary table definitions and PL/SQL packages are represented only in the root. This architecture achieves two main goals within the CDB:

• Reduction of duplication

For example, instead of storing the source code for the DBMS_ADVISOR PL/SQL package in every PDB, the CDB stores it only in CDB$ROOT, which saves disk space.

• Ease of database upgrade

If the definition of a data dictionary table existed in every PDB, and if the definition were to change in a new release, then each PDB would need to be upgraded separately to capture the change. Storing the table definition only once in the root eliminates this problem.