This technical paper demonstrates how customers can achieve business advantages with improved availability for business-critical applications by deploying database backup and restore operations on SSDs (16 pages)
In today’s world, business is global, with business processes that run on a 24 x 7 basis, and user demands that peak and ebb throughout the 24-hour cycle. Because of this reality, the availability of business-critical database applications is of primary importance. Any lapse, or failure, could cost the business millions of dollars in revenue, following an hour or more of downtime. That’s why businesses need to have a Business Continuity Plan (BCP) in place—and to maintain it, so that it can be activated quickly when downtime occurs.
Two metrics that define the BCP for database applications are the Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). The RPO allows business to recover to the point-in-time when the outage, or downtime, occurred. The RTO shows the amount of time it takes to reach that IT state—the way things were prior to the downtime.
In many data centers, database backup and any maintenance operations on such mission-critical database applications will have to be managed more efficiently than they are today. Database backup is an I/O-intensive operation. The presence of faster processors and faster systems, along with Oracle® Database 12c enhancements, provide many performance improvements, but, where storage is concerned, data still must be read and written to disk. The use of the traditional hard drives as the primary form of storage for such business-critical applications increases the time it takes to complete the backup and restoration processes. When this happens, the use of HDDs leads to inefficient utilization of business applications, and the revenue impact that brings.
There is another approach to deploying storage in the enterprise data center. The adoption of solid state drives (SSDs) is becoming pervasive in data centers that need faster processing—and faster timeto- results—than in traditional datacenters running primarily on hard-drive-based servers and storage. Data centers that are using flash storage for faster database performance are already seeing those benefits extended to database backup for business-critical applications.
This technical paper highlights the advantages of using SanDisk® SSDs to provide better RPO and RTO targets, thereby enabling the organization to meet demanding Service Level Agreements (SLAs) that are assigned to business-critical workloads.
SanDisk is a global leader in flash storage solutions, developing and selling a full portfolio of SSDs based on NAND technology. SanDisk offers purpose-built SSDs for a wide range of enterprise and cloud solutions, including those related to the megatrends of big data/analytics, cloud, mobility and social media.
With their performance and reliability, SanDisk Optimus™ SAS SSDs address enterprise storage and server applications. SanDisk Optimus drives provide best-in-class performance with a consistent quality of service (QoS). They provide IT flexibility, because IT managers can select storage ranging from 200GB to 3.84TB.
The Mean Time Between Failures (MTBF) for the Optimus SSDs is 2.5 million hours, with a guaranteed warranty period of five years. It should also be noted that the SanDisk Optimus drives are protected by SanDisk’s Guardian™ technology platform, increasing durability, recoverability, prevention of data loss and corruption.
This version of Oracle, which was introduced in June 2013, has introduced many new features, including expanded support for cloud-based workloads, including:
This paper is mainly focused on the performance for RMAN and Data Pump operations associated with Oracle Database 12c running in SSD and HDD deployments.
The RPO (Recovery Point Objective) and RTO (Recovery Time Objective) targets are the two important metrics that define a customer’s business continuity plan (BCP). The RPO defines the point-in-time at which the outage occurred—and the objective for the business, which is to recover to that point-intime, and the “state” of the database at that time. The RTO defines the amount of time that it takes to reach that IT state—the way things were prior to the downtime. Knowing the RTO and RPO values will guide customers when selecting the appropriate recovery technologies for their database deployments.
Figure 1: Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
For many database administrators, it has been a common practice to perform database backups with hard drives—and to transfer those backup images to tape, so that they can be restored in the event of database failure. This approach works well for normal business applications. However, for businesscritical applications, this approach has two limitations:
First, database backup to hard drives takes a considerable amount of time to get consistent backup for the RPO, affecting business usage and quality of service (QoS). Second, restoring the backup during failures impacts the RTO. It takes additional time to rebuild the database back to the same state it had prior to the downtime. In contrast, when flash storage (SSDs) are deployed as a backup media for business-critical applications, the rebuild performance is greatly improved. This approach, which expedites the backup and recovery processes through the use of SSDs, helps to alleviate IT concerns about RPO and RTO associated with system downtime.
|RPO AND RTO Target|
|Recovery Point Objective (RPO)||Zero data loss|
|Recovery Time Objective (RTO)||< 60 Seconds|
|Mean Time Between Failures (MTBF)
(i.e. reliable and fault-tolerant stack)
|5 years, hardware|
Table 1: Sample RPO and RTO Targets
The primary objective of this testing is to identify the advantages associated with deploying SSDs in Oracle database backup operations. Database administrators use Oracle Recovery Manager (RMAN) for full database backup—and they use Data Pump for table or schema-level backup to guarantee against data failures. This test, which was performed both for HDDs and SSDs, measured the performance of backup for the following categories:
RMAN and Data Pump operation elapsed time, database performance and system performance metrics were collected for analysis and reporting.
Testing hardware and software component details are provided in Table 2. For testing purposes, the Super Micro server internal storage drives were utilized for installation and configuring the Red Hat Enterprise Linux 6.5 operating system and the Oracle Database 12c software.
As shown in Figure 3, Automatic Storage Management (ASM) drive groups DATA(1/2), FRA, and REDO were created on both SSD and HDD drives and the Oracle 12c database was created on SSDs. As shown in Figure 2, the database was migrated between SSD storage and HDD storage to ensure that testing parameters and database configurations remained consistent for both types of storage environments. The testing results were captured for analysis and reporting.
|Server and Client|
|4 Optimus Eco™ SAS SSDs from SanDisk, each with 400GB
16 SAS 15K RPM HDD, each with 300GB
|Operating System||Red Hat® Enterprise Linux (RHEL) 6.5|
|Database||Oracle® Database 12c (220.127.116.11)|
Table 2: Hardware and Software Configuration
Figure 2: Data Pump and RMAN SSD and HDD Testing
Figure 3: Storage Layout with SanDisk SSD and HDD
The following sections provide details about the optimization that was carried out on the entire test environment stack, including the server, storage, operating system and database layers.
Following configuration settings enabled on the server
Following settings are enabled to take advantage of SanDisk SSDs:
Operating System Configuration
This section provides best practices and configuration settings implemented for Oracle Database 12c on the Red Hat Enterprise Linux (RHEL) 6.5 operating system.
### Virtual Memory Settings ### vm.swappiness = 0 vm.dirty_background_ratio = 3 vm.dirty_ratio = 80 vm.dirty_expire_centisecs = 500 vm.dirty_writeback_centisecs = 100 ### Shared memory Settings #### kernel.shmmax = 4398046511104 kernel.shmall = 1073741824 kernel.shmmni = 4096 ### Network Port Range ### net.ipv4.ip_local_port_range = 9000 65500 ### Optimum Network settings ## net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 ## Asynchronous I/O Request Settings fs.aio-max-nr = 1048576 ## File Handle Max limit fs.file-max = 6815744
SELinux was turned off
Shell Limits Settings
oracle soft nproc 16384 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768 grid soft nproc 16384 grid hard nproc 16384 grid soft nofile 1024 grid hard nofile 65536 grid soft stack 10240 grid hard stack 32768
Red Hat 6.5 provides a “tuned” package for optimizing database storage using Oracle ASM
Oracle Automatic Storage Management (ASM) Configuration
The following section highlights the benefits of using SanDisk Optimus SSDs, in terms of performance, when compared with HDDs:
Figure 4: SSD VS HDD Data Pump Elapsed Time
Data Pump Export and Import Operations
As shown in Figure 4, SSD database operations provide, on average, a 56% benefit, compared with HDDs. Data Pump operations running on servers with solid-state drives (SSDs) complete in less than half the time, compared to same jobs running on hard drive drives (HDDs).
Now, we’ll examine some technical aspects associated with achieving these results. These include the Oracle Database 12c Data Pump enhancements of:
Oracle’s ASM, because it is optimized to management storage for Oracle databases, provides superior performance for Oracle database workloads. It accomplishes this through the efficient distribution of I/O, across all of the available storage drives supplied to ASM. The same ASM benefits can be leveraged for Oracle Data Pump operations, as well, by creating a directory location on the ASM drive group and by initiating the Data Pump process to write and read from the ASM drive group.
As shown in the command section, below, a storage location directory named “DUMP100G” was created on the FRA ASM drive group. The “expdp” command initiated the Data Pump export process, which offloads or dumps the database contents by writing to the DUMP100G storage directory on the FRA drive group. The “impdp” command initiates the Data Pump import operation, which loads the DUMP100G storage contents back to the database. The syntax associated with the “expdp” and “impdp” commands is provided below. The same approach was adopted for carrying out testing of a 500GB Oracle database. The results of the Data Pump operations were recorded in the log file for SSDs and HDDs, as represented in Figures 5 and 6.
Data Pump Export and Import Command
SQL> Create or Replace directory DUMP100G as ‘+FRA/DUMP100G ’; # expdp system/XXXX SCHEMAS=TPCH100G CONTENT=ALL DIRECTORY=DUMP100G DUMPFILE=DUMP100G:tpch100%U.dmp LOGFILE=DUMP100GLOG:SSD_100G_exprt.log PARALLEL=32 LOGTIME=ALL & # impdp system/XXXX FULL=Y directory=DUMP100G DUMPFILE=DUMP100G:tpch100%U.dmp LOGFILE=DUMP100GLOG:100g_ssd_import.log PARALLEL=32 LOGTIME=ALL transform=disable_ archive_logging:Y &
Figures 5 and 6 show the Linux command “iostat” output graphs for the SSD-enabled and HDDenabled database images, respectively. The SSD benchmark generated 400 MB/s read and write throughput, and the total 800 MB/s throughput was generated during export operations with 100% SSD drive utilization. For the same test, HDD drives generated 200 MB/s read and write throughput, and a total throughput of 400 MB/s throughput with 100% HDD drive utilization. This shows that the Data Pump operations were completed more quickly with SSDs, and that the SSD drives were taking good advantage of running on faster and multi-threaded processors.
Figure 5: SSD IOSTAT Data Pump Performance
Figure 6: HDD IOSTAT Data Pump Performance
RMAN Backup and Restore Operations
Oracle Recovery Manager (RMAN) provides database backup, restore and recovery capabilities and it is tightly integrated with Automatic Storage Management (ASM). RMAN provides a common interface via a command line interface (CLI) and Oracle Enterprise Manager (OEM). This test involves a comparison between the performance of the database when using SSDs and when using HDDs, while leveraging RMAN best practices and incorporating Oracle Database 12c RMAN enhancements.
As shown in Figure 7, the RMAN backup and restore operation involves three distinct phases: Read, Copy and Write.
It is important to note that the RMAN script used for this testing backs up the database from data drive group (DATA) to backup drive group (FRA) by isolating the Read and Write workloads in two separate drive groups. RMAN parallel channels employed for increasing I/O throughput and large pool area sizing configuration settings adjusted to complement these RMAN parallel threads.
Figure 7: RMAN Data Flow
Starting with Oracle Database 12c, RMAN supports multi section for image copy and incremental Backupset. This feature helps in reducing the backup operation time by enabling RMAN channels to backup a single large file in parallel.
Figure 8 below shows the RMAN performance comparison, when using SSD or HDD to support databases ranging in size from 150GB to 500GB. This figure shows that SSDs deliver significantly improved backup and recovery time, helping databases to define lower RTO and RPO targets.
Figure 8: SSD VS HDD RMAN Performance
Oracle Enterprise Manager (OEM) performance graphs in Figures 9 and 10 show that the SSD-enabled server platform provides 1400 MB/sec throughput for RMAN operations, while the HDD-enabled platform drives 400MB/sec throughput. 3.5X performance throughput advantage with SanDisk Optimus SSD enables RMAN backup operation to complete in 71% shorter time.
Figure 9: HDD IO Performance Throughput for RMAN Operations
Figure 10: SanDisk Optimus SSD Performance Throughput for RMAN Operations
The business benefits of SSD-based backup solutions and how they support efficient utilization of database applications and reduce the “outage window” during application failures has already been discussed in this paper.
This section of the paper focuses on a cost-benefit analysis of SSD and HDD deployments supporting database backup solutions. As seen in Figure 11 below, backup and restore for a 150GB database under test consumed 57% of operational time in HDD environments, leaving only 43% of operational time for end users’ application transactions. In contrast, the backup and restore operations in SSD environments in our test were significantly faster—providing 87% of operational time for business use. This can have significant impact on revenue-generating business operations.
Figure 11: HDD versus SSD Database Utilization
The testing hardware, software components and configuration settings were identical for both the HDD and SSD deployments that were tested. That’s why this section explores the costs of acquiring enough drives, whether HDDs or SSDs, to support the full solution for database backup.
Four SanDisk Optimus Eco SSDs deliver 3X the performance throughput as a group of 16 HDDs. That’s why it would require 48 or more HDDs to match the performance of just 16 Optimus Eco SSDs.
The potential savings in terms of space, power and cooling costs demonstrate that the SanDisk Optimus SSD solution is a compelling alternative for database backup. This savings in operational costs (Opex) becomes evident when comparing the total number of solid state drives (SSDs) it takes to support a given solution—and the higher number of hard disk drives (HDDs) it takes to support the very same solution.
SanDisk Optimus Eco solid state drives deliver higher performance to expedite database operations for backup and recovery operations using Oracle’s Data Pump, and Oracle’s Recovery Manager (RMAN). By strategically using high-performance SSDs to back up data for business critical applications, IT professionals will be able to define lower RPO and RTO targets than before, thereby providing a more effective business continuity plan for their organizations.
The performance studies and analysis that were highlighted in this white paper demonstrated that just four SanDisk Optimus SSDs provide a performance advantage of more than 50%, compared to the performance provided by 16 HDDs. This test shows that, by deploying database backup and restore operations on SSDs, customers can achieve business advantages with improved availability for business-critical applications.