Pluggable Databases - Expert Consolidation in Oracle Database 12c - page 253

As you can see from the timing information this anonymous block was completed in a few minutes. The time to
deploy a new environment for a requesting business unit in your organization matches the time it takes to execute the
request to create a schema in a pre-12.1 database. Even though this process is already fast, it can be further enhanced
by using another automated database build procedure.
Assume for example that your build process creates a CDB as described but doesn't stop there. You could have a
PDB all set up to match your organization's standards on a shared location in your network exported via NFS. You can
clone and plug the reference PDB into the new CDB as a reference for future user (PDBs). Or maybe create a CDB with
common users that are required by the database management and monitoring tools. That way you reduce the latency
of cloning a PDB over the network and pay the price of over-the-network-cloning only once. Yet you have a fully
working reference PDB you can clone locally.
Chapter 3 presents a few considerations about storage classes or tiers. Using the file_name_convert clause in the
“create pluggable database” statement you can cater for these as well and create the PDB on premium storage if so
requested.
This leaves one concern to the administrators: how can Oracle ensure that a “runaway” PDB does not take all
resources of the server and thus starves out everybody else of resources? This question has been anticipated by Oracle
in the requirements design phase and as a result Database Resource Manager (DBRM) has been enhanced to deal
with inter-PDB resource requirements. Later in this chapter you can read how you could start managing resources
within a CDB.

Opening and closing PDBs
You read earlier in the chapter that a PDB is not accessible immediately after its creation. This is how the process has
been defined. The lifecycle states for a PDB are:

1. MOUNTED: the Pluggable Database is not accessible for users, and information about it

will not be displayed in the CDB% views.

2. OPEN read-only: accessible for queries, and ready to be cloned, but no modifications

possible. The PDB must specifically be opened with the “read only” clause to set it into
this mode.

3. OPEN read write: the PDB is available for users. This is the default state when opening

the PDB.

4. OPEN restricted: opens the PDB read write, but allows only uses with the “restricted

session” privilege to connect.

Additionally, after each restart of the CDB, all PDBs currently plugged in will be back in MOUNTED mode
irrespectively of their previous open mode. Once the CDB is opened, you can open your PDBs. Luckily the syntax for
doing so is straightforward, and it is possible to open all PDBs in a single command.

SQL> alter pluggable database all open;

You can even instruct Oracle to open all PDBs except for some you don't intend to open. The exception of the
rule is the seed database, which will always be open read-only, ready to be cloned.

SQL> alter pluggable database all EXCEPT PDB5 open;

Pluggable database altered.

The open mode of the PDB has to be compatible with the open mode of the CDB however. In other words, if you
opened the CDB in read-only mode, then you cannot open a PDB in read write mode.