Recommendations for ASM Storage Preparation

The following are guidelines for preparing storage for use with Oracle ASM:

• A minimum of four LUNs (Oracle ASM disks) of equal size and performance is recommended for each disk group.
• Ensure that all Oracle ASM disks in a disk group have similar storage performance and availability characteristics. In storage configurations with mixed speed drives, such as 10K and 15K RPM, I/O performance is constrained by the slowest speed drive.
• Oracle ASM data distribution policy is capacity-based. Ensure that Oracle ASM disks in a disk group have the same capacity to maintain balance.
• Create external redundancy disk groups when using high-end storage arrays. High-end storage arrays generally provide hardware RAID protection. Use Oracle ASM mirroring redundancy when not using hardware RAID, or when you need host-based volume management functionality, such as mirroring across storage systems. You can use Oracle ASM mirroring in configurations when mirroring between geographically-separated sites (extended clusters).
• Minimize I/O contention between Oracle ASM disks and other applications by dedicating disks in Oracle ASM disk groups.
• Choose a hardware RAID stripe size that is a power of 2 and less than or equal to the size of the Oracle ASM allocation unit.
• For Linux, use the Oracle ASMLib feature to provide consistent device naming and permission persistency.

This tutorial covers the steps to perform basic tasks on container databases (CDBs) and pluggable databases (PDBs).

Introduction
This tutorial shows you how to:

• Connect to a CDB and to a PDB.
• Create a PDB from the seed PDB.
• Manage CDBs and PDBs.
• Start a CDB, understand the different open modes of PDBs, and shut down a CDB.
• Open and close PDBs.
• Change the name of a PDB.
• Manage the storage in a CDB and its PDBs.
• Manage permanent tablespaces.
• Manage temporary tablespaces.
• Manage the security in PDBs.
• Create common and local users.
• Create common and local roles.
• Grant common and local privileges.
• Drop PDBs.

Note: For readability, formatting was applied to some columns shown in the output.

Prerequisites

Before starting this tutorial, you should: 

• Install Oracle Database 12c
• Create one CDB and one PDB
The environment used in the development of this tutorial is as follows:

• ORACLE_HOME: /u01/app/oracle/product/12.1.0
• TNS Listener port: 1521
• Container databases:
  • SID: cdb1
  • SID: cdb2
• Pluggable databases (in cdb1):
• pdb1
• pdb2
  

Connecting to the CDB Root or to a PDB:

Creating a CDB creates a service whose name is the CDB name. As a side effect of creating a PDB in the CDB, a service is created inside it with a property that identifies it as the initial current container. The service is also started as a side effect of creating the PDB. The service has the same name as the PDB. Although its metadata is recorded inside the PDB, the invariant is maintained so that a service name is unique within the entire CDB.


Use the Easy Connect syntax to connect to the root unless a net service name is configured in the tnsnames for the root service.




. oraenv

[enter cdb1 at the prompt]


sqlplus sys/oracle@localhost:1521/cdb1 as sysdba

show con_name

show con_id



Connect to the root by using OS authentication. 

connect / as sysdba

show con_name

show con_id



Display the list of available services for the root and the PDBs. 

select name, con_id from v$active_services order by 1;



Use the Easy Connect syntax to connect to the PDB unless a net service name is configured in the tnsnames for the PDB service. 

connect sys/oracle@localhost:1521/pdb1 as sysdba

show con_name

show con_id

exit

 

Creating a PDB from the Seed PDB:

In this section, you create a PDB from the seed PDB. Each CDB has a template PDB whose name is PDB$Seed.

 
Creating the OS Directory for the New Data Files and Temp Files of the PDB
Before starting the PDB creation, create a destination directory for the data files.





mkdir /u01/app/oracle/oradata/cdb1/pdb3
 

Creating the PDB

Create a PDB from the seed PDB. 

sqlplus / as sysdba

create pluggable database pdb3
admin user odb3_admin identified by oracle
roles = (DBA)
FILE_NAME_CONVERT=('/u01/app/oracle/oradata/cdb1/pdbseed','/u01/app/oracle/oradata/cdb1/pdb3');



Verify the status, open mode, and service names of the PDBs in the CDB. If the status for a PDB shows NEEDS SYNC, you can connect to the PDB and run the DBMS_PDB.SYNC_PDB procedure to change the status to NORMAL.

select pdb_name, status from cdb_pdbs;

select name, open_mode from v$pdbs;

select name, con_id from v$active_services order by 1;





The open mode of the newly created PDB is still MOUNTED. You will learn how to open the PDB in the next section. The creation of the PDB created a new service.

List the PDB data files.

select name from v$datafile where con_id=5;

 

Managing the CDB and the PDBs:

In this section, you start the CDB and shut it down. You also open and close the PDBs.

 

Managing the CDB

Ensure that you are connected to the root as SYSDBA. 

Shut down the CDB. 

show con_name

shutdown immediate




This operation first closes all PDBs, then dismounts the control files, and finally shuts down the instance.

Start the CDB. This operation requires the SYSDBA or SYSBACKUP privilege.


startup


This operation first starts the instance, then mounts the control files, and finally opens only the root container. 

Verify the open mode of the PDBs. This operation first starts the instance, then mounts the control files, and finally opens only the root container.


select name, open_mode from v$pdbs;



Notice that PDB1 is opened automatically because of a database trigger that was previously created in this environment. Later in this tutorial, you will learn how to create a trigger to open all PDBs after the CDB is started.

 

Managing the PDBs

Open a PDB.

alter pluggable database pdb2 open;

select name, open_mode from v$pdbs;



Open all PDBs at once.

alter pluggable database all open;

Verify the open mode of the PDBs.


select name, open_mode from v$pdbs;



Close a PDB.

alter pluggable database pdb1 close immediate;

select name, open_mode from v$pdbs;

Close all PDBs at once.

alter pluggable database all close immediate;

select name, open_mode from v$pdbs;





When a CDB instance starts, you discover that its PDBs do not automatically open. In a development environment, it is convenient to ensure that all PDBs open with the instance.

Perform the following actions:

a. Create a trigger to open all PDBs after CDB startup. 

b. Shut down and start the CDB to verify that the trigger automatically opens all PDBs.

create or replace trigger Sys.After_Startup after startup on database
begin
   execute immediate 'alter pluggable database all open';
end After_Startup;
/

shutdown immediate

startup

select name, open_mode from v$pdbs;



 

Renaming a PDB

Open the PDB in restricted mode.

alter pluggable database pdb3 close immediate;

alter pluggable database pdb3 open restricted;

select name, restricted from v$pdbs;



Rename the PDB. You must be connected to the PDB to rename it.

alter pluggable database pdb3 rename global_name to pdb3_bis;

Note: You should receive an error message when you execute this statement because you are not connected to the pluggable database that is being renamed.

connect sys/oracle@localhost:1521/pdb3 as sysdba

alter pluggable database pdb3 rename global_name to pdb3_bis;



Close and open the PDB. 

alter pluggable database close immediate;

alter pluggable database open;

select name, open_mode from v$pdbs;





The PDB was renamed.

 

Managing Storage in a CDB and Its PDBs:

Each container in a CDB stores data in its own data files and handles temporary data in its own temp files.


List the root's tablespaces, data files, and temp files.

connect / as sysdba

select tablespace_name, con_id from cdb_tablespaces where con_id=1;

select file_name, con_id from cdb_data_files where con_id=1;

select file_name, con_id from cdb_temp_files where con_id=1;






Create a permanent tablespace in the root.

create tablespace cdata datafile '/u01/app/oracle/oradata/cdb1/cdata01.dbf' SIZE 10M;

select tablespace_name, con_id from cdb_tablespaces order by con_id;





select file_name, con_id from cdb_data_files order by con_id;

 

Create a temporary tablespace in the root.

create temporary tablespace temp_root tempfile '/u01/app/oracle/oradata/cdb1/temproot01.dbf' SIZE 10M;

select tablespace_name, con_id from cdb_tablespaces where contents='TEMPORARY' and con_id=1;

select file_name, con_id from cdb_temp_files where con_id=1;

 

Create a tablespace in a PDB.

connect system/oracle@localhost:1521/pdb3_bis

create tablespace ldata datafile '/u01/app/oracle/oradata/cdb1/pdb3/ldata01.dbf' SIZE 10M;

select tablespace_name, con_id from cdb_tablespaces order by con_id;

select file_name, con_id from cdb_data_files order by con_id;

select file_name from dba_data_files;




When you are connected to a PDB, the CDB_xxx or DBA_xxx views show the same information.

Create a temporary tablespace in the PDB.

create temporary tablespace temp_pdb3 tempfile '/u01/app/oracle/oradata/cdb1/pdb3/temppdb301.dbf' SIZE 10M;

select tablespace_name, con_id from cdb_tablespaces where contents='TEMPORARY';

select file_name from dba_temp_files;

 

 Managing Security in PDBs:

Managing Common and Local Users

Each container in a CDB holds common and local users. Any user, common or local, can only exercise the granted privileges inside the specific container to which it is connected.

• Common users are created from the root and are  automatically replicated in each PDB except the seed PDB. Common users can connect to any PDB. The name assigned to a common user must start with c##.
• Local users are created in a PDB they need to access. Local users can only connect to the PDB where they are created. They are not visible to the other PDBs of the same CDB.

Create a common user while you are connected to the root.

connect / as sysdba

create user c##1 identified by oracle container=all;

select username, common, con_id from cdb_users where username like 'C##%';



The user is not created in the seed PDB (con_id 2).

Connect as a common user in a PDB.

connect c##1/oracle@localhost:1521/pdb2

connect c##1/oracle@localhost:1521/pdb3_bis





The user is recognized in each PDB but cannot connect because the CREATE SESSION privilege was not yet granted.

Connect as a DBA in a PDB to create a local user.


connect system/oracle@localhost:1521/pdb3_bis

create user hr identified by oracle;

select username, common, con_id  from cdb_users where username ='HR';



Connect as the local HR user in each PDB.

connect hr/oracle@localhost:1521/pdb2

connect hr/oracle@localhost:1521/pdb3_bis





The user is recognized in the PDB where he was created (pdb3_bis) but not in another PDB (pdb2) because he is local only to pdb3_bis.

 

Managing Common and Local Roles

Each container in a CDB holds common and local roles.

• Common roles are created from the root and are automatically replicated in each PDB except the seed PDB. The name assigned to a common role must start with c##.
• Common roles can be granted commonly: The grant operation is replicated in each PDB except the seed PDB.
• Common roles can be granted locally: The grant operation is performed in the container where the operation takes place.
• Local roles are created in a PDB they need to access. Local roles can be granted locally only in the PDB where they are created. They are not visible to the other PDBs of the same CDB.

Create a common role. 

connect / as sysdba

create role c##r1 container=all;

select role, common, con_id from cdb_roles where role='C##R1';




The role is created in all PDBs except the seed PDB (con_id 2).

Create a local role in a PDB. (When you are connected to a PDB, you cannot create a common role.)

connect system/oracle@localhost:1521/pdb3_bis

create role hr_manager;

select role, common, con_id from cdb_roles where role='HR_MANAGER';

create role c##r2 container=all;

You should see an error message after executing this statement because you cannot create a common role inside a PDB.



 

Managing Common and Local Privileges

You can grant common and local privileges to common and local users and roles. The privileges become common or local based on how they are granted. They are common when they are granted with the CONTAINER=ALL clause.

• Common privileges are automatically granted to the common grantee (user or role) in each PDB except the seed PDB.
• Local privileges are granted to a grantee (user or role) in a specific PDB.

Grant CREATE SESSION as a common privilege to a common user.

connect / as sysdba

grant create session to c##1 container=all;

select grantee, privilege, common, con_id from cdb_sys_privs
where privilege='CREATE SESSION' and grantee='C##1';

connect c##1/oracle@localhost:1521/pdb2

select * from session_privs;

connect c##1/oracle@localhost:1521/pdb3_bis

select * from session_privs;


Granting a privilege as a common privilege to a local user is not allowed. But you can grant the privilege locally to a local user: CREATE SESSION becomes a local privilege that allows the local user to exercise it only in the PDB and not in another PDB.


Grant the privilege locally to a local user.

connect system/oracle@localhost:1521/pdb3_bis

grant create session to hr container=all;
[you should see an error message after executing this statement. why?]

grant create session to hr;

select grantee, privilege, common, con_id from cdb_sys_privs
where privilege='CREATE SESSION' and grantee='HR';








connect hr/oracle@localhost:1521/pdb2
[you should see an error message after executing this statement. why?]

connect hr/oracle@localhost:1521/pdb3_bis

select * from session_privs;

 

Dropping PDBs:

When you drop a PDB, you can specify to keep or delete the data files. Keeping the data files is required when you unplug a PDB and want to plug it into another CDB (or the same CDB). The data files are reused when plugging in the PDB.


Close the PDBs.

connect / as sysdba

alter pluggable database all close immediate;

select name, open_mode from v$pdbs;



Drop the PDBs, including their data files. 

drop pluggable database pdb3_bis including datafiles;

select name from v$pdbs;

 

Resetting Your Environment:

Perform the following steps to reset your environment prior to repeating the activities covered in this OBE or starting another OBE.


Drop the common user and role that you created.

drop user c##1;

drop role c##r1;

Drop the tablespaces that you created in the CDB root.

drop tablespace cdata including contents;

drop tablespace temp_root including contents;

Open pdb1 and replace the database trigger with a trigger that opens only pdb1 at CDB startup.

alter pluggable database pdb1 open;

create or replace trigger Sys.After_Startup after startup on database
begin
   execute immediate 'alter pluggable database pdb1 open';
end After_Startup;
/

 Summary:

Summary:

In this tutorial, you learned how to manage basic tasks on container and pluggable databases, including creating PDBs from seed PDBs; managing tablespaces and security; and creating common and local users, roles, and privileges.


Resources

• To learn more about pluggable databases, refer to additional OBEs in the Oracle Learning Library.

Introduction to the Multitenant Architecture

This post contains information specific to the Oracle Multitenant option, and contains the following topics:

• About the Multitenant Architecture
• Benefits of the Multitenant Architecture
• Path to Database Consolidation
• Multitenant Environment Documentation Roadmap

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 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 container (also called the root). The root is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong (see "Overview of Containers in a CDB").

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.

Description of the illustration cncpt345.png

See Also:

Oracle Database Administrator's Guide for an introduction to the multitenant architecture

About User Interfaces for the Multitenant Architecture

You can use the same tools for both CDBs and non-CDBs. For example, you can use:

• 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 12ctargets, including non-CDBs, CDBs, and PDBs.
  See Oracle Database Administrator's Guide to learn more about Cloud Control.
• 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.

See Also:

"Tools for Database Administrators"

Benefits of the Multitenant 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-1 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-1 Database Environment Before Database Consolidation

Description of "Figure 17-1 Database Environment Before Database Consolidation"

A typical response to the management problem is to place multiple databases on each server. The problem is that the multiple database instances do not share background processes, system and process memory, or Oracle metadata. Another response is to logically separate the data into schemas or virtual private databases. The problem is that these virtual entities are difficult to manage, secure, and transport.

Benefits of the Multitenant Architecture for Database Consolidation

The process of consolidating data from multiple databases into one database on one computer is known as database consolidation. 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-2 depicts the databases in Figure 17-1 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-2 Single CDB

Description of "Figure 17-2 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.

See Also:

Oracle Database Administrator's Guide

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.

See Also:

"Data Dictionary Architecture in a 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 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 DATABASE clause, 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:

Description of the illustration admin095.png

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

See Also:

• Oracle Database Administrator's Guide to learn how to create a CDB using DBCA or the CREATE DATABASE statement
• Oracle Database SQL Language Reference for more information about specifying the clauses and parameter values for the CREATE DATABASE statement

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:

Description of the illustration cncpt358.png

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.

Description of the illustration cncpt350.png

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:

Description of the illustration admin089.png

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

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:

Description of the illustration admin091.png

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 perform this technique

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:

Description of the illustration admin090.png

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 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.
  See Oracle Database Administrator's Guide to learn how to perform this technique.
• 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.
  See Oracle Database Administrator's Guide to learn how to perform this technique.
• Use Oracle GoldenGate replication
  You replicate the data from the non-CDB to a PDB. When the PDB catches up with the non-CDB, you fail over to the PDB.
  See Oracle Database Administrator's Guide to learn how to perform this technique.

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:

Description of the illustration admin098.png

See Also:

• "Oracle GoldenGate"
• Oracle Database Administrator's Guide for an overview of how to create PDBs

Multitenant Environment Documentation Roadmap

Table 17-1 lists the most important topics for understanding and using CDBs, and includes cross-references to the appropriate documentation.

Table 17-1 Roadmap for the Multitenant Architecture Documentation

Category	Topic	Documentation
Concepts	Overview of CDBs and PDBs	Chapters in Part VI, "Multitenant Architecture", 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 a PDB	Oracle Database Administrator's Guide
Administration	Managing a PDB	Oracle Database Administrator's Guide
Performance	Troubleshooting PDBs	Oracle Database Performance Tuning 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.