Wednesday Sep 25, 2013

SPARC T5-8 Delivers World Record Oracle OLAP Perf Version 3 Benchmark Result on Oracle Database 12c

Oracle's SPARC T5-8 server delivered world record query performance for systems running Oracle Database 12c for the Oracle OLAP Perf Version 3 benchmark.

  • The query throughput on the SPARC T5-8 server is 1.7x higher than that of an 8-chip Intel Xeon E7-8870 server. Both systems had sub-second average response times.

  • The SPARC T5-8 server with the Oracle Database demonstrated the ability to support at least 700 concurrent users querying OLAP cubes (with no think time), processing 2.33 million analytic queries per hour with an average response time of less than 1 second per query. This performance was enabled by keeping the entire cube in-memory utilizing the 4 TB of memory on the SPARC T5-8 server.

  • Assuming a 60 second think time between query requests, the SPARC T5-8 server can support approximately 39,450 concurrent users with the same sub-second response time.

  • The workload uses a set of realistic Business Intelligence (BI) queries that run against an OLAP cube based on a 4 billion row fact table of sales data. The 4 billion rows are partitioned by month spanning 10 years.

  • The combination of the Oracle Database 12cwith the Oracle OLAP option running on a SPARC T5-8 server supports live data updates occurring concurrently with minimally impacted user query executions.

Performance Landscape

Oracle OLAP Perf Version 3 Benchmark
Oracle cube base on 4 billion fact table rows
10 years of data partitioned by month
System Queries/
hour
Users Average Response
Time (sec)
0 sec think time 60 sec think time
SPARC T5-8 2,329,000 700 39,450 <1 sec
8-chip Intel Xeon E7-8870 1,354,000 120 22,675 <1 sec

Configuration Summary

SPARC T5-8:

1 x SPARC T5-8 server with
8 x SPARC T5 processors, 3.6 GHz
4 TB memory
Data Storage and Redo Storage
Flash Storage
Oracle Solaris 11.1 (11.1.8.2.0)
Oracle Database 12c Release 1 (12.1.0.1) with Oracle OLAP option

Sun Server X2-8:

1 x Sun Server X2-8 with
8 x Intel Xeon E7-8870 processors, 2.4 GHz
1 TB memory
Data Storage and Redo Storage
Flash Storage
Oracle Solaris 10 10/12
Oracle Database 12c Release 1 (12.1.0.1) with Oracle OLAP option

Benchmark Description

The Oracle OLAP Perf Version 3 benchmark is a workload designed to demonstrate and stress the ability of the OLAP Option to deliver fast query, near real-time updates and rich calculations using a multi-dimensional model in the context of the Oracle data warehousing.

The bulk of the benchmark entails running a number of concurrent users, each issuing typical multidimensional queries against an Oracle cube. The cube has four dimensions: time, product, customer, and channel. Each query user issues approximately 150 different queries. One query chain may ask for total sales in a particular region (e.g South America) for a particular time period (e.g. Q4 of 2010) followed by additional queries which drill down into sales for individual countries (e.g. Chile, Peru, etc.) with further queries drilling down into individual stores, etc. Another query chain may ask for yearly comparisons of total sales for some product category (e.g. major household appliances) and then issue further queries drilling down into particular products (e.g. refrigerators, stoves. etc.), particular regions, particular customers, etc.

While the core of every OLAP Perf benchmark is real world query performance, the benchmark itself offers numerous execution options such as varying data set sizes, number of users, numbers of queries for any given user and cube update frequency. Version 3 of the benchmark is executed with a much larger number of query streams than previous versions and used a cube designed for near real-time updates. The results produced by version 3 of the benchmark are not directly comparable to results produced by previous versions of the benchmark.

The near real-time update capability is implemented along the following lines. A large Oracle cube, H, is built from a 4 billion row star schema, containing data up until the end of last business day. A second small cube, D, is then created which will contain all of today's new data coming in from outside the world. It will be updated every L minutes with the data coming in within the last L minutes. A third cube, R, joins cubes H and D for reporting purposes much like a view might join data from two tables. Calculations are installed into cube R. The use of a reporting cube which draws data from different storage cubes is a common practice.

Query users are never locked out of query operations while new data is added to the update cube. The point of the demonstration is to show that an Oracle OLAP system can be designed which results in data being no more than L minutes out of date, where L may be as low as just a few minutes. This is what is meant by near real-time analytics.

Key Points and Best Practices

  • Building and querying cubes with the Oracle OLAP option requires a large temporary tablespace. Normally temporary tablespaces would reside on disk storage. However, because the SPARC T5-8 server used in this benchmark had 4 TB of main memory, it was possible to use main memory for the OLAP temporary tablespace. This was accomplished by using a temporary, memory-based file system (TMPFS) for the temporary tablespace datafiles.

  • Since typical business intelligence users are often likely to issue similar queries, either with the same or different constants in the where clauses, setting the init.ora parameter "cursor_sharing" to "force" provides for additional query throughput and a larger number of potential users.

  • Assuming the normal Oracle Database initialization parameters (e.g. SGA, PGA, processes etc.) are appropriately set, out of the box performance for the Oracle OLAP workload should be close to what is reported here. Additional performance resulted from using memory for the OLAP temporary tablespace setting "cursor_sharing" to force.

  • Oracle OLAP Cube update performance was optimized by running update processes in the FX class with a priority greater than 0.

  • The maximum lag time between updates to the source fact table and data availability to query users (what was referred to as L in the benchmark description) was less than 3 minutes for the benchmark environment on the SPARC T5-8 server.

See Also

Disclosure Statement

Copyright 2013, 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 09/22/2013.

Tuesday Mar 26, 2013

SPARC T5-8 Delivers Oracle OLAP World Record Performance

Oracle's SPARC T5-8 server delivered world record query performance with near real-time analytic capability using the Oracle OLAP Perf Version 3 workload running Oracle Database 11g Release 2 on Oracle Solaris 11.

  • The maximum query throughput on the SPARC T5-8 server is 1.6x higher than that of the 8-chip Intel Xeon E7-8870 server. Both systems had sub-second response time.

  • The SPARC T5-8 server with the Oracle Database demonstrated the ability to support at least 600 concurrent users querying OLAP cubes (with no think time), processing 2.93 million analytic queries per hour with an average response time of 0.66 seconds per query. This performance was enabled by keeping the entire cube in-memory utilizing the 4 TB of memory on the SPARC T5-8 server.

  • Assuming a 60 second think time between query requests, the SPARC T5-8 server can support approximately 49,450 concurrent users with the same 0.66 sec response time.

  • The SPARC T5-8 server delivered 4.3x times the maximum query throughput of a SPARC T4-4 server.

  • The workload uses a set of realistic BI queries that run against an OLAP cube based on a 4 billion row fact table of sales data. The 4 billion rows are partitioned by month spanning 10 years.

  • The combination of the Oracle Database with the Oracle OLAP option running on a SPARC T5-8 server supports live data updates occurring concurrently with minimally impacted user query executions.

Performance Landscape

Oracle OLAP Perf Version 3 Benchmark
Oracle cube base on 4 billion fact table rows
10 years of data partitioned by month
System Queries/
hour
Users* Average Response
Time (sec)
0 sec think time 60 sec think time
SPARC T5-8 2,934,000 600 49,450 0.66
8-chip Intel Xeon E7-8870 1,823,000 120 30,500 0.19
SPARC T4-4 686,500 150 11,580 0.71

Configuration Summary and Results

SPARC T5-8 Hardware Configuration:

1 x SPARC T5-8 server with
8 x SPARC T5 processors, 3.6 GHz
4 TB memory
Data Storage and Redo Storage
1 x Sun Storage F5100 Flash Array (with 80 FMODs)
Oracle Solaris 11.1
Oracle Database 11g Release 2 (11.2.0.3) with Oracle OLAP option

Sun Server X2-8 Hardware Configuration:

1 x Sun Server X2-8 with
8 x Intel Xeon E7-8870 processors, 2.4 GHz
512 GB memory
Data Storage and Redo Storage
3 x StorageTek 2540/2501 array pairs
Oracle Solaris 10 10/12
Oracle Database 11g Release 2 (11.2.0.2) with Oracle OLAP option

SPARC T4-4 Hardware Configuration:

1 x SPARC T4-4 server with
4 x SPARC T4 processors, 3.0 GHz
1 TB memory
Data Storage
1 x Sun Fire X4275 (using COMSTAR)
2 x Sun Storage F5100 Flash Array (each with 80 FMODs)
Redo Storage
1 x Sun Fire X4275 (using COMSTAR with 8 HDD)
Oracle Solaris 11 11/11
Oracle Database 11g Release 2 (11.2.0.3) with Oracle OLAP option

Benchmark Description

The Oracle OLAP Perf Version 3 benchmark is a workload designed to demonstrate and stress the ability of the OLAP Option to deliver fast query, near real-time updates and rich calculations using a multi-dimensional model in the context of the Oracle data warehousing.

The bulk of the benchmark entails running a number of concurrent users, each issuing typical multidimensional queries against an Oracle cube. The cube has four dimensions: time, product, customer, and channel. Each query user issues approximately 150 different queries. One query chain may ask for total sales in a particular region (e.g South America) for a particular time period (e.g. Q4 of 2010) followed by additional queries which drill down into sales for individual countries (e.g. Chile, Peru, etc.) with further queries drilling down into individual stores, etc. Another query chain may ask for yearly comparisons of total sales for some product category (e.g. major household appliances) and then issue further queries drilling down into particular products (e.g. refrigerators, stoves. etc.), particular regions, particular customers, etc.

While the core of every OLAP Perf benchmark is real world query performance, the benchmark itself offers numerous execution options such as varying data set sizes, number of users, numbers of queries for any given user and cube update frequency. Version 3 of the benchmark is executed with a much larger number of query streams than previous versions and used a cube designed for near real-time updates. The results produced by version 3 of the benchmark are not directly comparable to results produced by previous versions of the benchmark.

The near real-time update capability is implemented along the following lines. A large Oracle cube, H, is built from a 4 billion row star schema, containing data up until the end of last business day. A second small cube, D, is then created which will contain all of today's new data coming in from outside the world. It will be updated every L minutes with the data coming in within the last L minutes. A third cube, R, joins cubes H and D for reporting purposes much like a view might join data from two tables. Calculations are installed into cube R. The use of a reporting cube which draws data from different storage cubes is a common practice.

Query users are never locked out of query operations while new data is added to the update cube. The point of the demonstration is to show that an Oracle OLAP system can be designed which results in data being no more than L minutes out of date, where L may be as low as just a few minutes. This is what is meant by near real-time analytics.

Key Points and Best Practices

  • Update performance of the D cube was optimized by running update processes in the FX class with a priority greater than 0. The maximum lag time between updates to the source fact table and data availability to query users (what was referred to as L in the benchmark description) was less than 3 minutes for the benchmark environment on the SPARC T5-8 server.

  • Building and querying cubes with the Oracle OLAP option requires a large temporary tablespace. Normally temporary tablespaces would reside on disk storage. However, because the SPARC T5-8 server used in this benchmark had 4 TB of main memory, it was possible to use main memory for the OLAP temporary tablespace. This was done by using files in /tmp for the temporary tablespace datafiles.

  • Since typical BI users are often likely to issue similar queries, either with the same, or different, constants in the where clauses, setting the init.ora parameter "cursor_sharing" to "force" provides for additional query throughput and a larger number of potential users.

  • Assuming the normal Oracle initialization parameters (e.g. SGA, PGA, processes etc.) are appropriately set, out of the box performance for the OLAP Perf workload should be close to what is reported here. Additional performance resulted from (a)using memory for the OLAP temporary tablespace (b)setting "cursor_sharing" to force.

  • For a given number of query users with zero think time, the main measured metrics are the average query response time and the query throughput. A derived metric is the maximum number of users the system can support, with the same response time, assuming some non-zero think time. The calculation of this maximum is from the well-known "response-time law"

      N = (rt + tt) * tp

    where rt is the average response time, tt is the think time and tp is the measured throughput.

    Setting tt to 60 seconds, rt to 0.66 seconds and tp to 815 queries/sec (2,934,000 queries/hour), the above formula shows that the SPARC T5-8 server will support 49,450 concurrent users with a think time of 60 seconds and an average response time of 0.66 seconds.

    For more information about the "response-time law" see chapter 3 from the book "Quantitative System Performance" cited below.

See Also

Disclosure Statement

Copyright 2013, 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 03/26/2013.

Thursday Feb 17, 2011

SPARC T3-1 takes JD Edwards "Day In the Life" benchmark lead, beats IBM Power7 by 25%

Oracle's SPARC T3-1 server, running the application, together with Oracle's SPARC Enterprise M3000 server running the database, have achieved a record result of 5000 users, with 0.523 seconds of average transaction response time, for the online component of the "Day in the Life" JD Edwards EnterpriseOne benchmark.

  • The "Day in the Life" benchmark tests the Oracle JD Edwards EnterpriseOne applications, running Oracle Fusion Middleware WebLogic Server 11g R1, Oracle Fusion Middleware Web Tier Utilities 11g HTTP server and JD Edwards EnterpriseOne 9.0.1 in Oracle Solaris Containers, together with the Oracle Database 11g Release 2.

  • The SPARC T3-1 server is 25% faster and has better response time than the IBM P750 POWER7 system, when executing the JD Edwards EnterpriseOne 9.0.1 Day in the Life test, online component.

  • The SPARC T3-1 server had 25% better space/performance than the IBM P750 POWER7 server.

  • The SPARC T3-1 server is 5x faster than the x86-based IBM x3650 M2 server system, when executing the JD Edwards EnterpriseOne 9.0.1 Day in the Life test, online component.

  • The SPARC T3-1 server had 2.5x better space/performance than the x86-based IBM x3650 M2 server.

  • The SPARC T3-1 server consolidated the application/web tier of the JD Edwards EnterpriseOne 9.0.1 application using Oracle Solaris Containers. Containers provide flexibility, easier maintenance and better CPU utilization of the server leaving processing capacity for additional growth.

  • The SPARC Enterprise M3000 server provides enterprise class RAS features for customers deploying the Oracle 11g Release 2 database software.

  • To obtain this leading result, a number of Oracle advanced technology and features were used: Oracle Solaris 10, Oracle Solaris Containers, Oracle Java Hotspot Server VM, Oracle Fusion Middleware WebLogic Server 11g R1, Oracle Fusion Middleware Web Tier Utilities 11g, Oracle Database 11g Release 2, the SPARC T3 and the SPARC64 VII based servers.

Performance Landscape

JD Edwards EnterpriseOne DIL Online Component Performance Chart

System Memory OS #user JD Edwards
Version
Rack
Units
Response
Time
(sec)
SPARC T3-1, 1x1.65 GHz SPARC T3 128 Solaris 10 5000 9.0.1 2U 0.523
\*IBM Power 750, 1x3.55 GHz POWER7 120 IBM i7.1 4000 9.0 4U 0.61
IBM Power 570, 4x4.2 GHz POWER6 128 IBM i6.1 2400 8.12 4U 1.129
IBM x3650M2, 2x2.93 GHz X5570 64 OVM 1000 9.0 2U 0.29

\* from http://www-03.ibm.com/systems/i/advantages/oracle/, IBM used Websphere

Configuration Summary

Hardware Configuration:

1 x SPARC T3-1 server
1 x 1.65 GHz SPARC T3
128 GB memory
16 x 300 GB 10000 RPM SAS
1 x 1 GbE NIC
1 x SPARC Enterprise M3000
1 x 2.75 SPARC 64 VII
64 GB memory
1 x 1 GbE NIC
2 x StorageTek 2540/2501

Software Configuration:

JD Edwards EnterpriseOne 9.0.1 with Tools 8.98.3.3
Oracle Database 11g Release 2
Oracle Fusion Middleware 11g WebLogic server 11g R1 version 10.3.2
Oracle Fusion Middleware Web Tier Utilities 11g
Oracle Solaris 10 9/10
Mercury LoadRunner 9.10 with Oracle DIL kit for JD Edwards EnterpriseOne 9.0 update 1

Benchmark Description

Oracle's JD Edwards EnterpriseOne is an integrated applications suite of Enterprise Resource Planning software.

  • Oracle offers 70 JD Edwards EnterpriseOne application modules to support a diverse set of business operations.
  • Oracle 's Day-In-Life (DIL) kit is a suite of scripts that exercises most common transactions of J.D. Edwards EnterpriseOne applications including business processes such as payroll, sales order, purchase order, work order, and other manufacturing processes, such as ship confirmation. These are labeled by industry acronyms such as SCM, CRM, HCM, SRM and FMS.
  • Oracle's DIL kit's scripts execute transactions typical of a mid-sized manufacturing company.
  • The workload consists of online transactions. It does not include the batch processing job components.
  • LoadRunner is used to run the workload and collect the users' transactions response times against increasing numbers of users from 500 to 5000.
  • Key metric used to evaluate performance is the transaction response time which is reported by LoadRunner.

Key Points and Best Practices

Two JD Edwards EnterpriseOne and two Oracle Fusion Middleware WebLogic Servers 11g R1 coupled with two Fusion Middleware 11g Web Tier HTTP Servers instances on the SPARC T3-1 server were hosted in four separate Oracle Solaris Containers to demonstrate consolidation of multiple application and web servers.

  • Each Oracle Solaris container was bound to a separate processor set with 40 virtual processors allocated to each EnterpriseOne Server, 16 virtual processors allocated to each WebServer container and 16 to the default set. This was done to improve performance by using the physical memory closest to the processors, thereby, reducing memory access latency and reducing processor cross calls. The default processor set was used for network and disk interrupt handling.

  • The applications were executed in the FX scheduling class to improve performance by reducing the frequency of context switches.

  • A WebLogic Vertical cluster was configured on each WebServer container with seven managed instances each to load balance users' requests and to provide the infrastructure that enables scaling to high number of users with ease of deployment and high availability.

  • The database server was run in an Oracle Solaris Container hosted on the Oracle's SPARC Enterprise M3000 server.

See Also

Disclosure Statement

Copyright 2011, 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 2/16/2011.

About

BestPerf is the source of Oracle performance expertise. In this blog, Oracle's Strategic Applications Engineering group explores Oracle's performance results and shares best practices learned from working on Enterprise-wide Applications.

Index Pages
Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today