Database 12C-- You need Access to Information In Subseconds, "Oracle Database In-Memory"

Last year, I had write an article regarding Larry Ellison's speech in Oracle Open World 2013.
http://ermanarslan.blogspot.com.tr/2013/09/database-12c-new-in-memory-option-flip.html

This year, Larry Ellison made another presentation about the upcoming Oracle In-Memory Option and I had followed it through youtube. The presentation was so exciting , and inspring for me, so I have sticked to my tradition and prepared this blog post to put whats have been presented in to the paper.

The subjects of the presentation was  Oracle Database In-Memory option, its features, the scalability and M6 Machine.. It  was like the speech in Open World 2013 but i have found it more focused and detailed. In addition, Larry have talked about RDBMS, SIMD instructions and the general characteristics of other in-memory databases.. Also, you will find real life stories, examples, feedbacks and demonstrations regarding the performance of Oracle In Memory Option in the presentation. The stories, examples and feedbacks are from real companies, real databases and real applications..

That's why I strongly suggest you to watch it...  

So lets start with it.. I will mention the things taking place in the presentation as key notes briefly.

• Nowadays, Memory- DRAM becomes cheapers. Thus, we need to make us of memory more because memory is fast.
• Flash Memory is new, but it have already started replace the Hard Disks. It s fast and persistent.. Thus, by using them, it s faster to reach the data using I/O subsystem..
• Network also have speeded up. Infiniband is much faster than ethernet. Oracle database and Oracle Hardware uses Infiniband to accelerate everthing.. reliably and economically...

"In-Memory Option" puts the frequently accessed data  in memory , and operate on this data instantly.

• Using In-Memory Option , you have 100X faster queries in both OLTP and DW. Also you have 2x Faster OLTP environment without a need for a single change in your application..
• The goals of Oracle In-Memory Option:

1) 100x sql .. It was a goal for this product, because it has been accelerated 2x or 3x in the past. With 100x, Oracle brings the real time analytics..
2) Speeding up the OLTP.. This is a hard thing to do. Normally, we need to compromise the transactions.
3) Transperency.. No application changes should be needed.. It must be like 'Throw a switch and everyting runs faster!'.. No need to rewrite anything for taking the advantage ..

• There are 2 RDBMS format out there.. 

1) Rows format DB .. It is good for OLTP. It delivers fast processing for few rows with many columns. It is also the traditional format of RDBMS databases, as well as Oracle.

2) Column format DB.. It is good for Analytics/Reports.. Analytical DB's are normally column organized.. The queries take the columns and operate on them.. I delivers fast processing for one or more column with many rows.

• The magic Oracle 12c is, It stores the data in memory, in both formats.. Both row format and column format. There is nothing changed in row format, bytheway. This makes Oracle 's new option transparent!! No changes needed to use the new in-memory option. No export/import.. nothing.
• Why is OLTP speeded up?  So , as there are 2 formats in memory, we have both row cache and column cache.. Row based OLTP operations works on the Row Cache.. The question is "how can transactions go faster?".. This question comes to mind, because in this technology, there are two stores in memory, and both of them should be updated.. So there is an additional work...
  Oracle explains this as follows,
  Normally we create 2 index for oltp , 10 index (maybe more) for analytic queries. Even, we create the indexes for queries, we speed up them, but then our transactions are slowing down..
  Inserting a row into a table means , insert row + update index + update index... + update index.. Maintaining those indexes is a very expensive operation and slows down OLTP..
  So, what Oracle suggest here is, actually dropping the analytical indexes, as the column store technology is developed to replace the analytical indexes..
• We dont log anything for the Column Cache, and we have using compressin on the column cache. We only say that; "I want this table in memory in column format"
• Oracle uses SIMD CPU instructions. "Single Instruction Multi Data". This brings an incredible speed for Oracle on Sparc and Intel. These SIMD instructions have been used for scientific work normally and in these days, they are used for graphic accelarations.. You can scan billion rows per second per core.
• With In-Memory Option, JOINS are turned into fast scans in memory.10x faster joins
• Ad-Hoc reports can be online using in-memory option. No need to prepare a cube.. Even if you havent a cube for data, this engine builds outline ad-hoc .. That's why It is fast and doesnt require query anticipation..
• Normally, when we build a columnar representation in db, our OLTP operations slow down. But OLTP will not slow down, anymore, besides OLTP operations will speeded up using in-memory option of Oracle Database.. This is explained with Oracle Database having 2 caches.. Row cache and Column cache. Of course, the maintanence operations of the cache increased by x2 but we dont need any anayltical indexes in this method.. So dropping the analytical indexes will make us to be speeded up.. Even in OLTP, we have some tables which have 20 or more indexes, because we run our analytical queries in OLTP environments.. (for example: E-Business Suite...) So consider dropping those indexes... No updates will be need for maintaining the indexes.. That's the thing which make use speeded up.. It takes long long time to update those indexes , so maintanence for 2 cache in memory is not important when you compare it with the index maintance.. 
• So, you can use your transaction systems as Warehouse!
• In Memory works in Scale-out.. so, Part of it can be on Machine 1, other part of it can be on Machine 2 and so on..
• Oracle 's In-Memory does not require the entire database to be in memory. It s smart. I keeps the active part in memory, inactive part can be in Flash or disk (Tiering) . So there is a memory hierarcy..
• The column store is a cache! (active dagta) "As your active data is in memory, your database runs at the speed of memory." So you get the speed of memory, but the capacity of disk.. So it is economic, scalable and fast.
• What about availability? What if a failure occurs in memory system? What will happen Oracle's In-Memory?  You are protected against any kind of failure.. Node, Site, corruption, human error and etc.. Oracle keeps  copies of the column cache in at least 2 nodes. (like a disk raid mirror) So if you lose a node, you are still online.
• To implement in-memory options, you need to  declare ;

inmemory_size = XX GB (how much you want in memory column cache)
alter table | partition in memory and in case of OLTP drop the indexes!

That's it..

• Oracle In-Memory is released a little late because Oracle wanted to supply a lot of things with it. Oracle EBS , Fusion Apps, JD Edwards, Peoplesoft, Siebel and etc run faster,reliable and economic with it.
• Example: E-Business Suite: 

A real company, real database and real application:  a batch job which runs for 58 hours, completed in 13 minutes with In-Memory Option.. You cant even wait for 58 hours, but you can wait 13 minutes and continue your work.. It is like real time, it can be waited..

• Example: OTM (transportation management) runs 1030x faster.. 
• So when you operate with this speed, you may change your processes. Your processes can be optimized to change on-the-fly according to the data that will be available online. 
• Example: Jd Edwards, analytics on AR becomes 3500x faster. 

"We have no idea . The old one never ever finished" -> Some customers answers the questions: "How much faster?"

:)

In Summary, 

• Using In-Memory option; you will have an extreme Performance in both Analytics and OLTP at the same time.. According to Oracle , no one else can do that at the moment.
• Everything is running unchanged.
• It is extremely available.  In Memory Cache is mirrored. so it is high available.. When you test High Availability, nothing happens :) Actually this should be the result :)
• It scales out in RAC.  It runs on M& 32 Machine.. Using In-Memory Option, Oracle places 3 trillion rows in M6's memory, and It runs in real time.. 
• We have never seen 3 trillions rows in 32TB memory :)
• When 1 node crashes, there will be a slowness in the rate of slowness/node .. that's expected, but there is no outgages..

Lastly, Larry Ellison answered the question regarding the comparison for Scale up & Scale out . A question like which one is a better choice.. The answer was as follows;

Scale out is the trend right now. but this does not mean that scale up will come to an end.. Some applications can works better on using scale up..

Oracle Database In-Memory is scheduled to be generally available in July 2014.

Note that: Scale up means using Smp boxes.. Adding ram, adding cpu or migrating to another more powerful server.. Scale out means something like adding a node to the RAC.

That's all .. I hope you will find this post useful..