Skip Headers
Oracle® Database Administrator's Guide
12c Release 1 (12.1)

E17636-21
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

36 Overview of Managing a Multitenant Environment

This chapter contains the following topics:

About a Multitenant Environment

You can use the Oracle Multitenant option to configure and manage a multitenant environment. The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB) that 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.

This section contains the following topics:

Components of a CDB

A CDB includes the following components:

  • Root

    The root, named CDB$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. A CDB has exactly one root.

  • Seed

    The seed, named PDB$SEED, is a template that you can use to create new PDBs. You cannot add objects to or modify objects in the seed. A CDB has exactly one seed.

  • PDBs

    A PDB appears to users and applications as if it were a non-CDB. For example, a PDB can contain the data and code required to support a specific application. A PDB is fully backward compatible with Oracle Database releases before Oracle Database 12c.

Each of these components is called a container. Therefore, the root is a container, the seed is a container, and each PDB is a container. Each container has a unique container ID and name within a CDB. Figure 36-1 shows a CDB with several PDBs.

Figure 36-1 CDB with PDBs

Description of Figure 36-1 follows
Description of "Figure 36-1 CDB with PDBs"

You can easily plug a PDB into a CDB and unplug a PDB from a CDB. When you plug in a PDB, you associate the PDB with a CDB. When you unplug a PDB, you disassociate the PDB from a CDB. An unplugged PDB consists of an XML file that describes the PDB and the PDB's files (such as the data files and wallet file).

You can unplug a PDB from one CDB and plug it into a different CDB without altering your schemas or applications. A PDB can be plugged into only one CDB at a time.

Each PDB has a globally unique identifier (GUID). The PDB GUID is primarily used to generate names for directories that store the PDB's files, including both Oracle Managed Files directories and non-Oracle Managed Files directories.

Common Users and Local Users

A CDB supports common users. A common user is a user that has the same identity in the root and in every existing and future PDB. A common user can log in to the root and any PDB in which it has privileges. The operations that a common user can perform depend on the privileges granted to the common user. Some administrative tasks, such as creating a PDB or unplugging a PDB, must be performed by a common user. A CDB also supports local users. A local user is a user that exists in exactly one PDB.

See Also:

Oracle Database Security Guide for more information about common users and local users

Separation of Duties in CDB and PDB Administration

Some database administrators manage the entire CDB. These database administrators connect to the CDB as common users, and they manage attributes of the entire CDB and the root, as well as some attributes of PDBs. For example, these database administrators can create, unplug, plug in, and drop PDBs. They can also specify the temporary tablespace for the entire CDB and the default tablespace for the root, and they can change the open mode of one or more PDBs.

Database administrators can also connect to a specific PDB as a local user and then perform a subset of management tasks on the PDB that a database administrator performs on a non-CDB. The subset of tasks are those required for the PDB to support an application. For example, these can include management of tablespaces and schemas in a PDB, specification of storage parameters for that PDB, and changing the open mode of the current PDB.

Purpose of a Multitenant Environment

A multitenant environment enables the central management of multiple PDBs in a single installation. By using a multitenant environment, you can accomplish the following goals:

  • 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 plug a PDB into a CDB, unplug the PDB from the CDB, and then plug this PDB into a different CDB. Therefore, you can easily move an application's database back end from one server to another.

  • 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 CDB, PDBs mimic the behavior of traditional non-CDBs. For example, if a user error causes data loss, then a PDB administrator can use point-in-time recovery to retrieve the lost data without affecting other PDBs.

  • Ease of performance tuning

    It is easier to collect performance metrics for a CDB than for multiple non-CDBs. It is easier to size one SGA than several SGAs.

  • Support for Oracle Database Resource Manager

    In a CDB, one concern is contention for system resources among the PDBs running on the same server. 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 Chapter 44, "Using Oracle Resource Manager for PDBs with SQL*Plus").

  • Fewer patches and upgrades

    It is easier to apply a patch to one CDB than to multiple non-CDBs and to upgrade one CDB than to upgrade several non-CDBs.

A multitenant environment is especially useful when you have many non-CDBs deployed on different hardware in multiple Oracle Database installations. These non-CDBs might use only a fraction of the hardware resources dedicated to them, and each one might not require a full-time database administrator to manage it.

By combining these non-CDBs into a CDB, you can make better use of your hardware resources and database administrator resources. In addition, you can move a PDB from one CDB to another without requiring changes to the applications that depend on the PDB.

Prerequisites for a Multitenant Environment

The following prerequisites must be met before you can create and use a multitenant environment:

  • Install Oracle Database 12c.

    The installation includes setting various environment variables unique to your operating system and establishing the directory structure for software and database files.

    See Oracle Database Installation Guide specific to your operating system.

  • Set the database compatibility level to at least 12.0.0.

    See Oracle Database Upgrade Guide for information about the database compatibility level.

Tasks and Tools for a Multitenant Environment

This section describes the common tasks you perform for a multitenant environment and the tools you use to complete the tasks.

This section contains the following topics:

Tasks for a Multitenant Environment

A multitenant environment enables you to achieve the goals described in "Purpose of a Multitenant Environment". To do so, you must complete the following general tasks:

Task 1   Plan for the Multitenant Environment

Creating and configuring any database requires careful planning. A CDB requires special considerations. For example, consider the following factors when you plan for a CDB:

  • The number of PDBs that will be plugged into each CDB

  • The resources required to support the planned CDB

  • Configuration options that apply to the entire CDB and configuration options that apply to each PDB

See "Planning for CDB Creation" for detailed information about planning for a CDB.

Task 2   Create One or More CDBs

When you have completed the necessary planning, you can create one or more CDBs using either the Database Configuration Assistant (DBCA) or the CREATE DATABASE SQL statement. In either case, you must specify the configuration details for each CDB.

See "Using DBCA to Create a CDB" and "Using the CREATE DATABASE Statement to Create a CDB" for detailed information about creating a CDB.

After a CDB is created, it consists of the root and the seed, as shown in Figure 36-2. The root contains minimal user data or no user data, and the seed contains no user data.

Figure 36-2 A Newly Created CDB

Description of Figure 36-2 follows
Description of "Figure 36-2 A Newly Created CDB"

Task 3   Create, Plug In, and Unplug PDBs

PDBs contain user data. After creating a CDB, you can create PDBs, plug unplugged PDBs into it, and unplug PDBs from it whenever necessary. You can unplug a PDB from a CDB and plug this PDB into a different CDB. You might move a PDB from one CDB to another if, for example, you want to move the workload for the PDB from one server to another.

See Chapter 38, "Creating and Removing PDBs with SQL*Plus" and Chapter 39, "Creating and Removing PDBs with Cloud Control" for information about creating PDBs, plugging in PDBs, and unplugging PDBs.

Figure 36-3 shows a CDB with several PDBs.

Figure 36-3 A CDB with PDBs

Description of Figure 36-3 follows
Description of "Figure 36-3 A CDB with PDBs"

Task 4   Administer and Monitor the CDB

Administering and monitoring a CDB involves managing the entire CDB, the root, and some attributes of PDBs. Some management tasks are the same for CDBs and non-CDBs, and some are different. See "After Creating a CDB" for descriptions of tasks that are similar and tasks that are different. Also, see Chapter 40, "Administering a CDB with SQL*Plus", Chapter 41, "Administering CDBs and PDBs with Cloud Control", and Chapter 43, "Viewing Information About CDBs and PDBs with SQL*Plus".

You can use Oracle Resource Manager to allocate resources among PDBs in a CDB and within individual PDBs. See Chapter 44, "Using Oracle Resource Manager for PDBs with SQL*Plus".

You can also use Oracle Scheduler to schedule jobs in a CDB and in individual PDBs. See Chapter 46, "Using Oracle Scheduler with a CDB".

Task 5   Administer and Monitor PDBs

Administering and monitoring a PDB is similar to administering and monitoring a non-CDB, but there are some differences. See Chapter 41, "Administering CDBs and PDBs with Cloud Control", Chapter 42, "Administering PDBs with SQL*Plus", and Chapter 43, "Viewing Information About CDBs and PDBs with SQL*Plus".

Tools for a Multitenant Environment

Use the following tools to complete tasks for a multitenant environment:

  • SQL*Plus

    SQL*Plus is a command-line tool that enables you to create, manage, and monitor CDBs and PDBs. You use SQL statements and Oracle-supplied PL/SQL packages to complete these tasks in SQL*Plus.

    See SQL*Plus User's Guide and Reference.

  • DBCA

    Oracle Database Configuration Assistant (DBCA) is a utility with a graphical user interface that enables you to configure a CDB, create PDBs, plug in PDBs, and unplug PDBs.

    See Oracle Database 2 Day DBA, Oracle Database Installation Guide, and the DBCA online help for more information about DBCA.

  • Oracle Enterprise Manager Cloud Control

    Cloud Control is a system management tool with a graphical user interface that enables you to manage and monitor a CDB and its PDBs.

    See the Cloud Control online help for more information about Cloud Control.

  • Oracle SQL Developer

    Oracle SQL Developer is a graphical version of SQL*Plus that gives database developers a convenient way to perform basic tasks.

    See Oracle SQL Developer User's Guide.

  • The Server Control (SRVCTL) utility

    The SRVCTL utility can create and manage services for PDBs.

    See "Managing Services Associated with PDBs".

No special tools are required to work with CDBs or PDBs.