Kicked off Oracle Open World with a great session on Oracle Database In-Memory.  The speaker (xinghua wei) did a great job of presenting both the technology itself as well as use cases and things to watch out for.  My team has started to look at the future of Exadata inside of our support model.  We have loved the performance we have gotten out of the appliances, but the coordination required to organize patching with Oracle and the hyper consolidation needed to justify the additional costs of running Exadata.

The biggest push back that I get from my team (and customer) is concerns with analytic workloads moving off the Exadata.  While it may not be the solution, Oracle’s In-Memory is one tool we have that could help with those concerns.  In this session I learned some new things that I did not know about In-Memory that will help us to better understand how it might play in our environment.  First, the feature is an extra sku, and a quick search gave $23K per CPU unit as the book price.  While not exactly cheap, it sure beats the heck out buying a whole Exadata.  More notes are included below.  I’m still not sure if this is something that we will use, but it’s nice to have a better understanding of the technology as we look at options other than Exadata.

Notes:

• In-Memory stores data in Columnar Format
• Data exists along with traditional row based tables
• 20% impact in TPS on row-based table associated with In-memory tables
  • Can be partially mitigated by removal of indexes on the tables that were used to support OLAP workloads
  • Results will vary based on a number of factors: design, workloads, etc.
• Works with RAC and Data Guard
• Differentiator vs. SAP HANA, SQL Server, DB2
  • 2 formats in 1 database (row and columnar)
  • 100% application transparency