Container Database Oracle 12.X what you need to understand

A container is a collection of schemas, objects, and related structures in a multitenant container database (CDB) that appears logically to an application as a separate database. Within a CDB, each container has a unique ID and name. The root container, also called the root, is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong. Every CDB has one and only one root container, named CDB$ROOT, which stores the system metadata required to manage PDBs. All PDBs belong to the root.

The root does not store user data. Thus, you must not add user data to the root or modify system-supplied schemas in the root. However, you can create common users and roles for database administration A common user with the necessary privileges can switch between PDBs.

A PDB is a user-created set of schemas, objects, and related structures that appears logically to an application as a separate database. Every PDB is owned by SYS, which is a common user in the CDB regardless of which user created the PDB.

Purpose of PDBs

You can use PDBs to achieve the following goals:

• Store data specific to a particular application
For example, a sales application can have its own dedicated PDB, and a human resources application can have its own dedicated PDB.
• Move data into a different CDB
A database is "pluggable" because you can package it as a self-contained unit, and then move it into another CDB.
• Isolate grants within PDBs
A local or common user with appropriate privileges can grant EXECUTE privileges on a package to PUBLIC within an individual PDB.

Names for PDBs

PDBs must be uniquely named within a CDB, and follow the same naming rules as service names. Moreover, because a PDB has a service with its own name, a PDB name must be unique across all CDBs whose services are exposed through a specific listener. The first character of a user-created PDB name must be alphanumeric, with remaining characters either alphanumeric or an underscore (_). Because service names are case-insensitive, PDB names are case-insensitive, and are in upper case even if specified using delimited identifiers

find out if the database has been created as a CDB or not

-- find out if the database has been created as a CDB or not
 select cdb from v$database;
## You can check the containers (or PDBs) created in a database in a view named V$PDBS
select con_id, dbid, name
from v$pdbs;

 *Note how the DBIDs are also different for each PDB. 
 *-There are two striking oddities in this output:
 *There is no CON_ID of 1. 
 The answer is simple - there is a special container called the "root" container, known as CDB$Root that is created to hold the metadata.
 This container has the CON_ID of 1.
 *There is a PDB called PDB$SEED, which is something we didn't create. You will get the explanation of this PDB later in the article.
 *There are new built-in functions to identify PDBs from their details without querying the V$PDBS view.

Creating PDBs

-- here we create a pluggable database named orclpdb2
create pluggable database orclpdb2
admin user orclpdb2 identified by orclpdb2
roles=(CONNECT,DBA)
/

alter pluggable database orclpdb2 open;
-- errors can appear during this process

One other thing worth mentioning is that a pluggable database is fully compatible with a non-CDB.
In fact, Oracle has something it is calling the PDB/non-CDB compatibility guarantee, 
which states that anything you would do in a non-CDB would also work in a PDB. 
This compatibility guarantee is important when it comes to certifying things 
like third-party vendor products to work in a multitenant architecture.

How to start and stop pluggable databases in Oracle 12c

Because the instance architecture of pluggable databases is entirely different from a non-container database, one would imagine that managing their state of readiness is also different. Well, it’s true. The first thing to remember is that because the CDB maintains the instance for which all PDBs share, that instance must be up and open for people to be able to connect to the PDBs. Starting and stopping the CDB is not different from non-CDBs. The next thing to remember is that when you start a CDB, all of its associated PDBs are left in MOUNT state, which means that, by default, they are not opened with the CDB. Unfortunately, 12cR1 doesn’t offer an option to change this behavior. However, 12c does provide a new type of trigger that will fire if it detects a CDB opening and will then open specified PDBs. See the Oracle documentation for further information on setting this up. After starting and opening a CDB, you can open any corresponding PDBs like so

`
alter pluggable database orclpdb2 open;
-- Pluggable database altered.
-- or
alter pluggable database all open;
`
To close PDBs, you can essentially do the opposite of the preceding commands:
`
 alter pluggable database devpdb1 close;
 -- Pluggable database altered.
 -- Or 
 alter pluggable database all close;
` 
To drop pluggable database
`
drop pluggable database orclpdb2 including datafiles;
` 
You can unplug a PDB from a CDB with this syntax: 
`
alter pluggable database 
   orclpdb2
unplug into
   '/{installationdir}|{backupdir}/orclpdb2pxml';
`

reference0 reference1