12c In-memory

I wrote a note about the 12c “In-Memory” option some time ago on the OTN Database forum and thought I’d posted a link to it from the blog. If I have I can’t find it now so, to avoid losing it, here’s a copy of the comments I made:

Juan Loaiza’s presentation is probably available on the Oracle site by now, but in outline: the in-memory component duplicates data (specified tables – perhaps with a restriction to a subset of columns) in columnar format in a dedicated area of the SGA. The data is kept up to date in real time, but Oracle doesn’t use undo or redo to maintain this copy of the data because it’s never persisted to disc in this form, it’s recreated in-memory (by a background process) if the instance restarts. The optimizer can then decide whether it would be faster to use a columnar or row-based approach to address a query.

The intent is to help systems which are mixed OLTP and DSS – which sometimes have many “extra” indexes to optimise DSS queries that affect the performance of the OLTP updates. With the in-memory columnar copy you should be able to drop many “DSS indexes”, thus improving OLTP response times – in effect the in-memory stuff behaves a bit like non-persistent bitmap indexing.

Updated 18th Oct 2013:

I’ve been reminded that I think the presentation also included some comments about the way that the code also takes advantage of “vector” (SIMD) instructions at the CPU level to allow the code to evaluate predicates on multiple rows (extracted from the column store, not the row store) simultaneously, and this contributes to the very high rates of data scanning that Oracle Corp. claims.

The presentation from Juan Loaiza was still unavailable at the time of publishing this blog note (3rd Nov 2013). If it does become available as part of the Open World set of presentations it should be at this URL.