Get it right the first time: Dell best practices for busy Oracle DBAs
Tue, 20 Sep 2022 15:10:59 -0000
|Read Time: 0 minutes
Oracle databases are critical components of most business operations. As these systems become more intelligent and complex, maintaining optimal Oracle performance and uptime can pose significant challenges to IT—and often has severe implications for the business.
According to a 2022 Quest IOUG survey, industry estimates put the cost of IT downtime at approximately $5,600 a minute, with the range of losses between $140,000 and $540,000 per hour. Maintaining optimal efficiency and performance of database systems is essential. The same survey also reported that 43 percent of Oracle DBAs reported that maintaining database management and deployment inhibit business competitiveness.
What are Oracle best practices for PowerStore?
To address the pressures and challenges that Oracle DBAs and other IT professionals face, Dell offers a Best Practice Program for deploying critical applications on Dell infrastructure. Dell Best Practices for Oracle database solutions are a comprehensive set of recommendations for both the physical infrastructure and the software stack. These recommendations derive from extensive testing hours and expertise from the PowerEdge server team, PowerStore storage team, and Oracle specialists.
Why use these Oracle best practices?
Business-critical applications require an optimized infrastructure to run smoothly and efficiently. Not only does an optimized infrastructure allow applications to run optimally, but it also helps prevent future unexpected outcomes, such as system sluggishness that could potentially affect system resources and application response time. Such unexpected outcomes can often result in revenue loss, customer dissatisfaction and damage to brand reputation.
The purpose of the Oracle Best Practices Program
Dell’s mission is to ensure that its customers have a robust and high-performance database infrastructure solution by providing best practices for Oracle Database 19c running on PowerEdge R750xs servers and PowerStore T model storage including the new PowerStore 3.0. These best practices aim to reduce or eliminate the complex work that our customers would have to perform. To enhance the value of best practices, we identify which configuration changes produce the greatest results and categorize them as follows:
Day 1 through Day 3: Most enterprises implement changes based on the delivery cycle:
- Day 1: Indicates configuration changes that are part of provisioning a database. The business has defined these best practices as an essential part of delivering a database.
- Day 2: Indicates configuration changes that are applied after the database has been delivered to the customer. These best practices address optimization steps to further improve system performance.
- Day 3: Indicates configuration changes that provide small incremental improvements in the database performance.
Highly, moderately, and fine-tuning recommendations: Customers want to understand the impact of the best practices and these terms are used to indicate the value of each best practice.
- Highly recommended: Indicates best practices that provided the greatest performance in our tests.
- Moderately recommended: Indicates best practices that provide modest performance improvements, but which are not as substantial as the highly recommended best practices.
- Fine-tuning: Indicates best practices that provide small incremental improvements in database performance.
Best practices test methodology for Intel-based PowerEdge and PowerStore deployments
Within each layer of the infrastructure, the team sequentially tested each component and documented the results. For example, within the storage layer, the goal was to show how optimizing the number of volumes for DATA, REDO, and FRA disk groups improve performance of an Oracle database.
The expectation was that performance would sequentially improve. Using this methodology, the last test in changing the Linux operating system kernel parameters and database parameters would achieve an overall optimal SQL Server database solution.
The physical architecture consists of the following:
- 2 x PowerEdge R750xs servers
- 1 x PowerStore T model array
Table 1 and Table 2 below show the server configuration and the PowerStore T model configuration.
Table 1. Server configuration
Processors | 2 x Intel® Xeon® Gold 6338 32 core CPU @2.00GHz |
Memory | 16 x 64 GB 3200MT/s memory, total of 1 TB |
Network Adapters | Embedded NIC: 1 x Broadcom BCM5720 1 GbE DP Ethernet Integrated NIC1: 1 x Broadcom Adv. Dual port 25 GB Ethernet NIC slot 5: 1 x Mellanox ConnectX-5-EN 25 GbE Dual port |
HBA | 2 x Emulex LP35002 32 Gb Dual Port Fibre Channel |
Table 2. PowerStore 5000T configuration details
Processors | 2 x Intel® Xeon® Gold 6130 CPU @ 2.10 GHz per Node
|
Cache size | 4 x 8.5 GB NVMe NVRAM |
Drives | 21 x 1.92 TB NVMe SSD |
Total usable capacity | 28.3 TB |
Front-end I/O modules | 2 x Four-Port 32 Gb FC |
The software layer consists of:
- VMware ESXi 7.3
- Red Hat Enterprise Linux 8.5
- Oracle 19c Database and Grid Infrastructure
There are several combinations possible for the software architecture. For this testing, Oracle Database19c, Red Hat Enterprise Linux 8.5, and VMware vSphere 7.3 were selected to have a design that applies to many database customers use today.
Benchmark tool
HammerDB is a leading benchmarking tool that is used with databases such as Oracle, MySQL, Microsoft SQL Server, and others. Dell’s engineering team used HammerDB to generate an Online Transaction Processing (OLTP) workload to simulate enterprise applications. To compare the benchmark results between the baseline configuration and the best practice configuration, there must be a significant load on the Oracle infrastructure to ensure that the system was sufficiently taxed. This method of testing guarantees that the infrastructure resources are optimized after applying best practices. Table 3 shows the HammerDB workload configuration.
Table 3. HammerDB workload configuration
Setting name | Value |
Total transactions per user | 1,000,000 |
Number of warehouses | 5,000 |
Minutes of ramp up time | 10 |
Minutes of test duration | 50 |
Use all warehouses | Yes |
User delay (ms) | 500 |
Repeat delay (ms) | 500 |
Iterations | 1 |
New Order per Minute (NOPM) and Transaction per Minute (TPM) provide metrics to interpret the HammerDB results. These metrics are from the TPC-C benchmark and indicate the result of a test. During our best practice validation, we compare those metrics against the baseline configuration to ensure that there is an increase in performance.
Findings
After performing various test cases between the baseline configuration and the best practice configuration, our findings showed that the results with best practices applied, the performance improved over the baseline configuration. Table 4 describes the configuration details for the database virtual machines that are used in the following graphs.
Note: Every database workload and system is different, which means actual results of these best practices may vary from system to system.
Table 4. vCPU and memory allocation
Resource Reservation | Baseline configuration per virtual machine | Number of Oracle database virtual machines | Total |
vCPU | 16 cores | 4 | 64 cores |
Memory | 128 GB | 4 | 512 GB |