Skip to content

Oracle Multitenant DB 1 : Basics of Oracle Multitenant architecture

The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB).

This feature is available in Oracle Database 12c or later releases so you must install or upgrade to Oracle Database 12c or later releases. The database compatibility level must be set to 12.0.0 or later to utilize the multitenant feature.

Below image shows how the CDB/PDB in multitenant architecture interact with each other:

Image Source: Oracle Documentations

In above image, we have

  • one CDB
  • one CDB$ROOT
  • one PDB$SEED
  • Three PDBs linked to CDB directly
  • Two Application roots – One having two application PDBs and one application seed and other having three application PDBs linked to it.

Some details on these components are mentioned below:


WHAT IS NON-CDB DATABASES?

Normal databases that you are familiar with and which were used earlier. Only one simple database with no pluggable/container databases etc.

All Oracle databases before Oracle Database 12c were non-CDBs.


WHAT IS CDB?

  • CDB is container database.
  • A CDB includes zero, one, or many customer-created pluggable databases (PDBs).
  • In a CDB, most user data resides in the PDBs. The root contains no user data or minimal user data.
  • The disk storage space requirement for a CDB is the space required for the Oracle Database installation plus the sum of the space requirements for all PDBs that will be part of the CDB.

WHAT IS PDB?

  • A PDB is a portable collection of schemas, schema objects, and non-schema objects that appears to an Oracle Net client as a non-CDB.

WHAT IS SYSTEM CONTAINER?

  • The system container includes the root CDB and all PDBs in the CDB. Thus, the system container is the logical container for the CDB itself.
  • A container is “logical” collection of data or metadata within the multitenant architecture.

WHAT IS THE CONCEPT OF DATABASE INSTANCE IN CONTEXT OF CDB/PDB?

  • A database instance is a set of memory structures that manage database files.
  • At the physical level, a CDB is a set of files on disk created by the CREATE DATABASE statement.
  • A CDB contains one or more user-created PDBs. A PDB contains its own set of data files within the overall set of data files that belongs to the CDB. The database instance manages the data associated with the CDB and its PDBs and serves their users.
  • Every running CDB is associated with at least one Oracle database instance. Because an instance exists in memory and a database (in the narrowest sense of term) is a set of files on disk, an instance can exist without a database and a database can exist without an instance.

WHAT CAN BE THE CONTENTS OF CDB?

Every CDB can have following five containers:

1) Exactly one CDB root container (also called simply the root)

  • The CDB root is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong
  • The root stores Oracle-supplied metadata and common users.
  • An example of metadata is the source code for Oracle-supplied PL/SQL packages.
  • The root container is named CDB$ROOT.
  • The CDB root does not store user data.
  • Oracle recommends that you do not add common objects to the root or modify Oracle-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 containers.
  • Oracle recommends AL32UTF8 for the root character set. PDBs with different character sets can reside in the same CDB without requiring character set conversion.

2) Exactly one system container

  • The system container includes the root CDB and all PDBs in the CDB. Thus, the system container is the logical container for the CDB itself as discussed earlier

3) Zero or more application containers

  • An application container consists of exactly one application root, and the PDBs plugged in to this root.
  • Whereas the system container contains the CDB root and all the PDBs within the CDB, an application container includes only the PDBs plugged into the application root.
  • An application root belongs to the CDB root and no other container.
  • Usually you will not see many clients using the application containers setup. Most clients will use PDBs inside of CDB.

4) Zero or more user-created PDBs

  • A PDB contains the data and code required for a specific set of features. For example, a PDB can support a specific application, such as a human resources or sales application.
  • No PDBs exist at creation of the CDB. You add PDBs based on your business requirements.
  • A PDB belongs to exactly zero or one application container. If a PDB belongs to an application container, then it is an application PDB.
  • A PDB is a user-created set of schemas, objects, and related structures that appears logically to a client application as a separate database.
  • Every PDB is owned by SYS, regardless of which user created the PDB. SYS is a common user in the CDB.
  • All PDBs are user-created with the CREATE PLUGGABLE DATABASE statement except for PDB$SEED, which is Oracle-supplied

5) Exactly one seed PDB

  • The seed PDB is a system-supplied template that the CDB can use to create new PDBs.
  • The seed PDB is named PDB$SEED.
  • You cannot add or modify objects in PDB$SEED.

WHAT ARE THE TYPE OF PDBS:

You can create the following types of PDBs:

1) Standard PDB

This type of PDB results from running CREATE PLUGGABLE DATABASE without specifying the PDB as a seed, proxy PDB, or application root. Its capabilities depend on the container in which you create it:

a) PDB plugged in to the CDB root

  • This PDB belongs to the CDB root container and not an application container.
  • This type of PDB cannot use application common objects.

This type of standard PDB is most commonly used.

b) PDB plugged in as Application PDB

  • An application PDB belongs to exactly one application container.
  • Unlike PDBs plugged in to the CDB root, application PDBs can share a master application definition within an application container. For example, a usa_zipcodes table in an application root might be a data-linked common object, which means it contains data accessible by all application PDBs plugged in to this root.
  • PDBs that do not reside within the application container cannot access its application common objects.

2) Application Root

  • Consider an application root as an application-specific root container. So Application root is sort of nested container inside the main container
  • It serves as a repository for a master definition of an application back end, including common data and metadata.
  • To create an application root, connect to the CDB root and specify the AS APPLICATION CONTAINER clause in a CREATE PLUGGABLE DATABASE statement.

3) Seed PDBs

  • Unlike a standard PDB, a seed PDB is not intended to support an application.
  • The seed is a template for the creation of PDBs that support applications.

A seed can be either of the following:

       A) Seed PDB plugged in the CDB root (PDB$SEED)

  • You can use this system-supplied template to create new PDBs either in an application container or the system container.
  • The system container contains exactly one PDB seed.
  • You cannot drop PDB$SEED, or add objects to or modify objects within it.

We saw one such PDB$SEED in earlier provided diagram.

     B) Application seed PDB

  • To accelerate creation of application PDBs within an application container, you can create an optional application seed.
  • An application container contains either zero or one application seed.
  • You create an application seed by connecting to the application container and executing the CREATE PLUGGABLE DATABASE … AS SEED statement.

We saw one such application seed PDB in earlier provided diagram.

4) Proxy PDBs

  • A proxy PDB is a PDB that uses a database link to reference a PDB in a remote CDB.
  • When you issue a statement in a proxy PDB while the PDB is open, the statement executes in the referenced PDB.
  • You must create a proxy PDB while connected to the CDB root or application root.
  • You can alter or drop a proxy PDB just as you can a standard PDB.

Proxy PDBs are not frequently used.


Tools used in a Multitenant Environment:

Some of the key tools used are:

  1. SQL*Plus — to create, manage, and monitor CDBs and PDBs.
  2. Oracle Enterprise Manager Cloud Control (Cloud Control) — manage and monitor a CDB and its PDBs.
  3. Oracle Enterprise Manager Database Express (EM Express) — can be configured for the CDB, individual hosted PDBs, or both.
  4. Oracle Database Configuration Assistant (DBCA) —  also enables you to create, relocate, clone, plug in, and unplug PDBs.
  5. Oracle SQL Developer — Client tool with graphical user interface that enables you to configure a CDB, create PDBs, plug and unplug PDBs, modify the state of a PDB, clone a PDB to the Oracle Cloud, hot clone/refresh a PDB, relocate a PDB between application roots, and more.
  6. Server Control (SRVCTL) utility —  can create and manage services for PDBs.

Naming Conventions in CDB-PDB:

Containers in a CDB share the same namespace, which means that they must have unique names within this namespace.

Names for the following containers must not conflict within the same CDB:

  • The CDB root
  • PDBs plugged in to the CDB root
  • Application roots
  • Application PDBs

Names for PDBs and application root containers must follow the same rules as net service names. Moreover, because a PDB or application root has a service with its own name, the container name must be unique across all CDBs whose services are exposed through a specific listener.

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


Common and Local Objects in a CDB

COMMON OBJECT:

  • A common object is defined in either the CDB root or an application root, and can be referenced using metadata links or object links.

=> We will discuss more on metadata links or object links in further posts

  • Database-supplied common objects are defined in CDB$ROOT and cannot be changed.
  • Oracle Database does not support creation of common objects in CDB$ROOT.

LOCAL OBJECT:

A local object is every object that is not a common object.

Brijesh Gogia
Leave a Reply