17 Introduction to the Multitenant Architecture

A container is either a PDB or the root. The root container is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong.

Every CDB has the following containers:

• Exactly one root

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

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

• Zero or more user-created PDBs

  A PDB is a user-created entity that 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.

The following figure shows a CDB with four containers: the root, seed, and two PDBs. Each PDB has its own dedicated application. A different PDB administrator manages each PDB. A common user exists across a CDB with a single identity. In this example, common user SYS can manage the root and every PDB. At the physical level, this CDB has a database instance and database files, just as a non-CDB does.

Figure 17-1 CDB with Two PDBs

Description of "Figure 17-1 CDB with Two PDBs"

You can use the same administration tools for both CDBs and non-CDBs.

For example, you can use the following tools in a multitenant environment:

• SQL*Plus for command-line access

  See SQL*Plus User's Guide and Reference.

• Oracle Enterprise Manager Cloud Control (Cloud Control)

  Cloud Control is an Oracle Database administration tool that provides a graphical user interface (GUI). Cloud Control supports Oracle Database 12c targets, including PDBs, CDBs, and non-CDBs.

  See Oracle Database Administrator's Guide to learn more about Cloud Control.

• Oracle Enterprise Manager Database Express (EM Express)

  EM Express is a web-based management product built into the Oracle database. EM Express enables you to provision and manage PDBs, including the following operations:

  • Creating and dropping PDBs

  • Plugging in and unplugging and PDBs

  • Cloning PDBs

  • Setting resource limits for PDBs

  See Oracle Database 2 Day DBA to learn more about using EM Express for managing CDBs and PDBs.

• Oracle Database Configuration Assistant (DBCA)

  DBCA enables you to create CDBs or non-CDBs, and create, plug, and unplug PDBs. See Oracle Database 2 Day DBA and Oracle Database Administrator's Guide for more information about DBCA.

• Oracle Multitenant Self-Service Provisioning application

  This application enables the self-service provisioning of PDBs. CDB administrators control access to this self-service application and manage quotas on PDBs.

  For more information about the application or to download the software, use any browser to access the OTN page for the application:

  http://www.oracle.com/goto/multitenant

  To access the application, click the Downloads tab, and in the Oracle Database 12c Multitenant Applications section select Multitenant Self-Service Provisioning.

Database consolidation is the process of consolidating data from multiple databases into one database on one computer. Starting in Oracle Database 12c, the Oracle Multitenant option enables you to consolidate data and code without altering existing schemas or applications.

The PDB/non-CDB compatibility guarantee means that a PDB behaves the same as a non-CDB as seen from a client connecting with Oracle Net. The installation scheme for an application back end that runs against a non-CDB runs the same against a PDB and produces the same result. Also, the run-time behavior of client code that connects to the PDB containing the application back end is identical to the behavior of client code that connected to the non-CDB containing this back end.

Operations that act on an entire non-CDB act in the same way on an entire CDB, for example, when using Oracle Data Guard and database backup and recovery. Thus, the users, administrators, and developers of a non-CDB have substantially the same experience after the database has been consolidated.

Figure 17-3 depicts the databases in Figure 17-2 after consolidation onto one computer. The DBA team is reduced from five to three, with one CDB administrator managing the CDB while two PDB administrators split management of the PDBs.

Figure 17-3 Single CDB

Description of "Figure 17-3 Single CDB"

Using the multitenant architecture for database consolidation has the following benefits:

• Cost reduction

  By consolidating hardware and sharing database memory and files, you reduce costs for hardware, storage, availability, and labor. For example, 100 PDBs on a single server share one database instance and one set of database files, thereby requiring less hardware and fewer personnel.

• Easier and more rapid movement of data and code

  By design, you can quickly plug a PDB into a CDB, unplug the PDB from the CDB, and then plug this PDB into a different CDB. The implementation technique for plugging and unplugging is similar to the transportable tablespace technique.

• Easier management and monitoring of the physical database

  The CDB administrator can attend to one physical database (one set of files and one set of database instances) rather than split attention among dozens or hundreds of non-CDBs. Backup strategies and disaster recovery are simplified.

• Separation of data and code

  Although consolidated into a single physical database, PDBs mimic the behavior of non-CDBs. For example, if user error loses critical data, a PDB administrator can use Oracle Flashback or point-in-time recovery to retrieve the lost data without affecting other PDBs.

• Secure separation of administrative duties

  A user account is common, which means that it can connect to any container on which it has privileges, or local, which means that it is restricted to a specific PDB. A CDB administrator can use a common user account to manage the CDB. A PDB administrator uses a local account to manage an individual PDB. Because a privilege is contained within the container in which it is granted, a local user on one PDB does not have privileges on other PDBs within the same CDB.

• Ease of performance tuning

  It is easier to collect performance metrics for a single database than for multiple databases. It is easier to size one SGA than 100 SGAs.

• Support for Oracle Database Resource Manager

  In a multitenant environment, one concern is contention for system resources among the PDBs running on the same computer. Another concern is limiting resource usage for more consistent, predictable performance. To address such resource contention, usage, and monitoring issues, you can use Oracle Database Resource Manager (see "Database Resource Manager").

• Fewer database patches and upgrades

  It is easier to apply a patch to one database than to 100 databases, and to upgrade one database than to upgrade 100 databases.

The multitenant architecture has benefits beyond database consolidation. These benefits derive from storing the data and data dictionary metadata specific to a PDB in the PDB itself rather than storing all dictionary metadata in one place. By storing its own dictionary metadata, a PDB becomes easier to manage as a distinct unit, even when only one PDB resides in a CDB.

Benefits of data dictionary separation include the following:

• Easier migration of data and code

  For example, instead of upgrading a CDB from one database release to another, you can unplug a PDB from the existing CDB, and then plug it into a newly created CDB from a higher release.

• Easier testing of applications

  You can develop an application on a test PDB and, when it is ready for deployment, plug this PDB into the production CDB.

The CREATE DATABASE ... ENABLE PLUGGABLE DATABASE SQL statement creates a new CDB. If you do not specify the ENABLE PLUGGABLE DATABASE clause, then the newly created database is a non-CDB and can never contain PDBs.

Along with the root container (CDB$ROOT), Oracle Database automatically creates a seed PDB (PDB$SEED). The following graphic shows a newly created CDB:

Figure 17-4 CDB with Seed PDB

Description of "Figure 17-4 CDB with Seed PDB"

SQL> SELECT NAME, CDB, CON_ID FROM V$DATABASE;
 
NAME      CDB     CON_ID
--------- --- ----------
CDB1      YES          0

The CREATE PLUGGABLE DATABASE SQL statement creates a PDB. This PDB automatically includes a full data dictionary including metadata and internal links to system-supplied objects in the root. You can only create a PDB in a CDB and not within another PDB.

The following figure depicts the options for creating a PDB.

Figure 17-5 Options for Creating a PDB

Description of "Figure 17-5 Options for Creating a PDB"

The following figure shows a CDB that contains six PDBs. hrpdb is a newly created PDB. salespdb was a pre-existing PDB that was unplugged from a different CDB and plugged into this CDB. The remaining four PDBs, each of whose names contains the prefix test, were copied from salespdb.

Figure 17-6 CDB with Six PDBs

Description of "Figure 17-6 CDB with Six PDBs"

The following sections describe the different techniques for creating PDBs.