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?

Conclusion

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?