Our goal in testing this mixed workload solution was to simulate a consolidated database platform for use by both Oracle and SQL Server teams. Generally, consolidation of database ecosystems is less of a priority than performance and protection because the perceived risks and complexity that are involved in consolidating databases are daunting. However, the introduction of faster, more powerful CPUs and new storage technology in a tested, proven reference architecture enables businesses to consolidate databases without risk concerns.

The PowerMax 2000 storage array uses NVMe flash drives, which are significantly faster than traditional SATA solid-state drives (SSDs). NVMe flash drives provide several enhancements that accelerate storage operations, including greater parallelism and an updated bus that enables faster data transport. In testing this database platform, we created a mixed database environment using Oracle and SQL Server and a mixed workload environment including OLTP and DSS workloads. This combination of different databases and workloads simulates what a customer might encounter during a database consolidation effort. 

Validated infrastructure configuration

The MX7000 modular chassis hosts disaggregated blocks of server and storage, making it ideal for consolidating databases. In the test configuration, we used two PowerEdge MX840c servers in the MX7000 modular chassis. We dedicated one MX840c server to the SQL Server 2017 Enterprise Evaluation Edition RTM-CU13 database and the other to the Oracle 18c Enterprise Edition database. Dedicating an MX840c server to each database optimizes licensing by limiting costs and enables us to test database consolidation. In our tests, we identically configured each MX840c with 4 CPUs and 1.5 TB of memory. Each CPU had 20 cores, so 80 cores were available to each database. 

We deployed both SQL Server and Oracle database VMs with Red Hat Enterprise Linux 7 as the guest operating system. Microsoft enables SQL Server customers to move their database licenses from Windows to Linux for free. We standardized the operating system, using Linux on both databases, to simplify management. In terms of the mixed database tests, using the same operating system streamlined execution and enabled faster analysis of the performance findings.

We configured the PowerMax 2000 storage array with 24 NVMe flash drives, which represents an entry-level storage configuration. Using an entry-level configuration for our tests demonstrates that customers can start with a minimal investment and scale-up to match growing demands. The following table shows the size of the storage configuration that we used and the maximum sizes for the PowerMax 2000 array as detailed in the PowerMax Family Specification Sheet:

Table 1.           PowerMax 2000 maximum supported configuration versus tested configuration

While testing the storage performance of the PowerMax 2000 array, we had the following goals:

• Generate a significant mixed database workload to challenge the PowerMax 2000.
• Drive a combination of IOPS and submillisecond latency that is representative of the demand on a mixed workload ecosystem.
• Capture test findings and transform our analysis into best practices for customers.

NVMe

The PowerMax 2000 array supports NVMe flash drives. NVMe flash drives enable large-scale block storage to support existing network adapters and host bus adapters. One of the primary advantages of NVMe flash drives is enhanced performance. Other benefits of NVMe-based storage include:

• Lower latency and higher IOPS
• Support for deep queues: 64 commands per queue, up to 64K queues
• Streamlined register interface that minimizes the CPU utilization required to manage I/O operations 
• Transparency to databases, so you can realize the benefits of NVMe performance without extra steps 

Note: Dell EMC also offers the PowerMax 8000 system, which has even higher scaling and performance capabilities than the PowerMax 2000 that we used in our tests of this solution.

VMware vSphere

We used VMware vSphere in this reference architecture to drive greater consolidation, accelerate database provisioning, and simplify management. Virtualization lets you pool compute and storage resources to drive greater hardware efficiencies. In this mixed workload solution, we used vSphere to virtualize both the SQL Server and Oracle databases and to assign CPU and memory resources. 

In our testing, the CPU and memory resources were not the same between SQL Server and Oracle, nor were the number of databases. Our goal was not to compare SQL Server to Oracle, but to place mixed databases and database workloads on the MX840c servers and PowerMax 2000 array to show how this single-infrastructure solution accelerates consolidated databases. The following table shows the Oracle and SQL Server VM configurations:

Table 2.           Virtualization configuration for databases

Each virtualized database used a subset of the available compute cores on the MX840c servers. We assigned 24 compute cores to Oracle VMs, leaving 136 cores for additional database consolidation on the MX840c server that was dedicated to Oracle. Similarly, we assigned 32 compute cores to the SQL Server VMs, leaving 128 cores available for other databases. 

We used memory reservations to dedicate memory to each virtualized database. We set low memory reservations for each database to generate activity on the PowerMax 2000 storage array. If these databases were actual customer production applications, we would recommend reserving more memory, because in-memory operations are faster than storage operations. Like the CPU configurations, the memory configurations used a subset of the available memory on the server. Across all the Oracle virtualized databases, the amount of used memory was 188 GB and the total available memory on the MX840c server was 1.5 TB. For all the SQL Server virtualized databases, the amount of used memory was 88 GB and the total available memory on the MX840c server was 1.5 TB.

Compute cores could be limited at the database layer using Oracle CPU caging or SQL Server resource governor, or at the Linux operating system layer with cgroups. However, vSphere virtualization simplifies resource management, making it the best choice for assigning compute cores and memory. 

The PowerMax 2000 storage array supports vSphere Native Multipathing Plug-In (NMP) technology. Multipathing increases the efficiency of sending data over redundant hardware paths that connect PowerEdge servers to PowerMax storage. Benefits include alternating I/O using round-robin to optimize use of the hardware paths and more evenly distribute the data. Another benefit is that if any component along the storage path fails, then NMP resets the connection and passes I/O using an alternate path. 

Test performance metrics

We tested three incremental use cases:

• Use case 1: OLTP workload using TPC-C–like benchmark
• Use case 2: DSS workload using TPC-H–like benchmark
• Use case 3: Snapshot OLTP workload using TPC-C–like benchmark

The performance metrics for these tests included:

• CPU cores—We generated production-like workloads using as few CPU cores as possible. Oracle and SQL Server databases use core-based licensing. As the number of cores increase, so does the licensing cost. Using the combination of the MX840c servers and the PowerMax 2000 storage array enabled us to generate a significant database workload with fewer compute cores.
• CPU utilization—We captured CPU utilization at the Linux layer using dstat. The CPU utilization values that we captured represent the sum of all the work that was supported by the cores assigned to the VMs. Reporting CPU utilization provides an understanding of the processing load that was carried by the CPU cores in these tests. There were no target goals for CPU utilization because using fewer cores in each VM was a higher priority; however, we captured this metric to provide insight into the processing workload. 
• TPM—We captured the number of transactions per minute (TPM) to show how fast an OLTP database was processing transactions. A higher TPM value indicates that the database was processing more business transactions. In testing the mixed workload solution, the goal was to generate sufficient TPM to support a typical production workload. This metric applies to OLTP workloads only and is captured in the HammerDB report. 
• NOPM—New Orders per Minute (NOPM) is a throughput measurement in the TPC-C benchmark. Each transaction consists of the following transaction types: new-order, payment, order status, delivery, and stock-level transactions. Thus, NOPM indicates how many order transactions were completed in one minute as part of a serial business process. This metric applies to OLTP workloads only and is captured in the HammerDB report.
• IOPS—The number of IOPS indicates the load on a storage system. You can use IOPS to understand the amount of load that each database and application is placing on the array and if they are approaching the maximum load on the storage array. IOPS together with latency provides a comprehensive picture of storage performance. In these tests, the goal was to show IOPS that is appropriate for the support of production databases. 
• Latency in submilliseconds—Latency indicates how fast data is read and written to the storage array. Storage latency is an important metric for OLTP applications because the faster the storage system can respond to read and write requests, the more responsive the application experience is for the users. The storage latency goal for this solution was 1 ms or less for reads and writes to all data and log files on OLTP workloads that were simulating production workloads. 
• Throughput in megabytes per second (MB/s)—Throughput is a metric that is used for DSS workloads to indicate how fast the system can process large amounts of data using complex queries. The greater the throughput of a system, the more data it can process and the faster it can perform complex data analysis. Our goal was to generate a moderate level of throughput on the solution to show that customers can have both DSS workloads and OLTP workloads running in parallel.
• Compression and deduplication—We disabled PowerMax compression and deduplication at the storage group level for all use cases. Therefore, we did not observe data reduction in this validation testing.  In the stress-testing phase, we ran the worst-case test scenarios with 100 percent active data on the PowerMax 2000.  This workload profile does not take advantage of the PowerMax data reduction performance features. A typical database production environment with mixed workloads does benefit from the PowerMax compression and deduplication engine, which provides performance and consolidation advantages. You might prefer to use these features when you deploy the solution.