Introduction to the Multitenant Architecture

About the Multitenant Architecture

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 anon-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 container (also called the root). The root 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 (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 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 graphic shows a CDB with four containers: the root, seed, and two PDBs. Each PDB has its own dedicated application, and is managed by its own PDB administrator. 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.

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 vice versa. You must define a database as a CDB at creation, and then create PDBs 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 DATABASEclause, then the newly created database is a non-CDB and can never contain PDBs.

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

Example 17-1 shows a simple query for determining whether the database to which an administrative user is currently connected is a non-CDB, or a container in a CDB.

Example 17-1 Determining Whether a Database Is a CDB

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

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 graphic depicts the options for creating a PDB:

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

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 graphic illustrates creation from the seed:

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

Creation of a PDB by Cloning a PDB

This technique copies the files associated with the source PDB to a new location and associates the copied files with the new PDB. You can clone a PDB that resides in the same CDB or in a different CDB. If in a different CDB, then you must use a database link to specify the remote CDB that contains the PDB to be cloned. The following graphic illustrates cloning a PDB from an existing 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

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 graphic illustrates 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

Creation of a PDB from a Non-CDB

You can use any of the following techniques to create a PDB from an existing non-CDB:

• Execute 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.
  
  
  
  
  
  
• Use Oracle Data Pump with or without transportable tablespaces
  You can use Oracle Data Pump to define a data set on a non-CDB. 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 all objects that can be exported using the transportable option, and then exports the remaining 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.
  
  

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

Overview of Common and Local Users in a CDB

Every user that owns objects that define the database is common. User-created users are either local or common. Figure 18-3 shows the possible user types in a CDB.

Figure 18-3 Users in a CDB

Figure 18-3 Users in a CDB"

Common Users in a CDB

A common user is a database user that has the same identity in the root and in every existing and future PDB. Every common user can connect to and perform operations within the root, and within any PDB in which it has privileges.

Every common user is either Oracle-supplied or user-created. Examples of Oracle-supplied common users are SYS and SYSTEM.

Figure 18-4 shows sample users and schemas in two PDBs: hrpdb and salespdb. SYS and c##dba are common users who have schemas in CDB$ROOT, hrpdb, and salespdb. Local users hr and rep exist in hrpdb. Local users hr and rep also exist in salespdb.

Figure 18-4 Users and Schemas in a CDB

Common users have the following characteristics:

• A common user can log in to any container (including CDB$ROOT) in which it has the CREATE SESSION privilege.
  A common user need not have the same privileges in every container. For example, the c##dba user may have the privilege to create a session in hrpdband in the root, but not to create a session in salespdb. Because a common user with the appropriate privileges can switch between containers, a common user in the root can administer PDBs.
• The name of every user-created common user must begin with the characters c## or C##. (Oracle-supplied common user names do not have this restriction.)
  No local user name may begin with the characters c## or C##.
• The names of common users must contain only ASCII or EBCDIC characters.
• Every common user is uniquely named across all containers.
  A common user resides in the root, but must be able to connect to every PDB with the same identity.
• The schemas for a common user can differ in each container.
  For example, if c##dba is a common user that has privileges on multiple containers, then the c##dba schema in each of these containers may contain different objects.

Local Users in a CDB

A local user is a database user that is not common and can operate only within a single PDB. Local users have the following characteristics:

• A local user is specific to a particular PDB and owns a schema in this PDB.
  In Figure 18-4, local user hr on hrpdb owns the hr schema. On salespdb, local user rep owns the rep schema, and local user hr owns the hr schema.
  A local user cannot be created in the root.
• A local user on one PDB cannot log in to another PDB or to the root.
  When hr connects to hrpdb, hr cannot access objects in the sh schema that reside in the salespdb database without using a database link. In the same way, when sh connects to the salespdb PDB, sh cannot access objects in the hr schema that resides in hrpdb without using a database link.
• The name of a local user must not begin with the characters c## or C##.
• The name of a local user must only be unique within its PDB.
  The user name and the PDB in which that user schema is contained determine a unique local user. Figure 18-4 shows that a local user and schema namedrep exist on hrpdb. A completely independent local user and schema named rep exist on the salespdb PDB.
• Whether local users can access objects in a common schema depends on their user privileges.
  For example, the c##dba common user may create a table in the c##dba schema on hrpdb. Unless c##dba grants the necessary privileges to the local hruser on this table, hr cannot access it.