EMC VMAX3 Service Level Objectives and SnapVX for Oracle RAC ...

White Paper

EMC VMAX3 SERVICE LEVEL OBJECTIVES AND SNAPVX FOR ORACLE RAC 12c

Perform one-click, on-demand provisioning of multiple, mixed Oracle workloads with differing Service Level Objectives

Non-disruptively adjust the Service Level Objective while running an Oracle workload

Create numerous SnapVX snapshots of a running Oracle database with no performance impact and improved ease-of-use

EMC Solutions

Abstract

This White Paper describes how the VMAX3 SLO feature manages mixed Oracle workloads, allows upgrading to a higher SLO to improve performance, and creates SnapVX instant copies for Oracle test/dev without impacting the production server.

February 2015

EMC Confidential

2 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c White Paper

Copyright © 2015 EMC Corporation. All rights reserved. Published in the USA.

Published February 2015

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

The information in this publication is provided as is. EMC Corporation 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 EMC software described in this publication requires an applicable software license.

EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c White Paper

Part Number H13896

http://www.emc.com/legal/emc-corporation-trademarks.htm

http://www.emc.com/legal/emc-corporation-trademarks.htm

EMC Confidential Contents


Contents

Chapter 1 Executive Summary 7

Business challenges ................................................................................................... 8

Technology solution ................................................................................................... 8

Chapter 2 About This Document 9

Purpose .................................................................................................................... 10

Scope ....................................................................................................................... 10

Audience .................................................................................................................. 10

Terminology and acronyms ....................................................................................... 10

Chapter 3 Technology Overview 11

Introduction ............................................................................................................. 12

Solution architecture ................................................................................................ 12

Hardware resources ............................................................................................. 13

Software resources .............................................................................................. 13

Key components ....................................................................................................... 14

EMC VMAX3 ......................................................................................................... 14

EMC HYPERMAX OS .............................................................................................. 14

EMC VMAX Service Level Objective ...................................................................... 14

EMC VMAX3 FAST ................................................................................................. 15

EMC TimeFinder SnapVX ...................................................................................... 15

EMC Unisphere for VMAX ..................................................................................... 16

VMware vSphere .................................................................................................. 16

Oracle Database 12c Enterprise Edition ............................................................... 16

SLOB Workload Generator ................................................................................... 17

Chapter 4 Database Deployment 19

Introduction ............................................................................................................. 20

VMAX Online Sizer Tool overview ......................................................................... 20

Storage provisioning with VMAX3 SLO ...................................................................... 20

Provisioning considerations ................................................................................. 21

Provisioning the OLTP Database .......................................................................... 22

Virtualization layer: ESXi and virtual machines ......................................................... 26

Configuring OLTP and DW databases ........................................................................ 27

Database Storage Analyzer ....................................................................................... 29

Contents EMC Confidential


Chapter 5 Use Case 1: Mixed Workload on VMAX3 35

Use case overview .................................................................................................... 36

Test with mixed workload ......................................................................................... 37

Test objectives ..................................................................................................... 37

Test procedures ................................................................................................... 37

Test results .......................................................................................................... 37

Summary of use case ........................................................................................... 41

Chapter 6 Use Case 2: Upgrade SLO 43


Test for upgrading SLO ............................................................................................. 44

Test objectives ..................................................................................................... 44

Test procedures ................................................................................................... 44

Change SLO ......................................................................................................... 44

Test results .......................................................................................................... 46


Chapter 7 Use Case 3: Business Continuity for Oracle Database 49

Overview .................................................................................................................. 50

Test with SnapVX ...................................................................................................... 50

Test scenario ....................................................................................................... 50

Test objectives ..................................................................................................... 50

Test procedures ................................................................................................... 50

Create an on-demand backup .............................................................................. 50

Schedule snaps ................................................................................................... 52

Test results .......................................................................................................... 55


Chapter 8 Conclusion 57

Summary .................................................................................................................. 58

Findings ................................................................................................................... 58

Appendix A References 59

References ............................................................................................................... 60

EMC documentation ............................................................................................ 60

Oracle documentation ......................................................................................... 60

VMware documentation ....................................................................................... 60

SLOB information ................................................................................................ 60

EMC Confidential Contents


Figures Figure 1. Solution architecture diagram ............................................................. 12

Figure 2. FAST workload-based data placement ................................................. 15

Figure 3. TimeFinder SnapVX snapshots ............................................................ 16

Figure 4. Service level objectives ....................................................................... 20

Figure 5. SLO - Average response time ............................................................... 21

Figure 6. Enter Service Level Objectives ............................................................. 22

Figure 7. Selecting the storage pool ................................................................... 22

Figure 8. Creating the storage group .................................................................. 23

Figure 9. Selecting the Host Group ..................................................................... 23

Figure 10. Selecting the port group ...................................................................... 24

Figure 11. Reviewing and completing the configuration ....................................... 24

Figure 12. Launch the Database Storage Analyzer (DSA) application .................... 29

Figure 13. Login pop-up windows ........................................................................ 30

Figure 14. Adding monitored databases .............................................................. 30

Figure 15. Select DSA user type ........................................................................... 31

Figure 16. Set monitored environment parameters............................................... 31

Figure 17. Parameter confirmation ....................................................................... 32

Figure 18. Database Storage Analyzer Dashboard ................................................ 32

Figure 19. Performance chart ............................................................................... 33

Figure 20. Average response time - 75/25 QUERY/UPDATE ratio test - AWR report .................................................................................. 38

Figure 21. System statistics - 75/25 QUERY/UPDATE ratio test - AWR report ......... 38

Figure 22. Query throughput – DW query workload test - AWR report.................... 39

Figure 23. Response time of the baseline from DSA ............................................. 40

Figure 24. Response time of the OLTP workload running with DW from DSA ......... 40

Figure 25. OLTPRAC storage group’s SLO before change ...................................... 45

Figure 26. Modifying the SLO ............................................................................... 45

Figure 27. OLTPRAC storage group’s SLO after change ......................................... 45

Figure 28. Average response time on Platinum SLO - AWR report.......................... 46

Figure 29. Comparison of performance between the Platinum and Gold SLO levels .................................................................................. 47

Figure 30. Select the TimeFinder menu ................................................................ 51

Figure 31. Click TimeFinder/SnapVX .................................................................... 51

Figure 32. Create a snapshot ............................................................................... 51

Figure 33. Set expiration days .............................................................................. 52

Figure 34. Snapshot created ................................................................................ 52

Figure 35. Create a task ....................................................................................... 53

Figure 36. Edit the scheduler trigger time ............................................................. 53

Contents EMC Confidential


Figure 37. Edit the action ..................................................................................... 54

Figure 38. Find the new SnapVX snaps in Unisphere ............................................ 54

Figure 39. Average response time for OLTP baseline at non-peak time - AWR report ................................................................................. 55

Tables Table 1. Terminology......................................................................................... 10

Table 2. Hardware resources ............................................................................. 13

Table 3. Software resources .............................................................................. 13

Table 4. Information about the Oracle database workload and SLO .................. 21

Table 5. Storage SLO configuration details for OLTP workload ........................... 21

Table 6. Oracle DW database configuration details ........................................... 21

Table 7. ASM disk group configuration for OLTP database ................................. 27

Table 8. ASM disk group configuration for DW database ................................... 27

Table 9. Database workload profile for each OLTP database ............................. 27

Table 10. Database and workload profile for DW database ................................. 28

Table 11. OLTP baseline workload performance comparison with the OLTP and DW workloads combined ..................................................... 39

Table 12. DW baseline workload performance comparison with the combined DW and OLTP workloads...................................................... 41

Table 13. OLTP workload performance comparison between Platinum and Gold SLO ........................................................................ 46

Table 14. OLTP workload performance comparison before and after snapshots creation ...................................................................... 55

EMC Confidential Chapter 1: Executive Summary


Chapter 1 Executive Summary

This chapter presents the following topics:

Business challenges .................................................................................................. 8

Technology solution ................................................................................................... 8

Chapter 1: Executive Summary EMC Confidential


Business challenges

According to the 2014 Resource Strategies Survey by the Independent Oracle Users Group, Oracle customers spend too much time and money maintaining their Oracle systems. Sixty-four percent of customers reported seeing increased database growth and 73 percent said that they used custom scripts and open source tools. Oracle databases are increasing in size. Tasks such as backup cloning, recovery, replication, and failover are becoming more complex and time consuming.

Oracle database administrators (DBAs) face the following operational challenges:

Manually provisioning and managing the storage-related aspects of an Oracle database is difficult and complex.

Multiple, mixed Oracle workloads on the same back-end storage are common, and must be managed so that they do not interfere with each other.

Oracle production workload priorities are constantly shifting. If management is done manually, accommodating those priorities requires regular adjustments.

Oracle DBAs must often manage a process that iteratively creates copies of a running production Oracle database. These copies are used for numerous purposes, including backup, disaster recovery (DR) staging, extract/transform/load (ETL), batch reporting, and so on. The Oracle DBA must take great care that the copy process does not impact the production workload. For example, a storage-based snapshot can create additional I/O or a storage-based clone can require additional I/O while it is being initialized. Both of these can negatively impact production database performance.

Technology solution

This White Paper describes a solution that addresses these business challenges as follows:

Using the new EMC® VMAX3™ service level objectives (SLO) feature, a service level can be assigned to an Oracle database. This SLO then manages the underlying storage to provide the expected performance, as defined by the assigned SLO, and these operations are completely transparent to the database.

By assigning different SLOs to multiple, mixed Oracle workloads (in this case, an online transaction processing (OLTP) workload and a data warehouse (DW) workload), these workloads can run simultaneously on the same backend storage without impacting each other’s performance.

The SLO assigned to a given Oracle workload can be adjusted dynamically, to meet the demands of shifting workload priorities. For example, when a monthly close cycle occurs, that workload’s SLO can be given higher priority.

The new VMAX3 SnapVX™ feature allows an Oracle DBA to create numerous copies of an operational Oracle production database with no measurable performance impact.

https://community.emc.com/docs/DOC-37463

EMC Confidential Chapter 2: About This Document


Chapter 2 About This Document


Purpose .................................................................................................................... 10

Scope ....................................................................................................................... 10

Audience .................................................................................................................. 10

Terminology and acronyms ...................................................................................... 10

Chapter 2: About This Document EMC Confidential


Purpose

The purpose of this White Paper is to describe the use of SLO provisioning on EMC VMAX3 to manage the storage and data protection aspects of virtualized Oracle RAC 12c. This paper also demonstrates the advantages of SnapVX for creating snapshots of an operational Oracle database with no performance impact.

Scope

This White Paper covers the following subject areas:

Demonstration of proficiency of Oracle database systems running OLTP and DW workloads, for service level provisioning of storage

Adjustment of service levels without application downtime as workloads fluctuate

Management of multiple, mixed Oracle production workloads using SLO

Appropriate usage of TimeFinder SnapVX for protecting and managing data in the Oracle database environment

Audience

The primary audience of this White Paper is database and system administrators, storage administrators, and system architects who are responsible for implementing, maintaining, and protecting robust databases and storage systems. Readers of this paper should have some familiarity with Oracle database backup concepts and EMC software, and should be interested in achieving higher database availability and protection.

Terminology and acronyms

This white paper includes the following terminology.

Table 1. Terminology

Term Definition

FAST Fully automated storage tiering

IG Initiator group in VMAX3

MV Masking view in VMAX3

PG Port group in VMAX3

SLO Service level objective

SRP Storage resource pool

EMC Confidential Chapter 3: Technology Overview


Chapter 3 Technology Overview


Introduction ............................................................................................................. 12

Solution architecture ............................................................................................... 12

Key components ...................................................................................................... 14

Chapter 3: Technology Overview EMC Confidential


Introduction

This chapter describes the enabling components used in the VMAX3 for Oracle database solution and explains how we implemented the solution in our laboratory environment.

Solution architecture

This section provides an overview of the EMC VMAX3 for Oracle RAC 12c solution architecture. This solution deployed multiple Oracle RAC 12c databases in a fully virtualized VMware vSphere environment, and connected to a VMAX 200K array as the backend storage, as shown in Figure 1.

Figure 1. Solution architecture diagram

Based on cost and storage performance requirements, the Oracle database for the OLTP workload was deployed in the predefined Gold SLO, while the database for the DW workload was deployed in the Silver SLO. The SLO policy used by each database can be adjusted dynamically according to customer requirements. For example, if the OLTP database priority increases, its SLO can be adjusted to use a higher-level SLO policy like Platinum.



Table 2 describes the hardware components used in the solution.

Table 2. Hardware resources

Device Quantity Configuration Description

EMC VMAX 200K

1 2 engines (1 TB cache per engine)

222 x 300 GB 15K FC disks

176 x 1 TB 7.2K SATA disks

70 x 200 GB flash drives

VMAX3 storage array

Servers 4 20 x 3 GHz Intel Xeon physical CPU cores and 40 logical cores

512 GB memory

2 x 10 GbE network NICs

1 x1 GbE network NIC

Database server

FC switch 2 Fibre Channel switch - 8 Gb/s FC Storage area network (SAN) connection between servers and storage

Ethernet switch

2 Ethernet switch – 1 GbE/s & 10 GbE/s

IP connection between servers

Table 3 describes the software components used in the solution.

Table 3. Software resources

Device Version Description

EMC Enginuity™ 5977 Operating environment for VMAX3

EMC Solutions Enabler 8.0.1214 API between storage and other components

EMC Unisphere® 8.0.1.2 VMAX3 management GUI

EMC PowerPath®/VE 5.9 Multipathing and load balancing for block access

Oracle Enterprise Linux 6.4 Operating system for database servers

Oracle Grid Infrastructure 12c Enterprise Edition 12.1.0.2

Software support for ASM storage and Oracle RAC

Oracle Database 12c Enterprise Edition 12.1.0.2

Oracle Database software

VMware vSphere ESXi 5.5 Hypervisor

VMware vCenter Server 5.5 vSphere management server

Hardware resources

Software resources



Key components

The key technology components used in this white paper are as follows:

EMC VMAX3

EMC HYPERMAX OS

EMC VMAX Service Level Objective

EMC VMAX3 FAST

EMC TimeFinder SnapVX

EMC Unisphere for VMAX

VMware vSphere

Oracle Database 12c Enterprise Edition

SLOB Workload Generator

The EMC VMAX3 family delivers the latest in Tier-1 scale-out multi-controller architecture with consolidation and efficiency for the enterprise. With completely redesigned hardware and software, the new VMAX 100K, 200K, and 400K arrays provide unprecedented performance and scale. Ranging from the single- or dual-engine VMAX 100K up to the eight-engine VMAX 400K, these new arrays offer dramatic increases in footprint density with engines and high-capacity disk enclosures for both 2.5" and 3.5" drives consolidated in the same system bay. In addition, VMAX 100K, 200K, and 400K can be configured as either hybrid or all-flash arrays. This revolutionary new VMAX architecture delivers Virtual Matrix Bandwidth of 175 GB/s per engine and up to 1,400 GB/s across an eight-engine VMAX array. All new VMAX models come fully preconfigured from the factory to significantly shorten the time to first I/O during installation.

VMAX arrays introduce the industry’s first open storage and hypervisor converged operating system, HYPERMAX OS. It combines industry-leading high availability, I/O management, quality of service (QoS), data integrity validation, storage tiering, and data security with an open application platform.

HYPERMAX OS features the first real-time, non-disruptive storage hypervisor that manages and protects embedded services by extending VMAX high availability to services that traditionally would have run external to the array. It also provides direct access to hardware resources to maximize performance. The hypervisor can be non-disruptively upgraded.

HYPERMAX OS runs on top of the Dynamic Virtual Matrix using its scale-out flexibility of cores, cache, and host interfaces. The embedded storage hypervisor reduces external hardware and networking requirements, and delivers higher levels of availability and dramatically lower latency.

All storage in the VMAX array is virtually provisioned, and all pools are created in containers called Service Level Objectives (SLOs). The system uses the dynamic and intelligent capabilities of the VMAX to guarantee the required performance levels

EMC VMAX3

EMC HYPERMAX OS

EMC VMAX Service Level Objective



throughout the lifecycle of the application. As the system workloads change over time and other workloads are added to the array, the VMAX continues to dynamically add resources to guarantee that you continue to get the required level of performance to match the defined SLO, provided that those resources are available in the array.

VMAX3 uses an updated FAST™ technology to dynamically move workloads to the appropriate tier of storage—that is, flash—and can quickly configure FAST using service level profiles. Choose the level of service you want (Diamond, Platinum, Gold, Silver, Bronze, or Optimized), and VMAX3 configures FAST automatically to meet your service level requirements.

As shown in Figure 2, FAST technology moves the most active parts of your workloads (hot data) to high-performance flash drives, and the least frequently accessed storage (cold data) to lower-cost drives, using the best performance and cost characteristics of each drive type. FAST delivers higher performance by using fewer drives to help reduce acquisition, power, cooling, and footprint costs.

Figure 2. FAST workload-based data placement

This promotion/demotion activity is based on policies that associate storage groups to multiple drive technologies using thin storage pools, and on performance requirements of the application contained within the storage group. Data movement executed during this activity is nondisruptive and does not affect business continuity and data availability.

VMAX3 uses EMC TimeFinder® for local replication. The TimeFinder family has been redesigned for VMAX3 with a focus on reducing infrastructure impact, increasing scale, and improving ease of use. Among other new features, some highlights of TimeFinder SnapVX include:

Supports up to 256 snapshots

Uses considerably less storage

Supports user-defined naming

EMC VMAX3 FAST

EMC TimeFinder SnapVX



Can snap an entire storage group in a single command

A new VMAX3 feature called SnapVX provides hybrid cloud-scale snapshots. Unlike older VMAX3 snapshots, SnapVX snaps do not require the use of a dedicated snapshot reserve volume. As depicted in Figure 3, SnapVX allows for up to 1,024 targets to be linked to the snapshots from each individual source. The new snapshots have a negligible effect on performance, and can be used for different purposes such as test/dev environment provisioning and backup.

Figure 3. TimeFinder SnapVX snapshots

EMC Unisphere for VMAX is an intuitive management interface that allows IT managers to maximize human productivity by dramatically reducing the time required to provision, manage, and monitor VMAX storage assets. Unisphere delivers key requirements such as simplification, flexibility, and automation. The Unisphere Performance Viewer facilitates detailed VMAX system performance analysis available without the need for a live array connection. REST APIs simplify programmatic performance monitoring from cloud management and data center orchestration tools.

VMware vSphere is a virtualization platform with policy-based automation. vCloud suite is integrated with VMware, which provides all the components for building and running a private cloud infrastructure that uses the software-defined data center architecture. This architectural approach delivers virtualized infrastructure services (compute, network, security, and availability) with built-in intelligence to automate the on-demand provisioning, high availability, configuration, and control of applications based on defined policies.

Oracle Database 12c introduces the Oracle multitenant architecture, which simplifies the process of consolidating databases onto the cloud. Oracle Database 12c delivers all the benefits of managing many databases as one, yet it retains the data isolation and resource prioritization of a separate database.

EMC Unisphere for VMAX

VMware vSphere

Oracle Database 12c Enterprise Edition



Oracle RAC 12c extends Oracle Database 12c so that you can store, update, and efficiently retrieve data using multiple database instances on different servers at the same time. Oracle RAC 12c provides the software that manages multiple servers and instances as a single group.

Silly Little Oracle Benchmark (SLOB) is a SQL-driven Oracle database I/O generator, as opposed to a synthetic I/O generator. SLOB uniquely drives massive physical I/O using minimal host CPU resources, and it specifically targets the Oracle I/O subsystem. SLOB performs all of its physical I/O buffering in the Oracle System Global Area (SGA); no physical I/O buffering is performed in the Oracle Program Global Area (PGA).

SLOB Workload Generator

EMC Confidential Chapter 4: Database Deployment


Chapter 4 Database Deployment


Introduction ............................................................................................................. 20

Storage provisioning with VMAX3 SLO ..................................................................... 20

Virtualization layer: ESXi and virtual machines ........................................................ 26

Configuring OLTP and DW databases ....................................................................... 27

Database Storage Analyzer ...................................................................................... 29

Chapter 4: Database Deployment EMC Confidential


Introduction

This chapter discusses the concept of service level objectives (SLOs) and the role they play in storage provisioning and performance management in an Oracle environment, as well as how we deployed the database in the solution. SLOs enable IT administrators to allocate and reallocate storage capacity and throughput based on the Oracle database workload and criticality.

Since SLOs are tied to the available drive types, it is important to plan the requirements for a new VMAX3 system carefully. EMC offers a new and easy-to-use sizer tool to assist with this task. The EMC VMAX3 Sizer Tool is a web-based application that is used by the EMC Sales teams and partners during the sales process. The application simplifies the process of sizing a VMAX3 family array to meet customers' workload requirements. The goal of the application is to enhance the configuration and ordering process for VMAX3 family arrays.

Storage provisioning with VMAX3 SLO

Overview

The VMAX3 family delivers storage provisioning for different service levels (Diamond, Platinum, Gold, Silver, Bronze and Optimized) as shown in Figure 4. By default, all devices not explicitly associated with an SLO are managed by the system-optimized SLO.

Figure 4. Service level objectives

Performance and capacity requirements differ depending on the roles and workloads of the different Oracle databases. In most cases, OLTP databases need a short response time while DW databases can feature a longer response time.

Based on the average response time provided by different service level objectives, as shown in Figure 5, the DW database was managed in the silver pool, and an OLTP database was managed in the gold pool. In this scenario, we ran tests with a SLOB (Silly Little Oracle Benchmark) workload against both the OLTP and DW databases.

VMAX3 Sizer Tool overview



Figure 5. SLO - Average response time

Table 4 shows the Oracle system and SLO information we considered in the provisioning steps.

Table 4. Information about the Oracle database workload and SLO

Workload type

SLO/Storage pool Expected average

response time Storage group

OLTP Gold 5 ms OLTPRAC

DW Silver 8 ms DWRACSG

SLO storage provisioning allows cascaded storage groups to granularly manage the storage for the database instance and provide different service levels for database files, redo log files, archive log files, and binaries.

Table 5 provides detailed information about the storage configuration for the Oracle OLTP workload.

Table 5. Storage SLO configuration details for OLTP workload

Storage group/Name

SLO Workload Volumes Capacity (GB)

OLTPRAC_Data Gold OLTP 11 1,000

OLTPRAC_Redo Gold OLTP 4 64

OLTPRAC_CRS Gold OLTP 3 200

OLTPRAC_FRA Gold OLTP 4 1,000

Table 6 provides detailed information about the Oracle DW storage configuration.

Table 6. Oracle DW database configuration details

Storage group/Name


DWRACSG_Data Silver DSS 21 1,000

Provisioning considerations



Storage group/Name


DWRACSG_Redo Silver DSS 4 64

DWRACSG_CRS Silver DSS 3 200

DWRACSG_FRA Silver DSS 4 1,000

Follow the steps below to provision storage for the OLTP database.

1. Log in to Unisphere, navigate to the Storage tab and select Service Levels, as shown in Figure 6.

Figure 6. Enter Service Level Objectives

2. In the Gold tab, click Provision Storage, as shown in Figure 7.

Figure 7. Selecting the storage pool

3. In the Storage Group Name box (shown in Figure 8), type OLTPRAC, the predefined name for the Oracle OLTP database. Under Service Level

Provisioning the OLTP Database



Objectives, select Gold, and then select OLTP under Workload Type. Refer to Table 4 for more information.

Cascaded storage groups can be created to meet critical storage performance requirements for the OLTPRAC database instance. Refer to Table 5 for information. Click Add Service Level in the bottom left of the screen to add the additional storage groups.

Figure 8. Creating the storage group

4. Click Select Host/HostGroup, and in the Type to Filter field, enter OLTP. Select OLTPRAC as shown in Figure 9.

Figure 9. Selecting the Host Group

1. Click Select Port Group, and select OLTPPG as shown in Figure 10.



Figure 10. Selecting the port group

2. Review the information you entered (storage group, host group, and port group), then click Add to Job List or Run now to create the Masking View, as shown in Figure 11.

Figure 11. Reviewing and completing the configuration



3. Finally, do the following in the vSphere Web client:

a. Perform a storage rescan.

b. Identify the newly provisioned storage device.

c. Create new data stores.

d. Deploy the Oracle systems accordingly.

We used similar steps to provision the storage for the DW database.



Virtualization layer: ESXi and virtual machines

The choice of a server platform for a virtualized infrastructure is based on both the supportability of the platform and the technical requirements of the environment. In production environments, the servers must have:

Sufficient cores and memory to support the required number and workload of the virtual machines

Sufficient connectivity, both Ethernet and FC, to enable redundant connectivity to the IP and storage network switches

Sufficient capacity to withstand a server failure and support failover of the virtual machines

In this solution, we used two physical servers configured as a vSphere HA cluster and each running a vSphere ESXi server. We then deployed four virtual machines to create multiple virtualized Oracle databases, including one 2-node RAC database for the OLTP workload and another 2-node RAC database for the DW workload.

For further information about recommended practices for VMware virtualization, please refer to the References section.



Configuring OLTP and DW databases

After installing Oracle 12c Grid Infrastructure and database software, we created the required ASM disk groups for the OLTP and DW databases separately. Table 7 and Table 8 detail each database’s ASM disk group design. On each database, we used three ASM disk groups including DATA, REDO, and FRA, to store the relevant database files, including data files, control files, online redo log files, archived log files, and temporary files. Default settings were used for ASM disk groups.

Note: Both OLTP and DW databases were enabled in archive log mode to simulate real-world cases.

Table 7. ASM disk group configuration for OLTP database

Item LUN size (GB) Number of LUNs ASM disk group name Storage group

CRS 200 3 +CRS OLTPRAC_CRS

DATA 1,000 11 +DATA OLTPRAC_DATA

REDO 64 4 +REDO OLTPRAC_REDO

FRA 1,000 4 +FRA OLTPRAC_FRA

Table 8. ASM disk group configuration for DW database

Item LUN size (GB) Number of LUNs ASM disk group name Storage group

CRS 200 3 +CRS DWRACSG_CRS

DATA 1,000 21 +DATA DWRACSG_DATA

REDO 64 4 +REDO DWRACSG_REDO

FRA 1,000 4 +FRA DWRACSG_FRA

The OLTP and DW workload profiles used in the solution are shown below.

OLTP database and workload profile

Table 9 describes the OLTP database workload profile for the solution. We used the SLOB toolkit to generate an OLTP database and drive the OLTP-like workloads with a read/write ratio of 75:25 for the solution.

Table 9. Database workload profile for each OLTP database

Profile characteristic Details

Database type OLTP

Database size 10 TB

Database name oltpdb

Oracle 12c Database 2-node RAC database on ASM




Workload profile OLTP-like workload driven by SLOB

Network connectivity 8 Gb FC for SAN

10 GbE for private network

DW database and workload profile

Table 10 details the DW database and workload profile for the solution. We also used the SLOB toolkit to generate a database and then dropped all the SLOB indexes to force the query-only workload with full-table scan to simulate a data-warehouse-type workload.

Table 10. Database and workload profile for DW database


Database type Data warehouse

Database size 20 TB

Database name dwdb

Oracle 12c Database 2-node RAC database on ASM

Workload profile Query-only workload driven by SLOB with all the SLOB indexes dropped

Network connectivity 8 Gb FC for SAN

10 GbE for private network



Database Storage Analyzer

Database Storage Analyzer (DSA) monitors Oracle databases and provides database I/O classification based on business priority and usage patterns. That data is in turn used to determine the appropriate tier of storage (Flash, Fibre Channel or SATA) that should be used. In the solution we deployed the DSA in our test environment to monitor the database performance.

Overview

DSA is a HYPERMAX OS feature available in either the Foundation or Advanced suite software packages. It supports database-to-storage correlation by providing a shared view on how performance issues correlate to database-level activity and storage-level activity. This view is accessible by a database administrator (DBA) and a storage administrator (SA). The view presents I/O metrics such as input/output operations per second (IOPS), as well as throughput and response time from both the database and the storage system. These metrics help to immediately identify any gap between the database I/O performance and the storage I/O performance.

DSA offers the following benefits:

Provides a unified view across database and storage

Quickly identifies when a database is suffering from high I/O response times

Reduces troubleshooting time for database or storage performance issues—DBAs and SAs can look at a unified database and storage I/O metrics view and quickly identify performance gaps or issues on both layers

Identifies database bottlenecks that are not related to the storage

Facilitates coordination between the SA and DBA

Reduces administrator burden and overhead in doing manual repetitive drill-downs for troubleshooting

DSA configuration

This section provides the steps we used to configure DSA and add a database into DSA for performance monitoring.

1. Log in to Unisphere, navigate to the Database tab and select Database Storage Analyzer, as shown in Figure 12.

Figure 12. Launch the Database Storage Analyzer (DSA) application

2. Provide the same username and password to login into the Database Storage Analyzer and click Login, as shown in Figure 13.



Figure 13. Login pop-up windows

3. Click the Administration tab to view the full list of monitored databases and their associated attributes. Click Add, as shown in Figure 14.

Figure 14. Adding monitored databases

4. Click either the Use Existing Database Storage Analyzer User or Create Database Storage Analyzer User button, and click Next, as shown in Figure 15.

Notes:

Select Create a DSA User to add a new DSA database user during the installation process. The SYS user must be provided to DSA during the next step of the installation.

Select Use an Existing DSA User if you prefer to create the user manually prior to the installation using the script provided, and then manually enter the new user during the installation.



Figure 15. Select DSA user type

5. Enter appropriate values for the following list of configurable parameters. For example, we used uniadmin as the DB user name and oracle as the DB user password. Then click Finish, as shown in Figure 16.

Figure 16. Set monitored environment parameters

6. Confirm the validity of the parameters as entered, then click Yes as shown in Figure 17. The DSA initial configuration is complete.



Figure 17. Parameter confirmation

Monitoring Database Performance with DSA

The DSA dashboard shows a variable database response time in the same time window as a constant storage response time, indicating that the database level variance is not caused by the storage layer. We used the following methods to monitor the database and storage I/O performance.

1. Click the Dashboard tab to view the full list of monitored databases and their associated attributes, as shown in Figure 18. Double-click a database name instance to view the Performance tab.

Figure 18. Database Storage Analyzer Dashboard

2. Set the time range for the monitoring activity in the Performance tab, and observe the following results in the performance chart as shown in Figure 19.

I/O Wait vs Non-I/O Wait

Average Active Session Wait

Response Time



IOPS

Throughput

IOPS for the Storage Back-end Activity and Tier Capacity

Throughput for the Storage Back-end Activity and Tier Capacity

Tier Capacity for the Storage Back-end Activity and Tier Capacity

Figure 19. Performance chart

EMC Confidential Chapter 5: Use Case 1: Mixed Workload on VMAX3


Chapter 5 Use Case 1: Mixed Workload on VMAX3



Test with mixed workload ........................................................................................ 37

Chapter 5: Use Case 1: Mixed Workload on VMAX3 EMC Confidential


Use case overview

This solution demonstrates the mixed workload performance with both OLTP and DW workloads running on the same VMAX3 array, and showing no performance impact on each other. Two virtual 2-node Oracle 12c RAC databases were deployed for this use case: One for OLTP with a size of 10 TB, and the other for DW with 20 TB.

The SLOB toolkit, the preferred workload generator for driving the maximum physical random I/O from database platform, was used to generate both OLTP and DW workloads:

Read/write ratio of 75:25 OLTP-like workload demonstrating sustained storage array IOPS.

Query-only DW-like workload to enforce a full-table scan execution plan by dropping all the SLOB indexes, which simulated the I/O pattern for the real-world DW workload.

Database performance metrics in this use case include:

IOPS and I/O latency data retrieved from AWR reports, VMAX Unisphere, and DSA GUI was used for OLTP workloads

Data throughput data retrieved from AWR reports, VMAX Unisphere, and DSA GUI was used for DW workloads

Notes:

Benchmark results are highly dependent upon workload, specific application requirements, and system design and implementation. Relative system performance will vary as a result of these and other factors. Therefore, the solution test workloads should not be used as a substitute for a specific customer application benchmark when critical capacity planning and/or product evaluation decisions are contemplated.

All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other operating environments may vary significantly.

EMC Corporation does not warrant or represent that a user can or will achieve similar performance expressed in transactions per minute.



Test with mixed workload

This testing use case demonstrates how to implement QoS (quality of service) on the VMAX3 with SLO feature, and verifies that running mixed OLTP and DW workloads on the same array at the same time has no impact on performance.

The overall test objectives demonstrate:

The level of performance achieved with a workload running on a specific VMAX SLO

Performance is not impacted by running OLTP and DW workloads on the same VMAX3 array at the same time

The following test scenarios were conducted on the solution and are described in subsequent sections:

OLTP with read/write ratio of 75:25

This test was used to measure the performance during concurrent SLOB non-zero-think-time sessions (simulated concurrent users with random think time) against the RAC database.

Note: “Think time” means the time between two commands issued by the session. In the test we generated a random think time for different sessions.

The 2-node RAC OLTP database workload consisted of 136 concurrent sessions, of which 75 percent were queries and 25 percent were UPDATE SQL statements.

The results of the OLTP test were used as a baseline for further testing.

DW query

Two concurrent sessions were run on the two-node RAC DW database with one for each node. All SLOB indexes were dropped to force full-table scans in this test. The degree of parallelism remained set to its default value for each query to generate 64 parallel processes for its execution, so the direct path read was used at all query runtimes. The following conditions were also in effect:

The results of the DW test were used as a baseline for further testing.

OLTP and DW workloads were running simultaneously

We combined the OLTP and DW workloads to generate the baselines, to verify that there was no performance impact as compared with the original baselines.

To calculate the performance statistics for the OLTP workload, we used the performance statistics from the AWR reports shown in Figure 20, which shows the AWR report generated from the baseline of the OLTP database.

Test objectives

Test procedures

Test results



Figure 20. Average response time - 75/25 QUERY/UPDATE ratio test - AWR report

The following top wait events were extracted from the AWR Report:

The db file sequential read wait event is used to calculate the response time to physically read a single block. The wait event occurs when an Oracle session has to wait for a single- block I/O read request to complete. It is shown as “Physical read response time for single block (ms)” in Table 11.

The db file parallel read wait event is used to calculate the response time to physically read multiple single blocks in a single batch . The wait event is caused when a process pre-fetches multiple noncontiguous single-block I/O requests together and issues them in parallel. In our test, on average, 61 noncontiguous blocks were pre-fetched for each wait of “db file parallel read”. It is shown as “Physical read response time for multi-noncontiguous blocks (ms)” in Table 11.

The log file parallel write wait event was used as the average latency for the LGWR background process, which is shown as “LGWR response time (ms)” in Table 11.

The following key metrics were extracted from an AWR Report as shown in Figure 21.

Figure 21. System statistics - 75/25 QUERY/UPDATE ratio test - AWR report



Physical write IO requests was used for physical write IOPS, which are shown as Write IOPS in Table 11.

Physical read IO requests was used for physical read IOPS, which are shown as Read IOPS in Table 11.

Redo size was used to calculate the redo write I/O bandwidth, which is shown as Redo throughput (MB/s) in Table 11.

To assess the DW query throughput (GB/s), we used physical read bytes in the AWR report as shown in Figure 22, which was created from the baseline of the DW database. The throughput was 5,901 GB/s (6,187,474,586.71 divided three times by 1,024, to convert bytes to gigabytes).

Figure 22. Query throughput – DW query workload test - AWR report

Table 11 shows the OLTP baseline workload performance data on VMAX3, including IOPS and the corresponding I/O response time which was retrieved from the OLTP database. It also shows the baseline’s performance data and the performance statistics running both OLTP and DW workloads together.

Table 11. OLTP baseline workload performance comparison with the OLTP and DW workloads combined

Performance metric

Performance data

OLTP Baseline Combined OLTP and DW workloads

Read IOPS 50,452 50,889

Write IOPS 14,724 14,728

Aggregate IOPS (write + read) 65,176 65,617

Redo throughput (MB/s) 10 10

LGWR response time (ms) 3.18 3.0



Performance metric Performance data

Physical read response time for single block (ms)

5.26 5.38

Physical read response time for multi-noncontiguous blocks (ms)

39.29 33.10

The storage I/O response time of the baseline from DSA is shown in Figure 23:

Figure 23. Response time of the baseline from DSA

The storage I/O response time of the OLTP workload running together with the DW workload from DSA is shown in Figure 24:

Figure 24. Response time of the OLTP workload running with DW from DSA

Table 12 shows the DW workload performance statistics on VMAX3, with throughput that was retrieved from the AWR report of DW database, including the baseline and the performance statistics with OLTP workload running together.



Table 12. DW baseline workload performance comparison with the combined DW and OLTP workloads

Performance metric

Performance data

DW Baseline Combined DW and OLTP workloads

Throughput (GB/s) 5,901 5,918

From the test results, we conclude the following:

The SLO for OLTP database was set to Gold to control the response time of read I/O at about 5 ms on the storage array.

EMC Database Storage Analyzer showed that the storage read I/O response time was 5.1 ms, verifying the response time set by the Gold SLO.

From the AWR report, the physical read response times for a single block were 5.26 ms (OLTP baseline) and 5.38 ms (OLTP and DW run together) respectively, which are aligned with the performance statistics gathered from storage and DSA.

The mixed workloads including OLTP and DW running on VMAX3 had little impact on each other.

From the OLTP results, the performance statistics of the baseline were almost the same as the numbers when running with the DW workload. For example, the Read IOPS was 50,452 with the OLTP workload, compared to 50,889 with the DW workload.

Comparing the performance when running the DW workload alone to the performance when running DW and OLTP workloads together, the throughputs were comparable at about 5,900 GB/s.

Summary of use case

EMC Confidential Chapter 6: Use Case 2: Upgrade SLO


Chapter 6 Use Case 2: Upgrade SLO



Test for upgrading SLO ............................................................................................ 44

Chapter 6: Use Case 2: Upgrade SLO EMC Confidential


Use case overview

The VMAX3 SLO feature makes it much easier for the Oracle DBA to add system resources when workloads increase; for example, during end-of-month reporting. The DBA can upgrade the SLO to a higher level with just a few mouse clicks and the system remains operational throughout the process. This use case demonstrates how to use VMAX3 SLO to accommodate a fluctuation in database workload by adjusting the SLO level from Gold to Platinum.

Test for upgrading SLO

The test procedures are designed to achieve the following objectives:

Simplify storage management to meet varying performance requirements by upgrading the SLO, for example during month-end reports, with simple mouse clicks.

Compare Oracle database and storage performance before and after promotion from Gold to Platinum SLO from Gold.

To validate the performance of the database, we followed these steps:

1. Promoted the SLO to Platinum.

2. After the data was moved to the flash tier, we ran the baseline OLTP workload from use case 1 (see Chapter 5 Use Case 1: Mixed Workload on VMAX3). That workload entailed 136 concurrent sessions with 75% running similar queries and 25% running similar UPDATE SQL statements.

3. Compared the performance on Platinum SLO to the baseline on Gold SLO.

This section illustrates how we changed the OLTPRAC storage group’s SLO from Gold to Platinum. The current SLO is shown in Figure 25.

1. Click Modify, as shown in Figure 25.

Test objectives

Test procedures

Change SLO



Figure 25. OLTPRAC storage group’s SLO before change

2. Choose Platinum as the Service Level for each sub-storage group, as shown in Figure 26.

Figure 26. Modifying the SLO

We changed the SLO of the OLTPRAC storage group to Platinum, as shown in Figure 27.

Figure 27. OLTPRAC storage group’s SLO after change



To calculate the workload, we used the performance statistics from the AWR reports, shown in Figure 28, just as we did in Use Case #1.

Figure 28. Average response time on Platinum SLO - AWR report

Table 13 shows the OLTP workload performance data for the Platinum level SLO compared to the Gold level SLO.

Table 13. OLTP workload performance comparison between Platinum and Gold SLO

Performance metric

Performance data

Platinum SLO Baseline on Gold SLO

Difference (%)

Read IOPS 80,032 50,452 58.63

Write IOPS 23,220 14,724 57.70

Aggregate IOPS (write + read) 103,252 65,176 58.42

Redo throughput (MB/s) 16 10 60.00

LGWR response time (ms) 2.71 3.18 -14.78


2.94 5.26 -44.11


11.53 39.29 -70.65

From the test results, the physical read response time for single block was 2.94 ms for the workload on Platinum SLO, which meets the expected response time for the Platinum SLO (3 ms). Figure 29 shows that the performance increased (IOPS increased while response time decreased) dramatically after the SLO changed to the higher level.

Test results

Summary of use case



Figure 29. Comparison of performance between the Platinum and Gold SLO levels

EMC Confidential Chapter 7: Use Case 3: Business Continuity for Oracle Database


Chapter 7 Use Case 3: Business Continuity for Oracle Database


Overview .................................................................................................................. 50

Test with SnapVX ..................................................................................................... 50

Chapter 7: Use Case 3: Business Continuity for Oracle Database EMC Confidential


Overview

This test case demonstrates how to create snapshots with the VMAX3 TimeFinder SnapVX feature. SnapVX can be used to bolster a customer’s existing backup strategies and test/dev environment provisioning. This use case shows how we created SnapVX snapshots with a production database.

Test with SnapVX

The test describes taking snapshots for the Oracle database platinum SLO LUNs while the OLTP workload is also running. Key procedures are included on how to use the GUI to create snapshots. We also show how to create snapshots regularly using a command line in the OS job schedulers.

As in a production OLTP system, we chose a nonpeak period to create our snapshot. In this case, the workload on the OLTP system was at about 50% of peak performance when we created snapshots. The test verifies a near-zero performance impact for the workload when the snapshots were created.

The test procedures are designed to validate:

The process of SnapVX snapshots creation, including the use of Unisphere and script (create snapshots regularly).

The source Oracle database production workload is not impacted when multiple SnapVX snapshots are created.

This is how we validated the performance of the database:

1. Ran multiple SLOB concurrent users for one hour to set up a baseline, with 75% sessions running queries and 25% sessions running UPDATE SQL statements.

2. Ran the baseline workload again, scheduling snapshot creation every 10 minutes.

3. After the workload finished, six snapshots were created. We compared the database performance before and after snapshot creation.

We created the SnapVX snapshots by following these steps:

1. Log in to Unisphere, then click Data Protection and select TimeFinder, as shown in Figure 30.

Test scenario

Test objectives

Test procedures

Create an on-demand backup



Figure 30. Select the TimeFinder menu

2. Click TimeFinder/SnapVX, as shown in Figure 31.

Figure 31. Click TimeFinder/SnapVX

3. Click Create Snapshot. Select Storage Group Name and enter the name for the new snapshot. We entered SNAP_OLTP_RAC as shown in Figure 32. Click Show Advanced to set more parameters.

Figure 32. Create a snapshot

4. Set an expiration time in the screen that appears. Click Run Now to create a snapshot. The amount of time the snapshot creation takes is recorded, as shown in Figure 33.



Figure 33. Set expiration days

5. Locate the successfully created SnapVX in the dashboard, as shown in Figure 34.

Figure 34. Snapshot created

To create multiple snapshots regularly, we scheduled the creation of regular snapshots with the following steps:

1. Log in to the server on which the Solution Enabler (SE) is installed. In our environment, we installed the SE in Windows 2008.

2. Create a command script with the name oraclesnap.cmd and edit the command to the following:

symsnapvx -sid 0544 -sg OLTPRAC -name SNAP_OLTPRAC establish -ttl

-delta 1 -nop”

(The meaning of the command is: “create a snapshot named SNAP_OLTPRAC from OLTPRAC and set one-day expiration on it”.)

3. Open a Task Scheduler and create a task, as shown in Figure 35. Select Run whether user is logged on or not.

Schedule snaps



Figure 35. Create a task

4. Edit the trigger time to set the scheduler to run. For example, we selected 6 minutes to create a snapshot every six minutes, as shown in Figure 36.

Figure 36. Edit the scheduler trigger time

5. In the Edit Action window, select Start a program, then browse to the scripts we created in step 2, as shown in Figure 37.



Figure 37. Edit the action

6. In Unisphere, verify that the SnapVX snaps were created every six minutes, as shown in Figure 38.

Figure 38. Find the new SnapVX snaps in Unisphere



To calculate the workload, we used the performance statistics from the AWR reports as shown in Figure 39, just as we did in Use Case #1 and Use Case #2. Figure 39 shows the OLTP baseline at non-peak time.

Figure 39. Average response time for OLTP baseline at non-peak time - AWR report

Table 14 shows the OLTP workload performance data comparing the OLTP baseline at non-peak time to the performance statistics of running an OLTP workload and creating snapshots at the same time.

Table 14. OLTP workload performance comparison before and after snapshots creation

Performance metric

Performance data

OLTP baseline at non-peak time

OLTP workload running and snapshot creation

Read IOPS 37,451 36,032

Write IOPS 9,305 8,949

Aggregate IOPS (write + read) 46,756 44,981

Redo throughput (MB/s) 8 7

LGWR response time (ms) 1.41 1.51


0.69 0.79


1.86 2.21

From the test results, as compared to the OLTP baseline at non-peak time, the total IOPS with read and write decreased about 3.8% ((46,756 - 44,981) / 46,756), which was negligible. The performance for OLTP workload was not impacted by the creation of six snapshots.

Test results

Summary of use case

EMC Confidential Chapter 8: Conclusion


Chapter 8 Conclusion


Summary .................................................................................................................. 58

Findings ................................................................................................................... 58

Chapter 8: Conclusion EMC Confidential


Summary

This White Paper presents use cases showing how EMC VMAX3 can be used to enhance data management and performance for Oracle database environments. The solution helps customers:

Use VMAX3 SLOs to move workloads across storage types based on service levels, while optimizing overall system performance at the lowest possible cost. In our testing, OLTP and DW workloads running together had no impact on each other. (Read response times remained consistent at 5.26 ms as compared with 5.38 ms, a variation of only 0.12 ms.)

Quickly and easily adjust the SLO and performance of an Oracle workload, in accordance with its priority. From our test results, the IOPS increased about 59% after we upgraded the Oracle database workload’s SLO to Platinum from Gold.

Reduce the cost, risk, and lost productivity associated with manual monitoring, managing, and root cause intervention to address performance issues.

Use SnapVX to provide snapshots for a running Oracle RAC 12c database with minimum impact to performance on the production database.

Findings

This White Paper produced the following key findings:

Based upon differing requirements, appropriate SLOs were assigned to different Oracle databases. This resulted in exactly the expected performance level of each workload.

Varying storage performance requirements can be easily satisfied by adjusting the SLO configuration of a system.

Multiple, mixed Oracle production workloads with differing SLOs ran on the same storage with no impact upon each other.

Changing the SLO of a running Oracle database produced the exact performance expected, as defined by the SLO.

Creating SnapVX snapshots does not impact the performance of a running Oracle database.

EMC Confidential Appendix A: References


Appendix A References

This appendix presents the following topic:

References ............................................................................................................... 60

Appendix A: References EMC Confidential


References

The following documents, available on the EMC Online Support or EMC.com websites, provide additional and relevant information. If you do not have access to a document, contact your EMC representative.

EMC VMAX

EMC VMAX Family with HYPERMAX OS Product Guide

Database Storage Analyzer online help

For additional information, see the following documents available from https://support.oracle.com, which requires a login:

Oracle Grid Infrastructure Installation Guide 12c Release 1 (12.1) for Linux

Oracle Database Installation Guide 12c Release 1 (12.1) for Linux.

Refer to the following topics on the VMware website:

Understanding Oracle Certification Support and Licensing in VMware -Environments

Oracle Databases on VMware Best Practices Guide

Performance Best Practices for VMware vSphere 5.5

For additional information about SLOB, please refer to http://kevinclosson.net/slob.

EMC documentation

Oracle documentation

VMware documentation

SLOB information

https://support.emc.com/

http://www.emc.com/resource-library/resource-library.htm

http://www.emc.com/storage/vmax/vmax3.htm



https://support.oracle.com/

http://kevinclosson.net/slob

EMC VMAX3 Service Level Objectives and SnapVX for Oracle RAC ...

Documents

Transcript of EMC VMAX3 Service Level Objectives and SnapVX for Oracle RAC ...