In-Memory Database options

This is a great announcement that has come out of #oow13.  I was lucky enough to attend the keynote that made this announcement, unlucky enough to spend 30 mins leaving the venue...

So the data is being stored in columnar format "in-memory", so this allows for you to drop indexes and reap the benefits of some incredible performance gains.  When your architecture is up to it, you can get benefits way in excess of the 100's times claim.  This is technology that is really going to test your architecture.  It's relying on the solid CPU / memory backbone, therefore the more tightly coupled this is with the database - the better the performance gains might be.  Note also that the closer oracle are getting to putting DB instructions on silicon will mean the benefits from this type of technology are only going to get more "real".  

Traditionally a heterogeneous database ERP like JD Edwards does NOT stress the database out that much.  The database is too busy doing reads (waiting for the IO) to be stressed.  Choosing the right tables to cache and having a lot of memory (remember, this is in-memory - you are going to need a lot of memory) might start putting some more stress on the JD Edwards database - nice!

"Oracle In-Memory Database Cache (IMDB Cache) enables database applications to selectively cache performance-critical subsets of the Oracle Database tables into the TimesTen In-Memory Database to improve application response time. "

The above statement indicates that there are two products in play here.  The "TimesTen In-Memory" database and the Oracle In-Memory database cache.  The TimesTen is the engine, this is generally deployed at the application teir.  Note also that because this is on the application tier, it would need to be kept "up-to-date" in an OLTP environment. 

The in-memory database cache is the "poor mans" implementation of the TimesTen database.  This is putting your data into a virtual TimesTen database without changing the application logic - everything through tnsnames.

In a JD Edwards environment, I'd guess that the in-memory database cache is your best option.

http://docs.oracle.com/cd/E21901_01/doc/timesten.1122/e21631/img/findingrecords.gif

The above diagram shows the totally different path to the data.

This is a true database option that is easy to enable on a table by table basis.  You initialise your 12c database to enable this option (note that you'll need to get your cheque book out too), initial RRP indications have it at about 23K per "oracle processor" [or core].

The Oracle In-Memory Database Cache option supports Oracle Database 12c, Oracle Database 11g Release 2, and Oracle Database 11g Release 1.

A good answer to try and explain what you need to run this option is found at:

2. Can Oracle TimesTen In-Memory database be used as an in-memory cache to the Oracle database?
Yes, this is the Oracle database option ' Oracle In-Memory Database Cache". This database option includes the TimesTen In-Memory Database, and caching technologies to enable TimesTen to be deployed as  an in-memory cache database  with automatic data synchronization between TimesTen and the Oracle database.

So this says that when you enable the "in-memory" option for your database, it deploys TimesTen to be deployed as a in-memory database cache.

3. Can I run Oracle In-Memory Database Cache on a different platform from the Oracle database server?
Yes, since In-Memory Database Cache runs as an Oracle client, it can be running on a different platform from that of the Oracle database server. Typically, In-Memory Database Cache resides on the application tier, whereas the Oracle Database sits on the database tier.

If you refer to the oracle price list, you'll also see that this is an "enterprise edition" enhancement only too.  You'll not be able to enable this without EE licences.