This blog post offers proof that you can trigger In-Memory Column Store feature usage with the default INMEMORY_* parameter settings. These parameters are documented as the approach to ensure In-Memory functionality is not used inadvertently.
What Really Matters?
This is a post about enabling versus using the Oracle Database 12c Release 220.127.116.11 In-Memory Column Store feature which is a part of the separately licensed Database In-Memory Option of 12c. While reading this please be mindful that in this situation all that really matters is what actions on your part the internal tables Oracle audits to charge you for feature usage.
Make Software, Not Enemies–And Certainly Not War
There is a huge kerfuffle regarding the separately licensed In-Memory Column Store feature in Oracle Database 12c Release 18.104.22.168–specifically how the feature is enabled and what triggers charges for usage of the feature.
I pointed a) the fact that the feature is enabled by default and b) the feature is easily accidentally used. I did that in Part I and Part II in my series on the matter. In Part III I shared how the issue has lead to industry journalists quoting–and then removing–said quotes. I’ve endured an ungodly amount of shameful backlash from friends on the Oaktable Network list as they asserted I was making a mole hill out of something that was a total lark (that was a euphemistic way of saying they all but accused me of misleading my readers). I even had friends suggesting this is a friendship-ending issue. Emotion and high-technology are watery-oil like in nature.
About the only thing that hasn’t happened is for anyone to apologize for being totally wrong in their blind-faith rooted feelings about this issue. What did he say? Please read on.
From the start I pointed out that the INMEMORY_QUERY feature is enabled by default–and that it is conceivable that someone could use it accidentally. The back lash from that was along the lines of how many parameters and what user actions are needed for that to be a reality. Maria Colgan–who is Oracle’ s PM for the In-Memory Column Store feature–tweeted that I’m confusing people when announcing her blog post on the fact that In-Memory Column Store usage is controlled not by INMEMORY_QUERY but instead INMEMORY_SIZE.
If I were to show you everyone else was wrong and I was right, would you think less of me? Please, don’t let it make you feel less of them. We’re just people trying to wade through the confusion.
The Truth On The Matter
Here is the truth and I’ll prove it in a screen shot to follow:
- INMEMORY_QUERY is enabled by default. If it is set you can trigger feature usage–full stop.
- INMEMORY_SIZE is zero by default. Remember this is the supposedly ueber-powerful setting that precludes usage of the feature and not, in fact, the top-level-sounding INMEMORY_QUERY parameter. As such this should be the feature that would prevent you for paying for usage of the feature.
In the following screenshot I’ll show that INMEMORY_QUERY is at the default setting of ENABLE and INMEMORY_SIZE is at the default setting of zero. I prove first there is no prior feature usage. I then issue a CREATE TABLE statement specifying INMEMORY. Remember, the feature-blocking INMEMORY_SIZE parameter is zero. If “they” are right I shouldn’t be able to trigger In-Memory Column Store feature usage, right? Observe–or better yet, try this in your own lab:
So ENABLED Means ENABLED? Really? Imagine That.
So I proved my point which is any instance with the default initialization parameters can trigger feature usage. I also proved that the words in the following two screenshots are factually incorrect:
Screenshot of blog post on Oracle.com:
Screenshot of email to Oracle-L Email list:
I didn’t want to make a mole hill of this one. It’s just a bug. I don’t expect apologies. That would be too human–almost as human as being completely wrong and wrongly clinging to one’s wrongness because others are equally, wrongly, well, wrong on the matter.