An Oracle Database patch that could cost you dearly

You’ve reached an archived Flexera blog post that may be out of date. Please visit the blog homepage for the most current posts.

Oracle has just released  version of its database product which provides a set of improvements including a new Oracle Database In-Memory option. This option provides significant performance improvements described by Juan Loaiza, Oracle SVP system Technology as “it’s orders-of-magnitude faster — like the difference between walking and flying in a plane.”  It enables customers to decide which data goes into memory and which data stays on the disk, drastically cutting the reporting time and freeing the database to quickly handle transactions. It has been built to compete with other database products available on the market such as SAP HANA which requires, for the same feature, loading the full database into DRAM. The SAP HANA approach could be quite costly. This new Oracle Database release comes as  a set of patches; the previous minor release has been removed from the Oracle download web site and is no longer available.

The new Database In-Memory feature does not come for free to existing Oracle database customers. The Oracle Database In-Memory option is sold by Oracle at $460.00 per Named User or $23,000.00 per processor. It has also been reported that the option is turned on by default when installing version, thus exposing all customers upgrading to this version to a potentially significant additional expense– one that may be uncovered by an Oracle software audit. (See this article in Computerworld). Any database administrator could start using it. For instance with a single command,  an in-memory table can be created, activating the use of the option.

As a reminder, options associated with Oracle databases such as Real Application Clusters (RAC), Partitioning, etc., along with management packs: Diagnostic Pack, Tuning Pack etc.,  must be licensed, when used, on the same terms as the database supporting these options. They are typically installed with the Oracle database itself but do not need a license as long as they are not used. For instance, if a database requires 4 processors, all options and management packs used with that instance must be licensed for the same number of processors. There is a way to protect database administrators from inadvertently using a database option: it can be turned off. However,  customers proactively need to perform that change.

There is no question about the benefits of the new Oracle Database option. It provides incredible performance improvements for applications where responsiveness is critical.  Oracle has likely spent a large amount of resources building this cutting edge technology and logically is selling the feature as a database option. The overall feeling is they could have been a bit more customer friendly by turning off the option by default. Many customers will probably not realize the licensing and financial impact of upgrading to this new Oracle release until it is too late.

To learn more about Software License Optimization solutions for Oracle, please visit our website, or read our whitepaper: Oracle License Management Best Practices.


Update – 07/30/2014

Oracle has reported in its own blog that the Oracle Database  In-Memory  option is not activated by default when installing the database. As a result, the risk of involuntarily using the option is less than previously anticipated. There is still a risk where Oracle DBAs could activate it without fully understanding the licensing consequences. This can be mitigated within organizations through communication and training from the license manager.

As a result, and contrary to what was written above, Oracle has in fact brought this option to the market in a customer-friendly way.


One comment on “An Oracle Database patch that could cost you dearly

  1. Piarasmacdonnel on   #

    This is an excellent point and although the In-Memory option is the latest and among the most expensive, any of the other database options and pack are a compliance risk if they remain available to be inadvertently used, especially if on a virtual host or cluster.

    DBA’s need to be encouraged to develop/follow a set of Database Post Install Tasks to avoid these complinace risks.

Comments are closed.