Architecture of a CDB

From a physical perspective, a CDB has basically the same structure as a non-CDB, except that each PDB has its own set of tablespaces (including its own SYSTEM and SYSAUX tablespaces) and data files. Figure 18-5 shows aspects of the physical storage architecture of a CDB with two PDBs: hrpdb and salespdb.

As shown in Figure 18-5, a CDB contains the following files:

• One control file
• One online redo log
• One or more sets of temp files

By default, the CDB has a single default temporary tablespace named TEMP that every PDB uses. You may choose to create a different default temporary tablespace. Only a temporary tablespace that you create while connected to the root can serve as a default temporary tablespace for the CDB. For an individual PDB, you may override the CDB-wide temporary tablespace by creating a local temporary named TEMP, and then setting it as the default.

• One set of undo data files

In a single-instance CDB, only one active undo tablespace exists. For an Oracle RAC CDB, one active undo tablespace exists for each instance. Only a common user who has the appropriate privileges and whose current container is the root can create an undo tablespace. All undo tablespaces are visible in the data dictionaries and related views of all containers.

• A set of system data files for every container

The primary physical difference between CDBs and non-CDBs is the system data files. A non-CDB has only one set of system data files. In contrast, the root and each PDB in a CDB has its own SYSTEM and SYSAUX tablespaces and its own complete set of dictionary tables describing the objects in itself.

• Zero or more sets of user-created data files

In a typical use case, each PDB has its own set of non-system data files. These data files contain the data for user-defined schemas and objects in the PDB.

The storage of the data dictionary within the PDB enables it to be portable. You can easily plug and unplug a PDB into a CDB.