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

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.

The CDB uses an internal linking mechanism to separate data dictionary information.

Specifically, Oracle Database uses the following automatically managed pointers:

• Metadata links

  Oracle Database stores metadata about dictionary objects only in the CDB root. For example, the column definitions for the  OBJ$  dictionary table, which underlies the  DBA_OBJECTS  data dictionary view, exist only in the root. As depicted in  Figure 19-4 , the  OBJ$  table in each PDB uses an internal mechanism called a  metadata link  to point to the definition of  OBJ$  stored in the root.

  The  data  corresponding to a metadata link resides in its PDB, not in the root. For example, if you create table  mytable  in  hrpdb  and add rows to it, then the rows are stored in the PDB data files. The data dictionary views in the PDB and in the root contain different rows. For example, a new row describing  mytable  exists in the  OBJ$  table in  hrpdb , but not in the  OBJ$ table in the CDB root. Thus, a query of  DBA_OBJECTS  in the CDB root and  DBA_OBJECTS  in  hrdpb  shows different results.

• Data links

  Note:

  Data links were called  object links  in Oracle Database 12 c  Release 1 (12.1.0.2).

  In some cases, Oracle Database stores the data (not only metadata) for an object only once in the application root. An application PDB uses an internal mechanism called a  data link  to refer to the objects in the application root. The application PDB in which the data link was created also stores the data link description. A data link inherits the data type of the object to which it refers.

• Extended data link

  An extended data link is a hybrid of a data link and a metadata link. Like a data link, an extended data link refers to an object in an application root. However, the extended data link also refers to a corresponding object in the application PDB. Like a metadata link, the object in the application PDB inherits metadata from the corresponding object in the application root.

  When queried in the application root, an extended data-linked object fetches rows only from the application root. However, when queried in an application PDB, an extended data-linked object fetches rows from both the application root and application PDB.

Oracle Database automatically creates and manages metadata and data links to  CDB$ROOT . Users cannot add, modify, or remove these links.

A  container data object  is a table or view containing data pertaining to multiple containers or the whole CDB.

Container data privileges support a general requirement in which multiple PDBs reside in a single CDB, but with different local administration requirements. For example, if application DBAs do not want to administer locally, then they can grant container data privileges on appropriate views to the common users. In this case, the CDB administrator can access the data for these PDBs. In contrast, PDB administrators who do not want the CDB administrator accessing their data do not grant container data privileges.

Examples of container data objects are Oracle-supplied views whose names begin with  V$  and  CDB_ . All container data objects have a  CON_ID  column. The following table shows the meaning of the values for this column.

In a CDB, for every  DBA_  view, a corresponding  CDB_  view exists. The owner of a  CDB_  view is the owner of the corresponding  DBA_  view. The following graphic shows the relationship among the different categories of dictionary views:

When the current container is a PDB, a user can view data dictionary information for the current PDB only. To an application connected to a PDB, the data dictionary appears as it would for a non-CDB. When the current container is the root, however, a common user can query  CDB_  views to see metadata for the root and for PDBs for which this user is privileged.

The following table shows a scenario involving queries of  CDB_  views. Each row describes an action that occurs after the action in the preceding row.

SQL> CONNECT SYSTEM
Enter password: ********
Connected.

SQL> SELECT COUNT(*) FROM CDB_USERS
WHERE CON_ID=1;
COUNT(*)
--------41

SQL> SELECT COUNT(DISTINCT(CON_ID))
FROM CDB_USERS;COUNT(DISTINCT(CON_ID))
-----------------------4

SQL> CONNECT SYSTEM@hrdb
Enter password: ********
Connected.

SQL> SELECT COUNT(*) FROM CDB_USERS;COUNT(*)
----------45

The data dictionary that stores the metadata for the CDB as a whole is stored only in the system tablespaces.

The data dictionary that stores the metadata for a specific PDB is stored in the self-contained tablespaces dedicated to this PDB. The PDB tablespaces contain both the data and metadata for an application back end. Thus, each set of data dictionary tables is stored in its own dedicated set of tablespaces.