Oracle Database In-memory in SAP Deployment

A closer look shows that there are considerable differences in the in-memory concepts of SAP and Oracle. This starts with the official naming:

While Hana is referred to as an "in-memory database", Oracle speaks of "database in-memory". What possibilities does Oracle's newly SAP-certified "Database In-memory" offer for use with SAP?

The basic commonality, because it is the fundamental theoretical concept for storing a database in the physical main memory (RAM), is the column-oriented storage of data.

This explains why in-memory has only recently become so popular. Until recently, in-memory was not used in almost all relational databases due to the considerable disadvantages of column orientation in the OLTP environment.

It was only the need to analyze large amounts of data quickly, the fall in RAM prices and the availability of multi-core processors that made this concept interesting.

Hana loads the entire database into the main memory, which is why the solution is also called an in-memory database. This concept requires special hardware, an enormous amount of RAM and, in the event of a server crash, a lot of time must be allowed for the recovery of the database.

A database must be completely migrated for use with Hana. The way back is only possible with a great deal of effort. The amount of main memory required is not only determined by the space required by the database. Rather, an additional 50 percent RAM is required for Hana-internal functionalities (merge processes, temp area).

RAM not new for the Oracle DB

The Oracle database was never just "disk-based". To optimize performance, it also used memory structures such as buffer, row and result cache in previous versions.

With Oracle Database version 12.1.0.2, the in-memory option was also introduced. Like Hana, Oracle Database In-memory is therefore particularly suitable for analyzing or aggregating large volumes of data more quickly.

Oracle does not call its database an in-memory database, but deliberately places the term in-memory at the end of the name. This is to make it clear that Oracle is the only database manufacturer to retain the existing technology unchanged and expand it with an in-memory component.

The previous principle of line-oriented buffering in the main memory and its storage on disk or flash memory is completely retained. The in-memory column store is set up in an additional RAM area.

Complete tables, individual columns or individual partitions can be stored there in column format. Oracle thus combines the advantages of row- and column-oriented databases in one product and - in contrast to SAP - creates a "hybrid database".

This is suitable for OLTP applications as usual and without modification, and still offers significant performance gains for analytical queries via Column Store.

Simple: installation and operation

To use in-memory in an existing database, only two steps are required: (1) The size of the in-memory column store must be defined by a parameter in the initialization file of the database. (2) The tables that are to be available in column format are then selected.

This makes it clear that changes to existing applications or infrastructures, for example for backup and recovery operations, are not necessary for the use of Oracle Database In-memory.

All the options of an Oracle database are retained with this approach, such as compression, encryption, Real Application Clusters or Data Guard.

It is important to dispel the widespread misconception that in-memory technology generally leads to performance improvements "just like that": This is neither the case with Hana nor with Oracle Database In-memory.

In the Oracle database, the Oracle In-memory Advisor helps with the setup. It provides information on the size of the required in-memory column store as well as information on tables that should be created as in-memory objects.

The Oracle Database Optimizer can now additionally use the Column Store to find the optimal access path for the respective analytical query.

The database can thus execute a query via the traditional buffer cache (unique index, index range scan) or via the in-memory column store. OLTP transactions are still executed in the buffer cache.

The database can be individually adjusted to its load distribution. The ratio of analytical and OLTP workload can be mapped via the ratio of buffer cache to in-memory store.

Oracle Database In-memory runs on all platforms that Oracle supports: UNIX, Linux, Windows. This makes the Oracle database an attractive, risk-free alternative to Hana for SAP users.

Oracle recommends its Exadata Database Machine as the optimal hardware platform. All the advantages of the Oracle database, including the in-memory option, can be fully exploited here. It offers various storage levels for the database: In-memory, flash and disk.

We will report in detail on the Oracle Exadata Database Machine for SAP in the next issue. Further information can be found in SAP Note 2178980 and on http://bit.ly/oracleinfo