There has been some buzz about what Larry Ellison of Oracle announced this past Tuesday June 10 in Redwood Shores. What is really interesting is Larry/Oracle did not call the new option for Oracle 12.1c an In-Memory Database. Rather, Larry trumpeted the Oracle 12.1c Database In-Memory Option. Here is the summary slide from the launch to show how Larry described the Oracle Database In-Memory “Extreme” option.
To me, this begs the question: Why did Larry choose to coin a new term, Database In-Memory, when there is already a well defined and well understood industry term, In-Memory Database? This is especially relevant given that many customers are already moving to in-memory database computing. The short answer is that the new-fangled Oracle Database in-memory option is 1) really not that new and 2) not an in-memory database at all…
Given that I’m currently reading the complete works of Plato (Plato was a student of Socrates), let me explain what Oracle has announced and will deliver in July via a Socratic approach.
What was announced by Larry Ellison on June 10, 2014?
Oracle 12.1c Database In-Memory Option
What is the Oracle 12.1c Database in-memory Option?
Oracle Database in-Memory option is an additionally priced, in-memory accelerator that complements and augments Oracle’s existing disk-based database. The database administrator manually creates a memory partition and then copies a selected set of tables from the Oracle disk-based row database to the memory partition in columnar format (table indexes). Larry Ellison referred to the option many times at the launch as a “columnar in-memory cache”. Of note was the fact that not once did Larry call this option an in-memory database.
What Technology does the Oracle 12.1c Database in-memory use?
Oracle has added an additional column-based in-memory table cache to their traditional database system. Think of this as a fully indexed table or set of indexed tables that are available in-memory to accelerate queries, but not applicable for OLTP. Pinning indexes or tables to memory to accelerate queries (commonly called caching) is not new and has been commonly used by many companies for multiple years to accelerate performance; in fact, many Oracle customers have been pinning tables and indexes to cache for years to improve poor Oracle performance. Removing disk access by pinning data into cache memory is a commonly accepted and well-worn DBA performance trick. With this new option, Oracle has made it easier for customers to manually pin tables as complete indexes to cache for analytical performance, as well as integrated the in-memory column cache with the Oracle optimizer. NB: a cache is not an ACID database management system, the option as described does not assume a full dataset in-memory, the cache is not used for updating / writing data, unless the data is replicated to another memory node (doubling the memory footprint), the data is volatile and can be lost in a power outage and finally if the cache is lost the cache must be rebuilt – which could take a significant amount of time and compute resources.
How does a customer utilize the new option?
The customer DBA manually creates a partition in memory for the in-memory option, and then manually pins a copy of a subset of their data (table by table) to the in-memory columnar partition, and then Oracle builds indexes on all the attributes pinned into the in-memory cache. The Oracle optimizer then will attempt to resolve received queries from the in-memory columnar cache first, then any row-based in-memory cached tables using table scans, then to tables in flash and finally to tables on spinning disk.
What are the ramifications of the new Oracle Database in-memory (caching) option?
While there should be a nice performance boost for poorly performing Oracle applications with this new caching option, there are some very interesting ramifications:
Why did Larry call this the Database In-Memory Option and not the Oracle In-Memory Database?
If you have read the blog to this point, you now know why Larry and Oracle have stayed away from calling the new 12.1c option announced this week an In-Memory Database. This is because it is not, and further it is not really new, innovative or transformational for customers. But I will give credit to Oracle for two things; 1) Creating full table indexes and pinning them into memory for better performance is an improvement for Oracle customers and 2) the name “Database In-Memory Option” is a way better name than the “Oracle Caching Option” – so Larry and Oracle get full credit for (continued) excellent marketing.
My next blog will contrast what is different about SAP HANA and the Oracle Database In-Memory Option…
For another viewpoint, Doug Henschen of Information Week has 6 points he wants to make about Oracle’s announcement (but not in a Socratic method). You can read Doug’s article here: