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
- Separately priced option
- Available in July
- No Pricing given
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:
- The in-memory columnar option for holding data in an in-memory cache is purely manual (setup of partition and pinning tables is done by the DBA)
- The in-memory columnar option assumes a subset of the dataset / subset of the tables pinned into the in-memory cache
- Oracle described at the announcement 4 copies of the data are now created: 1 copy on disk, 1 copy in-memory row-based cache, 1 copy in-memory column-based cache, 1 replicated copy in-memory columnar cache. This must all be kept in sync.
- Any query with data not in the in-memory columnar caching mechanism must go to either in-memory row tables or tables on disk for resolution, slowing performance dramatically. This is a major drawback for those business users demanding pure ad hoc (unknown) queries
- If there is a CPU outage and no replicated in-memory columnar cache, the cache must be rebuilt and could take a long time (up to hours) to recreate / rebuild the cache
- The in-memory caches (row and columnar) are read optimized and not optimized for writing transactions; in addition they are not fully ACID compliant, making them by definition not full database management systems.
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: