Where am I at: CDB vs. PDB? – 12 edition

All right, how many of us use the V$INSTANCE view to verify the instance name and current status of the database after we connect? In Oracle Database 12c, we can still find this information from V$INSTANCE. Breath a sigh of relief, for the moment! What if I connect to a container database and then issue an ALTER SESSION command to move into a different container, i.e. as PDB? Will I get the name of the PDB that I move into from the V$INSTANCE view or do I need to look somewhere else? Lets take a look.

Connect to the container database as usual and use the V$INSTANCE view to see where I’m at.

Lets move into a PDB. I have quite a few PDBs created, lets just use PDB1.

SQL> alter session set container=PDB1;

Session altered.

Did I actually move containers? How can I tell? Instead of selecting INSTANCE_NAME from V$INSTANCE; we have two new SHOW commands that will provide us the information we are looking for. These command are quite simple (SHOW CON_ID & SHOW CON_NAME).

SQL> show con_id

CON_ID------------------------------3SQL> show con_name

CON_NAME------------------------------PDB1

Now that we are confident that we are in PDB1, lets take a look at the V$INSTANCE view again. What you will notice is that V$INSTANCE provides us with information relative to the container database (CDB). It only makes sense that the V$INSTANCE would return CDB information. So, how do we identify items related to the pluggable database (PDB) without the SHOW commands?

Lets take a look at a view that is similar to V$INSTANCE. Enter the V$PDBS view!

This view provides similar information as V$INSTANCE does; yet is only specific to PDBs. If we wanted to find out the container_id, name, open_mode and size of the PDB we are currently connected to, we can use this query:

What is interesting to point out, is that since we used an ALTER SESSION statement to switch to PDB1, the V$PDBS view only lists the PDB we are currently working in. If we want to get a complete list of PDBs within the container database, we need to go back to the root container database and run the same SQL statement.