ORACLE DATABASE BACKUP AND RECOVERY WITH VMAX3

Transcription

1 ORACLE DATABASE BACKUP AND RECOVERY WITH VMAX3 EMC VMAX Engineering White Paper ABSTRACT With the intrductin f the third generatin VMAX disk arrays and lcal replicatin and enhanced remte replicatin capabilities, Oracle database administratrs have a new way t prtect their Oracle databases effectively and efficiently with unprecedented ease f use and management. June, 2015 EMC WHITE

2 T learn mre abut hw EMC prducts, services, and slutins can help slve yur business and IT challenges, cntact yur lcal representative r authrized reseller, visit r explre and cmpare prducts in the EMC Stre. Cpyright 2015 EMC Crpratin. All Rights Reserved. EMC believes the infrmatin in this publicatin is accurate as f its publicatin date. The infrmatin is subject t change withut ntice. The infrmatin in this publicatin is prvided as is. EMC Crpratin makes n representatins r warranties f any kind with respect t the infrmatin in this publicatin, and specifically disclaims implied warranties f merchantability r fitness fr a particular purpse. Use, cpying, and distributin f any EMC sftware described in this publicatin requires an applicable sftware license. Fr the mst up-t-date listing f EMC prduct names, see EMC Crpratin Trademarks n EMC.cm. All ther trademarks used herein are the prperty f their respective wners. Part Number H

3 TABLE OF CONTENTS EXECUTIVE SUMMARY... 6 Audience... 7 Terminlgy... 7 VMAX3 Prduct Overview... 8 VMAX3 SnapVX Lcal Replicatin Overview... 8 VMAX3 SRDF Remte Replicatin Overview... 9 ORACLE DATABASE REPLICATION WITH TIMEFINDER AND SRDF CONSIDERATIONS Number f Snapshts, Frequency, and Retentin Snapsht Link Cpy vs. N Cpy Optin Oracle Database Restart vs. Recvery Slutins RMAN and VMAX3 Strage Replicatin Cmmand Executin and Hst Users Oracle DBaaS SnapClne Integratin n VMAX Strage Layut and ASM Disk Grup Cnsideratins Remte Replicatin Cnsideratins ORACLE BACKUP AND DATA PROTECTION TEST CASES Test Cnfiguratin Test Overview Test Case 1: Creating a lcal restartable database replica fr database clnes Test Case 2: Creating a lcal recverable database replica fr backup and recvery. 17 Test Case 3: Perfrming FULL r incremental RMAN backup frm a SnapVX replica.. 19 Test Case 4: Perfrming database recvery f Prductin using a recverable snapsht Test Case 5: Using SRDF/S and SRDF/A fr database disaster recvery Test Case 6: Creating remte restartable cpies Test Case 7: Creating remte recverable database replicas Test Case 8: Parallel recvery frm remte backup image Test Case 9: Leveraging Access Cntrl List replicatins fr strage snapshts

4 CONCLUSION APPENDIX I - CONFIGURING ORACLE DATABASE STORAGE GROUPS FOR REPLICATION Creating snapshts fr Oracle database strage grups Linking Oracle database snapshts fr backup fflad r repurpsing Restring Oracle database using strage snapsht Creating a cascaded snapsht frm an existing snapsht APPENDIX II SRDF MODES AND TOPOLOGIES SRDF mdes SRDF tplgies APPENDIX III SOLUTIONS ENABLER CLI COMMANDS FOR TIMEFINDER SNAPVX MANAGEMENT Creatin f peridic snaps Listing details f a snap Linking the snap t a strage grup Verifying current state f the snap Listing linked snaps Restre frm a snap APPENDIX IV SOLUTIONS ENABLER CLI COMMANDS FOR SRDF MANAGEMENT Listing lcal and remte VMAX SRDF adapters Creating dynamic SRDF grups Creating SRDF device pairs fr a strage grup Listing the status f SRDF grup Restring SRDF grup APPENDIX V - SOLUTIONS ENABLER ARRAY BASED ACCESS CONTROL MANAGEMENT Identifying the unique ID f the Unisphere fr VMAX and database management hst Adding the UNIVMAX hst t AdminGrp fr ACL management Authenticate UNIVMAX hst fr ACL management Create access grup fr database hst

5 Create database device access pl Install Slutins Enabler n database hsts using nn-rt user REFERENCES

6 EXECUTIVE SUMMARY Many applicatins are required t be fully peratinal 24x7x365 and the data fr these applicatins cntinues t grw. At the same time, their RPO and RTO requirements are becming mre stringent. As a result, there is a large gap between the requirements fr fast and efficient prtectin and replicatin, and the ability t meet these requirements withut verhead r peratins disruptin. DBAs require the ability t create lcal and remte database replicas in secnds withut disruptin f Prductin hst CPU r I/O activity fr purpses such as testing patches, running reprts, creating develpment sandbx envirnments, publishing data t analytic systems, fflading backups frm Prductin, develping Disaster Recvery (DR) strategy, and mre. Traditinal slutins rely n hst based replicatin. The disadvantages f this slutin are the additinal hst I/O and CPU cycles cnsumed by the need t create such replicas, the cmplexity f mnitring and maintaining them, especially acrss multiple servers, and the elngated time and cmplexity assciated with their recvery. EMC and Oracle have made the creatin f such replicas mre efficient, integrated, easier t create, faster t restre, and very rbust in features. TimeFinder lcal replicatin values t Oracle include: The ability t create instant and cnsistent database replicas fr repurpsing, acrss a single database, multiple databases, including external data r message queues, and acrss multiple VMAX3 strage systems. The ability t perfrm TimeFinder replica creatin r restre peratins in secnds, regardless f the database size. The target devices (in case f a replica) r surce devices (in case f a restre) are available immediately with their data, even as incremental data changes are cpied in the backgrund. The ability t create valid backup images withut ht-backup mde that can be taken, and mre imprtantly restred, in secnds regardless f database size, leveraging the Oracle Snapsht Strage Optimizatin Oracle 12c feature. Prir t Oracle 12c, such valid backup images were achieved by using ht backup mde fr nly a few secnds. The ability t utilize RMAN Blck Change Tracking (BCT) file frm a TimeFinder replica, when fflading backups frm Prductin t a backup hst. Recvery peratins can take place n either the Backup r Prductin hst. VMAX3 TimeFinder SnapVX snapshts are cnsistent by default. Each surce device can have up t 256 space-efficient snapshts that can be linked t up t 1024 target devices, maintaining incremental refresh relatinships. The linked targets can remain space-efficient, r a backgrund cpy f all the data can take place, making it a full cpy. In this way, SnapVX allws unlimited number f cascaded snapshts. With Oracle 12c Clud Cntrl DBaaS Snap Clne, DBAs can perfrm strage prvisining and replicatins directly frm Enterprise Manager (TimeFinder is called via APIs). With Oracle VM 3.3 Strage Cnnect, strage devices can be prvisined t VMs, r VMs with their physical and virtual strage can be clned (TimeFinder is called via APIs). SRDF remte replicatin values t Oracle include: Synchrnus and Asynchrnus cnsistent replicatin f a single r multiple databases, including external data r message queues, acrss multiple VMAX3 strage array systems if necessary. The pint f cnsistency is created befre a disaster strikes, rather than taking hurs t achieve afterwards when using replicatins that are nt cnsistent acrss applicatins and databases. Disaster Recvery (DR) prtectin fr tw r three sites, including cascaded r triangular relatinships, where SRDF always maintains incremental updates between surce and target devices. SRDF and TimeFinder are integrated. Fr example, while SRDF replicates the data remtely, TimeFinder can be used n the remte site t create writable snapshts r backup images f the database. This allws the DBAs t perfrm remte backup peratins r create remte database cpies. SRDF and TimeFinder can wrk in parallel t restre remte backups. Fr example, while a remte TimeFinder backup is being restred t the remte SRDF devices, in parallel SRDF will cpy the restred data t the lcal site. This parallel restre capability prvides DBA with faster accessibility t remte backups and shrtens recvery times. VMAX replicatin and Silent Data Crruptin: Bth VMAX and VMAX3 arrays prtect all user data with T10-DIF frm the mment it enters the strage until it is retrieved by the hst, including fr lcal and remte replicatin. With Oracle ASMlib (Oracle 10g and abve), Oracle and EMC integrated the T10-DIF standard fr end-t-end data integrity validatin. Each read r write between Oracle and VMAX strage is validated. Starting with Oracle 12c, Oracle ASM Filter Driver (AFD) prvides a wider hst OS supprt fr T10-DIF with VMAX, and includes ther features such as the ability t reclaim deleted 6

7 ASM files in VMAX strage, prtectin frm nn-oracle writes t Oracle data, and mre. Internally, bth TimeFinder and SRDF use T10-DIF t validate all replicated data. Tgether, Oracle ASM and VMAX3 ffer the mst prtected and rbust platfrm fr database strage and replicatins that maintains data integrity fr each database read r write as well as its replicatins. By utilizing VMAX3 lcal and remte replicatins, DBAs gain the ability t prtect and repurpse their databases quickly and easily, withut the time and cmplexity assciated with hst-based replicatins, and the increasing RTOs assciated with grwing databases size. AUDIENCE This white paper is intended fr database and system administratrs, strage administratrs, and system architects wh are respnsible fr implementing, managing, and maintaining Oracle databases backup and replicatin n VMAX3 strage arrays. It is assumed that readers have sme familiarity with Oracle and the EMC VMAX3 family f strage arrays, and are interested in achieving higher database availability, perfrmance, and ease f strage management. TERMINOLOGY The fllwing table prvides explanatin t imprtant terms used in this paper. Term Restartable vs. Recverable database RTO and RPO Strage cnsistent replicatin Descriptin Oracle distinguishes between a restartable and recverable state f the database. A restartable state requires all lg, data, and cntrl files t be cnsistent (see Strage cnsistent replicatin ). Oracle can be simply started, perfrming autmatic crash/instance recvery withut user interventin. Recverable state n the ther hand requires a database media recvery, rlling frward transactin lg t achieve data cnsistency befre the database can be pened. Recvery Time Objective (RTO) refers t the time it takes t recver a database after a failure. Recvery Pint Objective (RPO) refers t any amunt f data lss after the recvery cmpletes, where RPO=0 means n data lss f cmmitted transactins. Strage cnsistent replicatin refers t strage replicatins (lcal r remte) in which the target devices maintain write-rder fidelity. That means that fr any tw dependent I/Os that the applicatin issues, such as lg write fllwed by data update, either bth will be included in the replica r nly the first. T the Oracle database, after a hst crash r Oracle shutdwn abrt, the snapsht data appears in a state frm which Oracle can simply recver by perfrming crash/instance recvery when starting. Starting with Oracle 11g, Oracle allws database recvery frm strage cnsistent replicatins withut the use f ht-backup mde (details in Oracle supprt nte: ). The feature has becme mre integrated with Oracle 12c and is called Oracle Strage Snapsht Optimizatin. VMAX3 HYPERMAX OS VMAX3 Strage Grup HYPERMAX OS is the industry s first pen cnverged strage hypervisr and perating system. It enables VMAX3 arrays t embed strage infrastructure services like clud access, data mbility and data prtectin directly n the array. This delivers new levels f data center efficiency and cnslidatin by reducing ftprint and energy requirements. In additin, HYPERMAX OS delivers the ability t perfrm real-time and nn-disruptive data services. A cllectin f hst addressable VMAX3 devices. A Strage Grup can be used t (a) present devices t hst (LUN masking), (b) specify FAST Service Levels (SLOs) t a grup f devices, and (c) manage device gruping fr replicatin sftware such as SnapVX and SRDF. Strage Grups can be cascaded, such as the child strage grups used fr setting FAST Service Level Objectives (SLOs) and the parent strage grups used fr LUN masking f all the database devices t the hst. VMAX3 TimeFinder SnapVX VMAX3 TimeFinder SnapVX Snapsht vs. Clne TimeFinder SnapVX is the latest generatin in TimeFinder lcal replicatin sftware, ffering higher scale and a wider feature set while maintaining the ability t emulate legacy behavir. Previus generatins f TimeFinder referred t Snapsht as a space-saving cpy f the surce device, where capacity was cnsumed nly fr data changed after the snapsht time. Clne, n the ther hand referred t full cpy f the surce device. With VMAX3 arrays, TimeFinder SnapVX snapshts are always space-efficient. When they are linked t hst-addressable target devices, the user can chse t keep the target devices space-efficient r perfrm a full cpy. 7

8 VMAX3 Prduct Overview The EMC VMAX3 family f strage arrays is built n the strategy f simple, intelligent, mdular strage, and incrprates a Dynamic Virtual Matrix interface that cnnects and shares resurces acrss all VMAX3 engines, allwing the strage array t seamlessly grw frm an entry-level cnfiguratin int the wrld s largest strage array. It prvides the highest levels f perfrmance and availability featuring new hardware and sftware capabilities. The newest additins t the EMC VMAX3 family, VMAX 100K, 200K and 400K, deliver the latest in Tier-1 scale-ut multi-cntrller architecture with cnslidatin and efficiency fr the enterprise. It ffers dramatic increases in flr tile density, high capacity flash and hard disk drives in dense enclsures fr bth 2.5" and 3.5" drives, and supprts bth blck and file (enas). The VMAX3 family f strage arrays cmes pre-cnfigured frm factry t simplify deplyment at custmer sites and minimize time t first I/O. Each array uses Virtual Prvisining t allw the user easy and quick strage prvisining. While VMAX3 can ship as an all-flash array with the cmbinatin f EFD (Enterprise Flash Drives) and large persistent cache that accelerates bth writes and reads even further, it can als ship as hybrid, multi-tier strage that excels in prviding FAST 1 (Fully Autmated Strage Tiering) enabled perfrmance management based n Service Level Objectives (SLO). VMAX3 new hardware architecture cmes with mre CPU pwer, larger persistent cache, and a new Dynamic Virtual Matrix dual InfiniBand fabric intercnnect that creates an extremely fast internal memry-t-memry and data-cpy fabric. 1 8 redundant VMAX 3 Engines Up t 4 PB usable capacity Up t 256 FC hst prts Up t 16 TB glbal memry (mirrred) Up t 384 Cres, 2.7 GHz Intel Xen E v2 Up t 5,760 drives SSD Flash drives 200/400/800/1,600 GB 2.5 / GB 1.2 TB 10K RPM SAS drives 2.5 / GB 15K RPM SAS drives 2.5 /3.5 2 TB/4 TB SAS 7.2K RPM 3.5 Figure 1 VMAX3 strage array Figure 1 shws pssible VMAX3 cmpnents. Refer t EMC dcumentatin and release ntes t find the mst up t date supprted cmpnents. T learn mre abut VMAX3 and FAST best practices with Oracle databases, refer t the white paper: Deplyment best practice fr Oracle database with VMAX3 Service Level Object Management. VMAX3 SnapVX Lcal Replicatin Overview EMC TimeFinder SnapVX sftware delivers instant and strage-cnsistent pint-in-time replicas f hst devices that can be used fr purpses such as the creatin f gld cpies, patch testing, reprting and test/develpment envirnments, backup and recvery, data warehuse refreshes, r any ther prcess that requires parallel access t r preservatin f the primary strage devices. The replicated devices can cntain the database data, Oracle hme directries, data that is external t the database (e.g. image files), message queues, and s n. VMAX3 TimeFinder SnapVX cmbines the best aspects f previus TimeFinder fferings and adds new functinality, scalability, and ease-f-use features. 1 Fully Autmated Strage Tiering (FAST) allws VMAX 3 strage t autmatically and dynamically manage perfrmance service level gals acrss the available strage resurces t meet the applicatin I/O demand, even as new data is added, and access patterns cntinue t change ver time. 8

9 Sme f the main SnapVX capabilities related t native snapshts (emulatin mde fr legacy behavir is nt cvered) include: With SnapVX, snapshts are natively targetless. They nly relate t a grup f surce devices and cannt be therwise accessed directly. Instead, snapshts can be restred back t the surce devices, r linked t anther set f target devices which can be made hst-accessible. Each surce device can have up t 256 snapshts that can be linked t up t 1024 targets. Snapsht peratins are perfrmed n a grup f devices. This grup is defined by using either a text file specifying the list f devices, a device-grup (DG), cmpsite-grup (CG), a strage grup (SG), r simply specifying the devices. The recmmended way is t use a strage grup. Snapshts are taken using the establish cmmand. When a snapsht is established, a snapsht name is prvided, and an ptinal expiratin date. The snapsht time is saved with the snapsht and can be listed. Snapshts als get a generatin number (starting with 0). The generatin is incremented with each new snapsht, even if the snapsht name remains the same. SnapVX prvides the ability t create either space-efficient replicas r full-cpy clnes when linking snapshts t target devices. Use the -cpy ptin t cpy the full snapsht pint-in-time data t the target devices during link. This will make the target devices a stand-alne cpy. If -cpy ptin is nt used, the target devices prvide the exact snapsht pint-in-time data nly until the link relatinship is terminated, saving capacity and resurces by prviding space-efficient replicas. SnapVX snapshts themselves are always space-efficient as they are simply a set f pinters pinting t the data surce when it is unmdified, r t the riginal versin f the data when the surce is mdified. Multiple snapshts f the same data utilize bth strage and memry savings by pinting t the same lcatin and cnsuming very little metadata. SnapVX snapshts are always cnsistent. That means that snapsht creatin always maintains write-rder fidelity. This allws easy creatin f restartable database cpies, r Oracle recverable backup cpies based n Oracle Strage Snapsht Optimizatin. Snapsht peratins such as establish and restre are als cnsistent that means that the peratin either succeeds r fails fr all the devices as a unit. Linked-target devices cannt restre any changes directly t the surce devices. Instead, a new snapsht can be taken frm the target devices and linked back t the riginal surce devices. In this way, SnapVX allws unlimited number f cascaded snapshts. FAST Service Levels apply t either the surce devices, r t snapsht linked targets, but nt t the snapshts themselves. SnapVX snapsht data resides in the same Strage Resurce Pl (SRP) as the surce devices, and acquire an Optimized FAST Service Level Objective (SLO) by default. See Appendix III fr a list f basic TimeFinder SnapVX peratins. Fr mre infrmatin n SnapVX, refer t the TechNte: EMC VMAX3 TM Lcal Replicatin and the EMC Slutins Enabler CLI Guides. VMAX3 SRDF Remte Replicatin Overview The EMC Symmetrix Remte Data Facility (SRDF) family f sftware is the gld standard fr remte replicatins in missin critical envirnments. Built fr the industry leading high-end VMAX strage array, the SRDF family is trusted fr disaster recvery and business cntinuity. SRDF ffers a variety f replicatin mdes that can be cmbined in different tplgies, including tw, three, and even fur sites. SRDF and TimeFinder are clsely integrated t ffer a cmbined slutin fr lcal and remte replicatin. Sme f the main SRDF capabilities include: SRDF mdes f peratin: SRDF Synchrnus (SRDF/S) mde which is used t create a n-data-lss f cmmitted transactins slutin. The target devices are an exact cpy f the surce devices (Prductin). SRDF Asynchrnus (SRDF/A) mde which is used t create cnsistent replicas at unlimited distances withut write respnse time penalty t the applicatin. The target devices are typically secnds t minutes behind the surce devices (Prductin), thugh cnsistent ( restartable ). SRDF Adaptive Cpy (SRDF/ACP) mde which allws bulk transfers f data between surce and target devices withut write-rder fidelity and withut write perfrmance impact t surce devices. SRDF/ACP is typically used fr data migratins as a Pint-in-Time data transfer. It is als used t catch up after a lng perid that replicatin was suspended and many changes are wed t the remte site. SRDF/ACP can be set t cntinuusly send changes in bulk until the delta between surce and target is reduced t a specified skew. At this time SRDF/S r SRDF/A mde can resume. SRDF grups: 9

10 An SRDF grup is a cllectin f matching devices in tw VMAX3 strage arrays tgether with the SRDF prts that are used t replicate these devices between the arrays. HYPERMAX OS allws up t 250 SRDF grups per SRDF directr. The surce devices in the SRDF grup are called R1 devices, and the target devices are called R2 devices. SRDF peratins are perfrmed n a grup f devices cntained in an SRDF grup. This grup is defined by using either a text file specifying the list f devices, a device-grup (DG), cmpsite/cnsistency-grup (CG), r a strage grup (SG). The recmmended way is t use a strage grup. SRDF cnsistency: An SRDF Cnsistency Grup is an SRDF grup t which cnsistency was enabled. Cnsistency can be enabled fr either Synchrnus r Asynchrnus replicatin mde. An SRDF cnsistency grup always maintains write-rder fidelity (als called: dependent-write cnsistency) t make sure that the target devices always prvide a restartable replica f the surce applicatin. Nte: Even when cnsistency is enabled the remte devices may nt yet be cnsistent while SRDF state is sync-in-prgress. This happens when SRDF initial synchrnizatin is taking place befre it enters a cnsistent replicatin state. SRDF cnsistency als implies that if a single device in a cnsistency grup can t replicate, then the whle grup will stp replicating t preserve target devices cnsistency. Multiple SRDF grups set in SRDF/A mde can be cmbined within a single array r acrss arrays. Such gruping f cnsistency grups is called multi-sessin cnsistency (MSC). MSC maintains dependent-write cnsistent replicatins acrss all the participating SRDF grups. SRDF sessins: An SRDF sessin is created when replicatin starts between R1 and R2 devices in an SRDF grup. SRDF sessin can establish replicatin between R1 t R2 devices. Only n first establish R1 and R2 devices require full cpy. Any subsequent establish (fr example, after an SRDF split r suspend) will be incremental, nly passing changed data. SRDF sessin can restre the cntent f R2 devices back t R1. Restre will be incremental, mving nly changed data acrss the links. TimeFinder and SRDF can restre in parallel, fr example: bring back a remte backup image. During replicatin the devices t which data is replicated are write-disabled (read-nly). An SRDF sessin can be suspended, temprarily halting replicatin until a resume cmmand is issued An SRDF sessin can be split, which nt nly suspends the replicatin but als makes the R2 devices read-writable. An SRDF checkpint cmmand will nt return the prmpt until the cntent f the R1 devices has reached the R2 devices. This ptin helps in creating remte database backups when SRDF/A is used. An SRDF swap will change R1 and R2 persnality, and the replicatin directin fr the sessin. An SRDF failver makes the R2 devices writable. R1 devices, if still accessible, will change t Write_Disabled (readnly). The SRDF sessin will be suspended and applicatin peratins will prceed n the R2 devices. An SRDF failback cpies changed data frm R2 devices back t R1, and makes the R1 devices writable. R2 devices are made Write_Disabled (read-nly). SRDF replicatin sessins can g in either directin (bi-directinal) between the tw arrays, where different SRDF grups can replicate in different directins. Appendix II, SRDF Mdes and Tplgies, and Appendix IV, Slutins Enabler CLI Cmmands fr SRDF Management, prvide additinal infrmatin. Fr mre infrmatin n SRDF, refer t the VMAX3 Family with HYPERMAX OS Prduct Guide. 10

11 ORACLE DATABASE REPLICATION WITH TIMEFINDER AND SRDF CONSIDERATIONS Number f Snapshts, Frequency, and Retentin VMAX3 TimeFinder SnapVX allws up t 256 snapshts per surce device with minimal cache and capacity impact. SnapVX minimizes the impact f Prductin hst writes by using intelligent Redirect-n-Write and Asynchrnus-Cpy-n-First-Write. Bth methds allw Prductin hst I/O writes t cmplete withut delay due t backgrund data cpy while Prductin data is mdified and the snapsht data preserves its Pint-in-Time cnsistency. If snapshts are used as part f a disaster prtectin strategy then the frequency f creating snapshts can be determined based n the RTO and RPO needs. Fr a restart slutin where n rll-frward is planned, snapshts taken at very shrt intervals (secnds r minutes) ensure that RPO is limited t that interval. Fr example, if a snapsht is taken every 30 secnds, there will be n mre than 30 secnds f data lss if it is needed t restre the database withut recvery. Fr a recvery slutin, frequent snapshts ensure that RTO is shrt as less data will need recvery during rll frward f lgs t the current time. Fr example, if snapshts are taken every 30 secnds, rll frward f the data frm the last snapsht will be much faster than rlling frward frm a nightly backup r hurly snapshts. Linked targets fr the existing snapshts can be further used t create additinal Pint-in-Time snapshts fr repurpsing r backups. Because snapshts cnsume strage capacity based n the database change rate, ld snapshts shuld be terminated when n lnger needed. Snapsht Link Cpy vs. N Cpy Optin SnapVX snapshts cannt be directly accessed by a hst. They can be either restred t the surce devices r linked t up t 1024 sets f target devices. When linking any snapsht t target devices, SnapVX allws using the cpy r n-cpy ptin where n-cpy is the default. Targets created using either f these ptins can be presented t the munt hst and all the Test Cases described in this dcument can be executed n them. A n-cpy link can be changed t cpy n demand t create a full-cpy linked target. N-cpy ptin: N-cpy linked targets remain space efficient by sharing pinters with Prductin and the snapsht. Only changes t either the linked targets r Prductin devices cnsume additinal strage capacity t preserve the riginal data. Hwever, reads t the linked targets may affect Prductin perfrmance as they share their strage via pinters t unmdified data. Anther byprduct f n-cpy linked targets is that they d nt retain their data after they are unlinked. When the snapsht is unlinked, the target devices n lnger prvide a cherent cpy f the snapsht pint-in-time data as befre, thugh they can be relinked later. Cpy ptin: Alternatively, the linked-targets can be made a stand-alne cpy f the surce snapsht pint-in-time data by using cpy ptin. When the backgrund cpy is cmplete, the linked targets will have their wn cpy f the pint-in-time data f the snapsht, and will nt be sharing pinters with Prductin. If at that pint the snapsht is unlinked, the target devices will maintain their wn cherent data, and if they are later relinked they will be incrementally refreshed frm the snapsht (usually, after the snapsht is refreshed). N-cpy linked targets are useful fr strage capacity efficiency due t shared pinters. They can be used fr shrt term and light weight access t avid affecting Prductin s perfrmance. When lnger retentin perid f the linked targets is anticipated, r heavy wrklad, it culd be better t perfrm a link-cpy and have them use independent pinters t strage. It shuld be nted that during the backgrund cpy the strage backend utilizatin will increase and the peratr may want t time such cpy peratins t perids f lw system utilizatin t avid any applicatin perfrmance verhead. Oracle Database Restart vs. Recvery Slutins TimeFinder SnapVX creates cnsistent snapshts by default, which are well suited fr a database restart slutin. A restartable database replica can simply be pened, and it will perfrm crash r instance recvery just as if the server rebted r the DBA perfrmed a shutdwn abrt. T achieve a restartable slutin all data, cntrl, and red lg files must participate in the cnsistent snapsht. Archive lgs are nt required and are nt used fr a database restart. Traditinally ht backup mde is used t create a database recverable slutin. A recverable database replica can perfrm database recvery t a desired pint in time using archive and red lgs. Oracle database 12c enhanced the ability t create database recverable slutin based n strage replicatins by leveraging strage cnsistency instead f ht-backup mde. This feature f Oracle 12c is called: Oracle Snapsht Strage Optimizatin and is demnstrated in Test Case 2. Fr a snapsht that will be recvered n the Prductin hst and therefre relies n the available lgs and archive lgs, the snapsht can include just the data files. Hwever, if the snapsht will be recvered n anther hst (such as when using linked targets) an 11

12 additinal snapsht f the archive lgs shuld be taken, fllwing the best practice described in Test Case 2 fr recverable replicas. Red lgs are nt required in the snapsht. It is pssible t create a hybrid replica that can be used fr either recvery r restart. This can be dne by including all data, cntrl, and red lgs in the first replica, and archive lgs in the secnd (fllwing the best practice fr recverable database replica). In that case, if a restartable slutin is perfrmed, the archive lg replica will nt be used. If a recverable slutin is used, the replica f the nline lgs will nt be restred (especially since we dn t want t verwrite Prductin s red lgs if thse are still available). RMAN and VMAX3 Strage Replicatin Oracle recvery manager (RMAN) is integrated with Oracle server fr tighter cntrl and integrity f Oracle database backups and recvery. RMAN validates every blck prir t the backup t ensure data integrity and prvides several ptins fr higher efficiency, parallelism, detailed histry, catalging, and backup file retentin plicies. RMAN backups can be ffladed t an alternate hst by using a linked SnapVX target and munting an Oracle database instance frm this cpy. As RMAN backups use DBID when string the backup catalg infrmatin, such backups can be restred directly t prductin database. As the size f the database grws, VMAX3 array snapsht-based backups allw creating recverable database cpies and munting them t an alternate hst fr RMAN backups. Alternatively an Oracle database munted using the VMAX3-based recverable snapshts can be registered in RMAN catalg database fr prper tracking f such snapsht-based backup images fr use in a prductin database recvery using RMAN. A typical Oracle database backup strategy invlves running full database backups n a peridic basis; hwever, running incremental backups frequently backs up nly the changes since the prir backup. T further imprve the efficiency f incremental backups, RMAN allws the use f blck change tracking t maintain metadata fr the changes in the backup. Once enabled, RMAN incremental backups use blck change tracking files (BCT) t quickly identify the changed blcks. The RMAN blck change tracking mechanism can als be deplyed when fflading backups t alternate hsts using VMAX3 snapshts. RMAN based backups are described in Test Case 3. Cmmand Executin and Hst Users Typically, an Oracle hst user accunt is used t execute Oracle RMAN r SQL cmmands. A strage admin hst user accunt is used t perfrm strage management peratins (such as TimeFinder SnapVX, r multipathing cmmands). A different hst user accunt may be used t setup and manage Data Dmain systems. This type f rle and security segregatin is cmmn and ften helpful in large rganizatins where each grup manages their respective infrastructure with a high level f expertise. There are different ways t address this: Allw the database backup peratr (cmmnly a DBA) a cntrlled access t cmmands in Slutins Enabler and Data Dmain, leveraging VMAX Access Cntrls (ACLs). Use SUDO, allwing the DBA t execute specific cmmands fr the purpse f their backup (pssibly in cmbinatin with Access Cntrls). It is beynd the scpe f this paper t dcument hw access cntrls are executed; hwever, it is imprtant t mentin that Slutins Enabler can be installed fr a nn-rt user as described in Test Case 9. Slutins Enabler has a rbust set f Access Cntrls that fit this situatin. Similarly, fr Oracle database replicatin r backup purpses, additinal user accunts ther than sysadmin can be created that can manage such prcesses apprpriately. Oracle als allws setting up a backup user and nly prviding them a specific set f authrizatins apprpriate fr their task. Oracle DBaaS SnapClne Integratin n VMAX3 Oracle Database as a Service (DBaaS) prvides self-service deplyment f Oracle databases and resurce pling t cater t multitenant envirnments. Oracle DBaaS SnapClne is strage agnstic and self-service apprach t creating rapid and space efficient clne rchestrated thrugh Oracle Enterprise Manager Clud Cntrl (EM12c). SnapClne is develped by Oracle and integrated with VMAX3 SMI-S prvider fr management and strage prvisining fr TEST and DEV cpies frm a TEST Master database using VMAX-based strage snapshts. It als ffers strage ceiling r capacity qutas per thin pl t give cntrl ver database strage cnsumptin t DBAs. At this pint SnapClne is available n the VMAX platfrm and develpment f VMAX3 supprt is underway. Please refer t Oracle nte: fr mre infrmatin abut SnapClne functinality. Strage Layut and ASM Disk Grup Cnsideratins Strage design principles fr Oracle n VMAX3 The strage design principles fr Oracle n VMAX3 are dcumented in the white paper: Deplyment Best Practices fr Oracle Database with VMAX3 Service Level Objective Management. Tw key pints are described belw: 12

13 ASM Disk Grups and Oracle files: A minimum f 3 sets f database devices shuld be defined fr maximum flexibility: data/cntrl files, red lgs, and FRA (archive lgs), each in its wn Oracle ASM disk grup (fr example, +DATA, +REDO, +FRA). The separatin f data, red and archive lg files allws backup and restre f nly the apprpriate file types at the apprpriate time. Fr example, Oracle backup prcedures require the archive lgs t be replicated at a later time than the data files. Als, during restre, if the red lgs are still available n the Prductin hst, we can restre nly data files withut verwriting the Prductin s red lgs. If nly database restart slutin is required, then the data and lg files can be mixed and replicated tgether (althugh they may be ther reasns t separate them, such as fr better perfrmance management). When Oracle RAC is used it is recmmended t use a separate ASM disk grup fr Grid infrastructure (fr example, +GRID). The +GRID ASM disk grup shuld nt cntain user data. In this way, the cluster infrmatin is nt part f a database backup and if a recvery is perfrmed n anther clustered server, it can already have its +GRID ASM disk grup cnfigured ahead f time. Partitin alignment n x86 based systems Oracle recmmends n Linux and Windws systems t create at least ne partitin n each strage device. Due t the legacy BIOS issue, by default such partitins are rarely aligned. It is therefre strngly recmmended t mve the beginning f the first partitin using fdisk r parted t an ffset f 1MB (2048 blcks). By having the beginning f the partitin aligned, I/O t VMAX3 will be aligned with strage tracks and FAST extents achieving best perfrmance. Remte Replicatin Cnsideratins It is recmmended fr an SRDF/A slutin t always use Cnsistency Enabled t ensure that if a single device cannt replicate, the entire SRDF grup will stp replicating, maintaining a cnsistent database replica n the target devices. SRDF is a restart slutin and since database crash recvery never uses archive lgs there is n need t include FRA (archive lgs) in the SRDF replicatin. Hwever, there are tw reasns why they culd be included: If Flashback database functinality is required fr the target. Replicating the flashback lgs in the same cnsistency grup as the rest f the database allws the use f Flashback database n the target. T allw fflad f backup peratins t the remte site as archive lgs are required t create a stand-alne backup image f the database. In this case, the archive lgs can use a different SRDF grup and mde, ptentially leveraging SRDF/A, even if data, cntrl, and lg files are replicated with SRDF/S. It is always recmmended t have a database replica available at the SRDF remte site as a gld cpy prtectin frm rlling disasters. Rlling disasters is a term used when a first interruptin t nrmal replicatin activities is fllwed by a secndary database failure n the surce, leaving the database withut an immediately available valid replica. Fr example, if SRDF replicatin was interrupted fr any reasn fr a while (planned r unplanned) and changes were accumulated n the surce, nce the synchrnizatin resumes and until the target is synchrnized (SRDF/S) r cnsistent (SRDF/A), the target is nt a valid database image. Fr that reasn it is best practice befre such resynchrnizatin t take a TimeFinder gld cpy replica at the target site. This preserves the last valid image f the database as a safety measure frm rlling disasters. When using Oracle RAC n the Prductin hst, since RAC uses shared strage by virtue f replicating all the database cmpnents (data, lg, and cntrl files), the target database can be started in cluster r single-instance. Regardless f the chice, it is nt recmmended t replicate the cluster layer (vting disks r cluster cnfiguratin devices) since these cntain lcal hsts and subnets infrmatin. It is best practice that if a cluster layer is required at the munt hsts, it shuld be cnfigured ahead f time, based n munt hstnames and subnets, and therefre be ready t bring up the database when needed. 13

14 ORACLE BACKUP AND DATA PROTECTION TEST CASES Test Cnfiguratin This sectin prvides examples using Oracle database backup and data prtectin n VMAX3 arrays. Figure 2 depicts the verall test cnfiguratin used t describe these Test Cases. Figure 2 Oracle lcal and D/R test cnfiguratin Test Overview General test ntes The FINDB database was cnfigured t run an industry standard OLTP wrklad with 70/30 read/write rati and 8KB blck size, using Oracle database 12c and ASM. N special database tuning was dne as the fcus f the test was nt n achieving maximum perfrmance, but rather cmparative differences f a standard database wrklad. DATA and REDO strage grups (and ASM disk grups) were cascaded int a parent strage grup (FINDB_SG) fr ease f prvisining, perfrmance management, and data prtectin. Strage grups were created n lcal and remte VMAX arrays fr linking pint-in-time snapshts fr varius Test Cases. Prductin Oracle database SnapVX and SRDF peratins were run n FINDB_SG. Database cnfiguratin details The fllwing tables shw the Test Cases test envirnment. Table 1 shws the VMAX3 strage envirnment, Table 2 shws the hst envirnment, and Table 3 shws the databases strage cnfiguratin. Table 1 Cnfiguratin aspect Test strage envirnment Descriptin Strage array Single engine VMAX 200K HYPERMAX OS Drive mix (including spares) 17 x EFDs - RAID5 (3+1) 66 x 15K HDD - RAID1 34 x 1TB 7K HDD - RAID6 (6+2) 14

15 Table 2 Test hst envirnment Cnfiguratin aspect Descriptin Oracle Oracle Grid and Database release Linux Oracle Enterprise Linux 6 Multipathing Hsts Vlume Manager Linux DM Multipath 2 x Cisc C240, 96 GB memry Oracle ASM Table 3 Test database cnfiguratin Prductin Database ASM Disk Grups Strage Grups (SG) Prductin Parent SG Lcal Linked Target SG SRDF R2 SG SRDF R2 SnapVX Target SG Name: FINDB Size: 1.5 TB +DATA: 4 x 1 TB thin LUNs +REDO: 4 x 150 GB thin LUNs +FRA: 4 x 100 GB thin LUNs DATA_SG FINDB_SG FINDB_MNT FINDB_R2 FINDB_R2_TGT REDO_SG FINFRA_SG - FINFRA_MNT FINFRA_R2 FINFRA_R2_TGT High level test cases: 1. Creating a lcal restartable database replica fr database clnes 2. Creating a lcal recverable database replica fr backup and recvery 3. Perfrming full r incremental RMAN backups frm a SnapVX replica (including Blck Change Tracking) 4. Perfrming database recvery f Prductin using a recverable snapsht 5. Using SRDF/S and SRDF/A fr database Disaster Recvery 6. Creating remte restartable cpies 7. Creating remte recverable database replicas 8. Parallel recvery frm remte backup image 9. Leveraging self-service replicatins fr DBAs Test Case 1: Creating a lcal restartable database replica fr database clnes Objectives: The purpse f this Test Case is t demnstrate the use f SnapVX t create a lcal database restartable cpy, als referred t as a database clne. The database clne can be started n a Munt hst fr purpses such as lgical errr detectin r creatin f Test, Develpment, and Reprting envirnments. These envirnments can be peridically refreshed frm Prductin. Nte: A restartable database replica must include all database cntrl, data, and red lg files, and therefre the cascaded strage grup FINDB_SG was used. High level steps: 1. Create a snapsht f Prductin database cntaining all cntrl, data, and red lg files. 2. Link the snapsht t target devices and present them t the Munt hst. 3. Start the Oracle database n the Munt hst. 15

16 Grups used: Server Strage Grup ASM Disk Grup Prductin Hst FINDB_SG DATA, REDO Munt Hst FINDB_MNT DATA, REDO Detailed steps: On Prductin hst: Create a snapsht f the Prductin database cntaining all cntrl, data, and red lg files. # symsnapvx sg FINDB_SG name FINDB_Restart establish On Munt hst: Cmplete pre-requisites: GRID infrastructure and Oracle binaries shuld be installed ahead f time n the munt hst. If RAC is used n the Munt hst then it shuld be pre-cnfigured s the ASM disk grups frm the snapshts can simply be munted int the existing cluster. If RAC is nt used n the Munt hst see steps later t bring up Oracle High Availability Services (HAS). The strage grup FINDB_MNT cntains the linked-target devices f Prductin s snapsht. It shuld be added t a masking view t make the target devices accessible t the Munt hst. If refreshing an earlier snapsht, shut dwn the database instance that will be refreshed and dismunt its ASM disk grups: Lgin t the database instance and shut it dwn. SQL> shutdwn immediate; Lg in t the ASM instance and dismunt the ASM disk grups. SQL> dismunt diskgrup DATA; SQL> dismunt diskgrup REDO; Link the Prductin snapsht based n FINDB_SG t the target strage grup FINDB_MNT. Fr the first link use the link ptin. Fr all ther links use the relink ptin. # symsnapvx sg FINDB_SG lnsg FINDB_MNT snapsht_name FINDB_Restart relink If RAC is used n the Munt hst then it shuld be already cnfigured and running using a separate ASM disk grup and therefre +DATA and +REDO can simply be munted. Skip t the next step. If RAC is nt used, an ASM instance may nt be running yet. Bring it up fllwing the prcedure belw befre munting +DATA and +REDO ASM disk grups. As the Grid infrastructure user (ASM instance user), start the Oracle high-availability services. $ crsctl start has CRS-4123: Oracle High Availability Services has been started. Lg in t the ASM instance and update the ASM disk string befre munting the ASM disk grups. $ sqlplus "/ as sysasm" SQL> alter system set asm_diskstring='/dev/mapper/ra*p1'; Munt the ASM disk grups that nw cntain the snapsht pint-in-time data. SQL> munt diskgrup DATA; SQL> munt diskgrup REDO; Lg in t the database instance and start up the database (d nt perfrm database recvery). The database will perfrm crash (r instance) recvery and will pen. SQL> startup Nte: Since there is n rll frward f transactins, the creatin f database clnes using SnapVX is very fast. The time it takes t Oracle t cmplete crash recvery and pens depends n the amunt f transactins in the lg since the last checkpint. 16

17 Test Case 2: Creating a lcal recverable database replica fr backup and recvery Objectives: The purpse f this Test Case is t demnstrate the use f SnapVX t create a lcal recverable database replica. Such a database replica can be used t recver Prductin, r can be munted n a Munt hst and used fr RMAN backup and running reprts. Nte: As lng as the database replica is nly munted, r pened in read-nly mde, it can be used t recver Prductin. High level steps: 1. Fr Oracle databases prir t 12c, place the Prductin database in ht-backup mde. 2. Create a cnsistent snapsht f Prductin cntrl, data, and red lg files (which are cntained in +DATA and +REDO ASM disk grups). 3. Fr Oracle databases prir t 12c, end ht-backup mde. 4. As the database user, switch lgs, archive the current lg, and save backup cntrl file t +FRA ASM disk grup. 5. If the replica is used t fflad RMAN incremental backups t a Munt hst then switch RMAN Blck Change Tracking file manually. 6. Create a snapsht f Prductin archive lgs cntained in +FRA ASM disk grup. 7. Link bth snapshts t target devices and present them t the Munt hst. 8. Munt the ASM disk grups n the Munt hst. 9. Munt the database instance n the Munt hst (d nt pen it). 10. Optinally, catalg the database backup with RMAN. Nte: See Test Case 3 fr details n hw the snapsht can be used t perfrm RMAN backups. Grups used: Server Strage Grup ASM Disk Grup Prductin Hst FINDB_SG DATA, REDO FINFRA_SG FRA Munt Hst FINDB_MNT DATA, REDO FINFRA_MNT FRA Detailed steps: On Prductin hst: Pre-Oracle 12c, place the Prductin database in ht-backup mde. SQL> alter database begin backup; Create a snapsht f Prductin cntrl, data, and red lg files cntained in +DATA and +REDO ASM disk grups. # symsnapvx sg FINDB_SG name Snapsht_Backup establish Pre-Oracle 12c, end ht-backup mde. SQL> alter database end backup; As the database user, switch lgs, archive the current lg, and save backup cntrl file t +FRA ASM disk grup. SQL> alter system switch lgfile; SQL> alter system archive lg current; 17

18 SQL> alter database backup cntrlfile t +FRA/CTRLFILE_BKUP REUSE; If the replica is nt used t fflad RMAN incremental backups t a Munt hst (Test Case 3) then skip t the next step. Otherwise, as a database user n Prductin, switch RMAN Blck Change Tracking file manually. SQL> execute dbms_backup_restre.bctswitch(); Nte: When RMAN incremental backups are taken using RMAN Blck Change Tracking (BCT), then RMAN switches the versin f the file with each backup autmatically. Hwever, when the RMAN backup is ffladed t a Munt hst, RMAN will update the BCT file n the Munt hst. Oracle prvides an API fr such cases that switches the BCT file manually n Prductin after incremental backups frm the Munt hst. Nte: By default Oracle nly keeps 8 versins in the BCT file fr incremental backups. That means that if mre than 8 incremental backup are taken befre anther level 0 (full) backup takes place, RMAN will nt be able t use the BCT file and will revert t scanning the whle database. T increase the number f versins in the BCT file use the init.ra parameter _bct_bitmaps_per_file (see Oracle supprt ntes: and ) Create a snapsht f Prductin archive lgs cntained in +FRA ASM disk grup. # symsnapvx sg FINFRA_SG name FRA_Backup establish On Munt hst: Cmplete pre-requisites: GRID infrastructure and Oracle binaries shuld be installed ahead f time n the munt hst. If RAC is used n the Munt hst then it shuld be pre-cnfigured s the ASM disk grups frm the snapshts can simply be munted int the existing cluster. If RAC is nt used n the Munt hst, see steps later t bring up Oracle High Availability Services (HAS). The strage grups FINDB_MNT and FINFRA_MNT cntain the linked-target devices f Prductin s snapshts. They shuld be added t a masking view t make the target devices accessible t the Munt hst. If refreshing an earlier snapsht, shut dwn the database instance and dismunt the ASM disk grups. Lgin t the database instance and shut it dwn. SQL> shutdwn immediate; Lg in t the ASM instance and dismunt the ASM disk grups that will be refreshed. SQL> dismunt diskgrup DATA; SQL> dismunt diskgrup REDO; SQL> dismunt diskgrup FRA; Link the Prductin snapshts based n FINDB_SG and FINFRA_SG t the target strage grup: FINDB_MNT and FINFRA_MNT respectively. Fr the first link use the link ptin. Fr all ther links use the relink ptin. Nte: By default SnapVX link uses n-cpy mde. T have a stand-alne cpy with all the data frm the surce, a cpy mde can be used by adding -cpy t the cmmand. # symsnapvx sg FINDB_SG lnsg FINDB_MNT snapsht_name Snapsht_Backup relink # symsnapvx sg FINFRA_SG lnsg FINFRA_MNT snapsht_name FRA_Backup relink If ASM instance is nt running, fllw the steps in the Test Case 1 t start the ASM instance and update the ASM disk string. Munt the ASM disk grups that nw cntain the snapsht pint-in-time data. SQL> munt diskgrup DATA; SQL> munt diskgrup REDO; SQL> munt diskgrup FRA; Lg in t the database instance and munt the database (but d nt pen it with resetlgs). SQL> startup munt Optinally, catalg the backup data files (all in +DATA disk grup) with RMAN. RMAN> catalg start with +DATA nprmpt; 18

19 Test Case 3: Perfrming FULL r incremental RMAN backup frm a SnapVX replica Objectives: The purpse f this test case is t fflad RMAN backups t a Munt hst using SnapVX snapsht. The RMAN backup can be full r incremental. In incremental backup, RMAN Blck Change Tracking (BCT) is used frm the Munt hst. High level steps: 1. If RMAN incremental backups are used then enable blck change tracking n Prductin. 2. Perfrm Test Case 2 t create a recverable replica f Prductin and munt it t the Munt hst. 3. Perfrm RMAN full r incremental backup frm the Munt hst Grups used: Server Strage Grup ASM Disk Grup Prductin Hst FINDB_SG DATA, REDO FINFRA_SG FRA Munt Hst FINDB_MNT DATA, REDO FINFRA_MNT FRA Detailed steps: On Prductin hst: If RMAN incremental backups are used then enable blck change tracking n Prductin. Make sure that the blck change tracking file is created in the +FRA ASM disk grup. Fr example: SQL> alter database enable blck change tracking using file +FRA/BCT/change_tracking.f reuse; Perfrm Test Case 2 t create recverable replica f Prductin and munt it t the Munt hst. If RMAN incremental backups are used, make sure t switch BCT file manually after the step that archives the current lg file, as described in Test Case 2. At the end f this step, ASM disk grup +FRA will be munted t the Munt hst with the Blck Change Tracking file included, and Prductin s BCT file will start tracking blck changes with a new versin. On Munt hst: If n RMAN incremental backups are used then simply run RMAN backup script and perfrm a full database backup. Example fr creating full backup (simplest frm): RMAN> run { Backup database; } If RMAN incremental backups are used perfrm a full backup (als called level 0 backup) peridically, fllwed by level 1 backup. Fr example, a weekly level 0 backup and daily level 1 backups. The DBA can determine an incremental backup strategy between Differential r Cumulative incremental backups (refer t Oracle dcumentatin fr mre details). Example fr creating first full backup as part f incremental backup strategy: RMAN> run { Backup incremental level 0 database; } Example fr creating an incremental backup: RMAN> run { Backup incremental level 1 database; } 19

20 Verify fr level 1 backups that the BCT file was used: SQL> select cunt(*) frm v$backup_datafile where used_change_tracking='yes'; Test Case 4: Perfrming database recvery f Prductin using a recverable snapsht Objectives: The purpse f this Test Case is t leverage a previusly taken recverable snapsht t perfrm a database recvery f the Prductin database. The Test Case demnstrates full and pint-in-time recvery. It als demnstrates hw t leverage the Oracle 12c Strage Snapsht Optimizatin feature during database recvery. High level steps: 1. Perfrm Test Case 2 t create recverable replica f Prductin, thugh there is n need t munt it t the Munt hst. 2. Restre the SnapVX snapsht f +DATA ASM disk grup alne t Prductin. (D nt restre the +REDO ASM disk grup t avid verwriting the current red lgs n Prductin if they survived). 3. Recver the Prductin database using the archive lgs and ptinally the current red lg. Grups used: Server Strage Grup ASM Disk Grup Prductin Hst (Parent) FINDB_SG (Child) DATA_SG (Child) REDO_SG FINFRA_SG (DATA, REDO) DATA REDO FRA Detailed steps: On Prductin hst during backup: Perfrm Test Case 2 t create a recverable replica f Prductin. The linked target (r Munt hst) will nt be used in this scenari, nly the riginal snapsht f Prductin. On Prductin hst during restre: Restre the SnapVX snapsht f +DATA ASM disk grup alne t Prductin (d nt restre the +REDO ASM disk grup t avid verwriting the current red lgs n Prductin if they survived). T d s, use the child strage grup: DATA_SG instead f the cascaded strage grup FINDB_SG that was used t create the riginal snapsht. If Prductin s +DATA ASM disk grup was still munted then, as Grid user, use asmcmd r SQL dismunt it (repeat n all ndes if RAC is used). SQL> alter diskgrup DATA dismunt; Restre the SnapVX snapsht f the +DATA ASM disk grup alne. # symsnapvx sg DATA_SG snapsht_name Snapsht_Backup restre It is nt necessary t wait fr the snapsht restre t cmplete; hwever, at sme pint after it cmpleted, terminate the snapsht-restre sessin as a best practice. # symsnapvx sg DATA_SG snapsht_name Snapsht_Backup verify restred # symsnapvx sg DATA_SG snapsht_name Snapsht_Backup terminate -restred SnapVX allws using the surce devices as sn as the restre is initiated, even as backgrund cpy peratin f the changed data is taking place in the backgrund. There is n need t wait fr the restre t cmplete. Once the restre starts, the +DATA ASM disk grup can be munted n the Prductin hst t the ASM instance. As Grid user, using asmcmd r SQL munt DATA ASM disk grup (repeat n all ndes if RAC is used). SQL> alter diskgrup DATA munt; 20