Welcome to the next topic on Oracle Multitenant Architecture. In this topic, I will describe the multitenant architecture used for container databases.

 

In general, there are two types of Oracle databases, a non-container database, or non-CDB, which is a traditional Oracle database that cannot contain pluggable databases. This type of database was used in previous Oracle database software versions. Although current version of Oracle database software doesn't support non-CDBs anymore, some customers may still use previous versions of Oracle software with non-CDB databases.

 

And, a multitenant container database, which is a single physical database that contains zero, one, or many user-created pluggable databases. The multitenant architecture enables an Oracle database to be a multitenant container database. A pluggable database is a portable collection of schemas, schema objects, and non-schema objects that appear to an Oracle client as a non-CDB database.

 

Multitenant architecture is using a concept of containers. Container is a logical collection of data or metadata within the multitenant architecture. Some containers are pre-created by Oracle. Some containers are created by users.

 

Pluggable database is simply a container which contains a portable set of database schemas and database objects. Pluggable databases can be easily unplugged from and plugged into any other container database, effectively moving data for one or more PDBs between alternate databases.

 

Let's have a look on different container types a CDB can contain. Every CDB has the following containers-- the system container, which is the logical container for the CDB itself and includes the CDB$ROOT container and all PDBs in the container database. There is exactly one system container in each container database.

 

Each container database also contains exactly one root container. The root container stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied PL SQL packages.

 

A common user is a database user known in every container. The root container is named CDB$ROOT. In each CDB, there is exactly one seed PDB. The seed PDB is a system-supplied template that the CDB can use to create the new PDBs. The seed PDB belonging to root container is named PDB$SEED. You should not add or modify objects in PDB$SEED.

 

Each container database contains zero or more user-created PDBs. A PDB contains data and code required for a specific set of features. For example, a PDB can support the specific applications, such as human resources or sales application. PDB can belong either to system container or to an application container.

 

If a PDB belongs to an application container, then it is an application PDB. An application seed is an optional application PDB that acts as a user-created PDB template, enabling you to create new application of PDBs rapidly. And finally, a CDB contains zero or more application containers.

 

Application container consists of exactly one application root and the PDBs plugged into this root. Whereas the system container contains the CDB$ROOT and all the PDBs within the container database, an application container includes only the PDBs plugged into the application root.

 

An application root belongs to the CDB$ROOT and no other container. Application container enables sharing of user defined-objects like tables and views across multiple application PDBs, which is not possible in PDBs as belonging to the system container.

 

Let's have a look on this diagram this diagram represents the relationship between containers and explores application container in more details. Each CDB has exactly one CDB$ROOT container, exactly one PDB$SEED container, and zero or more user-created PDBs. An application container consists of an application root, optional application seed, and zero or more application PDBs.

 

In non-CDB architecture used by Oracle previously, each database always contains its own instance-- that means its own set of background processes, its own SGA, and its own copy of Oracle-supplied data and metadata. Because, in multitenant architecture, all PDBs in the same CDB share one set of background processes, the same memory structures, and one set of Oracle-supplied data and metadata stored in CDB$ROOT container, multitenant architecture is consuming less resources and is more efficient.

 

In this diagram, we have more detailed representation of multi-tenant architecture. In this slide, we can see that in addition to previously-mentioned shared components, PDBs is container database are also sharing some database files-- control files, redo log files, and, optionally, undo tablespaces. Every Oracle database has one or more control file.

 

Control file is a small binary file which contains the physical structure of the database. It contains various metadata-- for example database name, synchronization information, list of data files and redo log files for the CDB, backup metadata, and so on. The redo log files store all changes made to the database as they occur. Redo log files are most crucial structures for recovery operations.

 

Undo tablespaces are used to store undo records. Undo records are used to roll back or undo changes to the database when needed. This slide also demonstrates that each PDB has its own set of data files containing user-defined application data and corresponding metadata.

 

This concludes the topic on Oracle multitenant architecture.