• January 7, 2015

Oracle Multitenant - Should you move to a single CDB/PDB architecture?

Guest Author

Note: Something happened to this original copy of this post. I'm not sure what it was, but somehow it was like a draft copy ended up being posted and it lost almost half it's content. I have re-created the post. So, for those of you who saw the earlier edition - I have no idea what happened. It actually happened to me twice yesterday - and then this time - very frustrating.

You are probably aware that there is a new feature in Oracle Database 12c called Multitenant. Multitenant provides the ability for a single instance to manage multiple databases. At the higest level the Multitenant architecture includes:

  • The Multitenant Instance - This is really my own name, for what Oracle calls the Database Instance in the documentation. I'm calling it the Multitenant Instance simply to distinguish between an instance supporting a Multitenant database and one that is not.
  • A Container Database (CDB) - This is the type of database that is created when that database supports Oracle's Multitenant option. The container database is also called the ROOT container and is called CDB$ROOT within the data dictionary views of the CDB.
  • The Root Container Database - This container (database) is created automatically when you create a Multitenant database. The Root container contains the data dictionary for the CDB
  • The Pluggable Database - These are the databases that are stored within the CDB.

When I talk to people about Multitenant, I often get very excited responses. However, when I mention that this is an option that requires a license, they are often very disappointed. Usually their ability to purchase such options is limited to budgets, budget cycles and other constraints.

There is a loophole in all of this, that provides a way for you to at least start moving towards this architecture. This is the fact that you can actually create a CDB, and populate it with a single PDB - all without needing an additional license. Even though you can't populate the CDB with any more than 1 PDB, this still offers some unique benefits:

  1. You can start taking advantage of the cloning features of Multitenant between two different CDB. For example, if you have one CDB with a "Gold" copy of a database, you can very quickly clone that database, using a database link, to another CDB database. This can make refreshes and new database creations much easier than using something like Data Pump.

  2. You can start taking advantage of the much easier upgrade process that the Multitenant architecture provides. The steps to upgrade a Multitenant database are far easier (I think) than a regular database.  In summary, you simply unplug the database in the old CDB, plug it into the new CDB (which you have created running the new version of the software you want to upgrade too). You then run a single script to upgrade and boom! Database upgraded.

    In fact, if you look at the instructions on how to upgrade from to in place and compare them to the instructions on doing an upgrade using Multitenant, you will find the Multitenant upgrade instructions much easier.

  3. Perhaps the most compelling reason is simply self-interest. Multitenant is the direction of the future. If you are an older DBA, you might recall the days when RAC (or OPS if you are really long in the teeth like me) was just a pipe dream and nobody you used was using it... unless they were a big shop with lots of money and hardware.

    Flash forward to today and how many job postings do you see that do not include some kind of requirement or preference for RAC experience. RAC, over time, has developed a very real presence in the Oracle landscape, and it is going to just continue to do so.

    Multitenant is going to go the same way. If you get ahead of the curve now, you will develop skills that will be very much in demand in the near future. Additionally, you will be positioning your infrastructure for the future. You will be preparing for the day when your organization has decided that it's time to take advantage of all of the features of Multitenant - and there are many.

So - what is my recommendation? Personally, I think that when you start upgrading to 12c from 11g or 10g - that is the time to move the databases into a CDB. Some might want to take a two phase approach - upgrade to 12c and wait a while, and then later move into a Multitenant infrastructure. This seems, to me, to be a waste of time and money. It will require two separate projects, two separate iterations of testing, two separate outages - though these can be minimized with something like Oracle GoldenGate.

It's often hard enough to get one large enterprise spooled up, coordinated and moving to do even a single large upgrade project. Splitting it into two large projects just makes things more complex from an execution point-of-view. Of course, every environment is different and has different needs and requirements, so moving to Multitenant right now might not be the right move for you. The Oracle database still has a few features that have not yet been migrated into the Multitenant architecture, but those are fewer now in - and will decrease over time - quickly I suspect.

I'd love to  hear your thoughts about moving to Oracle Database 12c and Multitenant!

Join the discussion

Comments ( 8 )
  • guest Thursday, January 8, 2015

    Should you move to a single CDB/PDB architecture?

    yes? no? what's your opinion now?

  • Robert Thursday, January 8, 2015

    Sorry about that. I have no idea what was going on with the blog yesterday. I was having more problems trying to post this post. I'm not sure if it was my browser or if it was the blog site that was having problems but I was about ready to throw my computer into my swimming pool last night. I finally thought I got it posted. Your comment made me aware of the problem and I re-did the post. It LOOKS like it's all there now... we shall see.


  • Tim Hall Friday, January 9, 2015


    I think people should assume they will be using lone-PDB, unless something prevents them doing so along the way. If your project demands a feature that is currently not supported under multitenant, the decision has been made for you. Apart from that I say go with lone-PDB all the way. Going along with your RAC observation, life is certainly different under multitenant and if you don't get started soon you will get left behind.

    Note. I forgot to put this blog into my feed. I only have your old blog location. Now I've remembered to add it, it's nice to see your active blog again, even if I am about 6 months late to the party. :)



  • Robert Friday, January 9, 2015

    Glad to have you back Tim! I agree with your comments completely. I think Multitenant is a BIG deal and people don't want to get left behind!

    Thanks for finding me!


  • guest Tuesday, January 13, 2015

    I presume that there are no noticeable overheads (performance, SGA sizing, data dictionary, database disk space) when running a CDB with a single PDB versus a non-CDB environment ? Applications can see the PDB via a service name.

    DBAs need to update scripts that rely on ORACLE_SID.

  • Tim Hall Tuesday, January 13, 2015


    The documentation claims there will be no performance impact of using lone-PDB, which sounds correct when you think about how this stuff is built.

    The SID/Service issue is actually quite a big problem for many people. If you have relied on OS authentication from CRON jobs you will be upset. I wrote an article about the solutions for this. :)




  • guest Monday, January 26, 2015

    "You can actually create a CDB, and populate it with a single PDB - all without needing an additional license."

    Does this mean that for every database in a rac cluster , you can create same number of CDBs, and then plug theses databases as PDB to each CDB ?

  • guest Thursday, February 5, 2015

    Sorry for the delay in approving comments... I've been a bit covered up. To answer the RAC/CDB question - yes. You can create RAC CDB's and each can have the one PDB without a license. So, you can have many CDB's with one PDB on a given server.

    >>The SID/Service issue is actually quite a big problem for many people. If

    >> you have relied on OS authentication from CRON jobs you will be upset.

    I think it really just points out that writing your own scripts is not the right solution. Use OEM if at all possible. This eliminates problems like this... I realize it's not always possible, but at the end of the day it's a more scalable solution.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.