Pure Storage® understands the headaches and challenges of maintaining and keeping Oracle databases running at maximum efficiency. By continuing to deliver innovation and value in our flagship product—Pure Storage FlashArray™—we’ve proven we can address these issues, simplify daily IT operations for Oracle database administrators (DBAs), and help you unlock new value in your data.

In support of those goals, Pure just announced the availability of our latest high-performance all-NVMe block storage product—FlashArray//X R3. This is the third generation of the FlashArray//X family (seventh generation of FlashArray) that delivers improved performance with the same easy and intuitive user experience, further advancing its place as an industry leader for all-flash and primary storage solutions. FlashArray//X R3 comes with updated controllers that feature new Intel Xeon Scalable Processors (formerly codenamed Cascade Lake), to keep Oracle databases operating at peak levels.  

Putting Improvements to the Test

To demonstrate the performance improvements, we ran a series of tests with the Silly Little Oracle Benchmark (a.k.a. SLOB) and HammerDB, popular Oracle benchmarking tools, to see how the FlashArray//X R3 compares with the previous generation //X (R2).

All the tests showed that FlashArray//X70 R3 demonstrated much lower latency and significantly higher IOPS and bandwidth compared to its predecessor. User I/O latency was reduced by up to 40%, IOPS and bandwidth increased by up to 52%. This directly reflected higher executions and transactions per second, resulting in faster application performance.

Needless to say, your mileage may vary. Performance gain depends on many factors, including application design and the current bottlenecks in your system. But these tests show that FlashArray//X R3, with is next-generation hardware and software upgrades, has set the performance bar even higher.

Setting Up the Test Environment

For this series of tests, we installed Oracle database 19c Enterprise Edition on four identical x86 commodity servers running Oracle Linux 7.7. As depicted below, we connected two servers (Host32 and Host33) to FlashArray //X70 R2 and another two servers (Host34 and Host35) to  FlashArray //X70 R3.

We next installed Oracle benchmarking tools SLOB and HammerDB on each of the four hosts. These tools generate workload on the Oracle database that is running on the same host. In addition, we set up another server as a Load Test Orchestrator. The orchestrator performs the following actions on each host connected to the FlashArray against which the test is being run: 

  1. Bounce the Oracle database.
  2. Start the load test. Each test is of 30 mins duration.
  3. Start OS monitoring (iostat and vmstat).
  4. Take an AWR snapshot after a delay of five mins.
  5. After 25 minutes into the load test, take another AWR snapshot.
  6. Generate an AWR report based on the two snapshots that were taken.
  7. Store the AWR report as well as OS monitoring data into its repository. 

Environment Specifications

Host

    •   Two Intel Xeon CPU E5-2697 v2 @ 2.70GHz with 12 cores
    •   Oracle Linux 7.7 with UEK 4.1.12-124.36.1
    •   512GB of memory

Oracle Database

    •   Oracle 19c (19.3.0.0)
    •   ASM with Filter Driver for ASM disk management
    •   SGA 32 GB

Storage

    •   FlashArray //X70 R2 with two 32Gb/s FC ports per controller
    •   FlashArray //X70 R3 with two 32Gb/s FC ports per controller
    •   Purity 5.3.5
    •   Four paths to the volumes

Oracle Performance Test with SLOB

The Silly Little Oracle Benchmark is a widely respected Oracle I/O workload generator and-load testing tool. It is free of all application-level contention and is very effective in testing the I/O subsystem with random single block physical reads as well as testing random single block writes.

Before you can execute a SLOB load test can be executed, you need to create the required database users and schema objects. We created 128 SLOB schemas each having a size (SCALE parameter in slob.conf) of 16G. This resulted in a SLOB database size of about 2T. We performed multiple SLOB tests with the following SLOB settings:

  •   Think time set to 0
  •   Scalability test with multiple users – 32,64,128,256,512,1024 and 2048
  •   Varying the read/update mix of workloads
    • 100% reads
    • 90% reads, 10% updates
    • 80% reads, 20% updates
    • 70% reads, 30% updates

We observed that at low database load, such as when the test was run with 32 or 64 users, there was a negligible difference between the performance of //X70 R3 as compared to //X70 R2. However, with increased loads, the //X70 R3 clearly outperformed its older sibling.  

In the following chart, we see that for a test with read/write ratio of 80/20, the transactions/second for 1024 user test increased by 51%. 

The next chart shows improvement in user I/O latency with //X70 R3 for different read/write ratios for 128 and 256 users. Here we are comparing the average wait time for “User I/O” wait-class statistics.

The next chart shows relative performance improvement of database IOPS in //X70 R3 over //X70 R2 for different read/write ratios for 128 and 256 users. The statistics used for calculating the delta came from the IO Profile section of the AWR report.

An increase in storage performance is meaningless if it does not translate into application performance. In the chart below, we can see how the improvements in I/O performance translates into higher executions/sec delta.

 The following table drills down into the 256 user SLOB test with an 80/20 read/write ratio and provides additional statistics. As we can see, the //X70 R3 performed significantly better with 36% lower user I/O latency and 52% higher IOPS and bandwidth. 

Improvement
User I/O Latency (ms) 36%
Read IOPS 52%
Write IOPS 52%
Read Bandwidth (MiB/s) 52%
Write Bandwidth (MiB/s) 52%
Executions/s 52%
Transactions/s 52%

SLOB 256 Users Test 80/20 Read/Write Ratio

In summary, we carried out extensive SLOB tests with different combinations of user counts and read/write ratios. We found that FlashArray //X70 R3 truly shows next-generation performance versus //X70 R2 in all respects—latency, IOPs, and throughput. That results in applications running faster, as indicated by higher executions/second achieved in //X70 R3.  

Oracle Performance Test with HammerDB

HammerDB is a leading benchmarking and load-testing tool for evaluating the performance of Oracle databases. It comes with a TPC-C like load test, which is the one we used for the next set of tests. It runs a mix of transactions that are around 75% read and 25% write.

Before we could run the TPC-C like test, we needed to create a tablespace and an Oracle database user, following which we built a 5000-warehouse schema. Similar to the setup for the SLOB tests, we connected two hosts running a single instance Oracle 19c database to each FlashArray. We performed multiple HammerDB tests with the following settings:

  •   User Delay : 1000 ms
  •   Repeat Delay : 1000 ms
  •   Scalability test with multiple vUsers – 64, 128, 256, 512, 1024 and 2048

The following chart shows a performance improvement of up to 35% for user I/O latency between FlashArray//X R3 and our previous generation R2. The raw numbers used for calculating the delta change come from the average wait time for “User I/O” wait-class statistic. 

The following chart shows that the performance improvement for database IOPS is up to 43% better when comparing //X R3 to //X R2.

 The last chart shows a transaction per second improvement percentage of up to 44% with 256 vUsers on FlashArray //X70 R3 vs. //X70 R2. 

The following table summarizes multiple improvements observed for a 256 user test. Significantly, user I/O latency decreased by 33%, while IOPS and bandwidth increased by more than 40%.

Improvement
User I/O Latency (ms) 33%
Read IOPS 43%
Write IOPS 43%
Read Bandwidth (MiB/s) 44%
Write Bandwidth (MiB/s) 42%
Executions/s 44%
Transactions/s 44%

HammerDB TPC-C 256 Users Test

HammerDB’s TPC-C like workload tries to emulate a real-life OLTP workload. We executed this test for 5000 warehouses with vUsers ranging from 64 to 2048. //X70 R3 demonstrated significantly higher performance. In the 256 vUser test, transactions per second increased by 44%. At higher vUser counts, the transactions-per-second improvement averaged approximately 34%. 

Listening to DBAs

The teams at Pure Storage listen closely to DBAs and understand the heavy demands and pressures they face to support increasing workloads. We know that rapid, unencumbered access to data is essential to organizations across the globe. In turn, a lack of access due to downtime or excessive latency and wait times can inhibit output and create frustrations for the business.

Our Evergreen™ model for non-disruptive software and hardware updates enables you to keep pace with increasing demands, eliminate time-consuming routine tasks, and do more with less. If you have a current license and are signed up for Pure’s Evergreen Gold subscription, you can get a “Free Every Three” set of new controllers every three years with your subscription renewal or do an Upgrade Flex within the three-year period. In addition, you get regular software updates for additional features regularly, which are always non-disruptive.  

The value in these upgrades goes beyond steady gains in raw performance. Each upgrade includes rich enterprise services spanning industry-leading data reduction, efficient and mobile snapshots, and robust business continuity and disaster recovery features that are simple to deploy. When your applications run faster and stay up with proven 99.9999% uptime, users can be more productive. That’s good for any business.

DBAs and their organizations choose to run their mission-critical production Oracle applications on FlashArray because of the exceptional performance, availability, efficiency, and simplicity it provides. With the latest release of the FlashArray //X R3, things just got even better.

More About FlashArray//X R3

0 Responses to Accelerate Oracle Database with the Next-Gen FlashArray//X

Leave a Reply

Your email address will not be published. Required fields are marked *