Deprecation of Non-CDB Architecture in Oracle 12c
January 26, 2015 26 Comments
Back in July 2013, Oracle released the latest version of its flagship database product, Oracle 12c. Among the usual fanfare was information about a number of new options – including one known as Multitenant. With the Multitenant option, databases use a new architecture which features a container database (or CDB) which in turn contains one or more pluggable databases (or PDBs). Use of Multitenant requires a licence – which at the time of writing retails at $17,500 per processor (perpetual) plus 22% per annum for support.
This post is not intended to discuss the way Multitenant works – if you want to read more about it, Tim has a great set of articles about Multitenant here. But keep in mind that you can choose to install the Multitenant feature or not. If you do install it, you can create a single PDB within your CDB without requiring the license. As soon as you use more than one PDB the license is required.
What I want to talk about is Oracle’s attitude to its customers and what seems to me to be breathtaking arrogance. Personally I can think of three very good reasons why I might not want to use the single PDB within a CDB configuration which does not require a Multitenant license:
- Multitenant requires additional configuration and the use of new administrative commands, which means re-writing admin procedures and re-training operations staff
- Multitenant is an entirely new feature, with new code paths – which means it carries a risk of bugs (the list of bug fixes for the 12.1.0.2 patchset contains a section on Pluggable/Container Databases which lists no fewer than 105 items)
- With the Multitenant option installed it is possible to trigger the requirement for an expensive set of licenses due to human error… without the option installed this is not possible
So it seems to me that, while Multitenant might be an interesting and useful new feature to evaluate, it is not something that I would want to be forced into using on production environments just yet. As always, people who manage production environments are conservative in their attitude to risk.
And that’s why I’m surprised to see this deprecation notice in the 12.1 documentation:
The non-CDB architecture (i.e. the old way of building a database without CDBs and PDBs) has been deprecated in 12c and “may be desupported or unavailable” in later releases of Oracle Database. In other words, you need to change to using the CDB and PDB configuration now, even if you do not plan to purchase the Multitenant option.
It would be nice to have the choice, wouldn’t it?
Deprecated versus Desupported
OK so first let’s just remember that the term deprecated does not mean the same as the term desupported. We can dip back into the documentation to define these two important terms:
“By deprecate, we mean that the feature is no longer being enhanced but is still supported for the full life of the 12.1 release. By desupported, we mean that Oracle will no longer fix bugs related to that feature and may remove the code altogether.”
– Oracle Database 12c Upgrade Guide
It seems that Oracle will still support the use of non-CDB databases and will continue to do so for the lifetime of the 12.1 release. But, if you were designing a new system right now, it would take some confidence to choose a configuration which is deprecated and already living on death row.
And there’s more. The deprecation notice says there are some features that still do not work with the CDB architecture – and that if you want to use these you should use the deprecated non-CDB architecture. The list of features which are restricted or not available includes Automatic Data Optimization, Heat Maps, DBVERIFY and Flashback Pluggable Database (you can see the complete lists here for 12.1.0.1 and 12.1.0.2).
So we can add a fourth reason to our list of three drawn up earlier:
The Multitenant causes a number of other options or features to be unusable
Now, given that I think all four reasons stated here are good enough to stand up on their own, what does this say about Oracle’s decision to deprecate non-CDB architectures?
You can draw your own conclusion, but I can’t help see it as arrogance on Oracle’s part as they force customers to use a specific new configuration with little regard for how it affects their operations. At worst, I don’t like being forced into changes by the vendor (to whom customers pay large amounts of money) while at best I would at least expect them to get all the features working before forcing the issue…
Update – 18 February 2015
Since I published this article back in late January I’ve had a lot of comments – both here and on Twitter. Some agree with me, some disagree – and unsurprisingly many of the latter are Oracle employees. One particular Oracle employee took to his corporate blog to post a four-part response!
One of those responses was in regard to my concern that, since it seemingly cannot be unlinked, customers may be able to inadvertently trigger usage of the Multitenant feature and thus incur an expensive and unexpected license bill. [I have no knowledge that this has ever happened, I am merely concerned that it may be possible.]
I’d like to quote the following response from our friend on the Oracle blog (his own opinion, not the views of his employer) who is apparently looking to rubbish that concern. I have placed the most enlightening part of the text in bold for emphasis:
This bit of FUD is silly. First of all, this risk already exists with various features of the Oracle database. For example, many of the OEM packs can be inadvertently used without a license as could several of the views in the database itself. Partitioning is another example that comes to mind. Often it’s installed in a database but it’s use requires a license.
So, how is this any different? Well, it’s not. Simply put, this is an argument for enterprise compliance auditing/management.
I hope this convinces you more than it convinces me.
flashdba 
Be ready for 42,000 tweets and blog comments from people who will convince you that since this is simple for *them* to figure out it is a non-issue and you are a gadfly.
With such a low adoption of Oracle 12c this makes no sense. Whoever, would have done it would definitely have used Non-CDB option as STEP 1 and then once 12.2 comes in with more stability (I hope) they would go down the Multitenant approach. No sense in what Oracle has done.
I do not work for Oracle or any Oracle partner and etc . Sorry but I do not see what is all that about . Non-CDB and also Oracle Restart ( which btw is also deprecated but still supported ) will still work on 12c so no one is forcing anyone to move to single PDB as far as I understand it. Not sure if that qualifies me as part of the 42000 that Kevin mentioned 🙂 Thanks
I understand the feelings about this issue.
But when I read in the first time I thought: “wait a minute, and about the deprecated LONG types? They still exists in the sys/sytem 12c schemas”.
So, in the next Oracle 32L release I will change to CDB.
FYI Oracle Streams (deprecated but supported in Oracle 12c) – does NOT work with Multi-tenancy
What is interesting is that OVM is now on Exadata. How does that fit in with Multitenant option. I thought the very reason for the existence of multitenancy was to avoid OS level partitioning.
Excellent point, my friend.
We’ve never said Virtualisation and Multitenant are incompatible approaches. In fact there’s plenty of benefits of leveraging both…
Hi… Dom Giles here. Full disclosure… Clearly I work for Oracle.. Drop me an email and we can discuss this. I might not convince you, but I can try…. But trust me it’s not “breath taking arrogance”… It would be wrong of us not to give our customers plenty of notice… What would have been breath taking arrogance is to spring the change on customers at the last possible moment. There’s plenty of positives with the new architecture…. Happy to discuss those.
sshdba – OVM and Multitenant – while they are of similar flavors, offer different benefits. I believe – in my opinion (my opinion is mine and does not represent Oracle Corp. in any way) OVM is now supported for these reasons. First is to offer greater flexibility with respect to taking advantage of Exadata. Now, I can run legacy systems on Exadata (granted – lacking things like cell offload) easing the ultimate migration to Exadata once the database can be run on a supported Database software version. Support for ACFS on Exadata also provides like benefits, all be it with a narrower range of OS options. The upshot is that during refresh cycles, I can now choose to consolidate on new or existing Exadata hardware with significant potential savings. In doing so I get the benefits of things like Infiniband and so on.
Further, in some government cases, OVM can help deal with “color of money” issues with respect to database deployments. It’s funny how sometimes a VM will suffice in these cases, even if you can pretty much demonstrate the ability to control resources at all levels in Exadata. Bottom line, OVM offers different kinds of isolation options.
Also, Oracle provides a lot of pre-built VM environments. This makes it easy to spool up development environments. I would prefer to use the Virtual Compute Appliance for these kinds of things unless they were database specific.
I’m not sure that I’d want OVM images running on my production boxes for a number of reasons. However, for spooling up dev/test and QA as well as POC/POV I think that OVM on Exadata is a great option.
To be honest, what I see in this 12c article is a bunch of FUD building. Your points are nothing more than running around chicken little style, crying that the sky is falling, In fact, it is far from falling. I’ll be addressing this post with a response on my own blog soon.
I had to read this comment a couple of times to make sure one of my club ex-Oracle friends wasn’t playing a joke on me. Five paragraphs and 328 words, almost all of which are devoted to the subject of OVM – a subject which I mentioned a total of ZERO times in this post.
However, the last paragraph offers the best window into Oracle’s feelings about its customers and its views on how to treat them. Customers are forced to move from an old method to a new method with no crossover period, but anybody complaining about this is either “FUD building” or “running around chicken little style, crying that the sky is falling”. Tough words there Robert, you’ve really allayed everybody’s fears on this subject. Man up, you license-paying cry babies, Oracle has got your back.
Feel free to post any response you like on your blog. You will not be posting any more of this nonsense on mine.
Honestly…. I’m not sure what I was thinking when I wrote that…. I wonder if I accidentally cut and pasted something else I’d started writing and didn’t realize it… hmmmm….. I have no recollection of writing this. I did write something on visualization and Multitenant and so I’m wondering if part of that got into here. Weird. Apologies for the confusion…
Hmmm ok.
Just because I never know if those oracle blogs will accept my reply, this is a response I posted to Part 2 of Roberts blog:
No, you make tactical decisions based on where you are now.
You make strategic decisions based on future directions.
Or at least you should. Oracle has a FUD problem when people make strategic decisions based on perceived marketing tactics.
People who are not on the bleeding edge do not appreciate being forced into a buggy new code path. This is not FUD, this is experience. Now, elsewhere I sarcastically responded to the “no history” with “Cost Based Optimizer,” but of course, many of us know that it has been around for decades and still has many of the same issues of predictability solved by the simple RBO – not to mention you can still see rule hints in many late model Oracle internal queries. And the “solution” is to layer more complexity on it!
It’s by no means new – the issue that immediately comes to mind is the 7.2 to 7.3 upgrade on VMS. People screamed, Oracle said “tough.” Sometimes organizations have to do a Stalin-esque “drag people into this century,” but is that who you want to be compared to?
Saying it will all be fixed in the future is anti-FUD, vaporware, not appreciated at all by those of us with an expectation of reasonable software development. We don’t want a moving target, we don’t want make-work, we want our data to be secure and reachable in a timely manner. We do NOT want working code and system procedures to be replaced with something that might work in the future maybe kinda sorta if you get around to it. Kids on “new paradigms” may want to deal with “inevitable bugs,” but my enterprise accounting support doesn’t. Speaking for myself, of course.
Is there a LIKE button here ?
I disagree with the rush to deprecate (if not desupport) non-CDB.
Me too 🙂
“We don’t want a moving target, we don’t want make-work, we want our data to be secure and reachable in a timely manner”
So much wisdom in so little words. Nicely put
Hi flashdba, ther is a crossover period.. thats why its deprecated and not desupported…All oracles own major products are still using the non -cdb databse … but its just a direction that in future cdb should be seriously looked at for any new developments….
I kind-of swing both ways on this. You will see some of my comments on Robert’s blog posts. and we’ve exchanged a few emails on the subject too.
I think he makes some good points, especially those regarding the fact the basic architecture (in this context) hasn’t changed in 35+ years, so we shouldn’t be surprised a change has come about. I hadn’t really though about it that way before. Not saying that is a defence, just an interesting point.
On the other hand, I do think the move to multitenant will be a really big step for many DBAs. I like to think I’m pretty good at Oracle stuff, but fast approaching 2 years down the line and I’m still finding new situations with multitenant I had not considered before on almost a daily basis.
I do feel 12.1.0.2 is a lot more solid than 12.1.0.1, but I can understand reluctance to go with so much new codepath.
Amongst other things, I would like to see a parameter that limits the total number of PDBs to 1, so you can’t accidentally create a second without making a concious decision to enable it. SE won’t let you build multiples, so it should be easy to give us some control over this. I’m waiting for the, “You’re changing your tune now!”, comment from Kevin. 🙂 I love you Kevin! XXX
I think the biggest issue for me relates to the timing of this. If this had come at the start of 12.1, or at 12.2 I think it would have been received differently. It certainly felt a little odd to me that is came with a patchset (12.1.0.2).
Cheers
Tim…
“I would like to see a parameter that limits the total number of PDBs to 1, so you can’t accidentally create a second without making a concious decision to enable it.”
Absolutely spot on, Tim. Would it really hurt Oracle to do this?
“It certainly felt a little odd to me that is came with a patchset (12.1.0.2)”
Yes! In the good old days it was: Base Release = chaos, Patchset = order… repeat. Now, we have to contend with every patchset bringing in new features, which means we never really know what to trust. I wonder how my old friends in Oracle Sustaining Engineering are feeling about this new policy? Nervous, I’d imagine.
Robert
I don’t mean to be unkind but you have now published five lengthy articles on the Oracle Blog in response to my post not to mention the comments I’ve allowed through here. I now find that I have another five comments from you awaiting approval, all from today. I’m sorry but that’s too much – it would drown out the views of the other readers who have chosen to comment, which I cannot allow.
I think you’ve had ample opportunity to reply – and I have allowed the URL of your blog to be registered against your name so that my readers can click through to your blog should they wish.
I think that’s more than fair. I will therefore not be publishing any more of your comments here.
“I’m waiting for the, “You’re changing your tune now!”, comment from Kevin. 🙂 I love you Kevin! XXX”
I actually don’t see this as a game in which Oracle tries to handle feature management worse than their own prior art! I also don’t know what Tim means by “changing your tune now.” I could guess it relates to my words on Oracle’s massively bungled approach to feature management in the In-Memory Column Store case but I don’t recall there being a large cadre of folks that though Oracle proved computer science genius nor care for customers in the approach they took to manageability of that expensive feature.
Yes. That’s the one. My, “You’re changing your tune now!”, comment about myself related to the fact I was happy with the on-off switch for In-Memory (assuming the bug you spotted gets fixed of course), but am not happy about having no off switch for multiple PDBs. Just taking the piss out of myself. Nothing directed at you apart from my admiration of course. 🙂
Cheers
Tim…
“assuming the bug you spotted gets fixed of course”
You’ll recall in my manifesto-like series on the matter that one of the most egregious aspects of that whole issue was the fact that Oracle “handled” it with a non-published bug. So I ask you, how would one know the bug was fixed without Oracle stating what they thought the bug was? Sure, we can test for known symptoms but that is no way to run a railroad.
Well, Microsoft never changed license for each tenant in SQL Server.
Well, that’s the same story of enterprise software upgrade again and again and again. If you want to implement a new feature that drastically changes the way your product works, you have to “force” somehow your clients to adopt the new feature if you don’t want to stuck in the old design and expend resources supporting an old architecture you don’t want to promote any more.
Just think in microsoft’s roadmap from MSDOS to WindowsXP and how many problems they had in between just because they want to still give support to the old design. Think about all the 64bit arch desktop software that had to wait to be released just because of that. By giving the costumer the choice of stay the same way, they will probably stay, and their own improvements will arrive too late.