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:
— Andreas Buckenhofer (@ABuckenhofer) January 22, 2015
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 126.96.36.199. Going into multitenant or single-tenant will a lot of change.
For 2015 – going to the latest patchset of 12c, which is the 188.8.131.52 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 184.108.40.206 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.