Infrastructure at your Service

Franck Pachot

Stay with non-CDB or go to CDB?

By Franck Pachot

This is a question that starts to be raised quite frequently. Oracle released the multitenant architecture 1.5 year ago. And now says that the previous architecture – known as non-CDB – is deprecated. What does it mean? Do we have to go to the CDB architecture even if we don’t want to use/pay multi-tenant?

It started like that on twitter:

The link shows the official statement. The blog post is from Mike Dietrich who is the ‘Mr upgrade’ at Oracle and the statement is also in the documentation.

What is the non-CDB architecture? I don’t like negative names. Most of Oracle customers have non-CDB on a non-Exadata machine…
I’ve explained the CDB architecture internals in several blog posts: 1, 2, 3, 4 and there is also the OOW14 presentation from Vit Spinka about it.


  • A non-CDB stores all metadata (system ones and user ones) in the same dictionary.
  • A CDB stores user metadata only in the database dictionary, which have links to a common dictionary that contains the system metadata. The common container is called ‘root’ and the database is called ‘pluggable database’.

The first one – the non-cdb – exists for years. You can see both SCOTT and system objects are in OBJ$



But through the releases a lot of oracle code was not only added to the binaries, but also in the databases in stored procedures. All those dbms_xxx packages for example. And if you have several databases of the same release, even if you share the ORACLE_HOME, you duplicate all this system dictionary.

Then in 12c came the multitenant architecture. It’s called multi-tenant because you can have several pluggable databases linked to the same root container. You need to have Enterprise Edition and the Multitenant option for that. Oracle has made a lot of changes for that and maintaining different code path for the non-CDB and the CDB architecture cannot be efficient. This is why the non-CDB is deprecated: we can expect that only the mutitenant code will evolve in the future.


So what if you are in Standard Edition? Or in Enterprise Edition without the multitenant option? You can still use the CDB architecture. The only limitation is that you can’t have more than one pluggable database (well more than two because SEED counts as a pluggable database). It’s called ‘single-tenant’

Let’s put it clearly. Without the need for additional license you can have a CDB database as long as:

select count(*) into aux_count from v$pdbs where con_id > 2;

returns no rows.
So, this is not a licensing issue… as long as you are sure that nobody creates additional PDBs


The first point to consider is the stability. The CDB architecture is new: less than 2 years. There are bugs. And there are fixes. That does not mean that we can’t use it but we need to test it a lot. And it’s not only testing the application, but also all our operations, monitoring, etc. Are you ready to always connect to your database though a service? Are you sure your recovery procedure works in multitenant? Do you know if you need to install Statspack in the ROOT or in the PDB?


If you are going to multitenant to consolidate several databases, then you will have an architecture that need less storage and less memory.
But if you are going to single-tenant, then all your databases will be bigger. And there are two reasons about that.
The first reason is here:


When you create a CDB you have to install all components. It’s grayed. You cannot uncheck.
Components that you don’t use takes space and will take time when you will need to upgrade.
That will probably be addressed in future releases, but for the moment if you have small databases that do not use all those components, the you will probably prefer to stay in non-CDB.
The second reason is here. I have migrated the following database to single-tenant

List of Permanent Datafiles
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    914      SYSTEM               YES     /u02/data/u01/oradata/DB1/system01.dbf
2    1094     SOE                  NO      /u02/data/u01/oradata/DB1/SOE.dbf
3    840      SYSAUX               NO      /u02/data/u01/oradata/DB1/sysaux01.dbf
4    96       UNDOTBS1             YES     /u02/data/u01/oradata/DB1/undotbs01.dbf
5    1220     EXAMPLE              NO      /u02/data/u01/oradata/DB1/example01.dbf
6    141      USERS                NO      /u02/data/u01/oradata/DB1/users01.dbf

And here is the result:

List of Permanent Datafiles
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    785      SYSTEM               YES     /u02/oradata/STCDB/datafile/o1_mf_system_bd1nsjms_.dbf
2    263      PDB$SEED:SYSTEM      NO      /u02/oradata/STCDB/SEED/datafile/o1_mf_system_bd1nsoc8_.dbf
3    702      SYSAUX               NO      /u02/oradata/STCDB/datafile/o1_mf_sysaux_bd1nsyt8_.dbf
4    581      PDB$SEED:SYSAUX      NO      /u02/oradata/STCDB/SEED/datafile/o1_mf_sysaux_bd1nt428_.dbf
5    908      UNDOTBS1             YES     /u02/oradata/STCDB/datafile/o1_mf_undotbs1_bd1nt7h1_.dbf
8    2        USERS                NO      /u02/oradata/STCDB/datafile/o1_mf_users_bd1nvwoc_.dbf
23   383      STDB1:SYSTEM         NO      /u02/oradata/STCDB/DB1/datafile/o1_mf_system_bdkzkjyg_.dbf
24   611      STDB1:SYSAUX         NO      /u02/oradata/STCDB/DB1/datafile/o1_mf_sysaux_bdkzkjym_.dbf
25   1220     STDB1:EXAMPLE        NO      /u01/oradata/STCDB/DB1/EXAMPLE.dbf
26   1094     STDB1:SOE            NO      /u01/oradata/STCDB/DB1/SOE.dbf
27   141      STDB1:USERS          NO      /u01/oradata/STCDB/DB1/USERS.dbf

I’ve done it with transportable database, so that I’ve not the problem I’ve described in previous posts about the noncdb_to_cdb.sql that drops system metadata but leaves the empty space in the SYSTEM tablespace.

My user tablespaces have the same size. The SYSTEM is bigger when we add the ROOT and the PDB ones. And it’s even worse with SYSAUX. My 4.2 gigabyte database has become a 5.7 gigabytes one. Note that in order to be fair I didn’t want to count the same overhead twice and I’ve done the test with a database that had all components installed.
In addition to the space, I’ve more datafiles, larger memory structures, etc.
For a large database, that overhead doesn’t matter. But for small databases, going to single-tenant is definitely a bad idea for the moment.
My advise: if you have small databases, either you consolidate in multi-tenant or you stay in non-CDB at least until 12.2

And don’t forget: at the exception of conventional export/import the non-CDB to CDB migration is a one way operation.


But is there anything better in single-tenant? Currently, I don’t see anything. It’s not faster to plug a database into an higher version CDB when we compare it to conventional upgrade. It’s not easier to manage. Cloning PDB is not easier that transportable database. And several features are not yet compatible with CDB architecture.

I’ll probably change my mind if in future version a ‘flashback pluggable database’ is possible. Why? Because flashback can be a very good solution for continuous integration in order to quickly get the database to the same state during the automated tests. But currently, what is long is that we have to close the database, and closing the database means restarting the instance later. Because a pluggable database can be closed and re-opened very quickly we can expect that a flashback pluggable database would be a quick operation. But that’s probably for 2016.


Yes it’s deprecated, but not yet desupported. Don’t worry! The non-CDB will still be supported for several years. And when we don’t buy all the options, we are used to use deprecated features anyway: Statspack because we don’t have Diagnostic pack, Outlines because we cannot use SPM in Standard Edition, partitioned views because we don’t have the partitioning option, etc.

What we expect from a software is stability (no big changes that may come with bugs, regressions, and changes in our code or procedures) and support (bug corrections, new features, etc). Staying in 11g will make any new SR difficult even in Going into multitenant or single-tenant will a lot of change.

For 2015 – going to the latest patchset of 12c, which is the for Enterprise Edition, with the latest PSU, and in the non-CDB architecture, is probably the best compromise we can do for stability and support. I hope that this patchset will be available soon for Standard Edition as well.

Update April 2016

One year later after this post I feel the need to refine the scope of this post. First, it’s clear that I’m talking about small databases here. The overhead of having multiple SYSTEM tablespace, become insignificant when the database is in hundred of GB. Second, Multitenant was new in 12.1, but it’s nearly 3 years old now. The first patchset has stabilized lot of problems. And the plug-to-upgrade will improve at each release. And finally, with experience, I realized that I was wrong when saying that unplug/plug has no big benefit over transportable tablespaces. Actually it’s the opposite. Because metadata comes physically with the SYSTEM tablespace, the time to transport a pluggable database is more predictable. And it’s available in Standard Edition.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Franck Pachot
Franck Pachot

Principal Consultant / Database Evangelist
Oracle ACE Director, Oracle Database OCM 12c
AWS Database Specialty certified, AWS Data Hero
Oak Table member

RSS for this blog: feed
Twitter: @FranckPachot
LinkedIn :
Podcast en français: DBPod