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:
- 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.
- 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 220.127.116.11 to 18.104.22.168 in place and compare them to the instructions on doing an upgrade using Multitenant, you will find the Multitenant upgrade instructions much easier.
- 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 22.214.171.124 - and will decrease over time - quickly I suspect.
I'd love to hear your thoughts about moving to Oracle Database 12c and Multitenant!