data protection for oracle database in mixed-application ... · pdf filecontents . data...

SOLUTION GUIDE

DATA PROTECTION FOR ORACLE DATABASE IN MIXED-APPLICATION WORKLOAD ENVIRONMENTS April 2017

Abstract

This solution guide illustrates the performance and efficiency of a Dell EMC solution for Oracle Database data protection as part of a mission-critical, mixed workload on Dell EMC Vblock System 740.

H15818R

This document is not intended for audiences in China, Hong Kong, and Taiwan.

Copyright

Data Protection for Oracle Database in Mixed-Application Workload Environments Solution Guide

The information in this publication is provided as is. Dell Inc. makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.

Use, copying, and distribution of any software described in this publication requires an applicable software license.

Copyright © 2017 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Intel, the Intel logo, the Intel Inside logo and Xeon are trademarks of Intel Corporation in the U.S. and/or other countries. Other trademarks may be the property of their respective owners. Published in the USA April 2017 Solution Guide H15818R.

Dell Inc. believes the information in this document is accurate as of its publication date. The information is subject to change without notice.

2

Contents


Contents

Chapter 1 Introduction 5 Business case ....................................................................................................... 6 Solution overview .................................................................................................. 6 Solution benefits ................................................................................................... 7 Audience ............................................................................................................... 8 We value your feedback ........................................................................................ 8

Chapter 2 Technology Components 9 Overview ............................................................................................................. 10 Data protection .................................................................................................... 10 Dell EMC Vblock System 740 ............................................................................. 11 Dell EMC AppSync .............................................................................................. 11 VMware vSphere ................................................................................................ 11 Enterprise mixed workloads ................................................................................ 12

Chapter 3 Architecture Overview 13 Logical architecture ............................................................................................. 14 Physical architecture ........................................................................................... 15 Hardware and software components ................................................................... 16

Chapter 4 Design Considerations 18 Overview ............................................................................................................. 19 Backup design .................................................................................................... 19

Chapter 5 Solution Validation 24 Test objective ...................................................................................................... 25 Workload profile .................................................................................................. 25 Test activities and results .................................................................................... 26

Chapter 6 Conclusion 35 Summary ............................................................................................................ 36

Chapter 7 References 37 EMC documentation ............................................................................................ 38 VMware documentation ...................................................................................... 38

Appendix A Backup Procedures 39 Configure AppSync service plan for offload backup automation .......................... 40 Run AppSync service plan for offload backup automation ................................... 46

3

Contents


Appendix B Restore Validation and Trial Recovery Procedures 49 Validate restore and perform trial recovery .......................................................... 50

Appendix C SLOB Tool 57 Configuration parameters .................................................................................... 58

Appendix D Test Results 60 Oracle initial backup ............................................................................................ 61 Oracle subsequent backup .................................................................................. 62

4

Chapter 1: Introduction


Chapter 1 Introduction

This chapter presents the following topics:

Business case ..................................................................................................... 6

Solution overview ............................................................................................... 6

Solution benefits ................................................................................................. 7

Audience .............................................................................................................. 8

We value your feedback ..................................................................................... 8

5



Business case The digital economy offers incredible opportunities for businesses, but it also brings formidable challenges. Businesses are changing at an accelerating pace to cope with ever-diversifying and personalized customer needs. This trend pushes the supporting IT organizations to struggle with limited resources to maintain complex existing applications and infrastructure, and invest in new and innovative solutions to better support the businesses.

IT organizations want to standardize and consolidate on platforms that can deliver mission-critical, mixed-application performance, and they need to provide adequate data protection at a reasonable cost.

As data volumes and the number of applications grow, data protection becomes increasingly important and difficult. The challenges include:

• Abundant data is scattered around different and sometimes isolated environments.

• The data footprint grows at an exponential rate.

• Businesses run 24 hours, and there is virtually no window for non-transactional activities such as backups.

Solution overview Converged infrastructure accelerates standardization and increases productivity by providing a proven platform that is engineered to optimize management, performance, and protection.

In today’s market, application owners are the influencers, if not the decision makers, when organizations choose a consolidation platform. Because they play such a vital role, they must understand and embrace the platform’s benefits. For example, IT organizations can use multiple databases, including Oracle and Microsoft SQL Server, and applications such as SAP Enterprise Resource Planning (ERP). Database administrators and application owners want assurance that running a mixed-application workload does not affect service levels. The consolidated platform must satisfy each application service-level agreement (SLA) for the solution to be successful.

The Dell EMC™ Vblock™ System 740 offers massive consolidation capability with up to 4 PB of raw storage capacity, Cisco UCS blade servers, and VMware vSphere virtualization. In this mixed-application solution, we tested the Vblock 740 in a consolidated platform scenario. This scenario shows customers how Vblock solutions can deliver performance while enabling an IT organization to gain efficiencies that include standardization. This solution uses Dell EMC Data Domain™, Dell EMC Avamar™, and Dell EMC AppSync™ data protection solutions to provide enterprise-grade application protection, achieving great process and footprint efficiency with zero performance impact to the mixed-production workloads.

In this solution, Dell EMC shows the results of several performance tests running Oracle, SQL Server, and SAP in parallel on the Vblock 740. You can review our approach and results to understand how the Vblock 740 provides a proven and trusted platform for data

6



center standardization and consolidation. This solution guide focuses on Oracle Database.

Solution benefits With this solution, Dell EMC proves that Vblock 740, Data Domain storage, and AppSync software deliver excellent performance in a heavily loaded, mixed-application workload environment during production backups. The solution benefits include:

• Vblock 740 converged infrastructure

Test results show little performance impact to the entire application environment while production backups are underway:

The Production database IOPS is relatively close to the baseline level during the backup window.

Database backup activity does not affect test/dev IOPS and online analytical processing (OLAP) bandwidth.

There is no impact to database response times (latency).

For more information, see Activity 1: Initial Oracle backup.

• AppSync automation

AppSync software seamlessly integrates with Dell EMC VMAX™ storage and other Dell EMC storage systems to automate databases activities.

Database administrators (DBAs) can automate cloning a production database, mounting it to a dedicated backup server, and backing up the database.

DBAs using AppSync software have access to Vblock 740 features and customize database backups by using a graphical user interface (GUI).

For more information about the AppSync process used to automate production backups, see Configure AppSync service plan for offload backup automation.

• Oracle Database backup throttling

Because this guide shows comparisons between throttling I/O bandwidth using the Recovery Manager RATE parameter at 500 MB/s and 1,000 MB/s, DBAs understand the benefits and costs to throttling Oracle Database backups.

For more information, see Activity 1: Initial Oracle backup.

• Data Domain backups

Data Domain deduplication and compression:

Save a substantial amount of storage space

Enable DBAs to perform fast and full daily database backups

Enable longer backup retention policies

Test Activity 2 shows the benefits of Data Domain as part of a daily full backup plan.

7



For more information about the benefits of Data Domain as part of a daily, full-backup plan, see Activity 2: Oracle subsequent backups.

Audience This solution guide is for infrastructure architects as well as database and system administrators who are looking for efficient backup solutions for Oracle Database in a mixed-application workload environment that is powered by a common converged-infrastructure platform.

We value your feedback Dell EMC and the authors of this document welcome your feedback on the solution and the solution documentation. Contact [email protected] with your comments.

Authors: Sam Lucido, Andrew Chen, Gavin Liao, Jason He, Mark Wu, Johnny Dai, Zhi Peng, Phil Hummel

8

mailto:[email protected]?subject=Data%20Protection%20For%20Oracle%20Database%20In%20Mixed-Application%20Workload%20Environments%20Solution%20Guide%20(H15818)

Chapter 2: Technology Components


Chapter 2 Technology Components


Overview ............................................................................................................ 10

Data protection .................................................................................................. 10

Dell EMC Vblock System 740 ........................................................................... 11

Dell EMC AppSync ............................................................................................ 11

VMware vSphere ............................................................................................... 11

Enterprise mixed workloads ............................................................................ 12

9



Overview This solution builds on the mixed-application workload solution described in the VCE Solution for Enterprise Mixed Workload on Vblock System 740 Solution Guide. In that solution, Vblock 740, AppSync software, and VMware vSphere are the key components. This solution adds Data Domain and Avamar data protection capabilities.

Data protection Data Domain deduplication storage systems and Avamar systems provide enterprise-grade backup and restore capabilities. The integration of these systems enables:

• A single point of management for backup and restore

• Avamar management of one or more Data Domain systems

• The use of Data Domain systems as a backup target for Avamar backups

• Avamar client integration with the Data Domain Boost™ (DD Boost™) Library so that the clients can send backups directly to Data Domain systems

Data Domain systems are disk-based, inline deduplication appliances and gateways that provide data protection and disaster recovery (DR) in the enterprise environment. Data Domain systems deduplicate data during the backup process so that the backup data is already deduplicated when it arrives on the disk, requiring a fraction of the disk space of the original dataset.

All Data Domain systems run the Data Domain Operating System (DD OS), which provides both a command line interface (CLI) for performing all system operations, and the Data Domain System Manager (DD System Manager) GUI for configuration, management, and monitoring.

For more information about Data Domain systems, see Dell EMC Data Domain. Avamar systems enable fast, efficient backup and recovery for enterprise workloads by reducing the size of backup data at the client before it is transferred across the network and stored. Reducing the size of backup data enables you to capture daily, full backups in a fraction of the time. Avamar Virtual Edition (Avamar VE) is a single-node, non-RAIN Avamar server that runs as a virtual machine (VM) in a VMware ESXi 5.1/5.5/5.5u2/6.0 environment. Avamar VE integrates the latest version of Avamar software with SUSE Linux as a VMware VM.

Avamar VE is similar to single-node Avamar servers in that it:

• Runs autonomously as a target for all Avamar client backups

• Performs replication to a physical Avamar system or another Avamar VE

Dell EMC Data Domain

Dell EMC Avamar Virtual Edition

10

https://www.emc.com/collateral/technical-documentation/h15197-vce-vblock-740-oracle-sql-sap-sg.pdf


https://www.emc.com/en-us/data-protection/data-domain.htm



Avamar VE supports backup of physical and virtual clients. For physical clients, install Avamar client software on each client. For virtual clients, choose from one of the following backup options:

• Guest OS backups (requires installing Avamar client software on each VM)

• Host-based backups (requires a proxy server)

For more information about Avamar VE, see Avamar Deduplication Backup Software and System.

Dell EMC Vblock System 740 Vblock Systems bring together compute, network, and storage components from vendors such as Cisco, Dell EMC, and VMware. Dell EMC integrates, configures, and then tests and validates all system elements before shipping a Vblock System. Seamless integration enables you to operate and manage the system as a single product instead of as individual components.

Vblock 740 uses VMAX storage. VMAX arrays can contain from 2 to 16 storage processors, depending on storage capacity requirements. For compute, the Vblock 740 can have multiple Cisco UCS domains. Cisco UCS products can support traditional operating-system and application stacks in physical environments, but they are optimized for virtualized environments.

For more information about Vblock 740, see Dell EMC VxBlock and Vblock Systems.

Dell EMC AppSync AppSync data protection software simplifies and automates the process of generating and consuming copies of production data. By abstracting the underlying Dell EMC storage and replication technologies, and through deep application integration, AppSync empowers application owners to satisfy copy demand for data repurposing, operational recovery, and DR using a single user interface. Storage administrators are only concerned with initial setup and policy management, which results in an agile, frictionless process.

For more information about AppSync software, see Dell EMC AppSync.

VMware vSphere The virtualization layer decouples the application from the underlying physical resources. This decoupling enables greater flexibility in the application layer by eliminating hardware downtime for maintenance and changes to the physical system without affecting the hosted applications. In a server-virtualization use case, this layer enables multiple independent VMs to share the same physical hardware.

VMware vSphere is a complete and robust virtualization platform that uses dynamic resource pools to virtualize business-critical applications with great flexibility and reliability. It transforms a computer's physical resources by virtualizing the CPU, RAM, hard disk,

11

http://www.emc.com/data-protection/avamar.htm

http://www.emc.com/data-protection/avamar.htm

http://www.emc.com/en-us/converged-infrastructure/converged-systems.htm

http://www.emc.com/storage/data-replication/appsync.htm



and network controller. This transformation creates fully functional VMs that run isolated and encapsulated operating systems and applications.

Enterprise mixed workloads For this solution, we tested and validated the ability of a single Vblock 740 with a Data Domain system to simultaneously sustain both mixed applications (Oracle, SQL Server, and SAP) and mixed workloads (OLTP, test/dev, Decision Support System (DSS), and backup) on a single Vblock System.

Microsoft SQL Server 2014 builds on the capabilities of the prior release by providing even greater performance, availability, and manageability for your mission-critical applications. SQL Server 2014 delivers in-memory capabilities that are built into the core database for online transaction processing (OLTP) and data warehousing. These built-in capabilities complement existing in-memory data warehousing and business-intelligence capabilities for the most comprehensive in-memory database solution on the market.

SQL Server 2014 also provides a new DR/backup capability and takes advantage of Microsoft Windows Server 2012 and Microsoft Windows Server 2012 R2 capabilities to provide a high level of scalability for your database application in a physical or virtual environment.

Oracle Database Enterprise Edition delivers performance, scalability, security, and reliability on a choice of clustered or single servers running Microsoft Windows, Linux, or UNIX. Oracle Database provides comprehensive features for transaction processing, business intelligence, and content management applications. This solution implements many Oracle Database features, including Real Application Clusters (RAC) and Automatic Storage Management (ASM). Oracle Database 12c R1 integrates Oracle ASM and Oracle Clusterware into the Oracle Grid Infrastructure. This integration provides the cluster and storage services that are required to run Oracle RAC databases. Oracle ASM is also extended to store Oracle Cluster Registry (OCR) and voting disks.

SAP Business Suite is a bundle of business applications that provides integration of information and processes, collaboration, industry-specific functionality, and scalability. SAP Business Suite is based on the SAP NetWeaver technology platform. SAP Business Suite 7 includes Enterprise Resource Planning (ERP) 6.0, Customer Relationship Management (CRM) 7.0, Supplier Relationship Management (SRM) 7.0, Supply Chain Management (SCM) 7.0, and Product Lifecycle Management (PLM) 7.0.

We used SAP ERP 6.0 in the test environment for this solution.

Microsoft SQL Server

Oracle Database

SAP Business Suite

12

Chapter 3: Architecture Overview


Chapter 3 Architecture Overview


Logical architecture .......................................................................................... 14

Physical architecture ........................................................................................ 15

Hardware and software components ............................................................... 16

13



Logical architecture Figure 1 shows the solution logical architecture.

Figure 1. Logical architecture

This solution consists of the following logical layers:

• The user layer has clients for each application.

• The utility layer has VMs for Avamar VE and AppSync components.

• The application layer components are application-specific, as shown in Table 1.

14



Table 1. Application layer components

Application Components

Oracle • 1 two-node Oracle RAC for production

• 10 single instances for test and dev

• 2 single instances for DSS—1 for the offload backup VM and 1 for the restore VMs

SAP • 1 system for production

• 5 systems for test and dev

SQL Server • 1 single instance for production

• 10 single instances for test and dev • 2 single instances for OLAP—1 for the offload backup VM and 1 for the

restore VM

Physical architecture This solution requires a single-cabinet Vblock 740 and a Data Domain 7200.

The application infrastructure consists of a dedicated, three-chassis, 24-blade Cisco UCS system with 15 hosts, as shown in Figure 2. A VMAX 450F all-flash array with four engines provides the back-end storage. The backup data, which is deduped and compressed for each backup operation, goes to the Data Domain 7200.

15



Figure 2. Physical architecture

Hardware and software components Table 2 lists the hardware that we used in the validation test environment.

Table 2. Hardware components

Layer Hardware Quantity

Compute Cisco UCS B200 M4 blade servers 15

Network Cisco UCS 6248UP Fabric Interconnects 2

Cisco MDS 9148 FC switches 2

Cisco Nexus 9396PX switches 2

Storage Dell EMC VMAX 450F all-flash array (4 engines, 2 TB mirrored cache)

1

Dell EMC Data Domain 7200 1

16



Table 3 lists the software used in the validation test environment.

Table 3. Software components

Software Version

Oracle Database 12c R1 Enterprise Edition 12.1.0.2

Oracle Enterprise Linux OEL 6.5

Oracle Grid Infrastructure 12c R1 Enterprise Edition 12.1.0.2

Silly Little Oracle Benchmark (SLOB) 2.2

Microsoft SQL Server 2014 Enterprise Edition SP1-CU5

Microsoft BenchCraft OLTP workload tool 1.12.0-1026

VMware vSphere 6.0

Microsoft Windows Server operating system 2012 R2 Standard Edition

SAP ERP 6.0 EHP5

SAP database (Oracle) 11g R2

SUSE Linux (for SAP) 11 SP3

SAP Power Benchmark Not applicable

Dell EMC AppSync 3.0.2.0

Dell EMC Avamar Virtual Edition 7.3.0-233

17

Chapter 4: Design Considerations


Chapter 4 Design Considerations


Overview ............................................................................................................ 19

Backup design .................................................................................................. 19

18



Overview This solution builds on the Enterprise Mixed Workloads on Vblock System 740 solution. Therefore, all configurations and design considerations are the same for each application and application infrastructure. See the VCE Solution for Enterprise Mixed Workload on Vblock System 740 Solution Guide for the complete design details.

This chapter provides additional design considerations that are specific for backup and restore of Oracle Database.

Backup design Backups are essential for protecting critical enterprise data that affects the financial operation of the company. The challenge for Oracle DBAs can be complex because they must choose an infrastructure and backup approach that safeguards the data without affecting application availability and performance. This challenge is not unique to Oracle, because most infrastructure is shared by using VMware vSphere to consolidate mixed applications.

This solution tested Oracle backups in a heavily loaded, mixed-application environment with SAP and SQL Server running on a shared Vblock 740 System. Our tests captured the performance profile of the following activities on Oracle Database while SAP and SQL Server workloads were running in parallel with the backups:

• Running Oracle backups at storage I/O bandwidths of 500 MB/s and 1,000 MB/s

• Running Oracle backups across 5 days of backup

DBAs can use the Oracle backup design and test results that are described in this guide to gain an understanding of how database backups perform with the Vblock 740 with Data Domain storage. For example, we used AppSync software to automate creating a copy of the production database on a dedicated backup server. Backing up from a copy of the production database on a dedicated backup server does not affect production performance and provides the DBA team with a production image that is never more than 24-hours old. Although every database backup design is customized, this guide provides a strong foundation for understanding backup options and performance in a mixed-application environment.

Oracle backup considerations

19





In this solution, we added backup and restore servers for the Oracle workloads. Table 4 shows the configuration details of the Oracle VMs.

Table 4. VM configuration for Oracle

VM role VM quantity vCPUs RAM (GB) OS

Oracle production (PRD) OLTP

2 28 40

Oracle Linux 6.5 64-bit

Oracle DSS 2 4 20

Oracle test/dev OLTP 10 4 20

Oracle backup server 1 14 20

Oracle restore server 2 28 40

Oracle load generate server

1 4 8

For the compute design of SQL Server and SAP Business Suite, see the VCE Solution for Enterprise Mixed Workload on Vblock System 740 Solution Guide.

Compute

20





Figure 3 shows the Oracle IP network architecture.

Figure 3. Oracle IP network architecture

We designed the solution’s IP network using separate virtual local area networks (VLANs) for the Oracle/SQL Server backup and restore operations. Table 5 shows the VLAN information for Oracle.

Table 5. VLAN information for Oracle

Name ID

CUSTOMER-VLAN-ORACLE 502

PRIVATE-VLAN-ORACLE 601

PRIVATE-VLAN-BACKUP_RESTORE 504

Network

21



For the IP network architecture for SQL Server and SAP Business Suite, see the VCE Solution for Enterprise Mixed Workload on Vblock System 740 Solution Guide.

Figure 4 shows the cluster and storage design for Oracle Database.

Figure 4. Storage design for Oracle Database

Table 6 shows the volumes that we created for the Oracle production database instances.

Table 6. Volumes for Oracle production instances

Name Size Quantity Description

DATA 1 TB 4 Oracle Database data files

FRA 500 GB 2 Oracle Database archived redo log files

OCR 10 GB 3 Oracle Database voting-disk file and OCR files

REDO 20 GB 4 Oracle Database online redo log files

Storage

22





AppSync software automatically mounts the Dell EMC SnapVX™ snapshot of the following volumes to the backup server to back up the database:

• DATA

• LOG

• FRA

For the detailed deployment steps, see the EMC AppSync User and Administration Guide. For the storage design for SQL Server and SAP Business Suite, see the VCE Solution for Enterprise Mixed Workload on Vblock System 740 Solution Guide.

23

https://support.emc.com/docu71556_AppSync-3.0.1-User-and-Administration-Guide.pdff?language=en_US



Chapter 5: Solution Validation


Chapter 5 Solution Validation


Test objective .................................................................................................... 25

Workload profile ................................................................................................ 25

Test activities and results ................................................................................ 26

24



Test objective We tested this solution to measure the impact of production backups on the end-user experience in a heavily loaded, mixed-application workload environment.

The previous chapters described the following solution components:

• Hardware components

• System software for virtualization and management

• Applications and workload simulation

This chapter describes the backup operations that we performed on the system and the performance impact of those backup operations for the simulated workloads. This chapter also shows how the backup operations affected the response latencies of the mixed workloads of Oracle, SQL Server, and SAP.

Workload profile To show the capabilities of this solution, we simulated a realworld, mixed-workload environment composed of Oracle, SQL Server, and SAP applications. We concurrently ran all workloads throughout all test activities. For a detailed workload profile of SQL Server and SAP Business Suite, see the VCE Solution for Enterprise Mixed Workload on Vblock System 740 Solution Guide.

In this solution, we used the Silly Little Oracle Benchmark (SLOB) tool to generate a random, read/write, I/O workload to the production and test/dev databases, simulating production and test/dev workloads. We also configured the SLOB tool to run queries that accessed data by using full table scans to generate sequential read-only I/O workloads to the DSS databases. This approach is the typical data-access pattern for a DSS reporting workload. Note that we modified the SLOB tool settings to populate the database with unique data rows instead of duplicated data rows as in the default settings.

Table 7 shows the Oracle production database configuration and workload profile.

Table 7. Oracle production database configuration and workload profile

Characteristic Description

Database type OLTP

Database size 3 TB

Oracle Database Two-node Oracle 12c R1 RAC on ASM

Instance configuration

SGA size: 16 GB

Note: Because a larger database cache buffers more data, we configured a small buffer cache to generate a stable and high physical I/O workload.

Workload profile SLOB random I/O workload with 80:20 read/write ratio and SLOB execution think time enabled See Appendix C for a full list of SLOB configuration parameters used.

Data block size 8 KB

25





Table 8 shows the Oracle test/dev database configuration and workload profile.

Table 8. Oracle test/dev database configuration and workload profile


Database type OLTP

Database size 3 TB

Oracle Database Single instance of Oracle 12c R1 on ASM that is provisioned from a SnapVX copy of the production database


SGA size: 16 GB

Note: Because a larger database cache size buffers more data, we configured a small buffer cache to generate a stable and high physical I/O workload.

Workload profile SLOB random I/O workload with 80:20 read/write ratio and SLOB execution think time enabled See Appendix C for a full list of SLOB configuration parameters used.


Table 9 shows the Oracle DSS database configuration and workload profile.

Table 9. Oracle DSS database configuration and workload profile


Database type DSS

Database size 3 TB

Oracle Database Single instance of Oracle 12c R1 on ASM, which is provisioned from a SnapVX copy of the production database


SGA size: 16 GB

Note: Because larger database cache size buffers more data, we configured a small buffer cache to generate a stable and high physical I/O workload.

Workload profile SLOB sequential read-only I/O workload with an I/O size of 128 KB and SLOB execution think time disabled See Appendix C for a full list of SLOB configuration parameters used.


Test activities and results The test procedure consisted of several related activities across the applications. The activities included tasks for backup, backup set validation, and restore for both the Oracle and SQL Server applications. Because this solution guide focuses on Oracle, we review only those activities that are related to backing up and restoring Oracle Database.

26



Table 10 shows the test metrics, source of the data, and the collection tools that we used to assess the impact of the backup activity on workload performance.

Table 10. Test metrics used in assessment

Metric Data source Collection method

VMAX storage group I/O latency

VMAX Dell EMC Unisphere™ for VMAX

VMAX cache hit ratio VMAX Unisphere for VMAX

VMAX storage group IOPS

VMAX Unisphere for VMAX

Vblock ESXi host CPU usage

vCenter vCenter performance panel

Vblock VM CPU usage


Backup network throughput


Backup data read bandwidth


Read and write IOPS Oracle Automatic Workload Repository (AWR) report

Taken from physical write I/O requests and physical read I/O requests of the System Statistics (Global) section

Read and write MB/s Oracle AWR report Taken from physical write bytes and physical read bytes of the System Statistics (Global) section

Read and write I/O operation latency

Oracle AWR report Taken from database file sequential read, database file parallel read, and log file parallel write of the Top Timed Events section

CPU usage Oracle OSWatcher Block Box running on production VMs

Calculated the average idle CPU usage during the test and then subtracted it from 100

Data Domain space usage

Data Domain Data Domain System Manager

Backup duration Oracle Recovery Manager (RMAN)

RMAN log files

We documented a performance baseline while running the following mixed workloads in parallel:

• Oracle production, test/dev, and DSS

• SQL Server production, test/dev, and OLAP

• SAP production and test/dev

Activity 1 involved running an Oracle backup against a 3 TB database on a clean system that had never been backed up to the Data Domain system. We tested two scenarios for this activity by throttling the backup storage I/O bandwidth to 500 MB/s and 1,000 MB/s

Baseline performance

Activity 1: Initial Oracle backup

27



using the RMAN RATE parameter. We removed the backup data from the Data Domain system after each activity to ensure that there were no existing Oracle Database backup sets resulting from deduplication that would reduce the amount of data that needed to be backed. The backup rate scenarios from this activity had impact on the remaining activities, regardless of which initial backup scenario they followed.

Figure 5 shows the initial Oracle backup performance bandwidth and throughput.

Figure 5. Initial Oracle backup performance: Bandwidth and throughput

The average backup read bandwidth was 497 MB/s for the 500 MB/s bandwidth test and 974 MB/s for the 1,000 MB/s bandwidth test. This result proves that we can achieve our goals. The average network throughput was 157 MB/s for the 500 MB/s test and 293 MB/s for the 1,000 MB/s test.

28



Figure 6 shows the initial Oracle backup performance duration and CPU utilization.

Figure 6. Initial Oracle backup performance: Duration and CPU utilization

In our testing, the average backup duration for the 1,000 MB/s test was almost twice as fast at 68 minutes, compared to 131 minutes for the 500 MB/s test. However, this result was at the expense of CPU utilization. For the bandwidth test, the 1,000 MB/s CPU utilization was almost twice as high at 62.11 percent, compared to the 500 MB/s CPU utilization at 32.97 percent.

Both the 500 MB/s and 1,000 MB/s tests used the same amount of space (1,116.5 GB) on the Data Domain system. This result shows that both initial backup tests backed up the same amount of data.

29



Figure 7 shows the initial Oracle performance IOPS and throughput.

Figure 7. Initial Oracle performance: IOPS and throughput

The Oracle production baseline at 82,292 IOPS and test/dev databases at 19,262 IOPS drove a combined 101,554 IOPS of workload on the Vblock 740. The baseline performance reflects the databases running without any backup activity. The large Oracle workload was only part of the scenario because SQL Server and SAP applications were also running in parallel on the system.

The most notable of the three environments is the PRD aggregate IOPS, in which the production IOPS is 2,855 higher than the 500 MB/s Oracle backup and 3,337 higher than the 1,000 MB/s Oracle backup. This difference between the baseline and the two Oracle backups is, at most, 4 percent, which is not significant due to the 62 minutes for the 500 MB/s test and 33 minutes for the 1,000 MB/s test.

The other categories (test/dev aggregate IOPS and OLAP aggregate bandwidth) have no significant performance deltas. This result means that the Oracle production backup did not affect our test/dev and OLAP environments.

30



Figure 8 shows the Oracle performance latencies during initial backup.

Figure 8. Initial Oracle performance: Latency

The latency of the Oracle production read baseline was 1 ms, the latency of the 500 MB/s read backup was 1.03 ms, and the latency of the 1,000 MB/s read backup was 1.09 ms. These results mean that the database read response times remained at the gold standard for all-flash arrays. There was no variation for production write latency across the baseline, 500 MB/s, and 1,000 MB/s backups.

For the production log write latency, the baseline was 1 ms, the 500 MB/s log write was 0.91 ms, and the 1,000 MB/s log write was 0.9 ms. The Vblock 740 with the VMAX system has a large write cache with write coalescing that provides excellent write latency for demanding applications such as databases. Write coalescing merges subsequent small random writes from different times into one large sequential write. In this case, the VMAX system’s ability to cache all writes combined with write coalescing reduced the log write latency for production during the backup tests.

The results of Activity 1 showed:

• A minor IOPS delta between baseline production, 500 MB/s, and 1,000 MB/s backups that is insignificant because backup times are short

• No impact to test/dev IOPS or OLAP MB/s from the two Oracle backup tests

• During the backup tests, consistent I/O latency of 1 ms or less for production reads and writes

The results from Activity 1 prove that Vblock 740 can manage a significant workload.

The two Oracle backup tests were similar in terms of the production IOPS and test/dev IOPS, which means that DBAs can increase the bandwidth of their backups and reduce backup time by nearly half (if there is sufficient network throughput and backup server CPU capacity).

31



During the tests, we observed no infrastructure bottlenecks, such as ESXi server CPU utilization or storage cache hit ratios. See Appendix D for the performance metrics.

In Activity 2, we performed additional full backups of Oracle Database to the Data Domain system to show the efficiency of deduplication. Before backing up the database, we modified 5 percent of the data (2.5 percent update and 2.5 percent insert) to create changed data for back up. We ran a full backup five times to simulate five daily backups. We used full backups in this test activity to achieve:

• Minimal time to restore data or lower recovery time objective (RTO)

• Data Domain deduplication efficiency gains to save network throughput and CPU utilization

We throttled the backup storage I/O bandwidth to 1,000 MB/s by setting the RMAN RATE parameter based on the results of Activity 1, where we saw no significant impact from the higher backup rate.

This section presents the results of this Activity 2 relative to baselines, with 1 meaning that the daily average is the same as the baseline. The dotted line in each of the figures shows the baseline performance and provides a visual means to compare results.

Figure 9 shows the backup performance ratios of subsequent backup tests to baseline.

Figure 9. Backup performance ratios: Subsequent backup tests to baseline

Baseline refers to the first backup of the production database. When the DBA backs up a database for the first time, backup takes longer because all the data is unique, eliminating any possibility for saving storage spaced based on deduplication. The average backup network throughput proves that the baseline backup takes more MB/s than the daily average. With subsequent daily backups, Data Domain deduplication reduces network throughput, providing ongoing value after the first backup.

0.109

1.1

0.507

0

0.2

0.4

0.6

0.8

1

1.2

Avg. backup networkthroughput (MB/s)

Backup duration Backup server CPU usage

Baseline Daily average

Activity 2: Oracle subsequent backups

32



Figure 10 shows the ratio of IOPS and bandwidth from subsequent backup tests to the baseline. The daily average full backup duration was slightly longer (as shown in Figure 9) than the baseline backup. A full backup includes reading all blocks in the database, so backup time is not reduced. However, as previously mentioned, Data Domain deduplication does substantially save on network throughput. For the daily average full backups, the 5 percent data change rate adds approximately 7 minutes of additional backup time.

The backup server CPU usage (as shown in Figure 9) for the subsequent full backups was almost half that of the baseline backups. Deduplication saves CPU usage because it results in significantly less data being sent over the network to the Data Domain system. On average, 175 GB of unique data was sent to the Data Domain system for each daily full backup.

Figure 10. IOPS bandwidth ratios: Subsequent backup tests to baseline

We took the average IOPS for production, test/dev, and OLAP across 5 days and divided that result by the baseline performance to show the ratio across these metrics. The results show relatively little difference between the IOPS for subsequent backups and the baseline. In terms of IOPS, the backup workload had no significant impact on the mixed applications.

0.962 0.990 0.999

0

0.2

0.4

0.6

0.8

1

1.2

Total PRD IOPS Total test/dev IOPS DSS aggregated bandwidth


33



Figure 11 shows the latency ratios of subsequent backup tests to baseline.

Figure 11. Latency ratios: Subsequent backup tests to baseline

We took the average latency in milliseconds for production reads, writes, and log writes across 5 days and divided that result by the baseline performance to show the ratio across these metrics. A comparison of latency between baseline and Oracle subsequent backups shows relatively little difference. In terms of latency, the backup workload had no significant impact on the production database.

The results of Activity 2 show:

• In subsequent full backups, the Data Domain system with deduplication provided efficiencies such as:

Minimized network throughput

Minimized CPU usage

Saved storage capacity

• DBAs can use full daily backups with minimal impact to backup times and gain the advantage of a lower RTO.

• In a heavily loaded, mixed-application environment, backup activity on Vblock 740 did not affect Oracle Database IOPS and throughput.

• Backup activity had no significant impact on read or write latency. In Activity 3, we validated the backup of Oracle Database without restoring the data. Oracle DBAs use this capability to ensure that there is no physical or logical corruption of backup sets. We also tested full recovery including the log tail to a newly created two-node Oracle RAC and validated the restored database to ensure that it was in good working order. See Appendix B for the validation procedure.

1.080 1.047 0.938

0

0.2

0.4

0.6

0.8

1

1.2

PRD data read latency PRD data write latency PRD log write latency


Activity 3: Oracle backup validation and recovery

34

Chapter 6: Conclusion


Chapter 6 Conclusion


Summary ........................................................................................................... 36

35

Chapter 6: Conclusion


Summary Testing of this solution proves that Vblock 740 can support a large mixed-application workload of 228,000 IOPS, of which Oracle Database represents just over 82,000 IOPS. In our testing, the addition of full Oracle Database backups did not affect production database performance. Production IOPS and latency remained near the baseline measurements during the backup activity tests. This solution provides DBAs and application users with consistent response times across all databases while full backups are underway.

This solution uses AppSync data protection software to automate creating a copy of the production database, mounting it to a dedicated backup server, backing up the database, and unmounting the copy. AppSync uses snapshots to create database copies quickly. Using the AppSync GUI, DBAs can also use storage features that are normally only available to storage administrators.

DBAs must ensure that, in the event of a database failure, the database is available to the business within the planned recovery time objective (RTO). The capability of doing full database backups quickly and efficiently enables a quick database recovery. For example, in Activity 1: Initial Oracle backup, a 3 TB full database backup using 1,000 MB/s throughput was completed in 33 minutes. The advantage of a short, full backup window is that the DBA team does not have to use differential or incremental backups that could lengthen database recovery time.

The combination of a streamlined, full, daily database backup policy combined with the performance capabilities of Vblock 740 enables DBAs to simplify their overall backup plan. Part of every backup plan includes defining a backup storage location and the backup retention policy. In Activity 1, the initial backup of the 1 TB database took 400 GB, or approximately 40 percent of the total database size. In Activity 1, the initial backup of the 3 TB database took only 1,116.5 GB, approximately one-third of the total database size. In Activity 2: Oracle subsequent backups, the average size of the daily full backups was 175 GB. The tests show that the Data Domain system reduces capacity requirements, making it is an ideal target to store backups. Additionally, DBAs can have a longer backup retention policy because daily, full backups use a fraction of the space of the total database size on the Data Domain system.

Activity 3: Oracle backup validation and recovery proved the effectiveness of the backups. We ensured that backup sets had no corruption, and we tested full recovery and ensured that the restored database was in working order.

36

Chapter 7: References


Chapter 7 References


EMC documentation ......................................................................................... 38

VMware documentation .................................................................................... 38

37

Chapter 7: References


EMC documentation The following documentation on EMC.com or EMC Online Support provides additional and relevant information. Access to these documents depends on your login credentials. If you do not have access to a document, contact your Dell EMC representative.

• Microsoft SQL Server Best Practices and Design Guidelines for EMC Storage White Paper

• Dell EMC VMAX All Flash Storage For Mission-Critical SQL Server Databases White Paper

• VMAX All Flash Family Specification Sheet

• EMC AppSync User and Administration Guide

• EMC Avamar 7.3 Administration Guide

• EMC Avamar 7.3 for Windows Server User Guide

• EMC Avamar 7.3 for SQL Server User Guide

• EMC Avamar Integration with EMC Data Domain Systems White Paper

• Dell EMC HYPERMAX OS TimeFinder Local Replication Technical Note

• Dell EMC VxBlock and Vblock Systems 740 Architecture Overview

• Vblock System 740 Data Sheet

• VCE Solution for Enterprise Mixed Workload on Vblock System 740 Solution Guide

VMware documentation The following documentation on the VMware website provides additional and relevant information:

• Performance Best Practices for VMware vSphere 6.0

38

http://www.emc.com/

https://support.emc.com/

http://www.emc.com/collateral/white-papers/h12341-sqlserver-bp-wp.pdf

http://www.emc.com/collateral/white-papers/h12341-sqlserver-bp-wp.pdf

http://www.emc.com/collateral/white-papers/h15019-vmax-all-flash-storage-for-sql-server-wp.pdf

http://www.emc.com/collateral/white-papers/h15019-vmax-all-flash-storage-for-sql-server-wp.pdf

http://www.emc.com/collateral/spec-sheet/h14892-vmax-af-ss.pdf

https://support.emc.com/docu71556_AppSync-3.0.1-User-and-Administration-Guide.pdff?language=en_US

https://support.emc.com/docu69617

http://taiwan.emc.com/collateral/TechnicalDocument/docu69643.pdf

https://support.emc.com/docu69637

https://www.emc.com/collateral/software/white-papers/h8883-avamar-dd-integration-wp.pdf

https://www.emc.com/collateral/technical-documentation/h13697-emc-vmax3-local-replication.pdf

http://www.emc.com/collateral/software/technical-documentation/vce-740-architecture-overview.pdf

https://www.emc.com/sp/cloud/vblock-system-720-data-sheet.pdf


http://www.vmware.com/

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-perfbest-practices-vsphere6-0-white-paper.pdf

Appendix A: Backup Procedures


Appendix A Backup Procedures

This appendix presents the following topics:

Configure AppSync service plan for offload backup automation .................. 40

Run AppSync service plan for offload backup automation ........................... 46

39



Configure AppSync service plan for offload backup automation To configure the AppSync service plan to automate offload backup:

1. In the AppSync GUI, select Service Plans and click Oracle, as shown in Figure 12.

Figure 12. Select Oracle service plan

2. Click Create. Choose the template and type the Plan Name, as shown in Figure 13.

40



Figure 13. Choose the template and type the plan name

3. Select Service Plans, click Oracle, and then double-click the service plan that you created in step 2, as shown in Figure 14.

Figure 14. Select the service plan

41



4. Select Create local copy. In Oracle Options, select Copy the Fast Recovery Area. In Storage Preference, select all three options.

Figure 15 shows the Settings tab for the service plan.

Figure 15. Service plan Settings tab

5. Click Mount copy. In Mount Settings, from the Mount on Server list box, select the server on which to mount the snapshot and other options, as shown in Figure 16.

42



Figure 16. Specify snapshot mount options

6. Select Post-mount script. In Post-mount script, as shown in Figure 17, complete the Full path to script field with the backup script and the username/password that is required to log in to the backup server to run the backup script.

43



Figure 17. Specify backup script and OS username/password

Figure 18 and Figure 19 show the scripts that the AppSync software runs to back up the database after the snapshot is mounted to the backup server and the database is opened.

44



Figure 18. Post-mount script in AppSync

Figure 19. RMAN backup script used in post-mount script

7. Select Unmount copy, and then click Apply, as shown in Figure 20.

45



Figure 20. Configure the backup service plan

Run AppSync service plan for offload backup automation To run the AppSync service plan for offload backup:

1. In the AppSync GUI, select Service Plans and click Oracle.

2. Select the service plan and click Run to begin the backup, as shown in Figure 21.

46



Figure 21. Select the AppSync backup service plan

Figure 22 shows the run results.

47



Figure 22. AppSync service plan run results

The following is the content of the Avamar flag file that the Avamar client uses in the backup server:

--pidname=Oracle --pidnum=1002 --logfile=/usr/local/avamar/var/clientlogs/avtar.log --vardir=/usr/local/avamar/var/clientlogs --id=oracle@avamar/clients/host12c --ap=oracle --path=/clients/host12c --expires=10 --ddr=true --ddr-index=1 --server=XXXXXXXX

48

Appendix B: Restore Validation and Trial Recovery Procedures


Appendix B Restore Validation and Trial Recovery Procedures


Validate restore and perform trial recovery .................................................... 50

49



Validate restore and perform trial recovery A good backup and recovery strategy includes periodic validation of your backups. Merely performing regular backups cannot guarantee that you can use the backups to successfully restore and recover the database.

In addition, scheduling regular trial recoveries using the latest backups for various simulated scenarios is a good practice. Performing trial recoveries not only verifies that the backups are being made correctly, but it also provides practice with recovery techniques, commands, and procedures.

This section describes the process to validate the backups of Oracle Database, as well as how to conduct trial recovery for Oracle Database.

To validate the Oracle Database backup sets on the backup server without restoring them to the array:

1. On the backup server, log in with SQLPLUS, and bring the database to the mount state by typing the following command:

startup mount;

2. Log in to RMAN and run the following script to restore the control file:

run{ allocate channel c1 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; send channel='c1' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c1_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c1_TEST"'; restore controlfile from 'controlfile_SLOBDB_20161202_2986-929492570.bck'; release channel c1; }

3. Mount the database in RMAN by using the ALTER DATABASE MOUNT command:

4. Run the RESTORE DATABASE PREVIEW; command to identify the archived redo files that are required to recover the database.

As shown in Figure 23, the archived log file with sequence number 540 is required for recovery.

Validate backups

50



Figure 23. Preview restore to identify archived log sequence needed for recovery

5. Run the following script to validate the backup of the data files:

run{ allocate channel c1 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; ...... allocate channel c16 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; send channel='c1' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c1_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c1_TEST"'; …… send channel='c16' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c16_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c16_TEST"'; restore validate check logical database; release channel c1; …… release channel c16; }

51



6. After the validation is completed, query v$database_block_corruption to verify that there is no physical or logical corruption in the backup of the data files.

Figure 24 shows the results of the database query.

Figure 24. Database query

7. Run the following script to validate the backup of the archived redo log files:

run{ allocate channel c1 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; ...... allocate channel c16 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; send channel='c1' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c1_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c1_TEST"'; ...... send channel='c16' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c16_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c16_TEST"'; restore archivelog sequence 540 validate check logical; release channel c1; ...... release channel c16; }

8. After the validation is completed, query v$database_block_corruption to verify that there is no physical or logical corruption in the backup of the archived redo log files.



52



The following is the content of the Avamar flag file that the Avamar client uses in the backup server:


To conduct the trial recovery:

1. On one of the nodes of the newly created two-node RAC, log in with SQLPLUS and start the instance using the STARTUP command with the NOMOUNT clause:

startup nomount;

2. Log in to RMAN and run the following script to restore the control file:

run{ allocate channel c1 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; send channel='c1' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c1_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c1_TEST"'; restore controlfile from 'controlfile_SLOBDB_20161202_2986-929492570.bck'; release channel c1; }

3. Mount the database in RMAN using the ALTER DATABASE MOUNT; command.

4. Run the following RMAN script to restore the database to the newly deployed RAC environment:

run{ allocate channel c1 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; …… allocate channel c16 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; send channel='c1' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--

Conduct trial recovery

53



logfile=/usr/local/avamar/var/clientlogs/c1_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c1_TEST"'; …… send channel='c16' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c16_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c16_TEST"'; restore database; release channel c1; …… release channel c16; }

5. Type the following command to validate the archived redo log files without applying the redo data to the restored data files:

recover database test until cancel using backup controlfile;

As shown in Figure 26, applying the archived redo does not corrupt any data block in the restored data files.

Figure 26. Verify the archived redo to be applied to the restored data files

6. Type the following command to recover the database and open it for access:

recover database until cancel using backup controlfile;

Figure 27 shows the results of recovering the database and opening it for access.

54



Figure 27. Recover the database and open it for access

7. After the database is open for access, run the following RMAN script to validate the database:

run{ allocate channel c1 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; …… allocate channel c16 type sbt PARMS="SBT_LIBRARY=/usr/local/avamar/lib/libobk_avamar64.so ENV=(PATH=/bin:/usr/local/avamar/bin)"; send channel='c1' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c1_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c1_TEST"'; …… send channel='c16' '"--flagfile=/home/oracle/my-avtar-flags.txt" "--logfile=/usr/local/avamar/var/clientlogs/c16_TEST_avoracle.log" "--bindir=/usr/local/avamar/bin" "--cacheprefix=c16_TEST"'; validate database check logical; release channel c1; …… release channel c16; }

55



8. After the validation is completed, query v$database_block_corruption to verify that there is no physical or logical corruption in the backup of the data files.



The following is the content of the Avamar flag file that the Avamar client uses in the newly created two-node RAC, which is the same as the Avamar flag file used in the backup server:


56

Appendix C: SLOB Tool


Appendix C SLOB Tool

This appendix presents the following topic:

Configuration parameters ................................................................................ 58

57



Configuration parameters Table 11 shows the Silly Little Oracle Benchmark (SLOB) tool configuration parameters that we used for the production database workload.

Table 11. SLOB tool configuration parameters used for the production database workload

Parameter Value

UPDATE_PCT 25

RUN_TIME 900

SCALE 400,000

WORK_UNIT 32

REDO_STRESS Light

LOAD_PARALLEL_DEGREE 8

SHARED_DATA_MODULUS 0

DO_UPDATE_HOTSPOT False

HOTSPOT_PCT 10

THINK_TM_MODULUS 7

THINK_TM_MIN 0.1

THINK_TM_MAX 0.5

Table 12 shows the SLOB tool configuration parameters that we used for the test/dev database workload.

Table 12. SLOB tool configuration parameters used for the test/dev database workload

Parameter Value

UPDATE_PCT 25

RUN_TIME 900

SCALE 400,000

WORK_UNIT 32

REDO_STRESS Light




HOTSPOT_PCT 10

THINK_TM_MODULUS 7

THINK_TM_MIN 0.1

THINK_TM_MAX 0.5

58



Table 13 shows the SLOB tool configuration parameters that we used for the DSS workload.

Table 13. SLOB tool configuration parameters used for the DSS workload

Parameter Value

UPDATE_PCT 0

RUN_TIME 900

SCALE 4,000,000

WORK_UNIT 32

REDO_STRESS Light




HOTSPOT_PCT 10

THINK_TM_MODULUS 0

THINK_TM_MIN 0.1

THINK_TM_MAX 0.5

59

Appendix D: Test Results


Appendix D Test Results


Oracle initial backup ......................................................................................... 61

Oracle subsequent backup .............................................................................. 62

60



Oracle initial backup Table 14 shows the backup performance data that we collected during the initial backup tests.

Table 14. Oracle initial backup performance

Initial backup Avg. backup read bandwidth (MB/s)

Avg. backup network throughput (MB/s)

Avg. backup duration (min)

Average DD space increase (GB)

Backup server CPU usage (%)

500 MB/s 497.3 157.5 131 1116.5 32.97

1,000 MB/s 974.0 293.0 68 1116.5 62.11

Table 15 through Table 18 show the performance data collected for the Oracle production, test/dev, and DSS databases in Activity 1.

Table 15. Oracle production database: Activity 1—Overall performance

Scenario PRD aggregate IOPS

Test/dev aggregate IOPS

OLAP aggregate bandwidth (MB/s)

PRD data read latency (ms)

PRD data write latency (ms)

PRD log write latency (ms)

Baseline 82,292 19,262 2,046 1.00 1.10 1.00

Initial backup—500 MB/s 79,437 19,380 2,048 1.03 1.10 0.91

Initial backup—1,000 MB/s 78,955 19,414 2,036 1.09 1.10 0.90

Table 16. Oracle production database: Activity 1—Storage group cache hit ratio

Scenario Data read hit ratio (%) Data read hit ratio (%) Log write hit ratio (%)

Baseline 10.45 100 64.60

Initial backup—500 MB/s 9.89 100 64.20

Initial backup—1,000 MB/s 9.53 100 64.74

Table 17. Oracle production database: Activity 1—CPU usage

Scenario RAC node 1 CPU usage (%)

RAC node 2 CPU usage (%)

VM 1 CPU usage (%)

VM 2 CPU usage (%)

ESXi 1 CPU usage (%)


Baseline 48 48 10.7 10.5 13.2 11.7

Initial backup—500 MB/s 53 53 15.9 15.5 18.3 16.7

Initial backup—1,000 MB/s 38 52 16.1 15.9 19.4 16.9

61



Table 18. Oracle production database: Activity 1—AWR I/O latency

Scenario DB file sequential reads average wait time (ms)

DB file parallel reads average wait time (ms)

Log file parallel writes average wait time (ms)

Baseline 1.23 3.45 1.51

Initial backup—500 MB/s 1.26 3.83 1.48

Initial backup—1,000 MB/s 1.27 3.95 1.42

Oracle subsequent backup Table 19 shows the backup performance data that we collected during subsequent backups.

Table 19. Oracle subsequent backup performance

Subsequent backup (1,000 MB/s)

Avg. backup read bandwidth (MB/s)

Avg. backup network throughput (MB/s)

Avg. backup duration (min)

Avg. Data Domain space increase (GB)

Backup server CPU usage (%)

Day 1 980 29.9 75 175 30.4

Day 2 996 34.6 74 174 32.6

Day 3 992 31.1 75 173 31.3

Day 4 977 31.4 75 174 31.6

Day 5 993 33.4 75 168 31.7

Table 20 through Table 23 show the performance data collected for the Oracle production, test/dev, and DSS databases in Activity 2. Table 20. Oracle production database: Activity 2— Overall performance

Scenario

PRD aggregate IOPS

Test/dev aggregate IOPS

DSS aggregate bandwidth (MB/s)

PRD data read latency (ms)

PRD data write latency (ms)

PRD log write latency (ms)

Baseline 82,292 19,262 2,046 1.00 1.10 1.00

Day 1 79,712 19,296 2,048 1.08 1.14 0.94

Day 2 78,669 19,341 2,046 1.06 1.11 0.90

Day 3 79,710 19,365 2,048 1.10 1.20 1.01

Day 4 78,833 19,381 2,046 1.05 1.11 0.90

Day 5 79,029 17,983 2,033 1.11 1.20 0.94

62



Table 21. Oracle production database: Activity 2—Storage group cache hit ratio

Scenario Data read hit ratio (%) Data write hit ratio (%) Online redo log write hit ratio (%)

Baseline 10.45 100 64.6

Day 1 9.33 100 65.0

Day 2 9.13 100 64.7

Day 3 9.24 100 63.5

Day 4 9.07 100 64.0

Day 5 9.10 100 63.4

Table 22. Oracle production database: Activity 2—CPU usage

Scenario RAC node 1 CPU usage (%)

RAC node 2 CPU usage (%)

VM 1 CPU usage (%)

VM 2 CPU usage (%)



Baseline 48.0 48.0 10.7 10.5 13.2 11.7

Day 1 51.5 51.8 16.4 16.0 20.0 17.2

Day 2 52.7 52.9 15.9 15.6 19.4 16.8

Day 3 52.4 51.7 15.9 15.8 18.7 17.0

Day 4 54.0 53.5 16.2 15.8 19.4 17.0

Day 5 52.9 52.1 16.2 15.8 19.6 16.9

Table 23. Oracle production database: Activity 2—Response times

Scenario Avg. data read latency (ms)

Avg. data write latency (ms)

Avg. log write latency (ms)

Baseline 1.23 3.45 1.51

Day 1 1.27 3.56 1.41

Day 2 1.32 3.77 1.56

Day 3 1.28 3.70 1.48

Day 4 1.30 3.80 1.50

Day 5 1.30 3.74 1.48

63

data protection for oracle database in mixed-application ... · pdf filecontents . data...

Documents