After much back-and-forth on blogs, Twitter, and online forums, Oracle has admitted that there is a bug that can cause its new in-memory database option to be reported as being in use when it's not, although the actual risk it poses remains unclear.
As reported by The Register last week, database pro Kevin Closson was the first to notice that executing a simple set of PL/SQL commands can seemingly activate Oracle 12c's In-Memory feature, even when that shouldn't be possible.
On Wednesday, Oracle product manager Maria Colgan acknowledged that Closson's results could be reproduced, that he had in fact located a bug, and that it will be patched soon. But what does that really mean for customers?
Here's a recap of the issue, as briefly as we can put it. With the Oracle 188.8.131.52 patch release installed, the database's INMEMORY_QUERY configuration option is enabled by default, just as all new features since Oracle 11g have been enabled by default. But the INMEMORY_SIZE parameter is set to zero, meaning no space has been allocated to store the new in-memory tables.
According to Oracle, when it's configured like that, the In-Memory Option is considered disabled, because it's not actually usable. The in-memory tables can't actually be created because there's nowhere to put them. What's more, changing the INMEMORY_SIZE parameter to anything other than zero requires restarting the database instance, making it extremely unlikely that a DBA could enable the feature accidentally.
But that's not what Closson found. In his tests, all he needed to do was create a new table specifying the INMEMORY property and his database reported that the In-Memory Option had been enabled and was in use, even though INMEMORY_SIZE was still set to the default of zero.
Closson enabled the In-Memory Option with a couple of simple SQL queries ... or did he? (click to enlarge)
What's more, Closson observed that merely setting INMEMORY_SIZE to some amount of memory isn't enough to make the In-Memory feature report as being in use. You have to assign the INMEMORY property to a table – and doing so apparently marks the feature as "in use" regardless of the value of INMEMORY_SIZE.
That's bad, Closson figures, because the In-Memory option isn't free; far from it. And at a reported $23,000 per Sparc CPU, "enabling" it by accident could be a serious blunder.
Closson's series of blog posts on the subject sparked a veritable firestorm of online comment over the next few days, with Oracle mostly denying his allegations. But when another Oracle user managed to reproduce Closson's results, this time with an ALTER TABLE command, Colgan finally admitted that the observed behavior wasn't correct.
"Recording that the In-Memory option is in use in this case is a bug and we will fix it in the first patchset update coming in October," Colgan wrote in a comment to her own blog on Wednesday.
Note, however, that she didn't say that there was a bug that allowed the In-Memory feature to be activated by mistake. She simply said that when a DBA performs Closson's series of steps, for the database to record that the In-Memory feature is in use is considered a bug.
That means the In-Memory Option isn't really in use, even when you repeat Closson's procedure. And whether Oracle would really try to charge a customer for the In-Memory Option based on that erroneous reporting is anybody's guess. Oracle wouldn't respond to El Reg's request for clarification on the matter.
If you have an Oracle support contract, however, you can track the progress of the patch in the company's bug database, where it is filed as Bug #19308780. And expect that fix to arrive in October. ®