Did you read my last post about the Multitenant Architecture? Today, we are going to go a bit deeper and learn about PDBs and how to create them.

PDBs can be created in multiple ways, however one thing is for sure, when you create the PDB you must be connected to a root, either the CDB Root (CDB$ROOT) or the application root of the application container, otherwise you will get an error. I think this is obvious, but I’ll state the obvious…you can only create PDBs in a Multitenant Architecture, not in a non-CDB database.

When you create a PDB, a GUID is assigned to it at creation time, a globally unique identifier. The GUID is mostly used to generate the directory name where the datafiles for the PDB will reside. Do not confuse GUID with DBID, these are two different things. Below is an example of the GUID usage in the datafile name.

PDBs can be created in many ways: starting from scratch, cloning, relocating, plugging in, or referencing as a proxy. Each method has also multiple ways to go about it, which we will cover in future post.

Today we’ll look at creating PDBs from scratch, that is with the CREATE PLUGGABLE DATABASE statement. The PDB is created either from the PDB seed or from the application seed database. During this process the seed files are copied to the location of the new PDB, and are associated with the new PDB. This is why we have a seed PDB, to be able to create quickly PDBs from it.

You can create a PDB in a one line statement, with very few clauses, but also you can use a more complicated create statement, with multiple clauses.

With this statement, you create the PDB either in the root container, if you are connected to the root, or in the application root if you are connected to the application root. If you create the PDB in the application root, then you basically created an application PDB. This will make more sense, when I cover the application containers in a future post. Once the database is created, it will be in MOUNTED state, and you will need to open it:

The create command completes very fast, the tablespaces from the seed are created (SYSTEM, SYSAUX, TEMP, UNDO), and the administrator user, a local user, in this case DRADMIN, is also created in the PDB. This user has the following role granted by default: PDB_DBA, with create pluggable database, and create session privileges in it.

The create database statement could be much more complicated, with different clauses. You can specify predefined roles to be granted to the administrator, you could specify other tablespaces to be created within the same statement, constraints on the tablespace sizes, and datafile location when not using OMF (instead of using the GUID naming convention). Below are some examples.

Questions you might have about the database:

• How do I know if the database is a CDB or non-CDB?
• Can I see the datafiles of all the PDBs, in one spot, or do I need to connect to each PDB?
• Is the PDB part of the root container, or application root container?

These are all great questions to ask, I would ask them myself. So let’s see the answers to them.

Is the database CDB or non-CDB?

Check out the datafiles from within the root container. For this you would use the CDB_DATA_FILES view, and the DBA_PDBS. Please note that by default the PDB$SEED datafiles are not included. A hidden parameter needs to be set, in order to see the PDB$SEED datafiles. This is an expected behavior. Also the DBA_PDBS has no entry for the root container, but my statement will also show you that information.

Is the PDB part of root container or application container?

Today’s email is a bit longer than usual, and I really hope you found it useful! Here is a mind map to put everything together for this post.