17 Introduction to the Multitenant Architecture

This chapter contains information specific to the Oracle Multitenant option.

It includes the following topics:

About the Multitenant Architecture

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

A CDB includes zero, one, or many customer-created pluggable databases (PDBs). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12c were non-CDBs.

About Containers in a CDB

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 follows
Description of "Figure 17-1 CDB with Two PDBs"

About User Interfaces for the Multitenant Architecture

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.

See Also:

Benefits of the Multitenant Architecture

The multitenant architecture solves a number of problems posed by the traditional non-CDB architecture.

Challenges for a Non-CDB Architecture

Large enterprises may use hundreds or thousands of databases. Often these databases run on different platforms on multiple physical servers.

Because of improvements in hardware technology, especially the increase in the number of CPUs, servers are able to handle heavier workloads than before. A database may use only a fraction of the server hardware capacity. This approach wastes both hardware and human resources.

For example, 100 servers may have one database each, with each database using 10% of hardware resources and 10% of an administrator's time. A team of DBAs must manage the SGA, database files, accounts, security, and so on of each database separately, while system administrators must maintain 100 different computers.

To show the problem in reduced scale, Figure 17-2 depicts 11 databases, each with its own application and server. A head DBA oversees a team of four DBAs, each of whom is responsible for two or three databases.

Figure 17-2 Database Environment Before Database Consolidation

Description of Figure 17-2 follows
Description of "Figure 17-2 Database Environment Before Database Consolidation"

Typical responses include:

  • Use virtual machines (VMs).

    In this model, you replicate the operating infrastructure of the physical server—operating system and database—in a virtual machine. VMs are agile, but use technical resources inefficiently, and require individual management. Virtual sprawl, which is just as expensive to manage, replaces the existing physical sprawl.

  • Place multiple databases on each server.

    Separate databases eliminate operating system replication, but do not share background processes, system and process memory, or Oracle metadata. The databases require individual management.

  • Separate the data logically into schemas or virtual private databases (VPDs).

    This technique uses technical resources efficiently. You can manage multiple schemas or VPDs as one. However, this model is less agile than its alternatives, requiring more effort to manage, secure, and transport. Also, the logical model typically requires extensive application changes, which discourages adoption.

Benefits of the Multitenant Architecture for Database Consolidation

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.

The following figure 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.

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.

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

Benefits of the Multitenant Architecture for Manageability

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.

Path to Database Consolidation

For the duration of its existence, a database is either a CDB or a non-CDB. You cannot transform a non-CDB into a CDB, or a CDB into a non-CDB. You must define a database as a CDB at creation, and then create PDBs and application containers within this CDB.

The basic path to database consolidation is:

  1. Creation of a CDB

  2. Creation of a PDB

Creation of a 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 follows
Description of "Figure 17-4 CDB with Seed PDB"

Example 17-1 Determining Whether a Database Is a CDB

The following simple query determines whether the database to which an administrative user is currently connected is a non-CDB, or a container in a CDB:

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

See Also:

Creation of a PDB

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 follows
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 follows
Description of "Figure 17-6 CDB with Six PDBs"

The following sections describe the different techniques for creating PDBs.

Creation of a PDB from Seed

You can use the CREATE PLUGGABLE DATABASE statement to create a PDB by copying the files from PDB$SEED, which is a template for creating PDBs.

The following figure illustrates creation from the seed.

Figure 17-7 Creation of a PDB from the Seed PDB

Description of Figure 17-7 follows
Description of "Figure 17-7 Creation of a PDB from the Seed PDB"

The following SQL statement creates a PDB named hrpdb from the seed using Oracle Managed Files:

CREATE PLUGGABLE DATABASE hrpdb
 ADMIN USER dba1 IDENTIFIED BY password

See Also:

Oracle Database Administrator’s Guide to learn this technique

Creation of a PDB by Cloning a PDB or a Non-CDB

You can use the CREATE PLUGGABLE DATABASE statement to clone a source PDB or non-CDB and plug the clone into the CDB. The source can be a PDB in a local or remote CDB, or starting in Oracle Database 12c Release 1 (12.1.0.2), it can also be a remote non-CDB. This technique copies the files associated with the source PDB or non-CDB to a new location and associates the copied files with the new PDB.

Note:

If you clone from a remote CDB, then you must use a database link.

The following graphic illustrates cloning a PDB from an existing PDB in the same CDB.

Figure 17-8 Cloning a PDB from a PDB in the Same CDB

Description of Figure 17-8 follows
Description of "Figure 17-8 Cloning a PDB from a PDB in the Same CDB"

If the underlying file system of a PDB supports storage snapshots, then you may specify the SNAPSHOT COPY clause to clone a PDB using storage snapshots. In this case, Oracle Database does not make a complete copy of source data files, but creates a storage-level snapshot of the underlying file system, and uses it to create PDB clones. Snapshot copies make cloning almost instantaneous.

The following SQL statement clones a PDB named salespdb from the plugged-in PDB named hrpdb:

CREATE PLUGGABLE DATABASE salespdb FROM hrpdb

See Also:

Oracle Database Administrator’s Guide to learn how to create a PDB by cloning an existing PDB or non-CDB

Creation of a PDB by Plugging In an Unplugged PDB

In its unplugged state, a PDB is a self-contained set of data files and an XML metadata file. This technique uses the XML metadata file that describes the PDB and the files associated with the PDB to associate it with the CDB.

The following figure illustrates plugging in an unplugged PDB.

Figure 17-9 Plugging In an Unplugged PDB

Description of Figure 17-9 follows
Description of "Figure 17-9 Plugging In an Unplugged PDB"

The following SQL statement plugs in a PDB named financepdb based on the metadata stored in the named XML file, and specifies NOCOPY because the files of the unplugged PDB do not need to be renamed:

CREATE PLUGGABLE DATABASE salespdb USING '/disk1/usr/financepdb.xml' NOCOPY

See Also:

Oracle Database Administrator’s Guide to learn how to perform this technique

Creation of a PDB from a Non-CDB

You can move a non-CDB into a PDB.

You can accomplish this task in the following ways:

  • Executing DBMS_PDB.DESCRIBE on a non-CDB in Oracle Database 12c

    You place a non-CDB in a transactionally consistent state, and then run the DBMS_PDB.DESCRIBE function to generate XML metadata about this database. While connected to the root in the CDB, you execute the CREATE PLUGGABLE DATABASE statement to create a PDB from the existing non-CDB. Finally, to convert the definitions in the PDB data dictionary to references to objects in CDB$ROOT, log in to the PDB and run the noncdb_to_pdb.sql script.

    See Oracle Database Administrator’s Guide to learn how to perform this technique.

  • Using Oracle Data Pump with or without transportable tablespaces

    You can define a data set on a non-CDB using Oracle Data Pump. This non-CDB can be in the current or a previous Oracle Database release, for example, Oracle Database 10g. You create an empty PDB in an existing CDB, and then use Oracle Data Pump to import the data set into the PDB.

    A Full Transportable Export using Oracle Data Pump exports all objects and data necessary to create a complete copy of the database. Oracle Data Pump exports objects using direct path unload and external tables, and then imports objects using direct path INSERT and external tables. The Full Transportable dump file contains all objects in the database, not only table-related objects. Full Transportable Export is available starting in Oracle Database 11g Release 2 (11.2.0.3) for import into Oracle Database 12c.

    See Oracle Database Administrator’s Guide to learn how to perform this technique.

  • Using Oracle GoldenGate replication

    You replicate the data from the non-CDB to a PDB. When the PDB becomes current with the non-CDB, you switch over to the PDB.

    See Oracle Database Administrator’s Guide to learn how to perform this technique.

The following figure illustrates running the DBMS_PDB.DESCRIBE function on a non-CDB, and then creating a PDB using the non-CDB files.

Figure 17-10 Creating a PDB from a Non-CDB

Description of Figure 17-10 follows
Description of "Figure 17-10 Creating a PDB from a Non-CDB"

See Also:

Multitenant Environment Documentation Roadmap

This topic lists the most important topics for understanding and using CDBs, and includes cross-references to the appropriate documentation.

Table 17-1 Road map for the Multitenant Architecture Documentation

Category Topic Documentation

Concepts

Overview of CDBs and PDBs

Chapters in Oracle Database Concepts, and Oracle Database Administrator’s Guide

Administration

Creating and configuring a CDB

Oracle Database Administrator’s Guide

Administration

Managing a CDB

Oracle Database Administrator’s Guide

Administration

Creating and configuring PDBs

Oracle Database Administrator’s Guide

Administration

Managing PDBs

Oracle Database Administrator’s Guide

Performance

Troubleshooting PDBs

Oracle Database Performance Tuning Guide

Monitoring

Viewing information about CDBs and PDBs

Oracle Database Administrator’s Guide

Backup and Recovery

Performing backup and recovery in a CDB

Oracle Database Backup and Recovery User’s Guide

Security

Managing common users, roles, and privileges in a CDB

Oracle Database Security Guide

Miscellaneous

All other tasks relating to managing a CDB or PDB, including Oracle RAC, resource management, data transfer, and so on

Oracle Database Administrator's Guide is the primary task-oriented intermediate and advanced documentation for managing CDBs. This guide also contains See Also links to books that cover different CDB topics. For example, Oracle Database Utilities explains concepts and tasks specific to PDBs when using Oracle Data Pump.