A goal of the modern business is real-time enterprise where analytics are run simultaneously with transaction processing on the same system to provide the most effective decision making. Oracle Database 12c Enterprise Edition utilizing the Oracle In-Memory option is designed for the same database to be able to perform transactions at the highest performance and to perform analytical calculations that once took days or hours to complete orders of magnitude faster.
Oracle's SPARC S7 processor has deep innovations to take the real-time enterprise to the next level of performance. In this test both OLTP transactions and analytical queries were run in a single database instance using all of the same features of Oracle Database 12c Enterprise Edition including the Oracle In-Memory option in order to compare the advantages of the SPARC S7 processor to the Intel Xeon Processor E5-2699 v3.
The SPARC S7 processor uses the Data Analytics Accelerator (DAX). DAX is not a SIMD instruction, but rather an actual co-processor that offloads in-memory queries which frees the cores up for other processing. The DAX has direct access to the memory bus and can execute scans at near full memory bandwidth. Oracle makes the DAX API available to other applications, so this kind of acceleration is not just available to Oracle Database.
Oracle's SPARC S7-2 server ran the in-memory analytics RCDB based queries 2.3x faster per chip under load than a two-chip x86 Intel Xeon Processor E5-2699 v3 server on the 24 stream test. Furthermore, the SPARC S7-2 server ran the in-memory analytics RCDB based queries 5.1x faster per core under load than the same x86 server.
The SPARC S7-2 server and the two-chip Intel Xeon Processor E5-2699 v3 server both ran OLTP transactions and the in-memory analytics on the same database instance using Oracle Database 12c Enterprise Edition utilizing the Oracle In-Memory option.
The table below compares the SPARC S7-2 server and 2-chip x86 Intel Xeon Processor E5-2699 v3 server while running OLTP and in-memory analytics against tables in the same database instance. The same set of transactions and queries were executed on each system. All of the following results were run as part of this benchmark effort.
|Real-Time Enterprise Performance Chart
24 RCDB DSS Streams, 112 OLTP users
x86 E5 v3
|SPARC Per Chip
|SPARC Per Core
(Transactions per Second)
(Queries per Minute)
The Real-Time Enterprise benchmark simulates the demands of customers who simultaneously run both their OLTP database and the related historical warehouse DSS data that would be based on that OLTP data. It answers the question of how a system will perform when doing data analysis, while at the same time executing real-time on-line transactions.
The OLTP workload simulates an Order Inventory System that exercises both reads and writes with a potentially large number of users that stresses the lock management and connectivity, as well as, database access.
The number of customers, orders and users is fully parametrized. This benchmark is base on 100 GB dataset, 15 million customers, 600 million orders and up to 580 users. The workload consists of a number of transaction types including show-expenses, part-cost, supplier-phone, low-inv, high-inv, update-price, update-phone, update-cost, and new-order.
The real cardinality database (RCDB) schema was created to showcase the potential speedup one may see moving from on disk, row format data warehouse/star schema, to utilizing Oracle Database 12c's In-Memory feature for analytical queries.
The DSS workload consists of, as many as, 2,304 unique queries asking questions such as "In 2014, what was the total revenue of single item orders?" or "In August 2013, how many orders exceeded a total price of $50?" Questions like these can help a company see where to focus for further revenue growth or identify weaknesses in their offerings.
RCDB scale factor 1050 represents a 1.05 TB data warehouse. It is transformed into a star schema of 1.0 TB, and then becomes 110 GB in size when loaded in memory. It consists of 1 fact table, and 4 dimension tables with over 10.5 billion rows. There are 56 columns with most cardinalities varying between 5 and 2,000, a primary key being an example of something outside this range.
The results were obtained running a set of OLTP transactions and analytic queries simultaneously against two schema: a real time online orders system and a related historical orders schema configured as a real cardinality database (RCDB) star schema. The in-memory analytics RCDB queries are executed using the Oracle Database 12c In-Memory columnar feature.
Two reports are generated: one for the OLTP-Perf workload and one for the RCDB DSS workload. For the analytical DSS workload, queries per minute and average query elapsed times are reported. For the OLTP-Perf workload, both transactions-per-second in thousands and OLTP average response times in milliseconds are reported.
All SPARC S7-2 server results were run with out-of-the-box tuning for Oracle Solaris.
All Oracle Server X5-2L system results were run with out-of-the-box tunings for Oracle Linux except for the setting in /etc/sysctl.conf to get large pages for the Oracle Database:
To create an in memory area, the following was added to the init.ora:
inmemory_size = 120g
An example of how to set a table to be in memory is below:
ALTER TABLE CUSTOMER INMEMORY MEMCOMPRESS FOR QUERY HIGH
Copyright 2016, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of June 29, 2016.
The previous information is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of Oracle.