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

Transcription

1 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 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

2 EMC Confidential 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. EMC 2, 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 Part Number H EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

3 EMC Confidential Contents Contents Chapter 1 Executive Summary 7 Business challenges... 8 Technology solution... 8 Chapter 2 About This Document 9 Purpose Scope Audience Terminology and acronyms Chapter 3 Technology Overview 11 Introduction Solution architecture Hardware resources Software resources Key components EMC VMAX 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 Chapter 4 Database Deployment 19 Introduction VMAX Online Sizer Tool overview Storage provisioning with VMAX3 SLO Provisioning considerations Provisioning the OLTP Database Virtualization layer: ESXi and virtual machines Configuring OLTP and DW databases Database Storage Analyzer EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 3

4 Contents EMC Confidential Chapter 5 Use Case 1: Mixed Workload on VMAX3 35 Use case overview Test with mixed workload Test objectives Test procedures Test results Summary of use case Chapter 6 Use Case 2: Upgrade SLO 43 Use case overview Test for upgrading SLO Test objectives Test procedures Change SLO Test results Summary of use case Chapter 7 Use Case 3: Business Continuity for Oracle Database 49 Overview Test with SnapVX Test scenario Test objectives Test procedures Create an on-demand backup Schedule snaps Test results Summary of use case Chapter 8 Conclusion 57 Summary Findings Appendix A References 59 References EMC documentation Oracle documentation VMware documentation SLOB information EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

5 EMC Confidential Contents Figures Figure 1. Solution architecture diagram Figure 2. FAST workload-based data placement Figure 3. TimeFinder SnapVX snapshots Figure 4. Service level objectives Figure 5. SLO - Average response time Figure 6. Enter Service Level Objectives Figure 7. Selecting the storage pool Figure 8. Creating the storage group Figure 9. Selecting the Host Group Figure 10. Selecting the port group Figure 11. Reviewing and completing the configuration Figure 12. Launch the Database Storage Analyzer (DSA) application Figure 13. Login pop-up windows Figure 14. Adding monitored databases Figure 15. Select DSA user type Figure 16. Set monitored environment parameters Figure 17. Parameter confirmation Figure 18. Database Storage Analyzer Dashboard Figure 19. Performance chart Figure 20. Average response time - 75/25 QUERY/UPDATE ratio test - AWR report Figure 21. System statistics - 75/25 QUERY/UPDATE ratio test - AWR report Figure 22. Query throughput DW query workload test - AWR report Figure 23. Response time of the baseline from DSA Figure 24. Response time of the OLTP workload running with DW from DSA Figure 25. OLTPRAC storage group s SLO before change Figure 26. Modifying the SLO Figure 27. OLTPRAC storage group s SLO after change Figure 28. Average response time on Platinum SLO - AWR report Figure 29. Comparison of performance between the Platinum and Gold SLO levels Figure 30. Select the TimeFinder menu Figure 31. Click TimeFinder/SnapVX Figure 32. Create a snapshot Figure 33. Set expiration days Figure 34. Snapshot created Figure 35. Create a task Figure 36. Edit the scheduler trigger time EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 5

6 Contents EMC Confidential Figure 37. Edit the action Figure 38. Find the new SnapVX snaps in Unisphere Figure 39. Average response time for OLTP baseline at non-peak time - AWR report Tables Table 1. Terminology Table 2. Hardware resources Table 3. Software resources Table 4. Information about the Oracle database workload and SLO Table 5. Storage SLO configuration details for OLTP workload Table 6. Oracle DW database configuration details Table 7. ASM disk group configuration for OLTP database Table 8. ASM disk group configuration for DW database Table 9. Database workload profile for each OLTP database Table 10. Database and workload profile for DW database Table 11. Table 12. Table 13. Table 14. OLTP baseline workload performance comparison with the OLTP and DW workloads combined DW baseline workload performance comparison with the combined DW and OLTP workloads OLTP workload performance comparison between Platinum and Gold SLO OLTP workload performance comparison before and after snapshots creation EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

7 EMC Confidential Chapter 1: Executive Summary Chapter 1 Executive Summary This chapter presents the following topics: Business challenges... 8 Technology solution... 8 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 7

8 Chapter 1: Executive Summary EMC Confidential Business challenges Technology solution 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 storagebased clone can require additional I/O while it is being initialized. Both of these can negatively impact production database performance. This 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. 8 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

9 EMC Confidential Chapter 2: About This Document Chapter 2 About This Document This chapter presents the following topics: Purpose Scope Audience Terminology and acronyms EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 9

10 Chapter 2: About This Document EMC Confidential Purpose The purpose of this 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 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 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 FAST IG MV PG SLO SRP Definition Fully automated storage tiering Initiator group in VMAX3 Masking view in VMAX3 Port group in VMAX3 Service level objective Storage resource pool 10 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

11 EMC Confidential Chapter 3: Technology Overview Chapter 3 Technology Overview This chapter presents the following topics: Introduction Solution architecture Key components EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 11

12 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. 12 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

13 EMC Confidential Hardware resources Chapter 3: Technology Overview 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 Software resources 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 API between storage and other components EMC Unisphere 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 Oracle Database 12c Enterprise Edition Enterprise Edition Software support for ASM storage and Oracle RAC Oracle Database software VMware vsphere ESXi 5.5 Hypervisor VMware vcenter Server 5.5 vsphere management server EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 13

14 Chapter 3: Technology Overview EMC Confidential 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 EMC VMAX3 EMC HYPERMAX OS 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 dualengine 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 nondisruptively 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. EMC VMAX Service Level Objective 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 14 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

15 EMC Confidential Chapter 3: Technology Overview 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. EMC VMAX3 FAST 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. EMC TimeFinder SnapVX 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 Service Level Objectives and SnapVX for Oracle 12c 15

16 Chapter 3: Technology Overview EMC Confidential 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 VMware vsphere Oracle Database 12c Enterprise Edition 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. 16 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

17 EMC Confidential Chapter 3: Technology Overview 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. SLOB Workload Generator 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). EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 17

18 Chapter 3: Technology Overview EMC Confidential 18 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

19 EMC Confidential Chapter 4: Database Deployment Chapter 4 Database Deployment This chapter presents the following topics: Introduction Storage provisioning with VMAX3 SLO Virtualization layer: ESXi and virtual machines Configuring OLTP and DW databases Database Storage Analyzer EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 19

20 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. VMAX3 Sizer Tool overview 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. 20 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

21 EMC Confidential Chapter 4: Database Deployment Figure 5. SLO - Average response time Provisioning considerations 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 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 SLO Workload Volumes Capacity (GB) DWRACSG_Data Silver DSS 21 1,000 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 21

22 Chapter 4: Database Deployment Storage group/name SLO Workload Volumes Capacity (GB) EMC Confidential DWRACSG_Redo Silver DSS 4 64 DWRACSG_CRS Silver DSS DWRACSG_FRA Silver DSS 4 1,000 Provisioning the OLTP Database 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 22 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

23 EMC Confidential Chapter 4: Database Deployment 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 23

24 Chapter 4: Database Deployment EMC Confidential 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 24 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

25 EMC Confidential Chapter 4: Database Deployment 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 25

26 Chapter 4: Database Deployment EMC Confidential 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. 26 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

27 EMC Confidential Chapter 4: Database Deployment 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 CRS OLTPRAC_CRS DATA 1, DATA OLTPRAC_DATA REDO REDO OLTPRAC_REDO FRA 1, 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 CRS DWRACSG_CRS DATA 1, DATA DWRACSG_DATA REDO REDO DWRACSG_REDO FRA 1, 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 Database type Database size Database name Oracle 12c Database Details OLTP 10 TB oltpdb 2-node RAC database on ASM EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 27

28 Chapter 4: Database Deployment Profile characteristic Workload profile Network connectivity EMC Confidential Details OLTP-like workload driven by SLOB 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 Profile characteristic Database type Database size Database name Oracle 12c Database Workload profile Network connectivity Details Data warehouse 20 TB dwdb 2-node RAC database on ASM Query-only workload driven by SLOB with all the SLOB indexes dropped 8 Gb FC for SAN 10 GbE for private network 28 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

29 EMC Confidential Chapter 4: Database Deployment 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 drilldowns 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 29

30 Chapter 4: Database Deployment EMC Confidential 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. 30 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

31 EMC Confidential Chapter 4: Database Deployment 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 31

32 Chapter 4: Database Deployment EMC Confidential 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 32 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

33 EMC Confidential Chapter 4: Database Deployment 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 VMAX3 Service Level Objectives and SnapVX for Oracle 12c 33

34 Chapter 4: Database Deployment EMC Confidential 34 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

35 EMC Confidential Chapter 5: Use Case 1: Mixed Workload on VMAX3 Chapter 5 Use Case 1: Mixed Workload on VMAX3 This chapter presents the following topics: Use case overview Test with mixed workload EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 35

36 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. 36 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

37 EMC Confidential Chapter 5: Use Case 1: Mixed Workload on VMAX3 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. Test objectives Test procedures 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-zerothink-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. Test results 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 37

38 Chapter 5: Use Case 1: Mixed Workload on VMAX3 EMC Confidential 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 38 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

39 EMC Confidential Chapter 5: Use Case 1: Mixed Workload on VMAX3 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, 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) LGWR response time (ms) EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 39

40 Chapter 5: Use Case 1: Mixed Workload on VMAX3 EMC Confidential Performance metric Physical read response time for single block (ms) Physical read response time for multi-noncontiguous blocks (ms) Performance data 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. 40 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

41 EMC Confidential Chapter 5: Use Case 1: Mixed Workload on VMAX3 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 Summary of use case 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 41

42 Chapter 5: Use Case 1: Mixed Workload on VMAX3 EMC Confidential 42 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

43 EMC Confidential Chapter 6: Use Case 2: Upgrade SLO Chapter 6 Use Case 2: Upgrade SLO This chapter presents the following topics: Use case overview Test for upgrading SLO EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 43

44 Chapter 6: Use Case 2: Upgrade SLO EMC Confidential Use case overview Test for upgrading SLO 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 objectives Test procedures Change 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 Click Modify, as shown in Figure EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

45 EMC Confidential Chapter 6: Use Case 2: Upgrade 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 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 45

46 Chapter 6: Use Case 2: Upgrade SLO EMC Confidential Test results 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, Write IOPS 23,220 14, Aggregate IOPS (write + read) 103,252 65, Redo throughput (MB/s) LGWR response time (ms) Physical read response time for single block (ms) Physical read response time for multi-noncontiguous blocks (ms) Summary of use case 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. 46 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

47 EMC Confidential Chapter 6: Use Case 2: Upgrade SLO Figure 29. Comparison of performance between the Platinum and Gold SLO levels EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 47

48 Chapter 6: Use Case 2: Upgrade SLO EMC Confidential 48 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

49 EMC Confidential Chapter 7: Use Case 3: Business Continuity for Oracle Database Chapter 7 Use Case 3: Business Continuity for Oracle Database This chapter presents the following topics: Overview Test with SnapVX EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 49

50 Chapter 7: Use Case 3: Business Continuity for Oracle Database EMC Confidential Overview Test with SnapVX 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 scenario 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. Test objectives Test procedures Create an ondemand backup 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 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

51 EMC Confidential Chapter 7: Use Case 3: Business Continuity for Oracle Database 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 51

52 Chapter 7: Use Case 3: Business Continuity for Oracle Database EMC Confidential Figure 33. Set expiration days 5. Locate the successfully created SnapVX in the dashboard, as shown in Figure 34. Figure 34. Snapshot created Schedule snaps 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 Create a command script with the name oraclesnap.cmd and edit the command to the following: symsnapvx -sid 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. 52 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

53 EMC Confidential Chapter 7: Use Case 3: Business Continuity for Oracle Database 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 53

54 Chapter 7: Use Case 3: Business Continuity for Oracle Database EMC Confidential 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 54 EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c

55 EMC Confidential Chapter 7: Use Case 3: Business Continuity for Oracle Database Test results 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) Physical read response time for single block (ms) Physical read response time for multi-noncontiguous blocks (ms) Summary of use case 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. EMC VMAX3 Service Level Objectives and SnapVX for Oracle 12c 55