Symmetrix Vmax Srdf Timefinder Oracle Database Wp

8/10/2019 Symmetrix Vmax Srdf Timefinder Oracle Database Wp

http://slidepdf.com/reader/full/symmetrix-vmax-srdf-timefinder-oracle-database-wp 1/51

White Paper

Abstract

This white paper introduces EMC® Symmetrix® VMAX™ software and hardware capabilities, andprovides a comprehensive set of best practices andprocedures for high availability and businesscontinuity when deploying Oracle Database 11g withSymmetrix VMAX, VMAX 10K, 20K and 40K. Thisincludes EMC TimeFinder ® and Symmetrix RemoteData Facility (SRDF ® ), which have been widely

deployed with Oracle databases.

August 2013

EMC S YMMETRIX VMAX USING EMCSRDF/TIMEFINDER AND ORACLE 11G



2EMC Symmetrix VMAX Using EMC SRDF/TimeFinder and Oracle 11g

Copyright © 2013 EMC Corporation. All rightsreserved.

EMC believes the information in this publication isaccurate as of its publication date. The information issubject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED“AS IS.” EMC CORPORATION MAKES NO

REPRESENTATIONS OR WARRANTIES OF ANY KIND WITHRESPECT TO THE INFORMATION IN THIS PUBLICATION,AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIESOF MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE.

Use, copying, and distribution of any EMC softwaredescribed in this publication requires an applicablesoftware license.

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

All other trademarks used herein are the property oftheir respective owners.

Part Number h6210.1




Table of Contents

Executive summary ......... ...................................... ...................................... ......... 5

Audience ............................................................................................................................ 6

Introduction ................................................................. ...................................... .. 7

Symmetrix VMAX ease of use, scalability and virtualization features ............................... ... 7

Oracle mission-critical applications require protection strategy ....................... ................... 7

Enterprise protection and compliance using SRDF .................................. ....................... ..... 7

Oracle database clones and snapshots with TimeFinder ..................... ........................ ........ 8

Oracle database recovery using storage consistent replications ...................... ................... 8

Best practices for local and remote Oracle database replications ........................ ............... 8

TimeFinder and SRDF Use Cases for Oracle databases ..................... ....................... ............ 8

Products and features overview .................................................................... ......... 9

Symmetrix VMAX ................................................................................................................ 9

Symmetrix VMAX Auto-Provisioning Groups ........................ ....................... ....................... 10

Fully Automated Storage Tiering (FAST DP)........................................................................ 11

Fully Automated Storage Tiering Virtual Pools (FAST VP) .................. ....................... .......... 11

FAST VP SRDF coordination .............................. ...................................... ............. 12

Symmetrix VMAX TimeFinder product family ...................................... ........................ ....... 13

TimeFinder/Clone and cascaded clones .................... ........................ ....................... .... 14

TimeFinder/Snap and TimeFinder/Snap Recreate ....................... ....................... ........... 15

TimeFinder VP Snap Enginuity 5876 ...................... ....................... ....................... ......... 15

VP Snap Restore to Target (RTT) .................................................................................... 17

TimeFinder Consistent Split .......................................................................................... 18

TimeFinder and SRDF .................................................................................................... 18

Symmetrix VMAX SRDF Overview ...................................................................................... 19

SRDF modes of operation ............................................................................................. 19

SRDF topologies ........................................................................................................... 23

Leveraging TimeFinder and SRDF for data consistency ....................... ....................... .... 26

ASM rebalancing and consistency technology ...................... ....................... ..................... 26

Leveraging TimeFinder and SRDF for business continuity solutions ........................ 28

Database storage layout and best practices ..................................................................... 28

Use Case 1: Offloading database backups from production .................... ....................... ... 31

High-level steps ........................................................................................................... 31

Device groups used ...................................................................................................... 31

Detailed steps .............................................................................................................. 32




Use Case 1a – Using TimeFinder to create local space efficient clones, VPSnap ............................................................................................................................ 34

Use Case 2: Parallel database recovery ............................................................................ 35

High-level steps ........................................................................................................... 35

Device group used ........................................................................................................ 35

Detailed steps .............................................................................................................. 35

Use Case 3: Local restartable replicas of production ...................... ........................ ........... 37

High-level steps ........................................................................................................... 37


Detailed steps .............................................................................................................. 37

Use Case 4: Remote mirroring for disaster protection (synchronous andasynchronous) ................................................................................................................. 38

High-level steps ........................................................................................................... 38


Detailed steps .............................................................................................................. 38

Use Case 5: Remote restartable database replicas for repurposing ........................ ........... 40

High-level steps ........................................................................................................... 40


Detailed steps .............................................................................................................. 40

High-level steps ........................................................................................................... 41


Detailed steps .............................................................................................................. 41

Use Case 7: Parallel database recovery from remote backup replicas ............................... 42

High-level steps ........................................................................................................... 42


Detailed steps .............................................................................................................. 42

Use Case 8: Fast database recovery from a restartable replicas .......................... .............. 44

High-level steps ........................................................................................................... 44


Detailed steps .............................................................................................................. 44

Use Case 8a – Demonstrating fast database recovery using a restartableTimeFinder VP Snap Restore to Target ...................... ........................ ....................... ...... 47

Conclusion ..................................................... ...................................... ............. 49

Appendix: Test storage and database configuration .............................................. 50

General test environment ................................................................................................. 50

Test setup .................................................................................................................... 50

Storage and device specific configuration: .................... ....................... ........................ 50




Executive summary

The EMC® Symmetrix® VMAX™ array is built on the strategy of simple,intelligent, modular storage, using the Virtual Matrix™ architecture thatconnects and shares resources across multiple VMAX engines, allowing thestorage array to seamlessly grow from an entry-level configuration into theworld’s largest storage system. Symmetrix VMAX provides improvedperformance and scalability for demanding enterprise databaseenvironments while maintaining support for EMC’s broad portfolio ofsoftware offerings. With the release of Enginuity 5876, Symmetrix VMAXsystems now deliver new software capabilities that improve ease of use,business continuity, Information Lifecycle Management (ILM), virtualizationof small to large environments, and security.

Symmetrix VMAX arrays are well integrated with Oracle databases and

applications to support their performance needs, scalability, availability,ease of management, and future growth. This white paper describesSymmetrix VMAX software and hardware capabilities, and provides acomprehensive set of best practices and procedures for high availabilityand business continuity when deploying Oracle Database 11g with EMCSymmetrix VMAX. This includes EMC TimeFinder ® and Symmetrix RemoteData Facility (SRDF ® ), which have been widely deployed with Oracledatabases.




Audience

The primary audience of this white paper is database and system

administrators, storage administrators, and system architects who areresponsible for implementing, maintaining, and protecting robustdatabases and storage systems. It is assumed that the readers have somefamiliarity with Oracle database backup aspects and EMC software, and areinterested in achieving higher database availability and protection.




Introduction

Symmetrix VMAX ease of use, scalability and virtualization features

The latest Symmetrix VMAX products provide enhanced performance,scalability, and availability, and Enginuity 5876 supports many ease of use,virtualization, and ILM functionalities. With Symmetrix VMAX Auto- Provisioning Groups , mapping devices to small or large Oracle databaseenvironments becomes fast and easy. Devices, HBA WWNs, or storage portscan be easily added or removed, and automatically these changes arepropagated through the Auto-Provisioning Groups, simplifying complexstorage provisioning for both physical and virtual environments. FullyAutomated Storage Tiering for Virtual Pools (FAST VP) provides real-time,sub-LUN storage management, by storage group, to migrate data to theappropriate storage tier. Enhancements to both TimeFinder and SRDF allowsystem managers choose the best data replication and recovery options at

the lowest cost.

Oracle mission-critical applications require protection strategy

The demand for database protection and availability increases as datagrows in size and, as databases become more interconnected, it isessential to have continuous access to the all databases and applications.Data centers face disasters caused by human errors, hardware/softwarefailures, and natural disasters. When disaster strikes, the organization ismeasured by its ability to resume operations quickly, seamlessly, and withthe minimum amount of data loss. Having a valid backup and restartableimage of the entire information infrastructure greatly helps achieve thedesired level of recovery point objective (RPO), recovery time objective(RTO), and service level agreement (SLA).

Enterprise protection and compliance using SRDF

Data consistency refers to the accuracy and integrity of the data andbetween copies of the data. Symmetrix VMAX offers several solutions forlocal and remote replication of Oracle databases. With SRDF software,single or multiple database mirrors can be created, together with theirexternal data, application files and message queues – all sharing aconsistency group. Replicating data this way creates the point ofconsistency across business units and applications before any disastertakes place. Failover to the DR site is merely a series of application restartoperations that reduce overall complexity and downtime. SRDF providestwo, three, or four-site solutions, with synchronous or asynchronousreplication, as well as a no data loss solution over any distance using

SRDF/Star, cascaded or concurrent SRDF, and SRDF/Extended DistanceProtection (EDP).




Oracle database clones and snapshots with TimeFinder

Every mission-critical system has a need for multiple copies of data, such as

for development, test, backup offload, reporting, data publishing, andmore. With Symmetrix VMAX using TimeFinder software, multiple Oracledatabase copies can be created or restored in a matter of seconds, eitherfull volume clones or snapshots, regardless of the database size. As soonas TimeFinder activates (or restores) a replica, the target device’s data isimmediately available to host, even if data copy operations continue in thebackground. This functionality shortens business recovery timestremendously because there is no need to wait for database reloadoperations. For example, rather than performing backup directly onproduction, it can be offloaded in seconds to a standalone replica. Inanother example, if an Oracle database restore is required, as soon asTimeFinder restore is initiated, database recovery operations can start, andthere is no need to wait for the storage restore to actually complete as

during the background restore operation the Symmetrix services reads forthe tracks not yet copied back from the target devices. This ability, alsoreferred to as parallel restore, provides a huge reduction in RTO andincreases business availability, as compared to traditional tape backup andrestore.

Additionally, in Enginuity 5876, any procedure where you use a traditionalsnap or clone, when using Virtual Provisioning, you now have the option touse a thin provisioned TimeFinder/Clone or a Virtual Provisioned Snap (VPSnap). These options are discussed in more detail later in the paper.

Oracle database recovery using storage consistent replications

In some cases there is a need for extremely fast database recovery, evenwithout failing over to a DR site, especially when only one database out of

many sustained a logical or physical corruption. By implementingTimeFinder consistency technology, periodic database replicas can betaken without placing the Oracle database in hot backup mode. Oracle nowsupports database recovery on a consistent storage replica, applyingarchive and redo logs to recover it (Oracle support is based on Metalinknote 604683.1).

Best practices for local and remote Oracle database replications

This white paper provides an overview of the best practices forimplementing Oracle replication and recovery using EMC TimeFinder andSRDF. Table 1 shows the use cases outlines for Oracle and VMAX toimplement recoverable and restartable local and remote database replicas.

TimeFinder and SRDF Use Cases for Oracle databases

1) Offloading database backups from production to a local traditionalthick TimeFinder/Clone, and then using Oracle Recovery Manager(RMAN) for backup




1(a) This is the same as Use Case 1 but in this example we will createa VP Snap and use it as the source for the RMAN backup

2) Facilitating parallel production database recovery by restoring a localTimeFinder/Clone backup image and applying logs to it

3) Creating local restartable clones or snaps of a database for repurposingsuch as creating test, development, and reporting copies

4) Creating remote mirrors of the production database for disasterprotection, synchronous and asynchronous

5) Creating remote restartable and writeable database clones, or snaps, forrepurposing

6) Creating remote database valid backup and recovery clones or snaps

7) Facilitating parallel production database recovery by restoring remoteTimeFinder/Clone backup images simultaneously with SRDF restore, andthen applying Oracle logs to the production database in parallel

8) Demonstrating rapid database recovery using a restartable TimeFinderreplica

8(a) Same as Use Case 8 using a TimeFinder VP Snap Restore toTarget replica

Products and features overview

Symmetrix VMAX

Symmetrix VMAX is built on the strategy of simple, intelligent, modularstorage, and incorporates the Virtual Matrix interface that connects andshares resources across all VMAX engines, allowing the storage array toseamlessly grow from an entry-level configuration into the world’s largeststorage system. It provides the highest levels of performance andavailability featuring new hardware capabilities, shown in Figure 1.




Figure 1 The Symmetrix VMAX platform

Symmetrix VMAX provides the ultimate scale-out platform. It includes theability to incrementally scale front-end and back-end performance byadding processing engines and storage bays. Each engine provides

additional front-end, memory, and back-end connectivity.Symmetrix VMAX Auto-Provisioning Groups

VMAX Auto-Provisioning Groups provides faster and easier mapping ofdevices for any application environments. Auto-Provisioning groupsprovide simple constructs of host initiator groups, Symmetrix FA portgroups and Symmetrix devices storage groups, and allow binding all ofthem in a masking view to automatically create relationship between hostLUNs, Symmetrix FA ports and host initiators. Any component in themasking view can be dynamically modified and the changes willautomatically propagate throughout the Auto-Provisioning Group, thusimproving and simplifying complex storage provisioning activities.

Figure 2 depicts Symmetrix storage provisioned to two Oracle databases

using Auto-Provisioning Groups.

• 2 – 16 director boards – 8 Engines

• Up to 2.1 PB usable capacity

• Up to 128 FC FE ports

• Up to 64 FICON FE ports

• Up to 64 Gig-E / iSCSI FE ports

• Up to 1 TB global memory (512 GB usable)

• 48 – 2,400 3.5 in., 3200 2.5 in. disk drives

• EFD 3.5” 100/200/400 GB

• FC/SAS drives 300/600 GB 15k/10k rpm

• SATA II drives 2 TB 7.2k rpm

• SAS 2.5” drives 300/600 10k rpm

• FC 2.5” drives 200/300GB EFD eMLC




Figure 3, Evolution of storage tiering

FAST VP SRDF coordination

While the use of FAST VP with SRDF devices is fully supported, FAST VPoperates within a single array and will only operate the RDF devices in thatarray. Since there is no FAST coordination of the data movement betweenRDF pairs, each device's extents will move according to the manner in whichthey are accessed on their array, source (R1) or target (R2).

For instance, an R1 device will typically be subject to a read/write workload,while the R2 will only experience the writes that are propagated across theSRDF link from the R1. Because the reads to the R1 are not propagated tothe R2, FAST VP on the R2 side will make its decisions based solely on the

writes and the R2 data may not be moved to the same tiers, in the sameamounts, as on the R1.

To ensure that the R2 array is always making the best FAST VP decisions,EMC introduced FAST VP SRDF coordination in Enginuity 5876. FAST VPSRDF coordination allows the R1 performance metrics to be transmittedacross the SRDF link and used by the FAST VP engine on the R2 array tomake promotion and demotion decisions. Both arrays involved withreplication must be at Enginuity 5876 to take advantage of this feature.

FAST VP SRDF coordination is enabled or disabled at the storage group levelthat is associated with the FAST VP policy. The default state is disabled.

FAST VP SRDF coordination is supported for single and concurrent SRDFparings (R1 and R11 devices) in any mode of operation: Synchronous,

asynchronous, or adaptive copy. FAST VP SRDF coordination is notsupported for SRDF/Star, SRDF/EDP, or Cascaded SRDF including R21 andR22 devices. See the SRDF Product Guide for additional supportinformation.




Symmetrix VMAX TimeFinder product family

The TimeFinder family of products provides Symmetrix local replicationsolutions designed to non-disruptively create point-in-time copies of criticaldata. You can configure backup sessions, initiate copies, and terminateTimeFinder operations from the Symmetrix CLI or using Unisphere for VMAX.

The TimeFinder local replication solutions include TimeFinder/Clone,TimeFinder/Snap, and TimeFinder VP Snap. TimeFinder/Clone creates full-device and extent-level point-in-time copies. TimeFinder/Snap createspointer-based logical copies that consume less storage space on physicaldrives. TimeFinder VP Snap provides improved cache utilization andsimplified pool management when using Symmetrix Virtual Provisioning.

Each solution guarantees high data availability. The source device is alwaysavailable to production applications. The target device becomes read/writeenabled as soon as you initiate the point-in-time copy. Host applicationscan immediately access the point-in-time image of critical data from thetarget device while TimeFinder copies data in the background.

Choose TimeFinder/Clone if:

• Full-volume copies are intended for recovery scenarios

• Full-volume or extent-level point-in-time copies of production data have to be immediately available to applications for activities such as reporting and

testing

• The majority of data on the production volumes changes between

subsequent backup sessions

•

Multiple copies of production data are needed, and you want to reduce diskcontention and improve data access speed to the production data.

Choose TimeFinder/Snap (Thick Devices) if:

• Only a fraction of data on the production volumes changes between

subsequent backup sessions

• Only a fraction of data on the production volumes frequently changes duringthe peak

• I/O activity window when multiple point-in-time copies are required.

Choose TimeFinder VP Snap if:

• You want to create space-efficient snaps for thin devices

• You want multiple sessions to share capacity allocations within a thin pool,

reducing the storage required for saved tracks.




TimeFinder Snap and Clones have three methods for synchronizing targetvolumes:

1. Precopy, also referred to as background copy, will synchronize source data to thetarget before the target is activated.

2. Copy, the copy process starts when the target is activated and completes when all

the all tracks are copied to the target device.

3. Nocopy, the difference between the copy option and the nocopy option is that thenocopy option does not start the background process upon activation. Like the copyoption, the nocopy process starts with the activation of the TimeFinder session,however the nocopy option will only copy data when triggered by a host I/O.

TimeFinder is well integrated with other EMC products such as SRDF andallows the creation of replicas on a remote target without interrupting thesynchronous or asynchronous replication. If a restore from a remote replicais needed, TimeFinder and SRDF will restore data incrementally and inparallel, to achieve a maximum level of availability and protection. The

TimeFinder product family supports the creation of dependent write-consistent replicas using EMC consistency technology, and replicas that arevalid for Oracle backup/recovery operations, as described later in the usecases.

In Enginuity 5876 EMC introduced FAST VP SRDF coordination which allowsthe R1 performance metrics to be transmitted across the SRDF link and usedby the FAST VP engine on the R2 array to make promotion and demotiondecisions. Both arrays involved with replication must be at Enginuity 5876to take advantage of this feature.

FAST VP SRDF coordination is enabled or disabled at the storage group thatis associated with the FAST VP policy. The default state is disabled.

TimeFinder/Clone and cascaded clones

TimeFinder/Clone provides the ability to create, refresh, or restore multiplefull volume copies of the source volumes and after the first fullsynchronization, only incremental changes are passed between source andtarget devices. TimeFinder/Clone operations can have any combination ofthick or thin provisioned devices as source or target devices, making itextremely flexible for both local and remote replication. TimeFinder/Clonecan scale to thousands of devices and can create up to 16 targets to eachsource device. TimeFinder always presents the final copied imageimmediately on its target devices (when creating a replica) or sourcedevices (when restoring it), even if background copy operations are still inprogress. This allows the application to immediately use the TimeFinder

devices. For example, during TimeFinder restore of a valid database backupimage, Oracle roll forward recovery can start in parallel, reducing RTO.




The Cascaded clones feature provides the ability to perform additionalclone operations on a clone target without losing the incremental nature ofthe original source to target relationships. This is useful when the first clonetarget is a ‘gold copy’ backup image and additional replicas are required offit for purposes such as backup, reporting, publishing, test/dev, and so on.

TimeFinder/Snap and TimeFinder/Snap Recreate

TimeFinder/Snap software allows users to create, refresh, or restoremultiple read/writeable, space-saving copies of data. TimeFinder/Snapallows data to be copied from each source device to as many as 128 targetdevices where the source devices can be either a STD device or a BCV andthe target devices are Symmetrix thick (STD) or thin provisioned devices(Thin) that consume negligible physical storage through the use of pointersto track changed data.

Any update to source target devices after the snap session was activated

causes the pre-updated data to be copied in the background to adesignated virtual storage pool. The virtual device’s pointer is then updatedto that location. Any subsequent updates after the first data modificationwon’t require any further background copy. Since copy operations happenin the background, using a feature called Asynchronous Copy on First Write(ACOFW), performance overhead of using TimeFinder/Snap is minimal.

TimeFinder/Snap Recreate provides the ability to very quickly refreshTimeFinder snapshots. Previously it was necessary to terminate an oldersnap session in order to create a new one. The TimeFinder recreatecommand simplifies the process to refresh old snaps without having todescribe the source and target devices relationships again.

TimeFinder VP Snap Enginuity 5876

TimeFinder VP Snap allows multiple sessions to share capacity allocationswithin a thin pool, reducing the storage required for saved tracks.TimeFinder VP Snap is available with Enginuity 5876 and Solutions EnablerV7.4 and higher, and is designed to create point-in-time replicas that areconceptually similar to those created by TF/Snap. Unlike traditionalSnaps/Clones, for VP Snaps, both the source and target devices must bethin devices. For VP Snaps all the source data and any copied data willreside in one or more thin pools. VP Snap sessions are unique because thethin pool allocations can be shared amongst target devices. For example,source updates that are new to multiple point-in-time copies are saved in asingle set of allocations that are shared by two or more target devices.When data is copied to more than one target, only a single shared copy ofthe data resides in the virtual pool, which provides cost-effective space

savings. TF/VP Snap targets can optionally use the source thin pool. TF/VPSnap is depicted in Figure 4.




Figure 4, TF/VP Snap

As shown above in Figure 4, when a TF/VP Snap session for 100 GB sourcedevice is created to a thin target device, no thin pool storage allocation isrequired for the target device. The thin target device uses a pointer basedtechnique to indirectly access data using the extent pointers of the sourcedevice. In this case, if the source volume had 100GB of allocated thin poolspace at the time of the VP Snap, thin pool allocated space would remain at100GB. Likewise, if additional VP Snaps are made total pool allocationwould remain at just 100GB. In contrast, a traditional 100GB thick clonewith 3 cascaded clones would require 400GB of allocated storage capacity.When a VP Snap session is activated a read request to the source device, orany of the activated snaps, will be satisfied by reading the original extent ofthe source volume.

When a protected track on the source device is modified the original thinpool extent will be copied to the target thin pool, and any active target snapsessions to which this data is newer will share the thin pool extent.

In the event of write to a target device extent that is shared only that extentwill cease to remain in shared group and additional allocation in target thinpool will take place for that extent. Only one shared copy exists for multipletarget snaps.

Because space allocated in the thin pool does not grow with respect to thenumber of snaps created but only based on the writes to protected thin poolextents on source and/target devices, TF/VP Snap allows all the functionstraditionally offered by full copy TF/Clone just with excellent storageefficiency. TF/VP Snap also greatly reduces the cache impact during

traditional TF/Clone operations allowing many copies of the source devicesfor a variety of use cases like backup, repurposing or reporting use cases.




VP Snap Restore to Target RTT)

TimeFinder Restore to Target functionality has been enhanced with

Enginuity 5876 Q4 2012 SR. Restore to Target (RTT) allows users to performan incremental restore to a cascaded clone target. VP Snap Restore toTarget permits devices in A (Source) B (Full-Copy Clone target) C (VPSnap target) cascaded VP Snap sessions to copy data from device C todevice A, by way of device B. The RTT feature can be used in any applicationuse case where any type of clone can be used. If the A copy is theproduction database and the B copy is a full copy clone, we could make a‘gold’ copy VP Snap BC at midnight and make no further copies from BCduring the normal production day. During the production day we couldmake incremental clones from AB on an hourly basis to provide finergrain recovery than having to revert to midnight VP Snap C. However, if wehave a case where hourly clone is not usable we are now able to restore Bfrom C and then A from B, to restore the gold copy VP Snap back to the

production device.For devices A B C in a cascaded VP Snap session, where the AB legis a clone, and the BC leg is a VP Snap session, the followingconsiderations apply:

• If the AB leg is in the copied or split state, and the BC leg is inthe copy-on-write or copied state, an incremental restore to B from Cis allowed.

Following the restore, the target device is Not Ready (NR).

• If the AB leg is in the copied or split state, and BC leg is in therestored state, an AB incremental restore is allowed.

Once both the AB and the BC sessions are restored, the only operation

allowed on A

B is terminate, unless or until the B

C persistent restoresession is terminated first.

The following graphic depicts TimeFinder Restore to Target functionality.




Figure 5, VP Snap Restore to Target RTT)

TimeFinder Consistent Split

With TimeFinder you can use the Enginuity Consistency Assist (ECA) featureto perform consistent splits between source and target device pairs acrossmultiple, heterogeneous hosts. Consistent split (which is animplementation of instant split) helps to avoid inconsistencies and restartproblems that can occur if you split database-related devices without firstquiescing the database. The difference between a normal instant split and aconsistent split is that when using consistent split on a group of devices,the database writes are held at the storage level momentarily while theforeground split occurs, maintaining dependent-write order consistency onthe target devices comprising the group. Since the foreground instant splitcompletes in just a few seconds, Oracle needs to be in hot backup modeonly for this short time when hot backup is used. When consistent splitalone is used to create a restartable replica, interference with businessoperations is minimal.

TimeFinder target devices, after performing a consistent split, are in a statethat is equivalent to the state a database would be in after a power failure,or if all database instances were aborted simultaneously. This is a state thatis well known to Oracle and it can recover easily from it by performing acrash recovery the next time the database instance is started.

TimeFinder and SRDF

TimeFinder and SRDF products are closely integrated. In fact, it is alwaysrecommended to use SRDF in conjunction with remote TimeFinder to allow

remote copies utilizing the target hardware resources without interruptingthe SRDF replications. Also the remote copies can serve as a gold copywhenever an SRDF target needs to be refreshed. As an example, a remoteTimeFinder/Clone can be created from the SRDF R2 devices, and many




additional snaps can be created out of that clone for test, development, andreporting instances. When SRDF/A is used any remote TimeFinder operationshould use the consistent split feature to coordinate the replica withSRDF/A cycle switching. The use cases in this paper illustrate some of thebasic Oracle business continuity operations that TimeFinder and SRDF canperform together.

Symmetrix VMAX SRDF Overview

Symmetrix Remote Data Facility (SRDF) is a Symmetrix-based businesscontinuance and disaster restart solution. In simplest terms, the purpose ofSRDF is to maintain real-time copies of host devices in more than onephysical Symmetrix. The Symmetrix units can be in the same room, indifferent buildings within the same campus, or hundreds of miles apart.SRDF provides data mobility and disaster restart spanning multiple hostplatforms, operating systems, and applications. It can scale to thousands ofdevices, can replicate while maintaining write-order consistency frommultiple source arrays to multiple target arrays, and can support a variety oftopologies and configurations, including support for FAST VP and SRDFCoordination.

The local SRDF device, known as the source (R1) device, is configured in apairing relationship with a remote target (R2) device, forming an SRDF pair.When the R2 devices are mirrored with R1 devices, the R2 devices are write-disabled to the remote host. After the R2 devices are synchronized with itsR1 devices, they can be split at any time, making the R2 devices fullyaccessible to their hosts. The R2 device can be either used directly by hosts,once they are split, or can be restored incrementally to the R1 devices.TimeFinder replicas can be taken from the R2 devices even while SRDF isreplicating, without disturbing the R1 to R2 relationship.

Many other new performance and scalability features were added to SRDFwith Enginuity release 5876, including a new protection mode calledSRDF/Extended Distance Protection (SRDF/EDP). Please refer to the SRDFproduct guide for a full description.

SRDF modes of operation

SRDF/Synchronous (SRDF/S), SRDF/Asynchronous (SRDF/A), and SRDFAdaptive Copy are the basic operation modes of SRDF. The first two are validfor Oracle database protection and maintain dependent write-orderconsistency. The third is useful for bulk data transfers or in combinationwith more complex SRDF solutions such as SRDF/Automated Replication(SRDF/AR)

SRDF/Synchronous mode

SRDF/S is used to create a no data loss solution of committed transactions.It provides the ability to replicate multiple databases and applications data




remotely while guaranteeing the data on both the source and target devicesis exactly the same. SRDF/S can protect single or multiple source Symmetrixstorage arrays with synchronous replication.

With SRDF/S Synchronous replication, shown in Figure 6, each I/O from thelocal host to the source R1 devices is first written to the local Symmetrixcache (1) and then it is sent over the SRDF links to the remote Symmetrixunit (2). Once the remote Symmetrix unit acknowledged it received the I/Oin its cache successfully (3), the I/O is acknowledged to the local host (4).Synchronous mode guarantees that the remote image is an exactduplication of the source R1 device’s data.

Figure 6, SRDF/Synchronous replication

SRDF/Asynchronous replication mode

SRDF/Asynchronous (SRDF/A) provides a consistent point-in-time image onthe target (R2) devices that is only slightly behind the source (R1) devices.SRDF/A allows replication over unlimited distance, with minimum to noeffect on the performance of the local production database(s). SRDF/A can“ride” through workload peaks by utilizing the local Symmetrix cache and

optionally spilling data to a disk pool (also called delta set extension, orDSE) and reducing the link bandwidth requirements.

SRDF/A session data is transferred to the remote Symmetrix array in timedcycles, also called delta sets, as illustrated in Figure 7. There are threecycles that work in unison – the capture cycle receives all new I/O from thehosts, the transmit/receive cycles on the R1 and R2, respectively, send andreceive the previous captured cycle until it is fully received, and the applycycle applies a previously fully received cycle to the R2 devices.

The SRDF/A cycle switching process is very efficient and scalable. Within acapture cycle if a piece of data is updated multiple times only the mostrecent update to the data is transmitted once. This process is called writefolding. Also, there is no need to maintain write consistency of each I/O.Instead, consistency is maintained between cycles. If replication stops forany reason SRDF will make sure to either apply a fully received cycle to thetarget R2 devices, or discard the last incomplete cycle. This leaves theremote R2 devices always only one or two cycles behind the R1 devices.

RDF links

Source Target

2

4

13

Production

Database




While the default minimum cycle switching time is 30 seconds, it can growduring peak workload, and shrink back to default afterward.

Figure 7, SRDF/Asynchronous replication

SRDF/A Consistency Exempt

Enginuity has the ability to add or remove devices from an SRDF/A sessionwithout breaking the session consistency to perform that operation. Whendynamic SRDF devices are added the consistency exempt flag is set,allowing them to synchronize without interrupting the consistencyattributes of the other devices in the SRDF/A session. After they are in syncfor two cycles the flag will be automatically removed, allowing them to jointhe session consistency attributes. When devices are suspended theconsistency exempt flag will be automatically set, thus allowing them to beremoved without interrupting the SRDF session consistency. These new andflexible abilities enhance database protection and availability.

SRDF/A Multi-Session Consistency

Like SRDF/S, SRDF/A can replicate from multiple source arrays to multipletarget arrays while maintaining write-order consistency between cycles.When dependent write consistently across multiple Symmetrix arrays isrequired, the SRDF/A Multi-Session Consistency (MSC) option is used andthe coordination of cycle switching across the arrays is performed with theassistance of SRDF redundant host daemons. The daemons merely wait forready conditions on all the arrays and then send the switch cycle command,keeping communication light and efficient. Similar to TimeFinder consistentsplit, also when SRDF/A MSC is used there is a brief hold of write I/O on allthe arrays simultaneously during cycle switch to preserve write-orderconsistency.

SRDF Adaptive Copy replication mode

SRDF Adaptive Copy replication facilitates long-distance data sharing andmigration (see Figure 8). SRDF Adaptive Copy replication allows the primary

Source Target

1

ProductionDatabase

Transmit Receive

Capture SRDF links

App ly

R2R1

2




and secondary volumes to be more than one I/O out of synchronization. Themaximum number of I/Os that can be out of synchronization is known asthe maximum skew value, and can be set using SRDF monitoring andcontrol software. There is no attempt to preserve the ordering of write I/Oswhen using SRDF Adaptive Copy replication.

Figure 8, SRDF Adaptive Copy mode

SRDF Adaptive Copy replication is useful as an interim step before changingto an Oracle-supported SRDF/S or SRDF/A replication. It is also used forpoint-in-time long-distance bulk transfer of data. For example, if theconnection between the two sides is lost for a long period of time allowingthe buildup of a large number of changes to accumulate, resumption of thelinks can cause a heavy surge in link traffic (created by the backlog ofchanges added to those generated by normal production traffic). By usingSRDF Adaptive Copy replication, the backlog of invalid tracks is synchronizedusing the SRDF low priority queue, while new writes are buffered in cacheand sent across using the high priority SRDF queue without impacting thehost application. Once the backlog of changes has been transferred, or thetotal amount of changed tracks has reached a specified number, the mode

can be changed to SRDF/S or SRDF/A replication to achieve databaseprotection.

SRDF Adaptive Copy replication is not supported for database restart or database

recovery solutions with Oracle databases. Using SRDF Adaptive Copy replication by

itself for disaster protection of Oracle databases will lead to a corrupt and unusable

remote database.

RDF links

Source Target

3

2

14

Production

Database




SRDF topologies

SRDF can be set in many topologies other than the single SRDF source and

target. Thus SRDF satisfies different needs for high availability and disasterrestart. It can use a single target or two concurrent targets; it can provide acombination of synchronous and asynchronous replications; it can providea three-site solution that allows no data loss over very long distances andmore. Some of the basic topologies that can be used with SRDF are shownin the following section1.

Concurrent SRDF

SRDF allows simultaneous replication of single R1 source devices to up totwo target devices using multiple SRDF links. All SRDF links can operate ineither Synchronous or Asynchronous mode or one or more links can utilizeAdaptive Copy mode for efficient utilization of available bandwidth on thatlink. This topology allows simultaneous data protection over short and long

distances.

Figure 9, Concurrent SRDF

Cascaded SRDF

SRDF allows cascaded configurations in which data is propagated from oneSymmetrix to the next. This configuration requires Synchronous mode forthe first SRDF leg and Asynchronous or Adaptive Copy modes for the next.This topology provides remote replications over greater distances withvarying degree of bandwidth utilization and none to limited data loss(depends on the choice of SRDF modes and disaster type).

1 For full coverage of SRDF topologies, please refer to SRDF product guide.

Source

Target

SRDF/S

Target

SRDF/A




Figure 10, Cascaded SRDF

SRDF/Extended Distance Protection

SRDF currently supports multi-site replications in cascaded SRDF

configuration. This feature is enhanced to support a more efficient two-siteDR solution over extended distances with zero or near zero data loss. In thisconfiguration the storage cache alone is used on the intermediate site for atemporary pass-through data store of the modified tracks before copyingthem over to the tertiary site. SRDF/S and Adaptive Copy are allowedbetween primary and secondary sites. SRDF/A and Adaptive Copy areavailable between secondary and tertiary sites.

Figure 11, SRDF/Extended Distance Protection

The major benefits of this configuration are:

• New long-distance replication solution with the ability to achievezero RPO at the target site

• A lower-cost alternative in which to achieve no data loss for target

site disaster restart

SRDF/S SRDF/A

Site A Site B Site C

SRDF/S SRDF/A

Production

Site

Pass-through

SiteTarget




SRDF/Star

SRDF/Star is a two- or three-site protection topology where data is

replicated from source Site A to two other Symmetrix systemssimultaneously (Site B and Site C). The data remains protected even in caseone target site (B or C) goes down. If site A (the primary site) goes down, thecustomer can choose where to come up (site B or C) based on SRDF/Starinformation. If the storage data in the other surviving site is more currentthen changes will be incrementally sent to the surviving site that will comeup. For protection and compliance, remote replications can startimmediately to the new DR site. For example, if database operations resumein Site C, data will be sent first from Site B to create a no data loss solution,and then Site B will become the new DR target. SRDF/Star has a lot offlexibility and can change modes and topology to achieve best protectionwith each disaster scenario. For full description of the product refer to theSRDF product guide.

Figure 12, SRDF/Star

Four-site SRDF solution

The four-site SRDF solution replicates data by using both concurrent andcascaded SRDF topologies. It is a multi-region disaster recovery solutionwith higher availability, improved protection, and limited downtime thanthe individual concurrent or cascaded SRDF solution.

The four-site SRDF can also be used for data migration Figure 13 shows anexample of the four-site SRDF solution. If two sites fail because of a regional

disaster, the copy of the data is available and you can continue to haveprotection between the remaining two sites. You can configure a four-siteSRDF topology from an existing two-site or three-site SRDF topology.

Site A

Site C

SRDF/S

Site B

SRDF/A




Leveraging TimeFinder and SRDF for data consistency

EMC TimeFinder and SRDF solutions with Enginuity Consistency Assist (ECAconsistent split) allow creation of dependent write-order consistent storage-based replicas. The replicas are created by temporarily holding write I/Os toall source devices included in the replica. Since all writes are held, nodependent writes can be issued (as they depend on a previous completionof the held I/O). For example, Oracle will not write to data files (checkpoint)until the redo writes for these data changes were fully recorded in the logfiles.

SRDF/S and SRDF/A modes ensure the dependent write-order consistencyof the replication by synchronizing each and every dependent I/O (SRDF/Smode) or by synchronizing across cycles of transferred data (SRDF/A mode).

In an actual disaster that leads to the loss of source location, databaserestart operations can be completed at the remote location without thedelays associated with finding and applying recovery across applications inthe correct sequence or to a coordinated time before the failure.

In addition to disaster restart benefits, SRDF significantly enhances disasterrecovery operations by using fast and reliable replication technology tooffload the Oracle backup operations to a remote site and later return therestored data to the local site as shown in the use cases section.

ASM rebalancing and consistency technology

ASM provides a seamless and nonintrusive mechanism to expand andshrink the diskgroup storage. When disk storage is added or removed, ASMwill perform a redistribution (rebalancing) of the striped data2. This entire

rebalance operation is done while the database is online, thus providinghigher availability to the database. The main objective of the rebalance

2 A disk failure will also trigger a rebalance; however, this is specific to ASM failure groups.

Figure 13 Four-site SRDF




operation is to always provide an even distribution of file extents, workload,and data protection across all disks in the diskgroup.

With Symmetrix arrays as the storage, it is considered a best practice to useASM external redundancy for data protection. The Symmetrix RAIDprotection will be utilized to provide RAID 1, RAID 5, or RAID 6 internal diskprotection.

The split operation of storage-based replicas is sensitive to the rebalancingprocess, which may cause ASM diskgroup inconsistencies if the diskgroupdevice members are split at slightly different times. These inconsistenciesare a result of possible ASM metadata changes occurring while a splitoperation is in process. Upon startup if ASM detects an inconsistency,metadata logs will be used to perform ASM instance recovery. In additionOracle provides tools and procedural steps to avoid inconsistencies whensplitting storage-based replicas; however, these procedures can besimplified and streamlined with the use of EMC consistency technology.

Since EMC consistent split technology suspends database I/O to preservewrite ordering, it also has the side effect of preventing any ASM metadatachanges during the split. Performing a consistent split will prevent ASMmetadata inconsistencies during the replication process, eliminating theotherwise extra steps or possible unusable replica if ASM rebalance wasactive while performing a non-consistent split.




Leveraging TimeFinder and SRDF for business continuity

solutions

Database storage layout and best practices

ASM and Solutions Enabler device planning

Table 2 shows the RAC database and Symmetrix device layout that wasused in the use cases. All the devices (LUNs) were 50 GB in size and thedatabase actual size was about 400 GB.

Table 1, ASM diskgroups, and Symmetrix device and composite groups

ASM

diskgroups

Database

devices

Recovery

Device

Groups DG)

Restart

Device

Groups DG)

SRDF

Consistency

Group CG)

+DATA 18 LUNs x 50 GB DATA_DG DB_DG ALL_CG+REDO 4 LUNs x 50 GB REDO_DG+FRA 3 LUNs x 50 GB FRA_DG

The database primary devices (also TimeFinder and SRDF source devices)were using Symmetrix RAID 1 protection. TimeFinder/Clone targets wereusing RAID 5 protection to improve storage utilization. SRDF target devicesalso used RAID 1 to match the same protection level as the primarydatabase devices.

ASM general best practices

3

ASM was using external redundancy (no software mirroring) in accordancewith EMC’s recommendation of leveraging the Symmetrix array RAID

protection instead.

ASM was set with three diskgroups: +REDO (redo logs), +DATA (data,control, temp files), and +FRA (archives, Fast Recovery Area). Typically EMCrecommends separating logs from data for performance monitoring andbackup offload reasons. When SRDF is used, temp files can go to their own“+TEMP” diskgroup if replication bandwidth is limited as temp is notrequired for database restart or recovery. In these use cases, however, SRDFFC bandwidth was not an issue and temp files were included in the +DATAdiskgroup. Finally, +FRA can typically use a lower-cost storage tier like SATAdrives and therefore require their own diskgroup.

TimeFinder best practices

Multiple Symmetrix device groups were used for TimeFinder/Clone (snap orVP Snap) operations, allowing finer granularity of operations. For recovery

3 These ASM best practices can easily be applied to other volume managers, filesystems, or raw devices.




solutions, data files (together with control files), REDO log files, and archivelogs each had their own DG, allowing the replica of each to take place atslightly different times as shown in the recovery use cases. For example, if avalid datafile’s backup replica should be restored to production, and theproduction logs are intact, by separating the datafiles and archived logs totheir own DG and ASM diskgroups, such a restore won’t compromise theavailable archived logs and full database recovery would be possible. For arestart solution, a single DG was used that includes all data (control) andlog files, allowing them to be split consistently creating a restartable andconsistent replica.

Note that TimeFinder operations can span Symmetrix arrays. When that isthe case instead of a device group (DG) a composite group (CG) should beused, following the exact same best practices as shown for the DG in thispaper.

It is recommended to issue TimeFinder and SRDF commands from a

management (or the target) host and not the database production host. Thereason is that in rare cases when consistent split is used, under heavy writeactivity Symmetrix management commands may be queued behinddatabase writes, interfering with completing the replication and the replicawill be deemed invalid.

It is recommended to use Symmetrix Generic Name Services (GNS) andallow them to be replicated to the SRDF targets. GNS manages all the DGand CG definitions in the array and can replicate them to the SRDF target sothe management host issuing TimeFinder and SRDF commands will be ableto operate on the same CG and DG as the source (without having to re-create them).

For the sake of simplicity the use cases assume that GNS is used and

replicated remotely. When remote TimeFinder or SRDF operations are used,they are issued on the target host. It is also possible to issue remoteTimeFinder and SRDF commands from the local management host using the–rdf flag; however it requires the SRDF links to be functional.

Note that remote TimeFinder replica creation from an SRDF/A target shouldalways use the –consistent flag to coordinate SRDF/A cycle switching withthe TimeFinder operation and simply put, guarantee that the replica isconsistent.

SRDF best practices

SRDF, whether synchronous or asynchronous, should always use acomposite group (CG) with consistency enabled (also called a consistencygroup). While enabling consistency is a requirement for SRDF/A, it is a

common misconception that SRDF/S being a synchronous replicationdoesn’t benefit from it. However SRDF/S with consistency enabled willguarantee that if even a single source device can’t replicate to its target, all




the SRDF devices in that session will stop replicating, preserving the targetconsistent image.

For SRDF replications a single CG was used that included all the databasedevices (data, control and REDO log files). As shown in Table 1 it alsoincluded the FRA devices. SRDF on its own is a restart solution and sincedatabase crash recovery never uses archive logs there is no need to includeFRA in the SRDF replications. However there are two reasons why they couldbe included. The first is if Flashback database functionality is required forthe target. Replicating the FRA (and the Fast recovery area) in the sameconsistency group with the rest of the database allows its usage on thetarget of flashback functionality. The second reason is that to allow offloadof backup images remotely, the archive logs are required (as shown in UseCase 6 on page 9 .

It is always recommended to have a clone copy available at the SRDF targetas a gold copy protection from rolling disasters . Rolling disasters is a term

used when a first interruption to normal replication activities is followed bya secondary database failure on the source, leaving the database withoutan immediately available valid replica. For example, if SRDF replication wasinterrupted for any reason for a while (planned or unplanned) and changeswere accumulated on the source, once the synchronization resumes anduntil the target is synchronized (SRDF/S) or consistent (SRDF/A), the targetis not a valid database image. For that reason it is best practice before suchresynchronization to take a TimeFinder gold copy replica at the target site,which will preserve the last valid image of the database, as a protectionfrom rolling disasters.

While the source database was clustered, since Oracle RAC is based on ashared storage architecture, by virtue of replicating all the databasecomponents (data, log, and control files) the target database has the option

of being started in cluster, or non-clustered mode. Regardless of the choice,it is not recommended to replicate the cluster layer (voting disks or clusterconfiguration devices) since these contain local hosts and subnetsinformation. It is best practice that if a cluster layer is required at the targethosts, it should be configured ahead of time, based on target hostnamesand subnets, and therefore be ready to bring up the database whenever thetime comes.




Use Case 1: Offloading database backups from production

This use case illustrates how to offload database backups from production

to a local TimeFinder/Clone, and then using Oracle RMAN to perform furtherbackup.

While the Oracle database is in hot backup mode on the production host, aTimeFinder/Clone activate is performed to create a recoverable replica ofthe database. This is a valid backup image that can be used to performquick recovery of the Oracle database. The image can also be mounted toanother host for RMAN backups.

The sample CLI commands shown below use both the –range option andthe –f (file) option to show the different ways the commands can beimplemented.

High-level steps

1. Place the database in hot backup mode.

2. Activate the DATA_DG clone (with –consistent since ASM is used).

3. End hot backup mode.

4. Archive the current log.

5. Copy two backup control files to the FRA ASM diskgroup.

6. Activate the ARCHIVE_DG clone (with –consistent since ASM is used).

7. Optionally mount the clone devices on a backup host and perform RMAN backup.

Device groups used

DATA_DG and ARCH_DG

# symdg cr eat e DATA_DG# symdg cr eat e ARCH_DG# syml d –g DATA_DG addal l –r ange 0300: 0303# syml d –g DATA_DG addal l –r ange 0310: 0313 - t gt# syml d –g ARCH_DG addal l –r ange 0330: 0331# syml d –g ARCH_DG addal l –r ange 0340: 0341 –t gtCreate txt file to pair Source and TGT devices –

DATA_PAIRS.txt

0300 03100301 03110302 03120303 0313# symcl one –f DATA_PAI RS. t xt cr eat e –copy - di f f - nopCreate txt file to pair Source and TGT devices –

ARCH_PAIRS.txt

0330 03400331 0341# symcl one –f ARCH_PAI RS. t xt cr eat e –copy –di f f - nop




Detailed steps

On the production host

1. Place the production database in hot backup mode.

# expor t ORACLE_SI D=RACDB1# sql pl us “/ as sysdba”SQL> al t er dat abase begi n backup;

2. Activate the TimeFinder/Clone DATA_DG replica. The clone replica includes dataand control files. Use –consistent with ASM or filesystems.

# symcl one –dg DATA_DG –t gt - consi st ent act i vat e


SQL> al t er dat abase end backup;

4. Switch logs and archive the current log file.

SQL> al t er syst em ar chi ve l og cur r ent ;

5. Create two backup control files and place them in the FRA diskgroup forconvenience (RMAN syntax is shown, although SQL can be used as well). One willbe used to mount the database for RMAN backup; the other will be saved withthe backup set.

RMAN>r un {al l ocat e channel ct l _f i l e t ype di sk;

copy cur r ent cont r ol f i l e t o‘ +FRA/ cont ro l _ f i l e/ cont ro l _start ’ ;copy cur r ent cont r ol f i l e t o‘ +FRA/ cont r ol _f i l e/ cont r ol _bakup’ ;r el ease channel ct l _f i l e;}

6. Activate the TimeFinder/Clone ARCHIVE_DG replica. The clone replica includesthe archive logs and backup control files. Use –consistent with ASM orfilesystems. If RMAN Catalog is used synchronize it first to register the mostrecent archive logs.

RMAN>r esync cat al og;

# symcl one –g ARCH_DG –t gt –consi st ent act i vate

On the backup host

The database replica can be used as a valid disk backup or as a source for

backup to a tertiary media such as tape or a disk library. In this exampleRMAN will be used to perform the backup.

Target/Backup host prerequisites:

Comment [E1]: All these ASM operadone differently now. I will provide propcommands.




The ASM devices (or partitions) on clone volumes have correct Oracle permissions.

The ASM_DISKSTRING parameter in the init.ora file for the ASM instance includes the

path to clone volumes.The ASM_DISKGROUPS parameter in the init.ora file for the ASM instance contains thenames of the production database diskgroups.

It is not necessary to have the database mounted as RAC. Prior to mounting thedatabase comment out, update ASM and database instance init.ora parameters asnecessary. Specifically change CLUSTER_DATABASE to false if clustered mode is notneeded. If the database is to be started in clustered mode then the cluster layer (andsoftware) should already be installed and configured on the target host (notreplicated with TimeFinder or SRDF)

7. (Continuing from step 6 on the previous page) Start the ASM instance. If othervolume managers or filesystems are used their appropriate import and mountcommands will be used instead. Make sure all the diskgroups were mounted

correctly by ASM.# expor t ORACLE_SI D=+ASM# crsct l start resour ce - al l

8. Mount the database instance. A database backup that was taken with hot backupmode is valid for recovery only as long as it has not been opened read-writeable(with the resetlogs option). For that reason, it should be only mounted, which is theminimum prerequisite for RMAN backup. It can also be opened in read-only modeafter enough archive logs are applied to resolve any data files’ fuzziness. Beforestarting the database in mount mode, change the CONTROL_FILES in the init.ora fileto point to the backup control file.

cont r ol _f i l es = +FRA/ cont r ol _f i l e/ cont r ol _star t

# expor t ORACLE_SI D=CLONE_DB# sql pl us “/ as sysdba”SQL> st ar t up mount

9. Back up the database with RMAN from the backup host. The control file copy thatwas not used to mount the instance ( control_bak ) should be part of the backup set.The control_start file should not be backed up because the SCN will be updatedwhen the database is mounted for backup.

RMAN>r un {al l ocat e channel t 1 t ype di sk;backup f ormat ‘ ct l %d%s%p%t ’

cont r ol f i l ecopy ‘ +FRA/ cont r ol _f i l e/ cont r ol _bak’ ;backup f ul l f ormat ‘ db%d%s%p%t ’ dat abase;backup f ormat ‘ al %d%s%p%t ’ archi vel og al l ;r el ease channel t 1;

}

Note: The format specifier %d is for date, %t for 4-byte timestamp, %s forbackup set number, and %p for the backup piece number




Use Case 1a – Using TimeFinder to create local space efficient clones, VP

Snap

The following general process could be used in conjunction with the Oracleprocedures, previously documented in Use Case 1, to make a copy of theactive database using VP Snap. Assuming all the LUNs in the DATA_DG andARCH_DG are thin devices, there is very little difference between theprocess to create thick or thin clones. The main difference betweentraditional clone and VP Snap is the use of the ‘Virtual Space Efficient’option <-vse> of the ‘symmclone create’ command. The –vse option issimilar to the –nocopy option used on standard clones, except for –vseclones data is only copied when there is a write to the source or any of theactivated VP Snaps.

# symdg cr eat e DATA_DG# symdg cr eat e ARCH_DG# syml d –g DATA_DG addal l –r ange 0300: 0303# syml d –g DATA_DG addal l –r ange 0310: 0313 - t gt# syml d –g ARCH_DG addal l –r ange 0330: 0331# syml d –g ARCH_DG addal l –r ange 0340: 0341 –t gtCreate txt file to pair Source and TGT devices –

DATA_PAIRS.txt

0300 03100301 03110302 03120303 0313

# symcl one –f DATA_PAI RS. t xt cr eat e –vse - di f f - nopCreate txt file to pair Source and TGT devices –

ARCH_PAIRS.txt

0330 03400331 0341# symcl one –f ARCH_PAI RS. t xt cr eat e –vse –di f f - nop

The remaining steps are identical to those detailed in Use Case 1.




DATA_DG (with data and controlfiles) is restored.

As soon as the restore starts it is possible to continue with the next step. Howevermake sure to split the clone replica at a later time when the background restorecompleted. Note that TimeFinder restore protects the replica from changes to thesource devices.

# symcl one –dg DATA_DG –t gt r est ore [ –f orce]# symcl one –dg DATA_DG –t gt spl i t

3. Start the ASM instance (follow the same activities as in Use Case 1, step 7).

4. Mount the database (follow the same activities as in Use Case 1, step 8).

5. Recover and open the production database. Use resetlogs if incomplete recoverywas performed.

# expor t ORACLE_SI D=RACDB1# sql pl us “/ as sysdba”SQL> st ar t up mountSQL> r ecover aut omat i c database usi ng backup cont r ol f i l eunt i l cancel ;SQL> al t er dat abase open;




Use Case 3: Local restartable replicas of production

This use case illustrates how to create local restartable clones (or snaps) of

production for database repurposing, such as creating test, development,and reporting copies.

While the Oracle database is running transactions on the production host,without the use of hot backup mode activate a consistent TimeFinder/Clonesession to create a restartable replica of the database. The replica can bemounted to another host for purposes such as test, dev, reporting, and soon. Mounting multiple replicas of the same database on the same host ispossible; however that topic is beyond the scope of this paper.

High-level steps

1. Activate the DB_DG clone (with –consistent to create restartable replica).

2. Start the ASM instance.

3. Start the database instance.

4. Optionally, refresh the clone replica from production at a later time.

Device group used

DB_DG

Detailed steps

On the target host

1. Activate the TimeFinder/Clone DB_DG replica. The clone replica includes all data,control, and log files. Use –consistent to make sure the replica maintainsdependent write consistency and therefore a valid restartable replica from whichOracle can simply perform crash recovery.

# symcl one –dg DB_DG –t gt –consi st ent act i vat e

Note: Follow the same target host prerequisites as in Use Case 1 prior to step 7.

2. Start the ASM instance (or perform import/mount if other volume managers orfilesystems are used). Make sure all the diskgroups were mounted correctly byASM.

# expor t ORACLE_SI D=+ASM# crsct l start r esour ce - al l

3. Simply start the database instance. No recovery or archive logs are needed.

# expor t ORACLE_SI D=CLONE_DB# sql pl us “/ as sysdba”SQL> st ar t up

At this point the clone database is opened and available for user connections.

4. Optionally, it is easy and fast to refresh the TimeFinder replica from production asTimeFinder/Clone operations are incremental as long as the clone session is not




terminated. Once the clone session is reactivated, the target devices are availableimmediately for use, even if background copy is still taking place.

1.1. Shut down the clone database instance since it needs to be refreshedSQL> shut down abort

1.2. Re-create and activate the TimeFinder/Clone replica from production. Thiswill initiate the background copy operation.

# symcl one –dg DB_DG –t gt r ecr eate# symcl one –dg DB_DG –t gt act i vat e - consi st ent

1.3. Start the clone ASM and database instances by following steps 2 and 3again.

Use Case 4: Remote mirroring for disaster protection synchronous

and asynchronous)

This use case illustrates how to create remote mirrors of a productiondatabase for disaster protection using SRDF/S or SRDF/A.

High-level steps

1. Perform initial synchronization of SRDF in Adaptive Copy mode.

2. Once the SRDF target is close enough to the source, change the replication modeto SRDF/S or SRDF/A.

3. Enable SRDF consistency.

Device group used

ALL_CG

Detailed steps

1. Perform initial synchronization of SRDF in Adaptive Copy mode. Repeat this step or

use the skew parameter until the SRDF target is close enough to the source.# symr df –cg ALL_CG set mode acp_wp skew <100- 65535>]# symr df –cg ALL_CG est abl i sh

2. Once the SRDF target is close enough to the source change the replication modeto SRDF/S or SRDF/A.

1.1. For SRDF/S, set protection mode to sync:

# symr df –cg ALL_ CG set mode sync

1.2. For SRDF/A, set protection mode to async:

# symr df –cg ALL_ CG set mode async

3. Establish SRDF replication if the copy is not already active and enableconsistency.

# symr df –cg ALL_CG enabl e# symr df –cg ALL_CG est abl i sh [ –f ul l ]# symr df –cg ALL_CG ver i f y –synchr oni zed - i 60




Use Case 5: Remote restartable database replicas for repurposing

This use case illustrates how to create remote restartable clones or snaps of

production for database repurposing without interrupting SRDF protectionOnce synchronized, an SRDF/S or SRDF/A session can be split at any time tocreate the dependent write consistent remote replica based on the R2 targetdevices. At that time SRDF will keep track of any changes on both sourceand target devices and only these changes will be copied over the next timeSRDF is synchronized (refresh the target devices) or restored (refresh thesource devices).

However it is a better practice to keep SRDF synchronized to maintainremote replication and protection, and instead activate a remote TimeFinderreplica such as clone or snap (currently supported with SRDF/S only), andalternatively additional snapshots can be taken from the remote clone.These replicas of the database are dependent write consistent and can be

used for activities such as test, development, reporting, data processing,publishing, and more. It also can serve as gold copy protection from rollingdisasters as explained earlier in the SRDF best practices section.

High-level steps

1. Activate the remote DB_DG clone (use –consistent to create restartable replica).

2. Start the remote ASM instance.

3. Start the remote database instance.

4. Optionally, refresh the remote clone replica from production (SRDF targets) at alater time.

Device group used

DB_DG

Detailed steps

On the target host

1. Activate the TimeFinder/Clone DB_DG remote replica. The clone replica includesall data, control, and log files. Use –consistent to make sure the replica maintainsdependent write consistency and therefore a valid restartable replica from whichOracle can simply perform crash recovery.

# symcl one –dg DB_DG –t gt –consi st ent act i vat e

Note: Follow the same target host prerequisites as in Use Case 1 prior tostep 7.

2. Start the ASM instance. Follow the same activities as in Use Case 3 step 2.

3. Start the database instance. Follow the same activities as in Use Case 3 step 3.

At this point the clone database is opened and available for user connections.




4. Optionally, to refresh the database clone follow the same activities as in Use Case3 step 4.

Use Case 6: Remote database valid backup replicas

This use case illustrates how to create remote database clones that are avalid Oracle backup image and can be used for database recovery.

By creating TimeFinder remote replicas that are valid for database recovery,backup to tertiary media can be performed at the remote site. Also, theTimeFinder replica itself is a valid backup to disk that can be used torecover production if necessary.

Note for SRDF/A: The SRDF checkpoint command will return control to the user onlyafter the source device content reached the SRDF target devices (SRDF will simply waittwo delta sets). This is useful for example when production is placed in hot backupmode before the remote clone is taken.

High-level steps


2. If using SRDF/A, perform SRDF checkpoint (no action required for SRDF/S).

3. Activate a remote DATA_DG clone (with –consistent if SRDF/A and/or ASM areused).


5. Archive the current log.

6. Copy two backup control files to the FRA ASM diskgroup.

7. If using SRDF/A then perform SRDF checkpoint (no action required for SRDF/S).

8. Activate the remote ARCHIVE_DG clone (with –consistent if SRDF/A and/or ASM isused).

9. Optionally mount the remote clone devices on the backup host and perform RMANbackup.

Device groups used

DATA_DG and ARCH_DG for TimeFinder operations, ALL_CG for SRDF operations

Detailed steps


1. Place production in hot backup mode. Follow the same activities as in Use Case 1step 1.

2. If SRDF/A is used then an SRDF checkpoint command will make sure the SRDFtarget has the datafiles in backup mode as well.

# symr df –cg ALL_CG checkpoi nt

3. Activate the remote DATA_DG clone. Use –consistent if SRDF/A is used and/orASM. Follow the same activities as in Use Case 1 step 2.




4. End hot backup mode. Follow the same activities as in Use Case 1 step 3.

5. Switch logs and archive the current log file. Follow the same activities as in Use

Case 1 step 4.6. Create two backup control files and place in the FRA diskgroup for convenience.

Follow the same activities as in Use Case 1 step 5.

7. If SRDF/A is used then an SRDF checkpoint command will make sure the SRDFtarget has the FRA diskgroup (with the last archives and backup control files) atthe target.

# symr df –cg ALL_CG checkpoi nt

8. Activate the remote TimeFinder/Clone ARCHIVE_DG replica. Follow the sameactivities as in Use Case 1 step 6.

9. Optionally mount the remote clone devices on the backup host and perform RMANbackup. Follow the same activities as in the “On the backup host” section in Use

Case 1.

Use Case 7: Parallel database recovery from remote backup replicas

This use case illustrates how to perform parallel production database recovery byrestoring a remote TimeFinder/Clone backup image simultaneously with SRDF restore,and then applying Oracle logs to the production database in parallel. This is similar toUse Case 2, only the recovery is from a remote replica.

High-level steps

1. Shut down production database and ASM instances.

2. Restore the remote DATA_DG clone (split afterwards). Restore SRDF in parallel.

3. Start ASM.

4. Mount the database.

5.

Perform database recovery (possibly while the TimeFinder and SRDF restore arestill taking place) and open the database.

Device groups used

DATA_DG; ALL_CG for SRDF operations

Detailed steps


1. Shut down any production database and ASM instances (if still running). Followthe same activities as in Use Case 2 step 1.

2. Restore the remote TimeFinder/Clone replica to the SRDF target devices, thenrestore SRDF. If SRDF is still replicating from source to target stop the replicationfirst. Then start TimeFinder restore, and once started start SRDF restore in parallel.In some cases the distance is long, the bandwidth is limited, and many changeshave to be restored. In these cases it might make more sense to change SRDF




mode to Adaptive Copy first until the differences are small before placing it againin SRDF/S or SRDF/A mode.

# symr df –cg ALL_CG spl i t# symcl one –dg DATA_DG –t gt r est ore [ –f orce]# symr df –cg ALL_CG r est or e

It is not necessary to wait for the completion of the SRDF restore before moving tothe next step.

3. Start ASM on the production host. Follow the same activities as in Use Case 1 step7.

4. Mount the database. Follow the same activities as in Use Case 1 step 8.

5. Recover and open the production database. Follow the same activities as in UseCase 2 step 5.




Full complete) database recovery

When all online redo logs and archive logs are available it is possible to perform a full

media recovery of the Oracle database to achieve a no data loss of committedtransactions.

SQL> r ecover aut omat i c database;SQL> al t er dat abase open;

Note: It might be necessary to point the location of the onlineredo logs or archive logs if the recovery process didn’t locatethem automatically (common in RAC implementations withmultiple online or archive logs locations). The goal is to applyany necessary archive logs as well as the online logs fully.

Point-in-time database recovery

When a full media recovery is not desirable, or when some archives oronline logs are missing, an incomplete recovery can be performed. Whenperforming incomplete recovery enough logs need to be applied to pass themaximum point of data file fuzziness so they are all consistent. Afterpassing that point additional archive can potentially be applied. Thefollowing is a sample script (based on the Oracle metalink note mentionedpreviously) that can help identify the minimum SCN required to open thedatabase. However performing data file scans can be an elongated processthat defeats the purpose of fast recovery and short RTO. Therefore runningthe script is optional, and it is recommended to simply perform the recoveryinstead for two reasons. First, the TimeFinder replica with the data andcontrol files can be restored again if necessary so it can’t be corrupted by

the restore. Second, since the replica is taken with consistent split, thepoint of fuzziness of the data files can’t go beyond the time of the split (itcan only be older). Therefore it is clear that recovering this replica to a timebeyond the split time will pass the maximum fuzziness in all the data filesand will be sufficient.

Optional scan datafile script (not recommended to run unless RTO is not aconcern):

spool scandat af i l e. outset server out put ondecl ar e

scn number ( 12) : = 0;scnmax number ( 12) : = 0;

begi n

f or f i n ( sel ect * f romv$dat af i l e) l oopscn : = dbms_backup_r est or e. scandat af i l e( f . f i l e#) ;dbms_output . put _ l i ne( ' Fi l e ' | | f . f i l e# | | ' absol ute

f uzzy scn = ' | | scn) ;




i f scn > scnmax then scnmax : = scn; end i f ;end l oop;

dbms_out put . put _l i ne( ' Mi ni mum PI TR SCN = ' | | scnmax) ;end;

Sample output generated by the scan data script:

SQL> @. / scandat a. sqlFi l e 1 absol ut e f uzzy scn = 27088040Fi l e 2 absol ut e f uzzy scn = 27144475Fi l e 3 absol ut e f uzzy scn = 27164171…Fi l e 22 absol ut e f uzzy scn = 0Mi ni mum PI TR SCN = 27164171

Perform incomplete database recovery (sample commands):

SQL> al t er dat abase recover dat abase unt i l change27164171;SQL> al t er database open r eset l ogs;




Use Case 8a – Demonstrating fast database recovery using a restartable

TimeFinder VP Snap Restore to Target

The following general process could be used in conjunction with the Oracleprocedures, previously documented in Use Case 8, to demonstrate fastdatabase recovery using a restartable TimeFinder VP Snap Restore to Targetclone. Assuming all the LUNs in the DATA_DG are thin devices and the thinTGT and VP Snap devices exist, here are the general steps to follow to createa recoverable point-in-time copy of the database in a cascaded TimeFindersnap environment.

1. Create one device file and one device group

a. The device file controls the SRC to TGT clone pairings.

b. The device group controls the TGT to VP Snap pairings.


3. Create and activate the SRC to TGT full copy differential clonesessions.

4. Create and activate the TGT to VP Snap sessions.

5. Restore the VP Snap to the TGT devices.




Use t he f ol l owi ng commands t o creat e recover abl e poi nt - i n- t i me

cascaded f ul l y copy cl one t o VP Snap copi es of t he dat abase.Assumi ng database i s i n hot backup mode# symdg cr eat e DATA_DG# syml d –g DATA_DG addal l –r ange 0300: 0303# syml d –g DATA_DG addal l –r ange 0310: 0313 –t gt# syml d –g DATA_DG addal l –r ange 0340: 0343 –t gtCreate txt file to pair Source and TGT devices –

DATA_PAIRS.txt

0300 03100301 03110302 03120303 0313# symcl one –f DATA_PAI RS. t xt cr eat e - di f f –nop# symcl one –f DATA_PAI RS. t xt act i vat e - nopCreate txt file to pair TGT to VP Snap devices –

TGT_VP_Snap.txt

0310 03400311 03410312 03420313 0342# symcl one –f TGT_VP_Snap. t xt cr eat e –vse DEV001 sym l d TGT001# symcl one –f TGT_VP_Snap. t xt act i vate DEV001 sym l d TGT001

Use t he f ol l owi ng command to rest ore the VP Snap to TGT, i nUse case 8 ‘ Det ai l St eps’ st ep 2.Symcl one –g TGT_VP_Snap. t xt r est ore DEV001 sym l d TGT001 - nop

The remaining steps are identical to those detailed in Use Case 8.




Conclusion

Symmetrix VMAX family offers enhanced scalability, performance,availability, and security features, allowing Oracle databases andapplications to be deployed rapidly and with ease.

With the introduction of enterprise Flash drives, and together with FibreChannel and SATA drives, Symmetrix provides a consolidation platformcovering performance, capacity, and cost requirements of small and largedatabases. The correct use of storage tiers together with the ability to movedata seamlessly between tiers allow customers to place their most activedata on the fastest tiers, and their less active data on high-density, low-costmedia like SATA drives. Features such as Autoprovisioning allow ease ofstorage provisioning to Oracle databases, clusters, and physical or virtual

server farms.

TimeFinder and SRDF technologies simplify high availability and disasterprotection of Oracle databases and applications, and provide the requiredlevel of scalability from the smallest to the largest databases. SRDF andTimeFinder are easy to deploy and very well integrated with Oracle productslike Automatic Storage Management (ASM), RMAN, Grid Control, and more.The ability to offload backups from production, rapidly restore backupimages, or create restartable database clones enhances the Oracle userexperience and data availability.

Oracle and EMC have been investing in an engineering partnership toinnovate and integrate both technologies since 1995. The integratedsolutions increase database availability, enhance disaster recoverystrategy, reduce backup impact on production, minimize cost, and improvestorage utilization across a single database instance or RAC environments.




Appendix: Test storage and database configuration

This appendix contains a description of the storage and database configurations

used in the test use cases.

General test environment

It is assumed that:Oracle is installed on the target host with similar options to production and configured for ASM use (CSS, or

Cluster Synchronization Service, is active).

Copies of the production init.ora files for the ASM instance and the database instance were copied to the

target host and modified if required to fit the target host environment.

The appropriate Clone, R2, or Remote Clone (whichever is appropriate for the test) is accessible by the

target host.

The SRDF and TimeFinder tests were performed while an OLTP workload was running , simulating a high number of concurrent Oracle users.

Although, TimeFinder and SRDF commands can be issued from any host connected tothe Symmetrix, in the following test cases, unless specified otherwise, they wereissued from the production host. The term “Production host” is used to specify theprimary host where the source devices are used, and “Target host” is used to specifythe host where the Clones, R2, or Remote clone devices are used.

Test setup

Storage and device specific configuration:

• All RAC nodes share the same set of devices and have proper ownerships.

• PowerPath is used to support multipathing and load balancing.

• PowerPath device names are uniform across all RAC nodes.

• Symmetrix device groups are created for shared storage for RAC. ASM diskgroupswere configured on Symmetrix devices.

• Appropriate local and remote replication relationships were created using SYMCLIcommands for TimeFinder/Clone and SRDF.

Table 2. Test hardware

Model OS Oracle version

Local “Production” Host:RAC Node 1

Dell Red Hat Enterprise Linux 5.0 11g release 1 (11.1.0.6.0)

Local “Production” Host:RAC Node 2

Dell Red Hat Enterprise Linux 5.0 11g release 1 (11.1.0.6.0)

Remote “Target” Host Dell Red Hat Enterprise Linux 5.0 11g release 1 (11.1.0.6.0)



Type Enginuity version

Symmetrix R1 VMAX 5876

Symmetrix R2 VMAX 5876

Symmetrix Vmax Srdf Timefinder Oracle Database Wp

Documents

Transcript of Symmetrix Vmax Srdf Timefinder Oracle Database Wp