What’s All the Buzz Around Oracle Multitenant?

posted December 11, 2015, 4:03 PM by

Mike Stone (@HoBMStone), CIO

It seems like every time I turn around this fall, I hear questions about “12c Multitenancy” or pluggable databases. This probably means that Oracle Sales has initiated a campaign around this new (separately licensed) feature. So, what’s all the buzz about?

Oracle Documentation (Summary)

The Problem

According to Oracle’s June 2013 12c whitepaper, Oracle Multitenant, it’s all about consolidation and maximizing consolidation density in order to reduce operating expense as well as manage hardware sprawl. They also mention capital expenses in terms of inefficient use of CPU and memory resources. Nowhere does the author mention reducing capital expense as a result of more efficient use of licenses, although that should be an obvious corollary. Instead, the only mention of licensing in the document centers on the additional licensing required for utilizing this new feature.

According to the “Customer Challenges Addressed by Multitenant” section on page five of the whitepaper, most Oracle databases reside on a dedicated server. This is considered wasteful, and leads to the natural desire to consolidate your Oracle workloads. The next few pages of the document describe the challenges with traditional consolidation techniques prior to 12c, and these are valid challenges we’ve probably all experienced.

Finally, they wrap up the list of challenges with provisioning and patching, which are tasks that consume a significant amount of an Oracle DBA’s time and often incur database down time.

The Oracle Solution
Of course, the whole point of the whitepaper is to demonstrate that the new “12c Multitenant Architecture” is the answer to these common challenges. But first we need to establish some terminology.

Container Database (CDB) = the container in which the Oracle software runs. This is mainly the set of kernel processes, SGA and “overhead” traditionally associated with a running instance. The new CDB itself however, does not contain any user data.

Pluggable Database (PDB) = the database we typically associate with a “non-CDB” environment. From a client perspective, there is no difference between a traditional database instance and a PDB.

In 12c, you have the option of creating a database as a traditional instance or as a CDB with a PDB in it. The syntax for managing this is incremental and does not present a steep learning curve, but as the whitepaper demonstrates, it touches a lot of core Oracle code and makes some sweeping changes to the kernel architecture.

All of this was done to allow you to consolidate multiple Oracle workloads onto a single physical server and more-or-less seamlessly move databases from server to server with simple point/click or SQL commands. However, the reality of the point/click is dependent on Oracle Enterprise Manager (OEM) and to date is somewhat lacking. Can somebody say hypervisor and vMotion?

Thoughts and Impressions

So What?
Now, you can create a CDB and a single PDB in any edition of 12c and still be compliant with the base feature set of that edition. However in order to create, or plug-in, more than one PDB Oracle requires additional licensing. In other words, in order to realize the benefits of consolidation that Oracle is promoting as the reason to adopt Multitenant, it’s gonna cost ya. And they want to “help” you with your consolidation efforts by using Oracle technology, so that while you’re trimming your core technology license and support, you are simultaneously supplementing your spend with Oracle by adding the feature licenses – how thoughtful…

This architecture provides the same basic structure and capability that has been native to Microsoft SQL Server for decades. So, why is Oracle all excited about this seemingly underwhelming new feature? My thought is because it’s one of the few things they have to sell that Oracle Sales can get their arms around. My first question to customers considering 12c Multitenant, is this: “Are you using the feature in your Microsoft environments?” And the response is usually something along the lines of “No, not really”. Well if that’s the case, then what would motivate you to pay Oracle to have the same capability in their world?

Isn’t Consolidation a Primary Argument for Virtualization?
Why yes it is. You can achieve the same benefits described for 12c Multitenant by licensing and building a virtual infrastructure. And, depending on your scale, doing so could be much less costly than adding the Oracle licenses for Multitenant. PLUS with the adoption of a virtual infrastructure, you gain the same benefits for all of your database and other workloads as well.

Oracle’s list of consolidation challenges is very nearly the same list that VMware and Hyper-V put together for the general case. Although the whitepaper language is Oracle-specific, the challenges are the same: isolation, reconfiguration, relocation, and performance/contention.

In the hypervisor space, we inherently have isolation of workloads in virtual machines instead of physical servers. We also have simple point-and-click interfaces to solve these problems, as well as automated tools, to analyze and relocate workloads in real time with no interruption of service. We can clone, patch, migrate, protect, and backup isolated workloads with little regard for the products used by, or contained within, the virtual machine. We can relocate with vMotion and respond dynamically to workload demands with automated tools such as DRS.

Why Change?
A big point the Oracle whitepaper makes is that this new change is non-disruptive to clients and applications. Well intuitively, there’s been a change so they might have broken something, but they claim they haven’t and even offer a “guarantee” of sorts. With a virtual machine, I don’t need to change anything in terms of either technology or operations, and I can run Oracle in its traditional mode that’s tried and true while bypassing the shiny (slippery?) new paths of execution.

A chunk of the document addresses conversion from non-CDB to CDB. Why expend the learning time and effort to do this when it’s not necessary with a hypervisor implementation?

The operational procedures in the white paper tout cloning as a key technology that reduces downtime and administrative workload in conjunction with PDB. Cloning under a hypervisor accomplishes the same operational benefits without changing how I manage my Oracle workloads – again, why change?


Why pay Oracle for a proprietary solution that only helps consolidate your Oracle workloads and requires a significant effort to implement? A cheaper, more flexible solution exists and is an inherent part of a virtual infrastructure. This solution will also address the same challenges for all your x86-based workloads and software.

Simple cost/benefit analysis will probably show that you’ll spend (a lot?) less for a virtual infrastructure and gain additional features, while simultaneously reducing your Oracle license and support costs. So then is it any wonder that Oracle is acting so hostile toward virtualization while simultaneously developing and touting features to counter or hinder its adoption?

Share with your networkTweet about this on TwitterShare on LinkedInShare on FacebookDigg thisEmail this to someone


  • Danielle says:

    Thank you for this insightful article. It’s interesting that you write that virtualization is more effective than Oracle Multitenant after conducting a cost/benefit analysis, because this Managing Director at a tech company writes the exact opposite in an IT Central Station user review.

    In his review of Oracle Multitenant, this Managing Director writes, “Some of my customers are using virtualization (mainly VMware), while others are running up to 20 databases on one server. Two of them have consolidated their schemas into two big databases. The reason for all of them is to make better use of the hardware. Virtualization is nevertheless a waste of space because every guest has its own memory allocated as well as its own software stack with OS and Oracle software. Running many databases on one server has huge impacts on the availability, especially for maintenance and consolidation on schema-level, which will even make maintenance worse. This is because you need to find one window where you can patch your database for all applications – that’s a lot of discussions. So for all of them, we are now testing and implementing Multitenant database.” You can read the rest of his review here: https://goo.gl/gLRXrR.

    I hope this is helpful in providing alternative views to this dialogue.

    • Mike Stone says:

      Thank you for the comment, but it appears you may have missed the point of both articles.

      Both make the same arguments to isolate database workloads and prevent the end user from feeling the pain of upgrades or patching of databases that are not part of their domain. The article you reference provides a partial solution to that end, but still requires multiple installations of Oracle software with the ability to clone the Oracle home on demand in order to patch it separately.

      As I already mentioned, in such cases, multi-tenant does then allow you to migrate a database to a new home that can be patched separately from the others. The ability to do this move is also subject to varying degrees of outage.

      The quote from the article is also mixing references. You need to read it carefully to understand the intent of the author is primarily to discredit the idea of consolidating 20 database schemas into a single database instance – a point we clearly both agree on.

      Finally, the critical argument he makes is that the extra effort required to clone Oracle Homes and patch isolated database binaries under multi-tenant, along with the one-off nature of that administration, outweighs the ‘overhead’ of maintaining separate O/S installations on VMs with a standardized deployment. It’s a subtle distinction with one solution requiring hardware overhead and the other requiring additional administrative overhead to solve the same problem.

      These days, hardware tends to be the least expensive component of the three biggies (people, license, hardware), and the overhead of the O/S is much smaller than the overhead of Oracle. So, the mix of technology and ‘overhead’ that is right for your environment, as well as whether you choose to pay Oracle, VMware, or both, is obviously up to you.

  • Tim Hall says:


    I’m a big fan of VMware and have been for over a decade. My current company uses VMware for almost all Oracle databases and WebLogic installations. I’m also not a fan of paying for the new multitentant option, as I believe it should be free. Having said that, I think there are some aspects of your post that don’t ring true to me as a DBA.

    “same basic structure and capability that has been native to Microsoft SQL Server for decades”
    Actually, it is capable of quite a bit more than what we get out of the box for MS SQL Server and MySQL, but I can see why people think it is the same. On the surface it seems very much so, but dig deeper and there is a whole lot more.

    “Isn’t Consolidation a Primary Argument for Virtualization?”
    Well, it’s one of the big reasons that virtualization exists in its current form today, but virtualization is by no means the only way to consolidate database workloads. We could use Virtualization, Containers, Multi-instance consolidation, schema consolidation and of course the multitenant option. With the exception of the new multitentant option, my company users all of them in combination. Virtualization gives you the greatest flexibility, but it also brings with it the greatest overhead. Running a bunch of VMs is so heavy compared to all the other methods, but of course you get other benefits. If feel putting a single method forward as being “the way to consolidate” is not realistic, when Oracle DBAs havealways, and still do, use multiple methods since before virtualization became mainstream.

    “A chunk of the document addresses conversion from non-CDB to CDB. Why expend the learning time and effort to do this when it’s not necessary with a hypervisor implementation?”
    Well, that’s rather short-termism. Oracle have deprecated the old non-CDB architecture, so some time over the next few years you are going to have to learn it, so why not now? My company aren’t planning to use the new option, but I still have to learn it, and in doing so can see a whole bunch of benefits we could get if we were to pay for it, even when running on VMware, which is our standard approach. So much so, that we will probably go single-tennant (CDB with 1 PDB) for all our systems, to take advantage of some of the new features, without the cost of the option.

    “Cloning under a hypervisor accomplishes the same operational benefits without changing how I manage my Oracle workloads – again, why change?”
    Cloning of an Oracle database involves so much more that just having a copy of the whole machine. In many cases, copying the machine would significantly increate the workload, as the post-clone configuration would increase massively. I would much prefer to leave the VM alone and just clone the database, given the choice. Especially if this is one of several databases running on the VM. Once again, if you consider each consolidation technique as an individual, you are not getting a true reflection of how Oracle DBAs consolidate workloads. The introduction of snapshot cloning means that, storage permitting, the database clone is almost instantaneous, from a single command. Why clone a whole VM when his is so much easier.

    As I keep saying, DBAs use a combination of consolidation approaches simultaneously. Picking any one and saying it is “the best” or “the easiest” is not real life. 🙂



    • Tim,

      I was hoping (and expecting) this article would generate lots of dialog. Thank you for being the first to respond. First, let me say I agree wholeheartedly with the arguments you are presenting. I am, and always have been, a fan of picking the best of breed in terms of finding the “right” solution.

      While Oracle has definitely tried to add some value to the pluggable DB concept, and while they have baked a significant amount of operational complexity into the solution that does indeed give it some advantages over the Microsoft equivalent. In my opinion, at the end of the day, the benefit is comparable.

      And, yes I will concede that the article is somewhat slanted toward a single solution. However, with limited attention span that blogs typically get, it’s important to make a concise point and make it with as little verbiage as possible.

      Again, thank you for a very insightful and thought provoking response!

Leave a Reply

Your email address will not be published. Required fields are marked *


Share with your networkTweet about this on TwitterShare on LinkedInShare on FacebookDigg thisEmail this to someone