Simplified Oracle RAC 12c Backup, Cloning, and Protection ... · Contents Simplified Oracle RAC 12c...

White paper

SIMPLIFIED ORACLE RAC 12C BACKUP, CLONING, AND PROTECTION FOR ORACLE DBAS Using VMware vSphere 5.5, EMC RecoverPoint, EMC Data Domain, EMC VNX, EMC VNX Snapshots, and EMC VNX SnapView Clones

Backup, restoration, and recovery using Oracle RMAN Cloning using RecoverPoint Bookmarks and EMC VNX Snapshots Protection using EMC RecoverPoint Continuous Remote Replication

EMC Solutions

Abstract

This solution demonstrates the use of EMC® RecoverPoint® and EMC Data Domain® with VMware vSphere to back up, clone, and protect an Oracle RAC 12c database.

June 2014

2 Simplified Oracle RAC 12c Backup, Cloning, and Protection for Oracle DBAs Using VMware vSphere 5.5, EMC RecoverPoint, EMC Data Domain, EMC VNX, EMC VNX Snapshots, And EMC VNX Snapview Clones White Paper

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

Published June 2014

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.

Simplified Oracle RAC 12c Backup, Cloning, and Protection for Oracle DBAs Using VMware vSphere 5.5, EMC RecoverPoint, EMC Data Domain, EMC VNX, EMC VNX Snapshots, And EMC VNX Snapview Clones White Paper

Part Number H13139

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

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

Contents


Contents

Executive Summary 9 Chapter 1Business case .......................................................................................................... 10

Solution overview ..................................................................................................... 10

Key results ................................................................................................................ 11

Introduction 13 Chapter 2Purpose .................................................................................................................... 14

Scope ....................................................................................................................... 14

Audience .................................................................................................................. 14

Terminology.............................................................................................................. 14

Solution Overview 17 Chapter 3Introduction to key components ............................................................................... 18

Oracle RAC 12c .................................................................................................... 18

VMware vSphere 5.5 ............................................................................................ 18

Oracle Linux ......................................................................................................... 18

EMC VNX5500...................................................................................................... 19

VNX Snapshots .................................................................................................... 19

SnapView clones ................................................................................................. 19

EMC RecoverPoint ................................................................................................ 19

EMC Unisphere .................................................................................................... 21

EMC Data Domain ................................................................................................ 21

Solution Architecture 23 Chapter 4Overview of solution ................................................................................................. 24

Physical environment ............................................................................................... 24

Hardware resources .................................................................................................. 26

Software resources ................................................................................................... 26

VMware virtual machines ......................................................................................... 27

VNX configuration ..................................................................................................... 27

Configuring SnapView clones ................................................................................... 28

Configuring VNX Snapshots ...................................................................................... 29

Design considerations for datastores ....................................................................... 30

Customizing the VMware template ........................................................................... 31

Configuring Oracle .................................................................................................... 32

Contents


Oracle database consistency .................................................................................... 33

Implementing EMC RecoverPoint .............................................................................. 34

Using the Data Domain system ................................................................................. 39

Test Case 1, Non-Disruptive Backup 41 Chapter 5Introduction ............................................................................................................. 42

Validation procedure ................................................................................................ 42

Enable the latest image access on the recovery site: ............................................ 42

Create the clone of replicated database LUNs ...................................................... 45

Mount the cloned VMFS datastores to ESXi hosts ................................................ 46

Assign the VMDKs to the Target Virtual Machine .................................................. 46

Mount the cloned database on the recovery VM ................................................... 47

RMAN backup to Data Domain ............................................................................. 49

Use RMAN to restore and recover the datafile from the backup set....................... 51

Results ................................................................................................................ 53

Test Case 2, Rapid Provisioning - Cloning Database 55 Chapter 6Introduction ............................................................................................................. 56


Create snapshot based on the cloned LUNs on recovery site ................................ 56

Open the snapshot database on the test/dev virtual machine ............................. 60

Results ................................................................................................................ 61

Test case 3, Continuous Remote Recovery with EMC Chapter 7RecoverPoint 63

Introduction ............................................................................................................. 64

Validate the replica at recovery site .......................................................................... 64

Overview .............................................................................................................. 64

Test procedure ..................................................................................................... 65

Result .................................................................................................................. 67

Restore table from human error ................................................................................ 67

Overview .............................................................................................................. 67

Test procedure ..................................................................................................... 68

Results ................................................................................................................ 70

Restore datafile from physical corruption or deletion ................................................ 71

Overview .............................................................................................................. 71

Test procedure ..................................................................................................... 71

Results ................................................................................................................ 73

Chapter 8: Conclusion 75

Summary .................................................................................................................. 76

Contents


Findings ................................................................................................................... 76

Chapter 9: References 79

References ............................................................................................................... 80

EMC product documentation ................................................................................ 80

Oracle product documentation ............................................................................ 80

VMware product documentation .......................................................................... 80

Appendix A: SnapView Clone 81

SnapView Clone Wizard ............................................................................................ 82

Appendix B: VNX Snapshot 87

Snapshot Consistency Group Wizard ........................................................................ 88

Create a snapshot .................................................................................................... 90

Create a snapshot mount point (SMP) ...................................................................... 91

Attach a snapshot .................................................................................................... 93

Contents


Figures Figure 1. SwingBench transactions per minute (green is before backup, blue is

during backup, and red is after backup) .............................................. 11

Figure 2. Data Domain space usage ................................................................... 12

Figure 3. Solution architecture (physical) ........................................................... 25

Figure 4. Mapping of ESXi Hosts and virtual machines to datastore ................... 30

Figure 5. Volume list .......................................................................................... 35

Figure 6. Define Production Journal screen ......................................................... 36

Figure 7. Add a Copy screen ............................................................................... 36

Figure 8. Define Journal Copy screen .................................................................. 37

Figure 9. Group Summary screen ....................................................................... 38

Figure 10. Complete the process .......................................................................... 38

Figure 11. Data Domain servers accessed using Direct NFS .................................. 39

Figure 12. Swingbench workload ......................................................................... 43

Figure 13. Unisphere for RecoverPoint – Test Copy............................................... 43

Figure 14. Select a Copy screen ........................................................................... 44

Figure 15. Select the latest image for the recovery site ......................................... 44

Figure 16. Latest Image in logged access on the recovery site .............................. 45

Figure 17. Relationship of the sources and clones ............................................... 45

Figure 18. Mount the VMFS datastores ................................................................. 46

Figure 19. vSphere client storage configuration screen ........................................ 46

Figure 20. Example PowerCLI script adding existing VMDKs to a target virtual machine .............................................................................................. 47

Figure 21. Dynamically scan for new disks ........................................................... 47

Figure 22. Scan for new Oracle ASM disks ............................................................ 48

Figure 23. Mount ASM disk groups ...................................................................... 48

Figure 24. Mount the cloned database ................................................................. 49

Figure 25. Swingbench transactions per minute ................................................... 50

Figure 26. Data Domain space usage ................................................................... 51

Figure 27. Access table failure ............................................................................. 51

Figure 28. Register backup in production database control file ............................ 52

Figure 29. Restore datafile 16 .............................................................................. 52

Figure 30. Recover datafile 16 .............................................................................. 53

Figure 31. Verify datafile recovery from Data Domain ........................................... 53

Figure 32. Create Snapshot Consistency Group Wizard ........................................ 57

Figure 33. Create a consistent snapshot .............................................................. 58

Figure 34. Snapshot mount point configuration ................................................... 59

Figure 35. Attach a snapshot to the ESXi host on recovery site ............................. 60

Figure 36. Open the Snapshot database .............................................................. 61

Contents


Figure 37. EMC RecoverPoint environment prior to testing ................................... 65

Figure 38. Record count and timestamp at production site ................................... 65

Figure 39. Creating bookmark 18000 and then enable access ............................. 66

Figure 40. Image access enabled at the remote replica ........................................ 66

Figure 41. Record count and timestamp at the remote replica site ....................... 67

Figure 42. Disable image access on the recovery site ........................................... 67

Figure 43. Drop the WAREHOUSE table ................................................................. 68

Figure 44. Enable PIT CRR image access ............................................................... 68

Figure 45. Export table from remote site to NFS share .......................................... 69

Figure 46. Finish accessing the image .................................................................. 69

Figure 47. Import the table back to production database ..................................... 70

Figure 48. Access the recovered table .................................................................. 70

Figure 49. Access table failure ............................................................................. 71

Figure 50. Enable PIT CRR image access ............................................................... 72

Figure 51. Copy missing file from standby database to NFS share ........................ 72

Figure 52. Register datafile copy in target database control file ............................ 73

Figure 53. Restore and recover datafile ................................................................ 73

Figure 54. Verify datafile recovery ........................................................................ 73

Figure 55. Storage System Properties screen ....................................................... 82

Figure 56. The Wizards menu ............................................................................... 83

Figure 57. Select the Source LUNs screen ............................................................ 83

Figure 58. Select Clone LUN Names screen .......................................................... 84

Figure 59. Storage Pool Configuration screen ....................................................... 84

Figure 60. Warnings from possible errors in clone configuration .......................... 85

Figure 61. Source LUNs tab .................................................................................. 85

Figure 62. Clone LUNS tab ................................................................................... 86

Figure 63. Clone fracture process ......................................................................... 86

Figure 64. Clone LUNs screen showing consistently fractured LUNs ..................... 86

Figure 65. EMC Unisphere – Software .................................................................. 88

Figure 66. EMC Unisphere – Start Consistency Group Wizard ............................... 89

Figure 67. EMC Unisphere – Consistency Group Name ......................................... 89

Figure 68. EMC Unisphere – Consistency Group LUNs .......................................... 90

Figure 69. EMC Unisphere – Create Snapshots..................................................... 90

Figure 70. EMC Unisphere – Snapshot Name ....................................................... 91

Figure 71. EMC Unisphere – Snap Created ........................................................... 91

Figure 72. Selecting a clone snapshot .................................................................. 92

Figure 73. Defining a snapshot mount point name in the Create Snapshot Mount Point screen ........................................................................................ 92

Figure 74. Confirm creating the mount point ........................................................ 93

Contents


Figure 75. Select a snapshot and right-click to reveal the attach menu ................ 93

Figure 76. The Select a Server screen ................................................................... 94

Figure 77. Results of the Snapshot Attach Wizard ................................................ 94

Figure 78. Confirm snap name ............................................................................. 95

Tables Table 1. Terminology......................................................................................... 14

Table 2. Hardware resources ............................................................................. 26

Table 3. Software resources .............................................................................. 26

Table 4. Production site virtual machines ......................................................... 27

Table 5. Remote site virtual machines ............................................................... 27

Table 6. Production and remote VNX550 array volumes .................................... 27

Table 7. Oracle RAC database LUNs and clone group names on remote VNX5500 array ........................................................ 28

Table 8. Clone LUN names for REMOTE VNX5500 array...................................... 29

Table 9. Virtual machine template configuration ............................................... 31

Table 10. Database and workload profile ............................................................ 32

Table 11. Virtual machine and database details ................................................. 32

Table 12. ASM disk groups ................................................................................. 32

Chapter 1: Executive Summary


Executive Summary Chapter 1

This chapter presents the following topics:

Business case .......................................................................................................... 10

Solution overview .................................................................................................... 10

Key results ............................................................................................................... 11



Business case

This white paperpresents three Oracle lifecycle management tasks that can be simplified using the described solution architecture:

Backup with EMC Data Domain using a proxy backup server

Cloning—Rapid provisions of database instances using RecoverPoint, SnapView clone, and VNX Snapshot technologies

Data recovery using RecoverPoint

Highly visible and mission-critical Oracle RAC 12c environments require consistent and predictable performance. Running RMAN backup on the production RAC cluster can often impact production database performance. To minimize the impact, DBAs frequently offload backups from the production database server to another server (backup proxy).

The combination of VMware vSphere with a storage-layer replication tool like EMC VNX® SnapView clone enables the DBA to rapidly provision a copy of the production database and mount that copy onto a VMware virtual machine which is a clone of a production RAC node. Oracle RAC 12c also requires a high-performance, space-efficient backup target. EMC Data Domain® avoids the complexity and additional dependencies of incremental backups by eliminating all non-unique data from the backup set. The customer can implement multiple full backups with at least the same space efficiency as incremental backups (and likely with much better efficiency).

Oracle RAC 12c databases are heavily developed by the end user. Many Oracle shops maintain multi-level test/dev (test and development) environments which leverage copies of the production database. An efficient, rapid method to provision thin copies of the production database is, therefore, very desirable. Combining EMC RecoverPoint bookmarks and EMC VNX Snapshots with VMware vSphere templates and virtual machine cloning provides a perfect solution for Oracle database test/dev cloning.

The Oracle RAC 12c database is often remotely replicated to a disaster recovery site to prevent data loss during a site-wide disaster. This is because Oracle frequently contains the source business data for the enterprise, and this data must be protected at all costs. EMC RecoverPoint® provides a reliable, efficient, high-performance remote replication tool for Oracle RAC 12c.

Solution overview

This solution demonstrates the use of EMC RecoverPoint and Data Domain with VMware vSphere to back up, recover, and clone an Oracle RAC 12c database. The tests covered by this solution include protection of the Oracle RAC 12c production database, with:

Backup—Proxy Backup deployment: SnapView clone and RMAN backups to EMC Data Domain

Cloning—Rapid Provisioning: This solution also covers rapid provisioning of an Oracle RAC 12c database for test/dev and other non production purposes with:



EMC RecoverPoint bookmarks

VNX Snapshots

Continuous Remote Recovery—Disaster Recovery Deployment: EMC RecoverPoint provides continuous remote replication (CRR) to a remote disaster recovery site

Key results

We1 ran a full backup on a virtualized proxy backup server/mount host to an EMC Data Domain target using the DR target replicated database as the source. We ran this backup while an OLTP workload was running on the production Oracle RAC 12c servers. As shown in Figure 1, the backup was completely non-disruptive to the production database servers, and had no performance impact:

Figure 1. SwingBench transactions per minute (green is before backup, blue is during backup, and red is after backup)

The following screenshot demonstrates that after performing four full RMAN backups, the backup data was deduplicated and compressed to occupy one fifth of the file system space on the Data Domain appliance:

1 In this guide, "we" refers to the EMC Solutions engineering team that validated the solution.



Figure 2. Data Domain space usage

We simulated a failure on the production database by deleting a datafile. We performed a datafile restore from the backup, and this restore completed with no issues in 1 minute and 45 seconds. Finally, we performed a datafile recovery which also completed with no issues.

Using both EMC RecoverPoint bookmarks and VNX Snapshots, thinly provisioned copies of the production database were created and mounted onto a virtualized test/dev server, without any disruption or performance impact on the production database server.

We validated the disaster recovery/remote replication of the production Oracle RAC 12c database using both row counts and time stamps. The remote replication dataset was used to recover from a deleted table, (completed in a total of 1 minute and 3 seconds) and a deleted datafile (completed in a total of 4 minutes and 37 seconds) on the production database server.

Chapter 2: Introduction


Introduction Chapter 2


Purpose .................................................................................................................... 14

Scope ....................................................................................................................... 14

Audience .................................................................................................................. 14

Terminology ............................................................................................................. 14



Purpose

This white paper covers the replication of a virtualized Oracle RAC 12c database to a remote disaster recovery site using EMC RecoverPoint. Using the copy of the production database on the data recovery (DR) site, this white paper also demonstrates offloading the Oracle RMAN backup process from the production server onto a virtualized proxy backup server. EMC Data Domain is used as the backup target, providing a space-efficient, high performance backup target for Oracle RMAN, which eliminates the need for incremental backups. Finally, multiple thinly-provisioned copies of the DR dataset are used to create virtualized test/dev clones of the production database.

Scope

This white paper covers:

Using a virtualized database server to offload Oracle RMAN full backups from the production server, and to create space-efficient backups on an EMC Data Domain target.

Restoration/recovery from an RMAN backup on an EMC Data Domain onto the Oracle RAC 12c production server.

Test/dev cloning using both EMC RecoverPoint bookmarks and EMC VNX Snapshots with VMware vSphere virtualized test/dev servers.

Implementing EMC RecoverPoint Continuous Remote Recovery (CRR) as a remote replication solution for Oracle RAC 12c production database servers.

Audience

This paper is intended for Oracle DBAs, storage administrators, virtualization administrators, system administrators, and their managers, as well as any others involved in evaluating, acquiring, managing, maintaining, or operating Oracle database environments.

Terminology

This white paper includes the following terminology:

Table 1. Terminology

Term Definition

ASM Oracle Automatic Storage Management

DD EMC Data Domain

DPE Disk Processor Enclosure

DR Disaster recovery

CRR Continuous remote replication



Term Definition

NFS Network File System

PowerCLI Windows PowerShell interface for managing VMware vSphere

RAC Oracle Real Application Clusters

RMAN Oracle Recovery Manager

RPA EMC RecoverPoint appliance

RTO Recovery time objective

PIT Point in Time

VMDK Virtual Machine Disk

Chapter 3: Solution Overview


Solution Overview Chapter 3


Introduction to key components............................................................................... 18



Introduction to key components

The key technology components for this solution are:

Oracle RAC 12c

VMware vSphere 5.5

Oracle Linux

EMC VNX5500

VNX Snapshots

SnapView clones

EMC RecoverPoint

EMC Unisphere®

EMC Data Domain

Refer to Overview of solution on page 24 for an explanation of which components perform the backup, cloning, and protection functions.

Oracle RAC 12c Stack consists of Oracle Grid Infrastructure, including Oracle ASM/CloudFS and Oracle Clusterware, and the Oracle Database with the Oracle Real Application Clusters (RAC) option.

The Oracle Database with the Oracle RAC option provides the ability to run multiple database instances on the different servers in the cluster against a shared set of data files, also known as the database. The database spans multiple hardware systems and yet appears as a single unified database to the application. This enables the use of commodity hardware to reduce total cost of ownership and to provide a scalable computing environment that supports various application workloads. Oracle RAC is Oracle’s shared disk database clustering technology.

Virtualization is an abstraction layer that decouples the physical hardware from the operating system to deliver greater IT resource utilization and flexibility. Virtualization allows multiple virtual machines with heterogeneous operating systems (for example, Windows 2003 Server and Linux) and applications to run in isolation, side-by-side on the same physical machine. A VMware vSphere virtual machine is the representation of a physical machine by software. It has its own set of virtual hardware (e.g., RAM, CPU, NIC, hard disks) onto which an operating system and applications are loaded. The operating system sees a consistent, normalized set of hardware regardless of the actual physical hardware components. VMware virtual machines contain advanced hardware features such as 64-bit computing and virtual symmetric multiprocessing.

Oracle Linux offers two Linux kernels to choose from:

The Red Hat Compatible Kernel for those who prefer strict Red Hat kernel ABI (kABI) compatibility

The Unbreakable Enterprise Kernel for those who want to leverage the latest features from mainline Linux and boost performance and scalability

Oracle RAC 12c

VMware vSphere 5.5

Oracle Linux



Oracle’s Unbreakable Enterprise Kernel is the default kernel since Oracle Linux 5 Update 6 and Oracle Linux 6. VMware supports only Unbreakable Enterprise Kernel Release 2 and Release 3.

The VNX5500 is a member of the VNX series next-generation storage platforms, which are designed for the mid tier space. This model provides either block and file, file only, or block only services. This solution uses the block only option.

The block only model uses a 2.13 GHz, four-core Xeon 5600 processor with 12 GB RAM and a maximum of 250 drives with the following block-based host connectivity options: FC, iSCSI, and FCoE.

The VNX5500 uses a DPE that is available in 15 x 3.5” drive or 25 x 2.5” drive form factors. The DPE includes four onboard 8 Gb/s Fibre Channel ports and two 6 GB/s SAS ports for backend connectivity on each storage processor.

VNX Snapshots are point-in-time views of a LUN, which can be made accessible to another host, or held as a copy for possible restoration. This is a new feature created to improve snapshot capability for VNX Block.

VNX Snapshots use a redirect-on-write algorithm, and are limited to pool-based provisioned LUNs. VNX Snapshots support 256 writeable snaps per pool LUN. Branching or “snap of a snap” is also supported. There are no restrictions to the number of branches, as long as the entire Snapshot Family is within 256 members. Consistency groups are also introduced, which means that several pool LUNs can be combined into a consistency group and snapped at the same time. For more information see the EMC VNX Snapshots white paper.

SnapView clones are fully populated point-in-time copies of LUNs that allow incremental synchronization between source and destination LUNs. Unlike snapshots that provide point-in-time views of data, clones provide fully populated point-in-time copies that maximize the flexibility of the storage environment. These point-in-time copies allow you to perform additional storage management tasks with minimal impact on production data. These tasks include backup/recovery, application testing, warehousing, and data movement.

EMC RecoverPoint is an advanced enterprise-class disaster recovery solution that is designed with the performance, reliability, and flexibility required for enterprise applications. It provides integrated continuous data protection and continuous remote replication to restore applications to any point in time.

EMC RecoverPoint systems enable reliable replication locally with one EMC RecoverPoint appliance (RPA) cluster, and over any distance to up to four remote RPA clusters. EMC RecoverPoint systems support replication of data for applications that are writing to SAN-attached storage using existing Fibre Channel (FC) and iSCSI infrastructure, to integrate seamlessly with existing host applications and data storage subsystems. For remote replication, the systems use existing connections to send the replicated data over FC and WAN. EMC RecoverPoint systems use FC and IP infrastructure to replicate data asynchronously or synchronously. The systems

EMC VNX5500

VNX Snapshots

SnapView clones

EMC RecoverPoint

https://support.emc.com/docu48702_White-Paper:-EMC-VNX-Snapshots.pdf?language=en_US



provide failover of operations to another cluster in the event of a disaster at the production cluster.

The EMC RecoverPoint family consists of three variants:

EMC RecoverPoint/CL for EMC and non-EMC storage platforms

EMC RecoverPoint/EX for EMC storage platforms (Block), licensed by storage array

EMC RecoverPoint/SE for VNX series, CLARiiON CX3 and CX4 series, and Celerra unified storage environments

In this solution, EMC RecoverPoint/SE is used with the EMC VNX5500.

EMC RecoverPoint 4.0 offers the following new features and enhancements to significantly increase capacity and improve performance, helping to build a more flexible and reliable disaster recovery solution:

Support for multisite replication: EMC RecoverPoint can replicate a primary site to up to four remote sites (1:4) for increased data availability. It can also protect data across branch offices with multi site replication from the branches to a central site (4:1).

Any-point-in-time recovery to VMware SRM operations

Asynchronous throughput up to 400 MB/s using distributed consistency groups

Replicated capacity from 300 TB to 2 PB per EMC RecoverPoint cluster

Support for synchronous replication over IP (versus Fibre Channel only before 4.0)

Support for RESTful API

A new, easy-to-use Unisphere interface for EMC RecoverPoint management

Unisphere for EMC RecoverPoint

The EMC RecoverPoint 4.0 and later user interface was developed using Adobe Flex technology and simplified to promote ease of use and a common user experience between EMC RecoverPoint, VNX, VPLEX, and Symmetrix products.

The EMC RecoverPoint wizards are streamlined and optimized for a simpler and more intuitive user experience, designed for the IT generalist. A dashboard provides an overview of system health at a glance, and all the information displayed through Unisphere for EMC RecoverPoint is consistently auto refreshed.

EMC RecoverPoint replication options

EMC RecoverPoint supports three modes of replication:

Continuous Local Protection—EMC RecoverPoint continuously captures and stores data modifications locally, enabling local recovery from any point in time (PIT) with no data loss. RecoverPoint Continuous data protection (CDP) supports both synchronous and asynchronous replications.



Continuous Remote Replication—EMC RecoverPoint captures local data modifications and replicates data to remote sites over IP or FC. Synchronous and asynchronous replications are supported.

Continuous Local and Remote Replication—A combination of continuous local replication and remote replication that provides both local and remote data replication.

Continuous Local Replication is normally used for PIT recovery where business data or application logic has been severely compromised. Continuous Remote Replication, on the other hand, is normally used for disaster recovery. Continuous Local and Remote Replication thus ensure that two replicas are made for every volume protected (local and remote) to protect from both scenarios.

This solution demonstrates Continuous Remote Replication with asynchronous replication.

EMC Unisphere® is a storage management platform that provides a flexible, integrated experience for managing existing EMC CLARiiON® and EMC Celerra® storage systems as well as next-generation EMC unified storage—the EMC VNX® and EMC VNXe® series. This approach to storage management fosters simplicity, flexibility, and automation. Unisphere supplies storage administrators with intuitive task-based controls, customizable dashboards, and single-click access to real-time support tools and online customer communities.

EMC Data Domain® systems are disk-based inline deduplication appliances and gateways that provide data protection and disaster recovery (DR) in the enterprise environment. All systems run the EMC Data Domain Operating System (DD OS), which provides both a command-line interface (CLI) for performing all system operations, and the EMC Data Domain System Manager (DD System Manager) graphical user interface (GUI) for configuration, management, and monitoring.

EMC Data Domain deduplication storage systems dramatically reduce the amount of disk storage required to retain and protect enterprise data. By identifying redundant data as it is being stored, Data Domain systems reduce backup storage requirements by 10 to 30 times. Backup data can then be efficiently replicated and retrieved over existing networks for streamlined disaster recovery and consolidated tape operations. This allows Data Domain appliances to integrate seamlessly into database architectures, maintaining existing backup strategies with no changes to scripts, backup processes, or system architecture.

The Data Domain appliance is the industry’s fastest, most cost-effective and scalable single-controller deduplication storage solution for disk-based backup and network-efficient DR.

The Data Domain Stream-Informed Segment Layout (EMC SISL™) scaling architecture enables the fast-inline deduplication throughput of the Data Domain system. A CPU-centric approach to deduplication delivers a high throughput while minimizing the number of disk spindles required.

EMC Unisphere

EMC Data Domain

Chapter 4: Solution Architecture


Solution Architecture Chapter 4


Overview of solution ................................................................................................ 24

Physical environment ............................................................................................... 24

Hardware resources ................................................................................................. 26

Software resources .................................................................................................. 26

VMware virtual machines ......................................................................................... 27

VNX configuration .................................................................................................... 27

Configuring SnapView clones ................................................................................... 28

Configuring VNX Snapshots ..................................................................................... 29

Design considerations for datastores....................................................................... 30

Customizing the VMware template........................................................................... 31

Configuring Oracle ................................................................................................... 32

Oracle database consistency ................................................................................... 33



Overview of solution

This solution demonstrates the use of a combination of EMC technologies to Backup, Clone, and provide Continuous Remote Recovery:

Backup—Proxy Backup deployment: SnapView clone and RMAN backups to an EMC Data Domain (Test Case 1)

Cloning—Rapid Provisioning: This solution also covers rapid provisioning of an Oracle RAC 12c database for test/dev and other non production purposes with EMC RecoverPoint bookmarks and VNX Snapshots (Test case 2)

Continuous Remote Recovery using a Disaster Recovery Deployment—EMC RecoverPoint Continuous Remote Replication (CRR) to a remote disaster recovery site (Test Case 3)

Physical environment

Figure 3 depicts the physical architecture of the solution environment.



Figure 3. Solution architecture (physical)

The production database consists of a two-node Oracle RAC cluster that is deployed on an EMC VNX5500. The database schema (SOE) includes tables for test validation.

The solution uses EMC RecoverPoint to protect the production Oracle RAC database. The recovery site consists of a virtualized two-node Oracle RAC database on an EMC VNX5500 storage array. Other virtual machines are provided for proxy backup and provisioning test/dev environments using EMC SnapView clones and VNX Snapshots features.

A Data Domain DD7200 deduplication appliance is included in the environment to act as a target for Oracle RMAN backups of the cloned database. The database is backed up from the cloned database to the Data Domain appliance using the Oracle Direct NFS Client.

The solution uses 10 Gb Ethernet for database interconnect, and between the Data Domain appliance and database hosts on the recovery site. One Gb Ethernet is used for all other IP traffic.



Hardware resources

Table 2 lists the hardware used to validate this solution.

Table 2. Hardware resources

Equipment Quantity Configuration

EMC RecoverPoint appliance 4 Gen 4

EMC VNX 2 VNX5500

VMware ESXi servers 4 Intel® Xeon® CPU X7560 2.27 GHz (8 core)

128 GB Memory

Quad-port network adapter (1 GbE)

2 x Dual-port network adapter (10 GbE)

Fibre Channel switch 4 8 Gb/s FC

Ethernet switch 4 1 Gb/s & 10Gb/s

EMC DD7200 1 128 GB memory

3 x internal SATA drives

One 1000/100/10 copper Ethernet

2 x dual-port 10 GbE optical network interface cards

4 x ES30 disk shelves with 15 x 3 TB SAS disks

Software resources

Table 3 lists the software used to validate this solution.

Table 3. Software resources

Software Version Purpose

EMC RecoverPoint 4.0.SP2.P1(m.29) EMC RecoverPoint OS

VNX Block Operating Environment

05.32.000.5.201 Unisphere Block, EMC RecoverPoint Splitter, VNX Snapshots, SnapView clones

Unisphere V1.2.25.1.0156 VNX Management

VMware vSphere 5.5.0 Virtualization Platform

Oracle Database 12c (with Oracle RAC and Oracle Grid Infrastructure)

Enterprise Edition 12.1.0.1.0

Oracle database and cluster software

Oracle ASMLib 2.0 Support library for ASM



Software Version Purpose

Oracle Linux 6.4 (with default kernel)

Operating system for all database servers

Data Domain OS 5.5.0.2-421637 Data Domain operating system

Fabric OS 5.2(8) SAN

Swingbench 2.5 Benchmark tool

VMware virtual machines

Table 4 lists the VMware virtual machines used on the production site.

Table 4. Production site virtual machines

Production Site Purpose

sse-rp-prodrac01 Production RAC database node

sse-rp-prodrac02 Production RAC database node

Table 5 lists the VMware virtual machines used on the remote site.

Table 5. Remote site virtual machines

Recovery Site Purpose

sse-rp-drrac01 DR RAC database node

sse-rp-drrac02 DR RAC database node

sse-rp-clone12c Cloned database mount host

sse-rp-test12c Test/dev database mount host

swingbench Swingbench host

VNX configuration

Table 6 details the LUNs we provisioned for this solution on the production and remote VNX5500 arrays.

Table 6. Production and remote VNX550 array volumes

Purpose Capacity No. of LUNs Replicated

Oracle Data 256 GB 4 Yes

Oracle Redo 16 GB 2 Yes

Oracle FRA 256 GB 6 Yes

Oracle Temp 256 GB 1 No



Purpose Capacity No. of LUNs Replicated

Oracle CRS 10 GB 1 No

EMC RecoverPoint Journal 26 GB 12 No

EMC RecoverPoint Repository 6 GB 1 No

Virtual Machine Datastores 1 TB 1 No

LUNs replicated to the remote array require target LUNs, of the same size or larger, to be configured on the remote array.

Note: The EMC RecoverPoint journal and repository volumes can also be created automatically through the EMC RecoverPoint/SE Installer Wizard if preferred. For more details see the EMC RecoverPoint Installation and Deployment Guide.

Configuring SnapView clones

Table 7 details the Oracle RAC database LUNs we cloned on the Remote VNX5500 array and the associated clone group names that were utilized in Test Cases 1 and 2.

Table 7. Oracle RAC database LUNs and clone group names on remote VNX5500 array

Source LUNs Capacity Clone LUN Name Clone Group Name

Data_dr_0 256 GB Data_dr_0_Clone_1 Data_dr_0_CloneGroup




Redo_dr_0 16 GB Redo_dr_0_Clone_1 Redo_dr_0_CloneGroup

Redo_dr_1 16 GB Redo_dr_1_Clone_1 Redo_dr_1_CloneGroup

Fra_dr_0 256 GB Fra_dr_0_Clone_1 Fra_dr_0_CloneGroup






For this solution, we used the Clone Wizard to create a clone of the production Oracle RAC database LUNs on the Remote VNX5500 using the steps outlined in Appendix A : SnapView .

Note: For automation purposes Unisphere CLI can be utilized, for more details please refer to the guide EMC VNX Series Command Line Interface Reference for Block.

https://support.emc.com/docu9565_RecoverPoint-Installation-and-Deployment-Guide.pdf?language=en_US

https://support.emc.com/docu41553_VNX-Command-Line-Interface-Reference-for-Block.pdf?language=en_US



Configuring VNX Snapshots

Table 8 details the clone LUNs we used to create VNX snapshots on the REMOTE VNX5500 array that were utilized in Test Case 2.

Table 8. Clone LUN names for REMOTE VNX5500 array

LUN Name Capacity Snapshot Name

Snapshot Consistency Group

Data_dr_0_Clone_1 256 GB

Snap1

CG_ORA_RP_SNAP




Redo_dr_1_Clone_1 16 GB

Redo_dr_2_Clone_1 16 GB

Fra_dr_0_Clone_1 256 GB






Create a Snapshot Consistency Group

For this solution, a single Snapshot consistency group (CG_ORA_RP_SNAP) was configured to take a snap of the Oracle 12c clone LUNs on the DR VNX5500. We created the Snapshot consistency group for Oracle 12c using the Create Group Wizard as outlined in Appendix B: Snapshot Consistency Group Wizard.

Create a Snapshot

We created a Snapshot using the Snapshot consistency group CG_ORA_RP_SNAP as outlined in Appendix B: Create a snapshot.

Create a snapshot mount point (SMP)

To present a snapshot to a server, use a snapshot mount point. A snapshot mount point (SMP) is a LUN-like container. It is used to emulate a typical LUN, but provides the ability for the host to write to snapshots and to change snapshots without the need to rescan the SCSI bus on the client.

For this solution we created the SMPs as outlined in Appendix B: Create a snapshot mount point (SMP)



Attach a Snapshot

To present a snapshot to a server, “attach” the snapshot. Attaching is an asynchronous operation during which the snapshot mount point (SMP) remains available, but the I/O is queued. This means that the host does not have to rescan the SCSI bus to view the snapshot. The rescan is required only to discover the SMP when it is first presented to the host.

For this solution we attached the snapshot using the Snapshot Consistency Group CG_ORA_RP_SNAP as outlined in Appendix B: Snapshot Consistency Group Wizard.

Note: Use Unisphere CLI for automation purposes. For more details please refer to the EMC VNX Series Command Line Interface Reference for Block.

Design considerations for datastores

For all virtual machines the OS and Oracle binaries reside on a shared data store: VM_PROD on the production VNX array and VM_DR on the remote VNX array. The Oracle database, however, uses dedicated datastores for the Oracle ASM disk groups, DATA, REDO, and the Fast Recovery Area (FRA), which are then replicated as consistency groups from the production site to the recovery site. The CRS and TEMP datastores are not replicated. This is depicted in Figure 4.

The solution uses the replicated database on the remote VNX array as the source for clone copies and then uses the clone as the source for multiple, independent snap copies as shown in Figure 4. All clones and snaps are created on the remote VNX array and mounted to mount hosts in the virtual environment.

Figure 4. Mapping of ESXi Hosts and virtual machines to data store





Customizing the VMware template

The virtual machine template was configured in VMware vSphere Client according to the requirements and prerequisites for the Oracle software (see Table 9), including:

RPM package manager

Kernel configuration

OS users

Supporting software

Table 9. Virtual machine template configuration

Part Description

CPU 8 vCPUs

Memory 16 GB

Operating system Oracle Linux Server release 6.4

Kernel 2.6.39-400.17.1.el6uek

Network interfaces Eth0 (for all nodes): 1Gb, public/management IP network

Eth1 (only for RAC nodes): 10Gb, dedicated to cluster interconnect

OS user (user created and password set)

Username: oracle

UserID:1101

OS groups Group: oinstall

GroupID:1000

Group: dba

GroupID:1031

Software pre installed The script sshUserSetup.sh was copied from the Oracle Grid Infrastructure 12c R1 binaries to /home/oracle/sshUserSetup.sh.

RPM packages installed (as Oracle prerequisites)

See the relevant Oracle installation guide.

Disk configuration 36 GB – virtual disk for OS, Oracle RAC 12c Release 1 Grid and RAC Database binaries

System configuration (Oracle prerequisites)

See the relevant Oracle Installation Guide:

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

Oracle Real Application Clusters Installation Guide 12c Release 1 (12.1) for Linux and UNIX



Configuring Oracle

To test the solution, we created one Oracle database for the production environment and several Oracle databases for different purposes on the recovery sites.

Table 10 details the profile for the production database.

Table 10. Database and workload profile

Profile characteristic Details

Database name Prod

Database type OLTP

Database size 1 TB

Oracle RAC 2 nodes

Benchmark profile Swingbench Order Entry workload

Table 11 provides a high-level view of the database role, database node and instance.

Table 11. Virtual machine and database details

Environment Database role Database node/instance

Production site Production database sse-rp-prodrac01/prod1

sse-rp-prodrac02/prod2

Recovery site Replica database sse-rp-drrac01/prod1

sse-rp-drrac02/prod2

Clone database sse-rp-clone12c/prod1

Test/dev database sse-rp-test12c/prod1

Table 12 details the Oracle ASM disk group configuration on the production and recovery sites.

Table 12. ASM disk groups

Environment ASM disk group File type

Production site

+CRS_PROD

Cluster Ready Services (CRS) files for prod database

+DATA Data files, control file

+REDO Online redo logs, mirrored control file

+FRA Archive logs

+TEMP_PROD Temp files for prod database



Environment ASM disk group File type

Recovery site +CRS_DR

Cluster Ready Services (CRS) files for replica database

+DATA Data files, control file

+REDO Online redo logs, mirrored control file

+FRA Archive logs

+TEMP_DR Temp files for replica database

Note: Because Oracle Clusterware and RAC database configuration information can be different between the production and recovery sites, the +CRS_PROD disk group is not replicated. Also it is possible to save bandwidth by not replicating temp files since they are not part of database recovery.

Oracle database consistency

While testing non-disruptive backup, rapid provisioning, and continuous remote recovery with EMC RecoverPoint, EMC consistency group technology preserves write order and crash consistency so that the database does not have to be put in Hot Backup mode (using ALTER DATABASE [BEGIN|END] BACKUP or ALTER TABLESPACE [BEGIN|END] BACKUP commands).

Transitioning a database in and out of Hot Backup mode has the following effects:

Additional redo data is logged

Complete database checkpoint is required

More operational steps and complexity during the backup operation

The Oracle database consistency is protected in the following way:

Test Case 1: Use “Test Copy” to access the RecoverPoint remote copy. The RecoverPoint consistency group assures the consistency and write-order fidelity of point-in-time images.

Test Case 2: Use the SnapView clone to create the clone based on the RecoverPoint remote copy. When RecoverPoint accesses the remote copy, production writes are stored in the image access log of the remote copy, so the remote copy is not changed by the production write. Use the SnapView clone-consistent fracture to preserve the Oracle restartable image. Accordingly, when RMAN is used to back up the cloned database, the write order and consistency are preserved.

Test Case 3: Use the VNX Snapshots consistency group to take write-order-consistent snapshots of a group of LUNs. The database is crash-consistent at the point of the snapshot, so a snapshot database can be opened for test/dev purposes.

Use consistency technology even if Hot Backup mode is used at the database level, because Hot Backup mode does not protect ASM metadata writes.



Implementing EMC RecoverPoint

This paper assumes the correct installation and initialization for both the Prod and DR EMC RecoverPoint Clusters has already completed. For detailed deployment steps, see EMC RecoverPoint Installation and Deployment Guide.

Before using the EMC RecoverPoint/SE Installer Wizard on each EMC RecoverPoint Cluster, complete the following prerequisites:

RPAs are Gen4 or later

RPAs are connected to SAN and Ethernet network

RPAs are loaded with the same EMC RecoverPoint/SE ISO image

RPAs are set with IP addresses (optional if the environment includes a DHCP server)

The computer that the wizard is run from can communicate with the cluster management IP and all the cluster’s RPA management (LAN) networks.

Ports 21, 22, 7225, and 8082 (all TCP) are open on the computer to enable communication with all RPAs.

Tip: Telnet to these ports on the computer to ensure they are open.

RPAs are all physical RPAs

You have EMC Online Support login credentials

If you do not have these credentials, or the computer that the wizard is run from does not have Internet connectivity, you must have an Installation Change Management XML file available locally to complete the installation.

Note: To obtain the XML file, you must submit an Installation Service Request to EMC Customer Support.

Configuring EMC RecoverPoint Consistency Group

EMC RecoverPoint can replicate only those volumes which are members of a consistency group. The number of such consistency groups will vary depending on the configuration and the number of applications being replicated.

For this solution, a single EMC RecoverPoint consistency group (ORA_RP_PROD) was configured to replicate the Oracle 12c production volumes to the replica volumes on the DR Site. EMC RecoverPoint CRR requires one replica volume on the remote site for each production volume. The replica volume must be equal or greater in size to the associated production volume. For this solution we created the consistency group for Oracle using the following steps:

Open a web browser and type the Cluster Management IP into the browser 1.address bar.

In the EMC RecoverPoint login screen, log in as a user with admin privileges. 2.




Select the Protection > Protect Volumes option to start the wizard that guides in 3.the creation of a consistency group.

In the Select Production Volumes screen: 4.

a. Define the consistency group name, the production name, and the RPA cluster that will manage the production.

b. Select the Oracle 12c production volumes in the volume list as shown in Figure 5.

Figure 5. Volume list

c. To continue configuring the group, click Next Define the Production Journal.

In the Define Production Journal screen (Figure 6), there are two provisioning 5.options:

a. Use Journal Provisioning

b. Manually select journal volumes

For this solution we selected the option Manually select journal volumes as we had previously created 24 x 26 GB journal volumes (RP_Journal_1 to 24).



Figure 6. Define Production Journal screen

c. To continue configuring the group, click Next Add a Copy.

In the Add a Copy screen (Figure 7): 6.

a. Define the copy name, the RPA cluster that will manage the copy volumes, and the replication mode.

Figure 7. Add a Copy screen



b. For each production volume, click Select volume link to add a volume to the copy. The selected volume is the volume that the production volume is replicated to.

c. To continue configuring the group, click Next Define Copy Journal.

In the Define Copy Journal screen (Figure 8), again there are two provisioning 7.options:

a. Use Journal Provisioning

b. Manually select journal volumes

In this solution we selected the option Manually select journal volumes as we had previously created 24 x 26 GB journal volumes (RP_Journal_1 to 24).

Figure 8. Define Journal Copy screen

c. To continue configuring the group, click Next Display Group Summary.

In the Group Summary screen (Figure 9): 8.

a. Ensure the consistency group diagram reflects the anticipated group configuration.

b. Select Finish to complete the Consistency Group creation wizard, as shown in Figure 10.



Figure 9. Group Summary screen

Note: This option applies all the specified settings, and starts a first-time initialization process to synchronize the production volumes to the copy volumes. Before you start transfer to any copy, ensure that the copy volumes are unmounted from any hosts.

Figure 10. Complete the process

The initialization process to synchronize the production volumes to the copy volumes is now in progress.



Using the Data Domain system

In this solution, the Oracle Database was configured to use Direct NFS Client to access the Data Domain system. The database was backed up by Direct NFS over 10 Gb Ethernet. The Data Domain system NFS share is mounted on the virtual machines at both the production and recovery sites. Once the NFS share was available we enabled the Oracle Direct NFS client on the database to improve RMAN backup and restore throughput and speed.

Figure 11 shows that the Data Domain system is accessed using Direct NFS client. For detailed steps of configuring Direct NFS Client, refer to Oracle Database Installation Guide 12c Release 1 (12.1) for Linux.

Figure 11. Data Domain servers accessed using Direct NFS

The mount points /mnt/DDshare/OraBackup and /mnt/DDshare/ArchBackup enable separate analysis of the data reduction effect that is achieved for each backup set, which enables better capacity management of the Data Domain system over time.

There is another mount point /mnt/NFSshare at both sites. The replica database can back up copies of datafiles or export tables to that directory and the production database can access these for recovery.

http://docs.oracle.com/cd/E16655_01/install.121/e17720/post_inst_task.htm#BJFIFHIF

http://docs.oracle.com/cd/E16655_01/install.121/e17720/post_inst_task.htm#BJFIFHIF

Chapter 5: Test case 1, Non-disruptive backup


Test Case 1, Non-Disruptive Backup Chapter 5


Introduction ............................................................................................................. 42


Chapter 5: Test case 1, Non-Disruptive Backup


Introduction

For this solution, we used EMC RecoverPoint to provide remote DR protection for an Oracle RAC 12c database. We also used EMC SnapView clone feature to offload the backup from the production database. During the proxy backup operation, there was no performance impact on production RAC database.

Backups were deployed over Direct NFS client to an EMC Data Domain DD7200 deduplication appliance, and backup and recovery operations were implemented using Oracle RMAN. The backup was preserved on the Data Domain DD7200.

Data Domain systems integrated seamlessly with Oracle RMAN, which is Oracle’s native backup and recovery utility for Oracle databases.

With Data Domain deduplication, only unique data was written to storage. This eliminated the data redundancy associated with multiple full backups of an Oracle database and made it possible to implement a backup strategy that used full backups only. This strategy avoided any possible restore penalty associated with incremental backups and was the option used for testing and validating this solution.

Validation procedure

The following steps were used to validate this solution for offloading production database backup:

Enable the latest image access on the recovery site. 1.

Create the clone of replicated database LUNs using Clone Wizard. 2.

Mount the cloned VMFS datastores to ESXi hosts on the recovery site. 3.

Assign the VMDKs to the target virtual machine. 4.

Mount the cloned database on the backup host (sse-rp-clone12c). 5.

Use RMAN to back up the cloned database and archive logs to the DD7200. 6.

Use RMAN to restore and recover the datafile from the backup set on the 7.DD7200.

This section demonstrates how to clone the database LUNs on the recovery site and how to generate the backup set on a Data Domain system. This section also shows how to use the backup set on the Data Domain appliance to restore and recover the production database to the production environment, in the event of data loss or corruption.

For testing purposes, a Swingbench workload was run against the production site as required, as shown in Figure 12.

Enable the latest image access on the recovery site:



Figure 12. Swingbench workload

To enable access to the latest image on the recovery site using Unisphere for RecoverPoint:

1. Open a web browser and type the RPA Cluster Management IP into the browser address bar.

2. In the EMC RecoverPoint login screen, log in as a user with admin privileges.

3. Select the options Recovery > Test a Copy as shown in Figure 13.

Figure 13. Unisphere for RecoverPoint – Test Copy

4. In the Select a Copy Screen, select the non production copy, in this case ORA_RP_DR, and click the Next Select the Image button as shown in Figure 14.



Figure 14. Select a Copy screen

5. In the Select an Image screen, select The latest image and click the Next Test the Image, as shown in Figure 15.

Figure 15. Select the latest image for the recovery site

6. The latest image is now available on the Remote site, in Logged Access mode, as shown in Figure 16.



Figure 16. Latest Image in logged access on the recovery site

Note: Use RecoverPoint CLI for automation purposes. For more details refer to the EMC RecoverPoint CLI Reference Guide.

We used the Clone Configuration Wizard to create the cloned LUNs on the recovery site. The relationship between the sources and the clones is shown in Figure 17. For detailed steps of creating the clone, refer to Appendix A: SnapView Clone Wizard.

Figure 17. Relationship of the sources and clones


Create the clone of replicated database LUNs

https://support.emc.com/docu49085_RecoverPoint-4.0-CLI-Reference-Guide.pdf?language=en_US

https://support.emc.com/docu49085_RecoverPoint-4.0-CLI-Reference-Guide.pdf?language=en_US





Mount cloned LUNs using the esxcli commands, as shown in Figure 18. Run the command directly on the remote ESXi server.

Figure 18. Mount the VMFS datastores

The cloned LUNs are seen by vSphere as “snapshot LUNs” as shown in Figure 19.

Figure 19. vSphere client storage configuration screen

Add VMDK to the target virtual machine using the vSphere Client or the command line. In this solution, multiple VMDKs were added from the cloned datastore using a simple PowerCLI script. Figure 20 shows an example of the script to add Data volumes.

Mount the cloned VMFS datastores to ESXi hosts

Assign the VMDKs to the Target Virtual Machine



Figure 20. Example PowerCLI script adding existing VMDKs to a target virtual machine

The cloned database is a single instance database that you can open on the mount host and use for proxy backup purposes. As a prerequisite, the following Oracle components must be installed on the mount host virtual machine:

Oracle Database 12c

Oracle Grid Infrastructure 12c for a Standalone Server option (for Oracle ASM support)

You can automate opening the database on the mount host by including the relevant commands in the post-mount script for the job. However, for demonstration purposes, we performed all the required steps manually, as follows:

Log in as root to the Guest OS on the virtual machine and dynamically scan for 1.new disks as shown in Figure 21.

Figure 21. Dynamically scan for new disks

Using Oracleasm, scan for new ASM disks as shown in Figure 22. 2.

Mount the cloned database on the recovery virtual machine



Figure 22. Scan for new Oracle ASM disks

Mount ASM disk groups as shown in Figure 23: 3.

Figure 23. Mount ASM disk groups

Start the database in mount mode: 4.

The initialization parameter file (INIT.ORA) for the cloned database is copied from the production RAC database, which consists of two Oracle RAC nodes.

To enable the single instance database, all parameters related to RAC must be removed from this file. For the solution, this means removing the following parameters:

*.CLUSTER_DATABASE=true

prod1.instance_number=1

prod2.instance_number=2

prod1.thread=1

prod2.thread=2

prod2.undo_tablespace='UNDOTBS2'

Use the Oracle SQL*Plus utility to mount the cloned database with the STARTUP 5.MOUNT command, as shown in Figure 24:



Figure 24. Mount the cloned database

RMAN backup scripts

This is the RMAN script used to back up the production database and all archived redo log files to the DD7200:

run

{

allocate channel d1 type disk;




backup as backupset filesperset=1 format

'/mnt/DDshare/OraBackup/db_%d_%s_%p_%t' database;

release channel d1;

release channel d2;

release channel d3;

release channel d4;

}

run

{





backup as backupset filesperset=1 format

'/mnt/DDshare/ArchBackup/db_%d_%s_%p_%t' archivelog all delete

input;

release channel d1;

release channel d2;

release channel d3;

release channel d4;

}

RMAN backup to Data Domain



RMAN backup parameters

filesperset The RMAN parameter FILESPERSET specifies the maximum number of datafiles that RMAN can include in a single backup set. When backing up to a Data Domain system, you must explicitly set this FILESPERSET parameter to 1. Failure to do so may result in lower deduplication rates than expected2.

Back up the database

The RMAN backup scripts were run on the mount host (sse-rp-clone12c) to perform the RMAN full backup, and to offload backup from the production environment. Figure 25 shows the Transactions Per Minute (TPM) of the production database. It has three sections:

Before the proxy backup (green region)

During the proxy backup (blue region)

After the proxy backup (red region)

The proxy backup process is non-disruptive and completely transparent to the production database so there is no performance impact on the production database.

Figure 25. Swingbench transactions per minute

The following screenshot demonstrates that after four full RMAN backups were performed, the backup data was deduplicated and compressed to occupy one fifth of the file system space on the Data Domain appliance:

2 For more information, refer to the EMC white paper: Oracle RMAN Design Best Practices with Data Domain.

http://uk.emc.com/collateral/hardware/white-papers/h8110-oracle-rman-data-domain-wp.pdf

http://uk.emc.com/collateral/hardware/white-papers/h8110-oracle-rman-data-domain-wp.pdf



Figure 26. Data Domain space usage

We created four RMAN full backups with each image being fully recoverable. Almost 1.2TB of data was sent to the Data Domain system but, due to the effects of deduplication and compression, less than 240GB of actual space was consumed.

Simulate production database failure

We simulated that one of the datafiles (datafile 16) which contains the CUSTOMERS table is corrupt or missing (a database failure).

Figure 27 shows what happens when you attempt to query the missing CUSTOMERS table:

Figure 27. Access table failure

RMAN recovery from the Data Domain system

To make the tablespace accessible again in the production database, we restored and recovered datafile 16 from the backup set on the DD7200:

1. Use the CATALOG command to register the backup in the control file of the production database, as shown in Figure 28.

Use RMAN to restore and recover the datafile from the backup set



Figure 28. Register backup in production database control file

2. Use the RESTORE command to retrieve the datafile from the backup set on the Data Domain system and make it available on the production database, as shown in Figure 29.

Figure 29. Restore datafile 16

3. Use the RECOVER command to recover the datafile, as shown in Figure 30.



Figure 30. Recover datafile 16

4. With recovery complete, bring datafile 16 back online. Then verify that the CUSTOMERS table is accessible again, as shown in Figure 31.

Figure 31. Verify datafile recovery from Data Domain

With the EMC technologies deployed for this scenario, you can:

Use EMC RecoverPoint and SnapView clone technology to offload backups from the production environment. It is non-disruptive to the source and there is no impact to critical production workloads.

Results



Deploy an EMC Data Domain appliance as a target for RMAN backups of the cloned database by using Direct NFS client over a 10 Gb Ethernet.

Substantially improve storage efficiency with Data Domain deduplication technology. This has the following benefits:

Data Domain deduplication enables retention of many RMAN full backups, which eliminates the need for implementing incremental RMAN backups.

Implementing Oracle RMAN full backups on a Data Domain system with deduplication, instead of traditional Oracle incremental RMAN backups, not only saves space but also reduces the complexity of the recovery process and the length of the recovery window (RTO).

Chapter 6: Test case 2, Rapid Provisioning – Cloning Database


Test Case 2, Rapid Provisioning - Chapter 6Cloning Database


Introduction ............................................................................................................. 56




Introduction

This section describes a method for quickly and easily replicating and repurposing an Oracle RAC 12c database on EMC infrastructure, without disrupting production. The replica databases are deployed on virtual machines in a virtualized environment and can be used for a variety of purposes, including test/dev, quality assurance (QA), decision support, and backup.

The solution uses the production RAC database replicated on the DR site as the source for clone copies and then uses the clone as the source for multiple, independent snap copies. All clones and snaps are created on the VNX array and mounted to mount hosts in the virtual environment.

Validation procedure

We used this procedure to validate this solution for rapid provisioning of test/dev environments:

1. Create a snapshot based on the cloned LUNs on recovery site.

2. Open the snapshot database on the test/dev virtual machine.

Note: You can get multiple snapshots on demand whenever you want to create another test/dev environment.

To create a snapshot based on the cloned LUNs on recovery site, follow these steps:

1. Create snapshot consistency group.

2. Create a consistent snapshot.

3. Create a Snapshot Mount Point.

4. Attach a snapshot to the ESXi host on the recovery site.

Create snapshot based on the cloned LUNs on recovery site



Create snapshot consistency group

After the SnapView clone has been created on the recovery site, you can take multiple, independent snap copies that can be used for a variety of purposes, including test/dev, quality assurance (QA), decision support, and upgrade. We used VNX Snapshot technology to create the snap copy as shown in Figure 32. For detailed steps of creating a snapshot consistency group, refer to Appendix B: Snapshot Consistency Group Wizard

Figure 32. Create Snapshot Consistency Group Wizard



Create a consistent snapshot

After the consistency group CG_ORA_RP_SNAP is created, you can highlight the consistency group, then right click and use the “Create Snapshot” option to create a consistent snapshot, as shown in Figure 33. For detailed steps of creating consistent snapshots, refer to Appendix B: Create a .

Figure 33. Create a consistent snapshot



Create Snapshot Mount Point

To enable access to hosts, SMPs must be provisioned to storage groups, like any typical LUN.

Figure 34 shows the Mount Points we created. For detailed steps on creating SMPs, refer to Appendix B: Create a snapshot mount point (SMP).

Figure 34. Snapshot mount point configuration

Attach a snapshot to the ESXi host on recovery site

To attach the snapshot quickly and easily, right-click the CG_RP_SNAP1 snapshot and choose the Attach option, as shown in Figure 35. For detailed steps of attaching snapshots, refer to Appendix B: Attach a snapshot.



Figure 35. Attach a snapshot to the ESXi host on recovery site

To open the snapshot database on the test/dev virtual machine, follow these steps:

Make the snapshot VMFS datastores accessible to ESXi hosts on recovery site, 1.using the same steps as described in Mount the cloned VMFS datastores to ESXi hosts on page 46.

Add VMDK to the virtual machine using the vSphere Client or the command line. 2.In this solution, multiple VMDKs were added to the test/dev data store. Refer to Assign the VMDKs to the Target Virtual Machine on page 46.

Follow the steps described in Mount the cloned database on the recovery on 3.page 47 to scan for new disks and mount ASM disk groups, and edit the database initialization parameter file.

Use SQL*Plus to open the snapshot database with the STARTUP command, as 4.shown in Figure 36:

Open the snapshot database on the test/dev virtual machine



Figure 36. Open the Snapshot database

Now you can open the snapshot database and start working with it. You can create other test/dev databases on demand, using the cloned LUNs as the source and with VNX Snapshot technology.

With the EMC technologies deployed for this scenario, you can use EMC RecoverPoint and SnapView Snapshot for agile Oracle database lifecycle management. With a predefined EMC RecoverPoint image bookmark, only a few steps are required to make multiple snapshot copies of the cloned database and provision Oracle instances for use in many non production environments, including test/dev, quality assurance, and decision support.

Results

Chapter 7: Test case 3, Continuous Remote Recovery with EMC RecoverPoint


Test case 3, Continuous Remote Chapter 7Recovery with EMC RecoverPoint


Introduction ............................................................................................................. 64

Validate the replica at recovery site ......................................................................... 64

Restore table from human error ............................................................................... 67

Restore datafile from physical corruption or deletion .............................................. 71



Introduction

The replicated database running on the recovery site can be used to recover the production database. If the production database encounters human error such as tables that have been inadvertently dropped by a user, a replicated database provides a way to restore tables. If a datafile on a production database is corrupt or accidentally deleted, the corresponding datafile on the replicated database can be copied and made available to the production environment to enable the recovery.

This test case contains three scenarios:

Validate the replica at recovery site 1.

Restore table from human error 2.

Restore datafile from physical corruption or data loss 3.

Validate the replica at recovery site

This test scenario validates that EMC RecoverPoint can successfully replicate the Oracle RAC database from the production environment to the Oracle RAC environment at recovery site, and that the database can be recovered at recovery site to selected points in time and for a variety of purposes. The main steps are:

Manually create a bookmark. 1.

Note: EMC RecoverPoint continuously creates point-in-time snapshots. For test purposes, a bookmark (named snapshot) is created manually to enable quick and easy recovery to a specific point in time.

Enable image access to the bookmarked image on recovery site. 2.

Recover the database into the RAC environment on recovery site. 3.

Verify the integrity of the database on the recovery site. 4.

The screenshot in Figure 37 shows the status of the EMC RecoverPoint environment before these steps were performed.

ORA_RP_PROD is the production source; ORA_RP_DR is the remote replica. EMC RecoverPoint is replicating consistency group CG_ORA_RP_PROD to the replica journal and storage at Site ORA_RP_DR. The local journal at Site ORA_RP_PROD is unused (it is configured so that it can take over the role of replica journal if that production needs to fail over to the remote site). The remote replica is not currently enabled for access.

Overview



Figure 37. EMC RecoverPoint environment before testing

For this test scenario:

With Swingbench running load against the Oracle RAC database in the 1.production environment, insert records into the production database. Figure 38 shows the record count and the time stamp of the last entry. This information was later used to validate the integrity of the data at Site ORA_RP_DR.

Figure 38. Record count and timestamp at production site

Using the EMC RecoverPoint Unisphere, create a bookmark and name it 2.appropriately for easy identification in the journal, then enable host access to the bookmarked image at Site ORA_RP_DR. You do this by using the Apply Bookmark and Test Copy option for the CRR replica as shown in Figure 39.

Test procedure



Figure 39. Creating bookmark 18000 and then enable access

The system rolls the replica storage to the bookmarked point in time and enables host access to the bookmarked image, as shown by the screenshot in Figure 40.

Figure 40. Image access enabled at the remote replica



Open the replica database at the recovery site so that the bookmarked image 3.can start being used for processing. To open the replica database, refer to Open the snapshot database on the test/dev virtual machine on page 60.

To verify data integrity at Site ORA_RP_DR, display the record count and 4.timestamp from the recovered database. Figure 41 shows that these match the values recorded at the production site (see Figure 38).

Figure 41. Record count and timestamp at the remote replica site

Disable image access on the recovery site using Finish Testing option, as shown 5.in Figure 42. All write operations to the replica volumes are discarded.

Figure 42. Disable image access on the recovery site

Host applications at Site ORA_RP_DR now have access to the replica volumes, which have been recovered to the bookmarked point in time and the validated data. The Swingbench session on the production database is unaffected throughout the procedure and EMC RecoverPoint replication to Site ORA_RP_DR continues uninterrupted. After image access on the recovery site is disabled, all write operations to the replica volumes are discarded.

Restore table from human error

If a major error occurs, such as a batch job being run twice in succession, the database administrator can request an EMC RecoverPoint operation that quickly restores the database object to a previous point in time, eliminating the need to restore or flashback the whole database. For example, it is possible to restore an entire table. Similarly, the DBA can recover tables that have been inadvertently deleted by a user.

The main steps are:

Simulate a table that has been accidentally deleted by a user or application. 1.

Enable image access to the PIT image before the table deletion on the recovery 2.site.

Result

Overview



Open the replica database and export the table that was deleted from the 3.production database.

Import the table back into the production database. 4.

For this scenario:

Drop the table WAREHOUSE from soe1 user using DROP TABLE PURGE 1.command. The table is purged from recycle bin, as shown in Figure 43. The index WHS_ID_IX associated with that table is deleted as well.

Figure 43. Drop the WAREHOUSE table

To enable CRR image access, select the PIT before the table deletion, as shown 2.in Figure 44:

Figure 44. Enable PIT Continuous Remote Replication image access

Test procedure



Open the replica database at the recovery site so that the bookmarked image 3.can start being used for processing. To open the replica database, refer to Open the snapshot database on the test/dev virtual machine on page 60.

Export the WAREHOUSE table from the replica database by using the Data Pump 4.Export utility. The dump files were exported to /mnt/NFSshare, which is mounted at both production and recovery sites by Direct NFS Client. The replica database can export database objects to the directory, and the production database can access these objects for recovery.

Figure 45 shows the table exporting process.

Figure 45. Export table from remote site to NFS share

After the export is finished, four dump files are available. At this point, select 5.Finish Testing from the drop down menu to finish the image access, as shown in Figure 46. Distribution of images from the copy journal to the copy storage continues from the accessed image forward.

Figure 46. Finish accessing the image

Import the WAREHOUSE table back to production database using Data Pump 6.Import utility. During the import operation, the Data Pump Import utility loads



the exported dump file from replica database into the production system, as show in Figure 47:

Figure 47. Import the table back to production database

During Import jobs, you can suppress the generation of redo for indexes using Oracle database 12c new feature. Set the transform=disable_archive_logging:y:index, so that the logging attributes for the indexes are disabled before the data is imported.

With Import complete, verify that the WAREHOUSE table is accessible again, as 7.shown in Figure 48.

Figure 48. Access the recovered table

The testing outlined in this section shows how easily administrators can restore their database objects in the event of human error, providing fast recovery of a table without restoring a backup or performing a flashback of the whole database.

Also, EMC RecoverPoint offers high restore point detail, allowing administrators to go back to a point in time in the past by selecting either user-defined bookmarks or

Results



snapshots generated automatically by EMC RecoverPoint on an ongoing basis, without affecting the production database operations.

Restore datafile from physical corruption or deletion

This section describes a flexible database protection and disaster recovery solution for Oracle production systems. EMC RecoverPoint maintains a remote replica on a VNX5500 storage array. This configuration provides optimal data protection in the case of an unexpected datafile failure, or if an unplanned outage makes the primary system unavailable.

The main steps are:

1. Simulate a database failure by making one of the datafiles inaccessible.

2. Enable access to a PIT image before the datafile corruption on the recovery site.

3. Restore and recover the datafile directly from the replica database.

4. Open the production database and verify that the recovered table is accessible.

For this scenario:

We simulated database failure by making datafile 16, which contains the table 1.CUSTOMERS, inaccessible.

Figure 49 shows what happens when you attempt to query the table CUSTOMERS:

Figure 49. Access table failure

Enable CRR image access and select the PIT before the datafile corruption, as 2.shown in Figure 50.

Overview

Test procedure



Figure 50. Enable PIT CRR image access

Open the replica database at recovery site so that the bookmarked image can 3.start being used for processing.

To open the replica database, follow the steps in Open the snapshot database on the test/dev virtual machine on page 60.

Recover the datafile from the remote replica. 4.

Use the RMAN BACKUP AS COPY command to copy datafile 16 from the replica database to the directory /mnt/NFSshare that is mounted at both production and recovery sites via Direct NFS Client. Figure 51 shows the backup copy being created.

Figure 51. Copy missing file from standby database to NFS share

5. On the production database, use the RMAN CATALOG DATAFILECOPY command to register the newly created copy of datafile 16 in the control file of the target database, as shown in Figure 52.



Figure 52. Register datafile copy in the target database control file

6. Use the RMAN RESTORE and RECOVER commands to restore and recover datafile 16 on the production database, as shown in Figure 53.

Figure 53. Restore and recover datafile

7. With recovery complete, bring datafile 16 back online and then verify that the table CUSTOMERS is accessible again, as shown in Figure 54.

Figure 54. Verify datafile recovery

The testing outlined in this section shows that EMC RecoverPoint along with Oracle RMAN can be used to recover a production database online from the remote site EMC VNX if the production system becomes unavailable for any reason.

Results

Chapter 8: Conclusion



This appendix presents the following topics:

Summary .................................................................................................................. 76

Findings ................................................................................................................... 76



Summary

This solution demonstrates how to use EMC technologies to provide data protection, disaster recovery, database backup and recovery, and test/dev environment provisioning for the Oracle RAC 12c databases.

EMC RecoverPoint is a robust replication technology with an intuitive GUI. It provides fine-grained local and remote point-in-time failover and recovery protection for the data center. In an Oracle environment, EMC RecoverPoint can reliably protect the database by providing multiple, consistent recovery points that are maintained by sophisticated journaling technology. This automated bookmarking and journaling provides a great deal of flexibility when recovering from a disaster scenario in case of datafile loss or corruption, as well as restoring the database objects in the event of human error on an ongoing basis and without affecting the production database operations.

EMC SnapView clone enables offloading backups from the production environment. It is non-disruptive to the source and there is no impact on critical production workloads.

EMC Data Domain systems provide a storage platform for maintaining Oracle RMAN backup sets. The integration of EMC Data Domain systems with Oracle RMAN provides the ability to compress and deduplicate backups, which can dramatically reduce the space required for backup storage.

Test/dev environment provisioning is a common requirement for customers who use Oracle Databases. This solution uses EMC’s space-efficient SnapView clone and VNX Snapshot technologies to create multiple, consistent replicas of the production database. By using the storage array’s consistent split capability, which simplifies replica creation and deployment, the solution enables quick, on-demand provisioning of new test/dev environments.

Findings

EMC technologies offer solutions for Non-Disruptive Backup, Rapid provisioning, and Continuous Remote Recovery with EMC RecoverPoint for Oracle RAC 12c databases:

Non-Disruptive Backup: Using EMC SnapView clone and Oracle RMAN, the proxy backup server backed up the replicated database on the recovery site to Data Domain without any performance impact on the Oracle production environment, and the compression ratio achieved on the Data Domain is approximately 5X. We restored and recovered a corrupt datafile from the backup, with no issues, in 1 minute and 45 seconds.

Rapid provisioning: EMC RecoverPoint bookmarks and VNX Snapshots enable rapid provisioning of on demand production databases for Oracle environments (such as testing, development, and quality assurance) in an Oracle Database application lifecycle infrastructure, without disrupting the Oracle production or DR environments.

Continuous Remote Recovery: EMC RecoverPoint provides continuous remote replication (CRR) to a remote disaster recovery site. We validated the disaster



recovery/remote replication of the production Oracle RAC 12c database using both row counts and time stamps. We also showed how easily administrators can restore their database tables (completed in a total of 1 minute and 3 seconds) and datafiles (completed in a total of 4 minutes and 37 seconds) using the remote replication dataset.

Chapter 9: References




References ............................................................................................................... 80



References

For additional information, see the white papers listed below.

EMC Data Domain Operating System Administration Guide

EMC RecoverPoint Installation and Deployment Guide

EMC RecoverPoint 4.0 Release Notes

EMC RecoverPoint Release 4.0 Administrator’s Guide

Introduction to the EMC VNX Series – a Detailed Review

VMware Infrastructure Architecture Overview – white paper

EMC VNX Snapshots white paper

EMC Glossary: Unisphere article

Oracle RMAN Best Practices with EMC Data Domain – White paper

Upgrade to Oracle RAC 12c with Oracle Multitenant Option (Pluggable Database) white paper

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

Oracle Real Application Clusters Installation Guide 12c Release 1 (12.1) for Linux and UNIX

Oracle Database Utilities 12c Release 1 (12.1)

Supported Backup, Restore, and Recovery Operations using Third Party Snapshot Technologies (Doc ID 604683.1)

vSphere Handling of LUNs Detected as Snapshot LUNs (1011387)

EMC product documentation

Oracle product documentation

VMware product documentation


http://uk.emc.com/corporate/glossary/unisphere.htm

Appendix A: Snapview Clone


Appendix A: SnapView Clone


SnapView Clone Wizard ........................................................................................... 82



SnapView Clone Wizard

For this solution, we used the SnapView Clone Wizard to create a clone of the Oracle production RAC database volumes on the Remote VNX5500 in the following way:

In the Unisphere login screen, log in as a user with Administrator privileges. 1.

Ensure the correct system is selected in Unisphere. 2.

Confirm that SnapView is enabled on the VNX array by selecting the options 3.System > System Properties > Software

Figure 55. Storage System Properties screen

Note: If SnapView is disabled, contact your EMC representative or partner for more information.

In Unisphere select the options Data Protection > Clones. 4.

From the Wizards Menu (Figure 56) select Clone Wizard. 5.



Figure 56. The Wizards menu

The Welcome to the Clone Configuration Wizard screen appears. To continue 6.click Next.

From the Select a Production Server screen select a server that has access to the 7.source LUNs to be cloned, and click Next.

From the Select Storage System screen, select the storage system that contains 8.the source LUNs to be cloned, and click Next.

From the Select the Source LUNs screen (Figure 57), select the source LUNs to 9.be cloned, previously listed in Table 7, and click Next.

Figure 57. Select the Source LUNs screen

From the Select Clone LUN Names screen (Figure 58), you can change the LUN 10.names or use the default names specified for each Clone LUN. For this solution we used the default Clone LUN names.



Figure 58. Select Clone LUN Names screen

In the Storage Pool Configuration screen (Figure 59), select from the available 11.storage pools or create a new storage pool. For this solution we used a previously configured storage pool called Clone_Pool.

Figure 59. Storage Pool Configuration screen

From the Assign Clone to a Server screen, optionally assign the clones to 12.servers, and click Next.

The following warnings (Figure 60) are shown when you attempt to: 13.

a. Assign the clone LUNs to more than one server or

b. Assign the clone LUNs to the same server as the source LUNs.



Figure 60. Warnings from possible errors in clone configuration

For this solution we selected yes as the response, because the ESXi cluster is used to present the LUNs to the required virtual machines.

Review the summary information shown in the Summary screen, and select 14.Finish to create the clones.

Once the results of the Clone Configuration Wizard are displayed, select Finish 15.to close the wizard.

The source LUNs are now displayed in the Source LUNS tab as shown in Figure 16.61.

Figure 61. Source LUNs tab

Select the Clone LUNS tab as shown in Figure 62 to display the clone LUNs 17.status, which is Synchronizing.



Figure 62. Clone LUNs tab

Once all clones display the Synchronized state, as shown in Figure 63, highlight 18.all clones to ensure a consistent fracture, then right-click and select the option Fracture.

Figure 63. Clone fracture process

To confirm and complete a consistent fracture of the clones, from the Confirm 19.Consistent Fracture Clones screen, select Yes.

On the Consistent Fracture Clones screen, click OK. 20.

As shown in Figure 64, all clones are now administratively fractured and 21.available to the assigned servers for testing or backup purposes.

Figure 64. Clone LUNs screen showing consistently fractured LUNs




Appendix B: VNX Snapshot




Snapshot Consistency Group Wizard ....................................................................... 88

Create a snapshot .................................................................................................... 90

Create a snapshot mount point (SMP) ...................................................................... 91

Attach a snapshot .................................................................................................... 93



Snapshot Consistency Group Wizard

For this solution, a single Snapshot consistency group (CG_ORA_RP_SNAP) was configured to take a snap of the Oracle 12c clone LUNs on the DR VNX5500. We created the Snapshot consistency group for Oracle 12c using the following steps:

In the Unisphere login screen, log in as a user with Administrator privileges. 1.

Select the correct system from the Unisphere dashboard. 2.

Confirm the VNX array has VNX Snapshots active by selecting the options 3.System > System Properties > Software as shown in Figure 65.

Figure 65. EMC Unisphere – Software

Note: If VNX Snapshots are disabled, contact your EMC representative or partner for more information.

In Unisphere select the options Data Protection > Snapshots. 4.

Select Create Group to start the wizard that guides in the creation of a Snapshot 5.consistency group, as shown in Figure 66.



Figure 66. EMC Unisphere – Start Consistency Group Wizard

The Welcome to the Create Snapshot Consistency Group Wizard screen appears. 6.To continue click Next.

Type a name for the consistency group (e.g. CG_ORA_RP_SNAP) as shown in 7.Figure 67. To continue click Next.

Figure 67. EMC Unisphere – Consistency Group Name

Highlight all clone LUNs listed in Table 8. To continue click Next as shown in 8.Figure 68.



Figure 68. EMC Unisphere – Consistency Group LUNs

The summary page is displayed. To continue configuring the Snapshot 9.consistency group, click Finish.

To complete the Create Snapshot consistency group wizard, click Finish. 10.

Create a snapshot

Create a snapshot using the snapshot consistency group CG_ORA_RP_SNAP, as follows:

In Unisphere select the options Data Protection > Snapshots 1.

Highlight the snapshot consistency group CG_ORA_RP_SNAP and click Create 2.Snapshot as shown in Figure 69.

Figure 69. EMC Unisphere – Create Snapshots

Type a name for the snap (for example Snap1). Click OK twice. 3.



Figure 70. EMC Unisphere – Snapshot Name

A consistent snap has now been created for the consistency group 4.CG_ORA_RP_SNAP, as shown in Figure 71.

Figure 71. EMC Unisphere – Snap Created

Create a snapshot mount point (SMP)

For this solution we created the SMPs as follows:

In Unisphere select the options Data Protection > Snapshots 1.

Right-click on the first clone Data_dr_0_Clone_1 as shown in Figure 72. 2.



Figure 72. Selecting a clone snapshot

In the Create Snapshot Mount Point screen, type the SMP name and the storage 3.group that needs access to the snapshot, as shown in Figure 73.

Figure 73. Defining a snapshot mount point name in the Create Snapshot Mount Point screen



Click OK, as shown in Figure 74, to create the SMP. 4.

Figure 74. Confirm creating the mount point

Repeat steps 2-4 for each clone LUN shown in Table 8. 5.

Attach a snapshot

Attach the snapshots using the Snapshot consistency group CG_ORA_RP_SNAP as follows:

From the Unisphere dashboard, select the options Data Protection > Snapshots 1.

Collapse the Snapshot consistency group CG_ORA_RP_SNAP. Right-click on the 2.previously created Snap1 and select Attach to start the Attach Wizard, as shown in Figure 75.

Figure 75. Select a snapshot and right-click to reveal the attach menu

In the Select a Server screen (Figure 76): 3.

a. Select the server that will have access to snap1.

b. Type a name for the snapshot copy if you want to protect the point-in-time data of Snap1.

c. To continue, select Next.



Figure 76. The Select a Server screen

Attach the original or the copy snap and select Next. 4.

Review the summary and select Finish. 5.

The results of the Attach Wizard are displayed as shown in Figure 77. All snaps 6.are now available to the selected server.

Figure 77. Results of the Snapshot Attach Wizard

To confirm the snaps are available to the server, previously selected in step 7.Figure 77, in Unisphere select the options Hosts > Host lists.

Highlight the server in the host list and select the Snapshots Mount Point tab. 8.Verify that the Attached Snaps column displays the snap name, as shown in Figure 78.



Figure 78. Confirm snap name




Simplified Oracle RAC 12c Backup, Cloning, and Protection ... · Contents Simplified Oracle RAC 12c...

Documents

Transcript of Simplified Oracle RAC 12c Backup, Cloning, and Protection ... · Contents Simplified Oracle RAC 12c...