How Oracle Database 12c embraces in-memory architecture

Tony Baer, Principal Analyst, Software – Enterprise Solutions

At the Oracle OpenWorld annual user conference last week, Oracle announced enhancements to the Oracle Database 12c platform, including a new in-memory option for both analytics and transactional applications and an extension of its engineered systems portfolio to cover backup and logging. The new Oracle Database In-Memory Option is targeted at improving performance with analytics and OLTP (online transaction processing).

The in-memory enhancement is in line with overall trends that Ovum has identified with data platforms adding the capability to handle more diverse workloads. Oracle also announced a new appliance with a long – but very descriptive – name: the “Oracle Database Backup Logging Recovery Appliance.” It is designed to make backup and recovery more manageable, reliable, and up to date.

The latest addition to Oracle’s engineered systems line does not add new capabilities beyond those available from software-only solutions from providers like Informatica. But it fills an important gap for Oracle’s engineered systems platforms to make them a more complete, self-reliant platform environment.

In-memory a natural step in data platform evolution

As enterprises face snowballing demands, not only to process larger or more diverse data sets, but also to more readily blend analytics into operations, transactional data platforms are adding new analytic capabilities that are increasingly set apart from the OLTP system. Oracle has joined IBM in appending capabilities to its core database platform that increase the performance and capability of analytics with separate analytic engines.

Oracle’s announcement is an “in-memory option” to Oracle Database 12c, which Ovum expects will hit general release around mid-2014. Having already added a columnar data store alongside the row store, Oracle this year took matters up a notch by adding an in-memory storage capability in both row and column format. This offers several benefits.

Killing two birds with one stone

The obvious benefit is that it accelerates analytic processing compared to conventional disk storage. Oracle claims OLTP processing that is twice as fast, and analytic processing that is up to 100x faster over the initial release of the 12c database generation.

The key to these benefits is that incorporating in-memory storage allows database designers to reduce or even eliminate analytic indexes. That, in turn, can greatly reduce database footprint, because indexes can multiply storage requirements geometrically (depending on the range of queries for which the database is modeled). And, while analytic indexes are used to speed query performance, burdening a database with multiple indexes typically slows OLTP performance.

In-memory is the latest refinement on the established practice of data tiering, where the most frequently used data is placed on the fastest storage. Traditionally that was on disk, but with the pricing of memory having dropped (until recently), it has become affordable to add memory as the fastest data storage tier.

Oracle’s core use case is for repurposing transactional data for analytics to allow, in effect, analytics that can be run with the same current data set as the transaction database. In the long run, Ovum believes that such a design approach should also foster development of transaction applications that embed analytics; it could provide another path for Oracle’s emerging “In-Memory Applications” (which are actually run in Flash, not DRAM).

Oracle is not the first to exploit in-memory; for instance, IBM, Teradata, and SAP HANA support it to varying degrees. Oracle is unique in that it is pairing it with a disk- and in-memory-based row store that will instantly replicate data to columnar tables. By comparison, SAP HANA (which offers a full in-memory store) requires the user to make an either/or decision of storing the data in row or in columnar format. By comparison, Teradata is only an analytic platform and IBM does not automatically treat in-memory columnar data as replicated from the transaction row store side.

The ACID test

While consistency may not always be as critical a consideration for pure analytic data stores, if the goal is ensuring that the analytic store is up to date with the transaction system, full ACID-compliance is essential. Oracle’s in-memory database option routes data to two destinations: data bound through the row store through the normal path (into cache, before committed to memory and/or disk), while column store is written straight to memory.

Oracle claims that writing data into memory will not add overhead to data being written to the row store and that the process should be instantaneous. The burden of proof is on Oracle to demonstrate that these claims are true.

An important new mouthful for engineered systems

Database backups and recoveries have long been a necessary evil; the process not only requires that data be copied or replicated onto a hot or cold standby system, but that the status of the database – the logs – is covered as well. Most database providers offer such capability. Nonetheless, taking backup and recovery down to the log level is not always observed in practice; many organizations simply copy off the data and, if they have to restore, resort to guesswork to avoid losing transactions and data.

Among Oracle’s message for engineered systems is self-management and optimization; the systems are designed to be optimized for the workload, and carry management features to deliver efficiency. Consequently, the announcement of the new Oracle Database Backup Logging Recovery Appliance (flouting grammatical correctness, the branding omits commas) is an important addition to Oracle’s engineered systems platforms by offering a self-contained solution for ensuring proper backups.

It reduces overhead and adds currency by conducting backups continually, with automatic checks to ensure backups are valid. Compared to software-based solutions, the appliance promises speed: backups are completed within subseconds. But there is one major difference between Oracle’s appliance-based backup and generic software solutions: the Oracle appliance only supports the Oracle database; that makes it a tight fit for all-Oracle installations, but not for mixed database environments.

The new appliance fills an important gap in Oracle’s strategy for high manageability in its engineered systems by extending the umbrella to the often-overlooked processes of backup and restore.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.