Index of Related Posts
This is part 1 in a series: Part I, Part II, Part III, Part IV, Part V.
Update: Oracle Acknowledges Software Defect
During the development of this study, Oracle’s Product Manager in charge of the In-Memory feature has cited Bug #19308780 as it relates to my findings. I need to point out, however, that it wasn’t until this blog installment that the defective functionality was acknowledged as a bug. Further, the bug being cited is not visible to customers so there is no closure. How can one have closure without knowing what, specifically, is acknowledged as defective? Also read more at The Register: Click here.
Other Blog Updates
Please note, there are blog updates at the end of this article.
How Do I Feel About Oracle Database 12c Release 12.1.0.2?
My very first words on Oracle Database 12c Release 12.1.0.2 can be summed up in a single quotable quote:
This release is hugely important.
I’ve received a lot of email from folks asking me to comment on the freshly released In-Memory Database Option. These words are so overused. This post, however, is about much more than word games. Please read on…
When querying the dba_feature_usage_statistics view the option is known as “In-Memory Column Store.” On the other hand, I’ve read a paper on oracle.com that refers to it as the “In-Memory Option” as per this screen shot:
A Little In-Memory Here, A Little In-Memory There
None of us can forget the era when Oracle referred to the flash storage in Exadata as a “Database In-Memory” platform. I wrote about all that in a post you can view here: click this. But I’m not blogging about any of that. Nonetheless, I remained confused about the option/feature this morning as I was waiting for my download of Oracle Database 12c Release 12.1.0.2 to complete. So, I spent a little time trying to cut through the fog and get some more information about the In-Memory Option. My first play was to search for the term in the search bar at oracle.com. The following screen shot shows the detritus oracle.com returned due to the historical misuse and term overload–but, please, remember that I’m not blogging about any of that:
As the screenshot shows one must eyeball their way down through 8 higher-ranking search results that have nothing to do with this very important new feature before one gets to a couple of obscure blog links. All this term overload and search failure monkey-business is annoying, yes, but I’m not blogging about any of that.
What Am I Blogging About?
This is part I in a short series about Oracle licensing ramifications of the In-Memory Option/In-Memory Column Store Feature.
The very first thing I did after installing the software was to invoke the SLOB database create scripts to quickly get me on my way. The following screen shot shows how I discovered that the separately-licensed In-Memory query feature is enabled by default. If there is any confusion over my use of the word enabled, please click here for a screenshot of Oracle documentation on the parameter. And now, the screen shot showing the default in an instance of the database:
Now, this is no huge red flag because separately-licensed features like Real Application Clusters and Partitioning are sort of “on” by default. This fact about RAC and Partitioning doesn’t bother me because a) one can simply unlink RAC to be safe from accidental usage and b) everyone that uses Enterprise Edition uses the Partitioning Option (I am correct on that assertion, right?). However, I think things are a little different with the In-Memory Option/In-Memory Column Store feature since it is “on” by default and a simple command like the one in the following screen shot means your next license audit will be, um, more entertaining.
OK, please let me point out that I’m trying as hard as I can to not make a mountain out of a mole-hill. I started this post by stating my true feelings about this release. This release is, indeed, hugely important. That said, I do not believe for a second that every Enterprise Edition deployment of Oracle Database 12c Release 12.1.0.2 will need to have the In-Memory Option/In-Memory Column Store Feature in the shopping cart–much unlike Partitioning for example. Given the crushing cost of this option/feature I expect that its use will be very selective. It’s for this reason I wanted to draw to people’s attention the fact that–in my assessment–this option/feature is very easy to use “accidentally.” It really should have a default initialization setting that renders the option/feature more dormant–but the reality is quite the opposite as I will show in Part II. (BLOG UPDATE 2014.07.26: Many Oracle separately licensed features are enabled by default but users actually have to “use” the feature to trigger feature usage as would show up in an audit. Please see Part II where I show that registered usage of this feature happens even if one doesn’t “use” the feature.)
Summary
I have to make this post short and relegate it to part I in a series because I can’t yet take it to the next level which is to write about monitoring the feature usage. Why? Well, as I tweeted earlier today, the scripts most widely used for monitoring feature usage are out of date because they don’t (yet) report on the In-Memory Column Store feature. The scripts I allude to are widely known by Google search as MOS 1317265.1. Once these are updated to report usage of the In-Memory Option/In-Memory Column Store Feature I’ll post part II in the series.
Thoughts?
Please click on the following link to view Part II in this series: Link to Part II.
BLOG UPDATE 2014.07.29: As you read this please bear in mind the words in this tweet issued by Oracle’s Maria Colgan and consider whether I am saying you “don’t have 2 [sic] do anything” to trigger feature usage. You’ll find that I am saying the opposite in this post. The point is, however, the feature ships ready for you to do this. The feature is enabled by default as per Oracle’s spokesman as reported by informationweek.com and my example herein merely corroborates the spokesman’s assertion.
BLOG UPDATE 2014.07.28: Please don’t forget to view this post (click here) with clear proof that neither the INMEMORY_SIZE nor INMEMORY_QUERY initialization parameters prevent triggering usage of the In-Memory feature.
BLOG UPDATE 2014.07.28: Here is a link to an Informationweek.com article as of 26 July 2014. In the comment section the author quotes an Oracle spokesman as saying “Yes, Oracle Database In-Memory is an option and it is on by default, as have been all new options since Oracle Database 11g.” : Link to 26 July version of Informationweek.com article. Other supporting links: Screenshot 1, Screenshot 2, Screenshot 3, PDF of 26 July 2014 Informationweek article,
BLOG UPDATE 2014.07.25: There is now a Part II posting available in this series. Link to Part II.
Kevin Closson's Blog: Platforms, Databases and Storage 
Oracle really should sort this out pronto. US$23,000 per CPU for a feature the customer didn’t intend to use.
Oracle’s approach to licensing is often close to “entrapment”. Make it as easy as possible to enable a new cost option or even – as in this case – almost switch usage on by default, then clout the customer with an enormous bill at the next audit for a feature they didn’t intend to use. Worst kind of underhand sales technique.
A while back I found that the absence of a startup mount option in oradim meant that in 11.2.0.3 ( I think) on Windows, restarting a standby server would result in opening the database with Real Time Query enabled, potentially resulting in a demand for an Active Data Guard licence.
There was no way round this other than starting the instance using a script called by a Windows startup trigger. (There’s probably another way if you have OHAS from Grid Infrastructure now, but that’s a whole other install.)
John,
To prevent unintential use of active data guard, you could set the “_query_on_physical” parameter to false.
However this is a undocumented parameter.
See http://uhesse.com/2013/10/01/parameter-to-prevent-license-violation-with-active-data-guard/ for details
Thanks, that’s interesting, but it’s not an answer to the accidental licence violation problem.
Customer’s cannot be expected to Google or parse executables to find hidden parameters that may or may not prevent accidental licence use related to the parameter name.
John,
I completely agree with you.
Hi,
you could make a very similar argument for the tuning and diagnostic packs, save for the CONTROL_MANAGEMENT_PACK_ACCESS parameter.
Interesting findings, thanks. Not exactly surprising it is on by default, as so many options are these days in the database. Worse offenders in my experience are the Diagnostics and Tuning Packs; so easy to use and so many people assume they are part of the core database (they can be used on Standard Edition as well, though shouldn’t be of course).
The MOS scripts you refer to are, frankly, poor and inaccurate — not a basis to judge your product usage or license requirements. LMS scripts certainly take a lot more into consideration than the MOS scripts.
On your point about everyone using Partitioning when they Enterprise Edition, that’s incorrect — we have collected accurate usage information from many servers, totaling thousands of instances and only 23% of the Enterprise Edition instances use Partitioning. Contrast this with 57% using Diagnostics Pack. I can assure you that *way* less than 57% of those instances were licensed for Diagnostics Pack. Combined with a recent 50% increase in the Diagnostics Pack cost and more people will be caught out with large bills.
@xpabu : Thank you so very much for your insight on options usage!
I wonder how long until the first blog conflating an INMEMORY table with a pinned-in-buffer-cache table exists to help arm that timebomb.
I think the naming is quite confusing. There was lots of talk about “In-Memory Database” and “In-Memory Option”, but as you point out, it is now documented as “In-Memory Column Store”, which is a better name.
I think there will be a lot of confusion with the “Full Database Caching Mode”, which effectively makes an In-Memory Database, but has nothing to do with the column store…
It would be nice if people decided on the final names earlier on in the process. 🙂
Cheers
Tim…
I think it’s even more confusing than that, as the Licensing Information document shows Oracle Database In Memory comprising of three different features:
– In-Memory Column Store
– Fault Tolerant In-Memory Column Store (Requires Exadata or Supercluster)
– In-Memory Aggregation
http://docs.oracle.com/database/121/DBLIC/options.htm#DBLIC2265
I’d love to know Kevin’s thoughts on the restriction of Fault Tolerant IMCS to just Exadata and Supercluster… 🙂
– flashdba
Relatively, it’s not *that* crushing – according to the pricing list, per processor it’s just $23,000 – same price as RAC.
Admittedly, I don’t pay the $$ for RAC either.
Ah, Jay…long time no see…
Hope all is well…
“b) everyone that uses Enterprise Edition uses the Partitioning Option (I am correct on that assertion, right?)”
I think that assertion is generally true for customers with EULAs, but I think there is a significant number of separately licenced Enterprise Editions who do not use partitioning because it costs more. Or, was that comment made tongue-in-cheek?
No tongue-in-cheek at all. Thanks for the input, David.
Well, everyone does use partitioning, because it is used in the SYSTEM tablespace, but it is logged in the feature usage as “Partitioning (system)”, which is free.
If you are using it in your schema it is logged as “Partitioning (user)”, which definitely does need to be paid for!
Cheers
Tim…
One mitigating factor is that although you can set a table in memory It won’t be loaded into the column store until you set a value for INMEMORY_SIZE and restart the instance.
This somewhat depends on how the feature usage is measured if its when a table is specified as In memory then its problematic, if its when the table is loaded into the column store then that seems fair enough as you had to set a static parameter and restart to fall into the trap.
Hi Chris, please see Part II.