A container is logical collection of data or metadata within the multitenant architecture.

The following figure represents possible containers in a CDB.

Figure 1-1 Containers in a CDB

Description of "Figure 1-1 Containers in a CDB"

Every CDB has the following containers:

• 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 (see "Overview of Containers in a CDB"). The root stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied PL/SQL packages (see "Data Dictionary Architecture in a CDB"). A common user is a database user known in every container (see "Common Users in a CDB"). The root container is named CDB$ROOT.

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

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

• Zero or more user-created PDBs

  A PDB contains the data and code required for a specific set of features (see "PDBs"). 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. For example, the cust1_pdb and cust2_pdb application PDBs might belong to the saas_sales_ac application container, in which case they belong to no other application containers. An application seed is an optional application PDB that acts as a user-created PDB template, enabling you to create new application PDBs rapidly.

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

Example 1-1 CDB with No Application Containers

This example shows a simple CDB with five containers: the system container (the entire CDB), the CDB root, the PDB seed (PDB$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 1-2 CDB with No Application Containers

Description of "Figure 1-2 CDB with No Application Containers"

Example 1-2 CDB with an Application Container

In this variation, the CDB contains an application container named saas_sales_ac. Within the application container, the application PDB cust1_pdb supports an application for one customer, and the application PDB cust2_pdb supports an application for a different customer. The CDB also contains a PDB named hrpdb, which supports an HR application, but does not belong to an application container.

Figure 1-3 CDB with an Application Container

Description of "Figure 1-3 CDB with an Application Container"

In this example, multiple DBAs manage the CDB environment:

• A CDB administrator manages the CDB itself.

• An application container administrator manages the saas_sales_ac container, including application installation and upgrades.

• An application PDB administrator manages the two PDBs in the saas_sales_ac container: cust1_pdb and cust2_pdb.

• A PDB administrator manages hrpdb.

See Also:

"Overview of Configuring and Managing a Multitenant Environment"

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

Database consolidation is the process of consolidating data from multiple databases into one database on one computer. 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 definition (for example, tables and PL/SQL packages) 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 definition is identical to the behavior of client code that connected to the non-CDB containing this application definition.

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 graphic depicts the databases in Figure 1-4 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 1-5 Single CDB

Description of "Figure 1-5 Single CDB"

Starting in Oracle Database 12c Release 2 (12.2), you can create an application container that contains application PDBs. This approach enables you to create and manage an application within this container. Most benefits that apply to consolidation into a CDB also apply to consolidation within an application container.

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

• Cost reduction

  By consolidating hardware and database infrastructure to a single set of background processes, and efficiently sharing computational and memory resources, you reduce costs for hardware and maintenance. For example, 100 PDBs on a single server share one database instance.

• 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. You can also clone PDBs while they remain available. You can plug in a PDB with any character set and access it without character set conversion. If the character set of the CDB is AL32UTF8, then PDBs with different database character sets can exist in the same CDB.

• Easier management and monitoring of the physical database

  The CDB administrator can manage the environment as an aggregate by executing a single operation, such as patching or performing an RMAN backup, for all hosted tenants and the CDB root. 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, then 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 common user can connect to any container on which it has sufficient privileges, whereas a local user is restricted to a specific PDB. Administrators can divide duties as follows:

  • An administrator uses a common account to manage a CDB or application container. 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.

  • An administrator uses a local account to manage an individual PDB.

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

• 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 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. This benefit occurs even when only one PDB resides in a CDB. Grouping PDBs into a separately managed application container increases manageability even further.

In a CDB, the data dictionary metadata is split between the root and the PDBs. Benefits of data dictionary separation include the following:

• Easier upgrade of data and code

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

• Easier migration between servers

  To perform load balancing or to meet SLAs, you can migrate an application database from an on-premise data center to the cloud, or between two servers in the same environment.

• Protection against data corruption within a PDB

  You can flash back a PDB to an SCN or PDB-specific restore point, without affecting other PDBs. This feature is analogous to the Flashback Database feature for a non-CDB.

• Ability to install, administer, and upgrade application-specific data and metadata in a single place

  You can define a set of application-specific PDBs as a single component, called an application container. You can then define one or more applications within this container. Each application is a named, versioned set of common metadata and data shared within this application container.

  For example, each customer of a SaaS vendor could have its own application PDB. Each application PDB might have identically defined tables named sales_mlt, with different data in each PDB. The PDBs could share a data-linked common object named countries_olt, which has identical data in each PDB. As an application administrator, you could manage the master application definition so that every new customer gets a PDB with the same objects, and every change to existing schemas (for example, the addition of a new table, or a change in the definition of a table) applies to all PDBs that share the application definition.

• Integration with Oracle Database Resource Manager

  In a multitenant environment, 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, use Oracle Database Resource Manager.

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. In this case, the non-CDB can never contain PDBs.

When you create a CDB, Oracle Database automatically creates a root container (CDB$ROOT) and a seed PDB (PDB$SEED). The following graphic shows a newly created CDB:

Figure 1-6 CDB with Seed PDB

Description of "Figure 1-6 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.

The created PDB automatically includes a full data dictionary including metadata and internal links to system-supplied objects in the CDB root. You must define every PDB from a single root: either the CDB root or an application root.

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.