1
Yaron Dar & Udgith Mankad VMAX Partner Engineering VMAX 3 AND ORACLE ORACLE BEST PRACTICES FOR REPLICATIONS, BACKUP/RECOVERY, AND PROTECTPOINT 2
ROADMAP INFORMATION DISCLAIMER EMC makes no representation and undertakes no obligations with regard to product planning information, anticipated product characteristics, performance specifications, or anticipated release dates (collectively, Roadmap Information ). Roadmap Information is provided by EMC as an accommodation to the recipient solely for purposes of discussion and without intending to be bound thereby. Roadmap information is EMC Restricted Confidential and is provided under the terms, conditions and restrictions defined in the EMC Non- Disclosure Agreement in place with your organization. 3
AGENDA Traditional Database Backups vs. Storage Snapshots Oracle BC/DR using VMAX 3 Local Replications Oracle BC/DR using VMAX 3 Remote Replications VMAX 3 and Oracle Replications Examples Oracle 12c EM DBaaS Snap Clone for VMAX VMAX 3 and Oracle Backup Offload with ProtectPoint 4
TRADITIONAL DATABASE BACKUPS VS. STORAGE SNAPSHOTS 5
LIMITATIONS OF TRADITIONAL DATABASE BACKUPS RMAN backup from Production: Requires Production s CPU resources Requires Production s host I/O resources (reads, then writes ) Full backup time depends on database capacity Recovery Time (RTO) depends on database capacity Recovery can t start until Full Backup image restored (zzz ) Recovery can t start until Incremental backups applied (zzz ) RMAN backup from Standby database Alleviate CPU and I/O overhead from Production All other considerations still apply Backups typically left to daily incremental with Full Backup weekly 6
ORACLE BACKUP OFFLOAD WITH STORAGE SNAPSHOTS Minimum requirements to recover Production data files: Backup using Oracle 12c (11g with some limitations) Create consistent PiT snapshot of Data Files Backup with Oracle prior to 12c Begin hot-backup mode Create snapshot of data files End hot-backup mode Additional requirements to create a stand-alone database backup add: On Production: Switch logs, archive logs, copy control file to FRA Create PiT snapshot of Archive logs (FRA) On Mount host: Perform RMAN backup from Mount host to Data Domain (or other) Open database read-only for Reporting Open database read-write for logical recoveries Open database read-write to start a database Clone 7
ORACLE BC/DR USING VMAX 3 LOCAL REPLICATIONS 8
EASILY MANAGE MANY COPIES WITH SNAPVX Production Volume Linked Target Linked Target 8 Start AM Snapshot of Day 9 AM Snapshot 10 AM Snapshot 11 AM Snapshot 12 PM Noon Snapshot 1 PM Snapshot 2 PM Snapshot 3 PM Snapshot 4 PM Snapshot 5 End PM Snapshot of Day Snaps as Versions Minimal Cache Minimal Management Best Performance 256 Snaps User-assigned Names Automatic Expiration 1024 Linked Targets Storage Group Operation Create, Restore Link no-copy, or copy 9
TIMEFINDER SNAPVX ADVANTAGES FOR ORACLE BACKUP No effect on Production s CPU or host I/O resources Each snapshot is a Full backup, yet small in capacity Snapshot time is always fast regardless of database size Oracle Storage Snapshot Optimization (12c feature) Backup snapshots without hot-backup RMAN can be used from Mount host (with Block Change Tracking) Data Integrity protection with T10-DIF With 256 snapshots and Oracle 12c Backup can be on-going! (short RTO!!) 10
TIMEFINDER SNAPVX ADVANTAGES FOR ORACLE Oracle Recovery advantages: As soon as SnapVX restore starts DB recovery can start! (short RTO) No incremental backups needed snapshot is always Full (short RTO) Frequent snapshots = shorter RTOs (less data to recover) RMAN recovery can be to Production or to Mount host ( logical recovery ) Oracle Restart advantages: Instant Database Clones for: Reporting, Test/Dev, BI, Patch test, etc. SnapVX snapshots are Consistent. Include: data, control, and log files SnapVX can create snapshots that are valid for both Recovery and Restart 11
VMAX3 AND ORACLE LOCAL REPLICATIONS EXAMPLES 12
ORACLE USE CASES CONFIGURATION Snap VX Link Data+REDO SRDF Group Setup for FINDB FINDB_SG DATA Snapshot Backup Reporting FINDB_MNT DATA FINDB_R2 DATA FINDB R2 Gold Copy REDO TEST Refresh REDO REDO Snap VX Link FRA Production FINFRA_SG FRA FINDB Storage Groups FRA 10:00 AM FRA Backup FRA Full Copy FINDB Snapshots FRAMNT_SG FRA FINDB Mount Storage Groups Mount FRAMNT_SG FRA Remote Copy FINDB R2 FRA Gold Remote Snapshots D/R 13
OFFLOAD BACKUP On Production Host Pre 12c: Begin backup mode FINDB_SG SQL> alter database begin backup; DATA Snapshot Backup Create DATA+REDO snap # symsnapvx -sg FINDB_SG name SnapshotBackup ESTABLISH REDO Pre 12c: End backup mode (prior to 12c) SQL> alter database end backup; Production FINFRA_SG FRA FRA Backup Archive current log and create backup control file SQL> alter system switch logfile; SQL> alter system archive log current; SQL> alter database backup controlfile to +FRA/CTRL_START REUSE; SQL> alter database backup controlfile to +FRA/CTRL_BKUP REUSE; FINDB Storage Groups Create FRA snap # symsnapvx -sg FINFRA_SG name FRABackup ESTABLISH 14
OFFLOAD BACKUP On Mount/Backup Host Snap VX Link Data+REDO Snapshot Backup Snap VX Link FRA FRA Backup FINDB_MNT DATA REDO FRAMNT_SG FRA FINDB Mount Storage Groups RMAN Catalog Backup Copy Mount RMAN BCT Backup RMAN Full Backup Link snaps to target storage group # symsnapvx -sg FINDB_SG name SnapshotBackup lnsg FINDB_MNT LINK # symsnapvx -sg FINFRA_SG name FRABackup lnsg FRAMNT_SG LINK Start ASM Instance if not already running SQL> startup Start ASM Instance if not already running SQL> alter diskgroup all mount; Mount Oracle instance using the control file copied in FRA DG SQL> startup mount Perform RMAN Operations Catalog mounted copy as the backup RMAN > catalog datafilecopy <DB file name> ; Run full/incremental backup RMAN cmdfile <backup script> 15
ORACLE 12C SNAPSHOT OPTIMIZATION FINDB_SG DATA REDO Storage Optimized Snapshot On Production Host - Snapshot Create DATA snap # symsnapvx -sg DATA_SG name StorageOptimizedSnapshot ESTABLISH [Optional] Create DATA+REDO snap Production FINFRA_SG FRA FINDB Storage Groups # symsnapvx -sg FINDB_SG name StorageOptimizedSnapshot ESTABLISH Note: This works as SnapVX allows restoring just DATA devices even though both DATA and REDO are involved in Snapshot 16
ORACLE 12C SNAPSHOT OPTIMIZED RECOVERY Shutdown Oracle instance SQL> shutdown immediate Dismount ASM diskgroup FINDB_SG SQL> alter diskgroup DATA dismount; Database Recovery DATA REDO Storage Optimized Snapshot Restore DATA Snap symsnapvx -sg Data_SG snapshot_name StorageOptimizedSnapshot restore Full or Point-in-Time Recovery Mount ASM diskgroup SQL> alter diskgroup DATA mount; Production FINFRA_SG FRA Use production host REDO and archived logs Full recovery: SQL> recover automatic database; SQL> alter database open; FINDB Storage Groups Point in time recovery: SQL> alter session set NLS_DATE_FORMAT="YYYY-MM-DD HH24:MI:SS"; SQL> recover database until time '2015-03-21 12:00:00' snapshot time '2015-03-21 11:50:40'; SQL> alter database open RESETLOGS; 17
ORACLE BC/DR USING VMAX 3 REMOTE REPLICATIONS 18
VMAX3 SRDF REMOTE REPLICATION JUST A REMINDER SRDF/Sync (SRDF/S) No data-loss of committed transactions Though - latency increases with distance SRDF/Async (SRDF/A) Consistent replications to any distance without latency overhead RPO of seconds to minutes SRDF/Adaptive Copy (SRDF/ACP) Migrations or bulk transfer before starting SRDF/S or SRDF/A SRDF/Multi-Session-Consistency (SRDF/MSC) Grouping of SRDF/A sessions with Consistency (can span arrays) Copyright 2015 2014 EMC Corporation. All rights reserved. 19
VMAX3 SRDF REMOTE REPLICATION JUST A REMINDER Concurrent SRDF Simultaneous replications from Production to two other sites Cascaded SRDF & SRDF/Extended-Distance-Protection (SRDF/EDP) Three-site replications, typically sync to bunker and Async to far site No data-loss at any distance SRDF/STAR Advanced three-site replications that can send to far site last transactions even when Production unavailable. Copyright 2015 2014 EMC Corporation. All rights reserved. 20
Causes for Silent Data Corruptions Data Centers have a tremendous amount of complex equipment Physical Data Corruptions can enter anywhere in the host and IO stack Memory errors Hardware / Firmware failure Software bugs Server hard crash Optical cables pulled or cut 21
T10-DIF (DATA INTEGRITY FIELD) IMPLEMENTATION WITH VMAX AND VMAX 3 Full end-to-end Data Integrity READ Application WRITE 520 bytes Host OS Host HBA Storage Array DATA (512 bytes) DIF Field Normal SCSI block Guard Tag (16 bit) Application Tag (16 bit) Reference Tag (32 bit) DIF (8 bytes) With T10 DIF protection DIF Content CRC TBD Lower 32 bit LBA Note: by default, within the array, VMAX and VMAX 3 protect ALL user data with T10-DIF. Now we can extend T10-DIF all the way to Oracle 22
T10-DIF Implementation with VMAX and VMAX 3 Combining DIX+DIF DIX = ASM OS HBA DIF = HBA Storage Minimum requirements for DIX + DIF ASM Filter Driver (Oracle 12c) - Oracle Linux / RHEL* / SuSE * ASMlib (Oracle 11g and above) - Oracle Linux 5.x or 6.x - Oracle UEK 2.6.39-200.24.1.el6uek or later - Oracle ASMlib 2.0.8 or later Host Bus Adapters - Emulex HBA LPe1200x - Qlogic HBA QLE267x-E-SP VMAX Operating Environments - VMAX w/enginuity 5876 or - VMAX3 w/hypermax OS 5977 VMAX or VMAX 3 RedHat 7.0 (DIF only, no DIX) * Consult with Oracle for latest AFD with T10-DIF OS support EMC Support Matrix: https://elabnavigator.emc.com/vault/pdf/emc_vmax_director_bit_settings_essm.pdf 23
SRDF ADVANTAGES FOR ORACLE Oracle Disaster Recovery advantages when using SRDF: No effect on Production s CPU or host I/O resources Consistency is created BEFORE a disaster, can span applications Target is Restartable and Consistent (across hosts, databases, message queues, external data, and applications) Full resiliency to Silent Data Corruptions Source can be T10-DIF protected from Oracle to VMAX storage VMAX always uses T10-DIF (including for TimeFinder and SRDF) 24
SRDF ADVANTAGES FOR ORACLE Oracle Backup advantages when using SRDF: SnapVX snapshots from Target can offload backups remotely With Oracle Storage Snapshot Optimization (Oracle 12c) Or with hot-backup mode (pre Oracle 12c) RMAN can be used by mounting SnapVX replica to a remote Backup host Oracle Recovery advantages when using SRDF: Parallel Recovery allows concurrent execution of remote SnapVX restore and SRDF restore (short RTO!) With Oracle Storage Snapshot Optimization (12c feature) and Archive logs on target target is RECOVERABLE 25
VMAX3 AND ORACLE REMOTE REPLICATIONS EXAMPLES 26
REMOTE PROTECTION USE CASES FINDB_SG R1 SRDF Group Setup for FINDB DATA REDO FRA SRDF/S SRDF/A FINDB_R2 R2 DATA REDO FRA FINDB_R2TGT D/R Snapshot Backup Reporting TEST Refresh FINDB_R2_FRA TGT FRA @ 10:00 AM FRA @2:00 PM Create devices and setup storage groups on remote VMAX 3 Create dynamic RDF groups for production storage groups FINDB_SG and FRA Create and Establish RDF pairs FINDB_SG can use sync mode where as FRA can just use async FINDB is RDF protected once establish completes SnapVX operations can be run to create gold copy or additional copies off R2 27
D/R USE CASES SRDF Restore After disaster SRDF failover to R2 R1 devices will be write disabled Prod FINDB_SG DATA REDO FRA SRDF/S SRDF/A FINDB_R2 DATA REDO FRA Gold Tgt Restore FINDB_R2TGT Restore Remote Backup Snapshot Backup D/R FINDB_R2_FRA TGT FRA @ 10:00 AM R2 devices will be RW enabled Application restart on R2 side [Optional] R2 devices can be restored using gold copy target [Optional] Remote backup can be restored to R2 devices to use prior to SRDF restore Parallel SRDF restore from R2 can be initiated R1 R2 SRDF Failover 28
ORACLE ENTERPRISE MANAGER 12C DBAAS SNAP CLONE WITH VMAX 29
ORACLE EM CC 12C DBAAS SNAP/CLONE What is DBaaS Snap/Clone Developed and shipped by Oracle (including VMAX support) DBA can View and Provision VMAX storage New storage is automatically mapped/masked to Hosts ASM Disk Groups created automatically DBA can create and refresh Test/Dev Clones of the DB Storage ceiling (capacity quota) is set per Thin Pool How does DBaaS Work with VMAX Use SMI-S 7.6.2 for VMAX 10K, 20K, and 40K Work for VMAX 3 support is in progress https://docs.oracle.com/cd/e24628_01/doc.121/e28814/cloud_db_portal.htm#emclo619 30
DBAAS SNAP/CLONE VMAX REGISTRATION 31
DBAAS SNAP/CLONE PROVISIONING 32
VMAX3 AND ORACLE BACKUP OFFLOAD WITH PROTECTPOINT 33
PROTECTPOINT OVERVIEW Integration between best of breed products: VMAX 3, SnapVX, and Data Domain Data Domain connected to VMAX 3 backend via FTS (Federated Tier Storage) Leveraging new Data Domain block-device service Encapsulation of Data Domain Backup and Restore devices via FTS The encapsulated devices can be used by TimeFinder SnapVX ProtectPoint File System Agent: CLI based tool (great for Oracle ASM) ProtectPoint Application Agent: fully integrated with RMAN (but not Oracle ASM) http://www.emc.com/collateral/white-papers/h14777-vmax3-protectpoint-file-system-agent-vmax3-wp.pdf 34
PROTECTPOINT BENEFITS Complete Backup & Restore offload from Production No host I/O or CPU utilized for copy of database files Backup, Restore, and Recovery performed by the DBA Backup benefits SnapVX snapshots are always fast regardless of DB size! Only changed data sent to Data Domain (Faster copy) Backups are always Full (Shorter RTO) SnapVX consistency + Oracle 12c = no need for Hot Backup mode! Data Domain Compression, Dedup, and remote replications Recovery benefits Short RTOs when performing recovery from the encapsulated devices Data copy is done within the integrated system http://www.emc.com/collateral/white-papers/h14777-vmax3-protectpoint-file-system-agent-vmax3-wp.pdf 35
ProtectPoint File System Agent Backup Workflow Management host Oracle Production Backup: Pre 12c: Hot backup start +Data +Redo +FRA 1a 1b 2 2 +Data +Redo +FRA 2 Data Domain static-images (1a) ProtectPoint Snapshot Create: Data, REDO Pre 12c: Hot backup end Switch logs, Archive logs, backup control file (1b) ProtectPoint Snapshot Create: FRA (archive logs) VMAX 3 Native Devices Snaps Encapsulated Backup vdisks (2) ProtectPoint Backup VMAX 3 Full backup yet only changed data is copied Data Domain 36
ProtectPoint File System Agent Recovery Workflow Oracle Production Oracle Mount host (optional) Restore: 4c 4b 4a ProtectPoint Backup Show List (choose a backup ID) +Data +Redo +FRA Data Domain static-images 3 +Data +Redo (3) ProtectPoint Restore (4a, Restart) Logical recovery on Mount host (4a, Recovery) Read-only inspection on Mount host VMAX 3 VMAX 3 Native Devices Data Domain +FRA Encapsulated Restore vdisks Snaps (4b) Production recovery using encapsulated devices (4c) Production overwrite with Backup 37
RELATED SESSIONS Session Title Day / Time Slot Session Title VMAX3 & Oracle: Oracle Deployment Best Practices With VMAX3 FAST & Other New Integrations Tuesday, May 5, 4:30 PM Thursday, May 7, 10:00 AM VMAX3 & Oracle: Oracle Deployment Best Practices with VMAX3 FAST & Other New Integrations VMAX3 & Oracle: Oracle Best Practices For Replications, Backup/Recovery & The Integrated Data Domain (ProtectPoint) Monday, May 4, 12:00 PM VMAX3 & Oracle: Oracle Best Practices For Replications, Backup/Recovery & The Integrated Data Domain (ProtectPoint) Wednesday, May 6, 8:30 AM VMAX3: The Replication Revolution VMAX3: The Replication Revolution Tuesday, May 4, 8:30 AM Thursday, May 7, 8:30 AM VMAX3: Unleash the power of Service Level Objectives What's New With ProtectPoint: Redefining Backup With VMAX3 & Data Domain Monday, May 4, 1:30 PM Wednesday, May 6, 8:30 AM VMAX3: Performance Monitoring Made Simple Tuesday, May 5, 3:00 PM Thursday, May 7, 8:30 AM 39