DISASTER RECOVERY STRATEGIES FOR ORACLE ON EMC STORAGE CUSTOMERS Oracle Data Guard and EMC RecoverPoint Comparison

Transcription

1 DISASTER RECOVERY STRATEGIES FOR ORACLE ON EMC STORAGE CUSTOMERS Oracle Data Guard and EMC RecoverPoint Comparison

2 Document Control Change Record 3 Date Author Version Change Reference 15-Aug-2007 Ravi Krishnaswami 1.0 First version 18-Aug-2007 Ravi Krishnaswami 2.0 Updates based on feedback 4-Oct-2007 Ravi Krishnaswami 4.0 Updated doc based on EMC feedback 17-Oct-2007 Ravi Krishnaswami 4.6 Added diagrams and URL for OTN and EMC links Reviewers Name Shankar Jayaganapathy Bill Gaynor David Wallace Matt Sebastian Jamie Shikiya Alex D Anna Jeff Barnard Jason Kotsaftis Position Director, Oracle Partner Programs Technical Manager, Oracle Partner Programs Senior Principal Consultant, Oracle Partner Programs Senior Principal Consultant, Oracle Partner Programs Technical Consultant, EMC Technical Consultant, EMC Technical Alliance Manager, EMC Oracle Alliance Marketing, EMC Distribution Copy No. Name Position / Location ii

3 Contents Overview..4 Executive Summary 4 Solutions Overview 5 Data Guard and RecoverPoint Comparison. 8 Disaster Recovery Requirement Scenarios..13 Conclusion.14 iii

4 Overview Executive Summary Oracle and EMC each offer disaster recovery solutions that can be utilized by Oracle customers using EMC storage. Oracle offers Oracle Data Guard, a native Oracle capability included with the Oracle Database Enterprise Edition. EMC offers RecoverPoint. Through combining the best attributes of both of these technologies Oracle and EMC together are able to offer a holistic solution for disaster recovery at the lowest total cost. The motivation to write this short paper came from Oracle on EMC client requests for a comparative assessment document that would compare Oracle Data Guard and EMC RecoverPoint. The objective of this document is to come up with a comprehensive list of criteria/features/capabilities for an effective disaster recovery strategy and use this list as a framework for evaluating RecoverPoint and Data Guard. Details of this comparison are provided in a later section of this document. An effective disaster recovery solution needs to be able to satisfy the service level agreements for Recovery Time Objectives (RTO), Recovery Point Objectives (RPO) and Oracle data corruption protection. Recovery Time Objective (RTO) is the measurement of the amount of time that a customer will not have access to data while the data is being recovered. Recovery Point Objective (RPO) is the measurement of the point in time to which data must be restored in order to resume processing business transactions. RTO and RPO for mission critical business data need to be established while evaluating disaster recovery solutions. Data corruptions typically fall into two categories: Physical data corruptions and Logical data corruptions. Physical corruptions are usually caused by failure of different components that make up the infrastructure stack including HBA, File System, Operating System, Memory, NIC, RAID, Switch, and Controllers etc. Logical data corruptions are caused by human errors such as deleting wrong tables, running wrong jobs, updating or deleting wrong set of tables and rows etc. Requirements for tolerance to physical and logical data corruptions also need to be established while evaluating disaster recovery solutions. A summary of the detailed comparative analysis in this paper is as follows: Oracle Data Guard is a compelling solution for Oracle customer environments with the following requirements: 1. Aggressive Recovery Point and Recovery Time Objectives for mission critical applications where there is little tolerance for data loss or downtime. Note in such cases where mission critical data also includes non-oracle database data, EMC recommends augmenting the Oracle Data Guard disaster recovery solution with EMC RecoverPoint for protecting non-oracle database data. 2. Highest possible level of protection from physical and logical data corruptions.

5 3. A desire to reduce cost associated with using specialized storage subsystems, network hardware, and protocols, or the integration of high availability components from multiple vendors. 4. An ability to perform rolling database upgrades with minimal downtime. 5. Full resource utilization, including utilizing standby storage and servers for ad-hoc queries, reports, fast incremental backups and test activities, all without compromising data protection even to the degree that a single replica can support each of these activities at different times of the day. 6. A desire to enhance primary database performance by making dual-use of the disaster recovery standby database to offload queries and reports that require access to an up-to date replica of the primary database. EMC RecoverPoint is a compelling solution for Oracle customer environments with the following requirements: 1. Where there is a significant volume of dynamic data that resides outside of the Oracle database, either in O.S. files or in a database management system from another vendor, and a single replication solution is desired to reduce costs and simplify management. Note that in such cases, and where aggressive RPO/RTO objectives exist for the Oracle data, Oracle recommends augmenting EMC RecoverPoint with a Data Guard standby database. 2. Limited network bandwidth is a primary concern, making full time, nonhost based compression for all data transmitted over the network a fundamental requirement. 3. The need to be able to throttle the network bandwidth used by the disaster recovery solution. 4. The need to deploy a large number of standby databases, with flexible and less aggressive RTO and RPO requirements, where the primary requirement is the ability to implement a single disaster recovery solution that can replicate database and non-database mission critical data. Solutions Overview: For Oracle on EMC storage customers there are different solutions available today to protect mission critical business data from disasters, data corruptions and other primary site failures. An effective disaster recovery solution should be able to quickly restore business operations and provide business continuity and data protection while making effective use of all assets while in standby role. Oracle Data Guard Oracle Data Guard available as part of Oracle s Enterprise edition is an Oracle solution to create, maintain, and monitor one or more synchronized standby databases to protect Oracle data from failures, disasters and corruptions. Oracle Data Guard can support zero data loss and near zero down times. Data Guard also supports rolling database software upgrades for major releases and patchset upgrades with near zero downtime. Data Guard can enable automatic and quick fail-over to a standby database in the event of a primary database failure. When used in conjunction with Oracle Flashback Database, Data Guard provides a Continuous Data Protection Solution (CDP). Data Guard s native integration within the Oracle kernel enables continuous, Oracle-aware, data validation that prevents

6 data corruptions from being applied to the standby database, offering a unique level of data protection not possible with any other solution. Depending on the business requirements for data protection, availability and performance, Data Guard can be configured in one of the following 3 modes: Maximum Protection, Maximum Availability, & Maximum Performance. Data Guard complemented with Oracle Real Application Clusters (RAC) can uniquely address scalability, high availability and disaster recovery requirements for an Oracle database and can satisfy aggressive recovery time objectives (RTO) and recovery point objectives (RPO). Oracle Active Data Guard, an option available for Oracle Database 11g Enterprise Edition, can enhance Quality of Service by offloading resource intensive activities from a production database to one or more synchronized standby databases. There are no distance limitations with Oracle Data Guard. The following diagram below illustrates automatic updating of a Data Guard physical standby database. Refer to the following link for more info on Oracle Data Guard: EMC RecoverPoint EMC RecoverPoint is a solution that can provide both business continuity and data protection for Oracle database environments. RecoverPoint is an out-of-band replication product from EMC. RecoverPoint leverages a fabric-based out-of-band appliance approach that tracks every write that occurs in the source database storage volumes and writes them in parallel to the local RecoverPoint appliance. All the writes are journaled, pooled and replicated to the remote disaster recovery site to provide Continuous Remote Replication. EMC RecoverPoint uses time stamped history volumes and Bookmark features to provide bookmarked recovery points. These recovery points can be immediately accessed and mounted back to production environments within a very short time. RecoverPoint uses the following bandwidth reduction technology features: Delta Differentials, Hot Spot Identification, De-Dup, and Algorithmic Compression. These

7 bandwidth reduction technology features can help reduce the overall network utilization of the disaster recovery solution. Recovery Point also provides capability to throttle the network bandwidth utilized by the disaster recovery solution. RecoverPoint is database agnostic and can be used to replicate heterogeneous database environments. RecoverPoint can also be used to replicate mission critical data that is residing outside the database in operating system files. There are no distance limitations with EMC RecoverPoint as well. The following diagram illustrates Recover Point network based Continuous Remote Replication. SAN WAN SAN Third- Party EMC EMC Third- Party RecoverPoint splitter drivers Intercepts server writes (block-level) Resides on host or in fabric Mirrors write to RecoverPoint appliance RecoverPoint appliance Journal writes to History Volume Manages and prioritizes resources Compresses data for WAN transfer Distributes changes to remote site Manages recovery processes Supports instant access to protected data Journal Tracks all data changes to every protected LUN Utilizes bookmarks for application-aware recovery Repository for live data updates Provisioned from existing SAN LUNs Dynamically compressed, which saves storage Provides advanced functionality Policy-based bandwidth management 3 15-times data compression Lowers cost of IP infrastructure Supports heterogeneous environments Works with EMC and third-party storage True any-to-any volume replication Refer to the following link for more info on EMC Recover Point:

8 Data Guard and RecoverPoint Comparison Comparison Criteria Data Guard RecoverPoint Replication Type Host based replication where Oracle transmits redo data from primary database transactions and applies the changes to the standby database. Fabric Based Out-Of-Band Appliance that transmits and applies changed blocks. Supported Replication Modes Recovery Point Objective (RPO): Can it support zero data loss? Maximum Protection (Synchronous), Maximum Availability (Synchronous), Maximum Performance (Asynchronous). All modes support Continuous Data Protection (CDP) using Oracle Flashback Database.. Maximum Protection and Maximum Availability modes support zero data loss. Minimal data loss is supported with Maximum Performance mode (ASYNC). Continuous Remote Replication (CRR): Async Only RecoverPoint does not support zero data loss since it can t support synchronous replication. Minimal data loss is supported with Asynchronous mode. What gets transmitted over the network for an Oracle database replication Data Guard only transmits primary database redo log writes to the disaster recovery site. RecoverPoint solution transmits primary database redo log writes, data file writes, other online logfile member writes, archive log file writes, control file writes and flashback log writes. Recovery Time Objective (RTO): Can it support zero down time? A Data Guard standby database is always mounted and in continuous recovery mode. This enables very fast failovers, achieving near zero downtime should the primary site fail. RTO is largely dependent on the host reconfiguration in the DR side. The Oracle database is not mounted, activating the standby database as primary requires some time and involves manual administrative tasks. Failover capability: Support for Automatic Failover during unplanned downtime?. The 'Fast-Start Failover' capability allows Data Guard to automatically and quickly fail over to a standby database in the event of loss of the primary database. There is no need for any manual steps to invoke the failover. When old primary is repaired Data Guard automatically reinstates it to be the new standby database. Additional features in the Oracle tech stack can be leveraged to enable failing over the application as well. No. RecoverPoint does not automatically mount and open the database. It is an administrative task. For Continuous Remote Replication (CRR), the image at the secondary site must be promoted to a host on the secondary site. Database needs to be mounted and opened. Fail-Back capability With Flashback Database configured it is It is an administrative task, including replicating the possible to quickly resynchronize the failed changed data back to the primary site, then mounting to primary and fail-back to the primary side with the image as presented in the journal volume at the zero data loss. primary site. Switchover capability for planned downtime Data Guard provides an integrated switchover capability for planned maintenance such as hardware or OS upgrades and patching. Switchover can be executed with downtime measured in seconds because a Data Guard standby database is always mounted. RecoverPoint provides switchover capability as well. This switchover procedure can be scripted using the RecoverPoint CLI and the script can be invoked when a switchover is needed. It can be done manually as well using the RecoverPoint GUI with a few clicks.

9 Distance Limitations / Latency None None Hardware/Software requirements for data transport between primary and standby sites. License cost for Replication Data is transported from the primary side to the standby side over the standard TCP/IP based network using existing Oracle Net Services. RecoverPoint Appliances uses pairs of Active-Active servers that will write order, compress, and replicate the data to pairs of RecoverPoint Appliances at the secondary DR site. In addition, you need to use host based agent to do the write split or you can get SANTap module from Cisco or Brocade to do write split at the SAN switch level. Available at no extra charge with the Oracle Licensed by Terabyte for RecoverPoint or Licensed by Database Enterprise Edition. Active Data Array pair for RecoverPoint /SE (for Microsoft Windows Guard, which provides advanced features for / EMC CLARiiON environments). read access to a synchronized physical standby database, is a separately priced option in Oracle Database 11g. FC to IP conversion Not needed Not needed if the write splits are configured using hostbased drivers. If write splits are configured at the SAN level, FC to IP conversion is completed automatically by the RecoverPoint Appliance, which has an HBA connection to the FC initiator and target, and also via Ethernet GigE ports to the WAN. Re-Purpose capability Logical Standby databases are always of the database at DR site for reporting or test purposes during normal operations mounted and open read-write, making them very flexible for offloading the primary database of ad-hoc queries and reports. A Physical Standby database is always mounted, and when using the Oracle Active Data Guard option, can be open read-only while being actively synchronized with the primary database. This enables read-only queries and reports that need access to up-to-date information to be offloaded to a physical standby database. In addition, Data Guard Snapshot Standby enables a standby database to be opened read-write to process transactions that are independent of the primary database for test or other purposes. A snapshot standby continues to receive and archive primary database changes while it is open read-write. This provides continuous data protection, and the local archive is used to quickly resynchronize the standby database with the primary once test activity is complete. These features allow standby databases to be used to enhance primary database performance and support test activities, improving ROI without compromising RTO/RPO objectives. RecoverPoint allows the mounting of a Read/Write point-in-time image of the replicated data to a host on the disaster recovery side for reporting purposes. This mounted copy and the reporting usage has no effect on the ongoing journaling and does not interrupt or interfere with the disaster recovery replication solution. Compression In Oracle Database 11g, Data Guard compresses data that is transmitted to resolve a redo gap, caused by the standby database falling behind a primary database due to a network disconnect or a standby server outage. Compression and De-dup features are available with RecoverPoint for all the data transmissions over the network.

10 Bandwidth usage throttling capability Server utilization at the DR site Bandwidth usage throttling is not available with Data Guard. Data Guard design goal is to reduce RPO. Bandwidth usage throttling conflicts with that goal, since anything that delays transmission will increase the risk of data loss. Complete utilization of the server and storage at the DR side for ad-hoc queries, reporting, test, cloning and backup activities. Standby servers can also be used to host other databases and applications while in standby role. Bandwidth used for replication can be throttled with RecoverPoint. With RecoverPoint, you can utilize the standby servers to host other databases and applications. If RTO is flexible, servers in the DR side can be fully utilized for test/dev and other purposes during normal operations. When there is primary side failure, the server in the DR side needs to be re-purposed to serve as the new primary database server. RecoverPoint does not allow you to utilize the storage being consumed by the replicated volumes as you can with Data Guard to offload the primary database of ad-hoc queries and reports against an up-to-date replica of the primary. Network Utilization / Bandwidth cost Oracle System Change Number (SCN) awareness and capability to flashback to a specific Oracle SCN Capability to replicate just a subset of the database Only redo data is sent over the WAN with Data Guard (as opposed to sending data files, redo files, control files etc). Since each change on the primary side is only sent once, Data Guard transport mechanisms are designed to efficiently utilize network bandwidth and minimize RPO. Within an Oracle database, when a user commits a transaction, the transaction is assigned a System Change Number (SCN), which Oracle saves along with the transaction s redo entries in the redo log. SCN aware Data Guard implementation takes full advantage of Oracle flashback features and provides granular recovery capabilities and flashback to an SCN capability... In a Data Guard Logical Standby configuration, Oracle provided DBMS_LOGSTDBY package could be used to skip applying DML or DDL to selected tables or entire schemas in the standby database. However, in general, Oracle recommends Oracle Streams for more granular replication requirements. Data files, control files and archived and online redo log files needs to be replicated. In addition if the flash recovery area is also on the source volumes then the flash back logs will get replicated as well. So each change on the primary side is sent multiple times to the remote site. This increases the volume of data that must be sent over a WAN. RecoverPoint uses bandwidth reduction technology features (such as Delta Differentials, Hot Spot Identification, De-Dup, and Algorithmic Compression) to reduce overall WAN utilization. RecoverPoint is not Oracle SCN aware. (Note: There was a one-off custom version of RecoverPoint for Oracle 9i on Solaris 8 that was Oracle SCN aware. Going forward with Oracle 10g, RecoverPoint is NOT Oracle SCN aware.) RecoverPoint replication is at the LUN level. It is theoretically possible to replicate a subset of the database if you isolate the subset of the database objects to physically reside on separate LUNs. Oracle data corruption Data Guard only propagates the redo data, protection & Resiliency and Oracle validates redo data before it is applied to the standby database. Data Guard detects physical corruptions that are caused by the underlying storage subsystem that the storage subsystem cannot detect. One example is lost write detection feature in Oracle Database 11g using a physical standby database, that can detect if a lost write has occurred on either the primary or standby Data corruptions introduced on the primary production database will be replicated to the DR site since there is no Oracle data corruption detection possible with RecoverPoint.

11 database. This ensures data protection from various physical corruptions and eliminates the possibility of corrupt data being propagated to the DR site. Data Guard logical standby (SQL Apply) can be used to provide additional protection against logical corruptions. State of the Standby database at the DR site during replication In a physical standby configuration, the standby database is always mounted. In a logical standby configuration, the standby database is always open. In both cases, data is validated before it is applied. In a RecoverPoint configuration, the target volumes that are being replicated are not mounted while the replication is going on. During a fail-over, the replication process is turned off, the database is mounted and opened. This will be the first opportunity to evaluate the condition of the database. Bi-directional replication of a database Support for Federated DB Replication is one direction at any given time. Replication is one direction at any given time. A separate standby database is required for each distinct primary database.. A single fabric-based replication strategy with RecoverPoint can more easily handle Federated DB architectures. Support for Heterogeneous DB (Oracle, SQL, DB2 etc.) Support any Point-In- Time recovery Local replication? Remote Replication capabilities? File system data protection No. Data Guard with Flashback Database. both local and remote replication possible. No. Data Guard can only protect data inside Oracle databases. Data Guard does not protect any data that is residing outside the Oracle database in a file system.. RecoverPoint is database agnostic. It can protect heterogeneous mix of databases (such as Oracle, SQL, DB2) on the SAN.. With Bookmarks feature. RecoverPoint supports both local (CDP/Continuous Data Protection) and remote (CRR/Continuous Remote Replication) with EMC or other arrays, as per the EMC support matrix.. RecoverPoint is database agnostic. It can protect file system data. Network outage impact on primary database availability Rolling database upgrades with minimal downtime No impact to primary database.. Oracle Data Guard SQL Apply supports database software upgrades for major release and patchset upgrades (from Oracle Database 10g onwards) in a rolling fashion with near zero database downtime. No impact on the primary database. No support for rolling database upgrades. One-To-Many Replication. You can also do cascaded destinations where a standby database receives its redo data from another standby database instead of the original primary database. This can reduce load on the primary system. Manageability & Monitoring capabilities GUI based management and monitoring capabilities including lag alert notifications. GUI based management and monitoring capabilities Oracle 10g RAC support

12 Oracle 10g ASM support Support all Operating Systems Pause and Restart replication easily? Support for heterogeneous storage environments between primary and DR site Most operating systems supported. Refer to EMC support matrix. Support for, subject to the limitations described in Heterogeneous Host MetaLink note Operating Systems between Primary & DR side? Not supported. Different Oracle versions between Primary and DR side? Same release of Oracle Enterprise edition is required on primary side and all the standby side. Only exception is during rolling database upgrades. Same release of Oracle required on both Primary and DR side. Number of vendors involved in the DR strategy for an Oracle infrastructure Since Data Guard is part of the Oracle Multiple vendors involved in the implementation of a DR Enterprise edition, a DR strategy using Oracle strategy for an Oracle database. RecoverPoint introduces Data Guard requires less integration since it a replication technology that is database agnostic and does not have any other vendor dependency. will work with heterogeneous storage arrays. Any component swap has implications to DR protection and overall robustness of the solution. Consistency group across multiple applications, databases and file systems for storage infrastructure wide continuous data protection. Data Guard is intended to protect individual Oracle databases only. Cannot provide storage infrastructure wide continuous data protection.. EMC offers a capability to group all the LUNs that make up the entire EMC storage infrastructure into a consistency group and perform a consistent split on multiple application, database, and file system related LUNs. This capability provides continuous data protection for the entire storage infrastructure.

13 Disaster Recovery Requirement Scenarios Below are multiple scenarios to help provide tangible examples of use cases in which Oracle Data Guard and EMC RecoverPoint can be combined to deliver a holistic solution for disaster recovery. Scenario 1: Several mission critical databases having RPO s/rto s that range from zero data loss RPO and an RTO of 60 seconds during production hours, to RPO s/rto s measured in minutes. Additionally, there is a requirement for fast point in time recovery up to 8 hours prior to the current point in time to recover from user error. Data protection and availability is very important thus any capability that can protect against hardware induced data corruptions is highly desired. The applications using these databases require high Quality of Service for executing business transactions thus it is also desirable to offload the primary database of the overhead of long running ad-hoc queries and reporting that require read access to the current information (the replica must be within 15 seconds of the primary database). Additionally, the customer would like to reduce downtime required while implementing database upgrades, and reduce storage requirements for additional test databases. Solution for Scenario 1: Oracle Data Guard physical standby database in Maximum Availability Mode using synchronous replication is configured to meet the most stringent RPO requirement. Fast-Start Failover is configured to meet the most stringent RTO requirement. For RPO/RTO in minutes Data Guard Maximum Performance mode is used. Oracle data validation, including Oracle Lost-Write Detection, is utilized to prevent data corruptions. Flashback Database with an 8-hour retention period is used to meet the CDP requirement. The standby databases are used to offload long running ad-hoc queries and reporting during peak production hours using Active Data Guard (this allows physical standby databases to remain synchronized while open for read access). During off-peak hours the same standby databases are used to offload the primary of doing fast incremental backups using Oracle Recovery Manager block-change tracking. In emergencies or during off-peak hours, the standby databases can be open read/write for testing database changes and application fixes using Data Guard Snapshot Standby, and then quickly resynchronized with their primary database when testing is complete. Data remains protected the entire time the snapshot standby is being used for test purposes (the primary database continues to ship data to the snapshot standby where it is archived for protection and used to resynchronize the standby database once testing is complete). During periods of planned maintenance, database rolling upgrades are executed using the same physical standby databases and the Data Guard 11g feature called Transient Logical Standby. Scenario 2: The customer has 10 different production databases hosted on a single SAN. The databases are a mix of Oracle and non-oracle DBMS. RPO and RTO of up to 8 hours are acceptable. There is no concern for consolidating storage required to offload reporting, testing or backups. The primary database workload is light with no concern for offloading queries, reports, or other long-running operations. There is no concern for rolling database upgrades extended periods of planned downtime are acceptable. Network bandwidth is limited and is a primary concern, thus more data loss exposure and downtime are acceptable trade-offs for a solution that can compress all data transmission. Given the less stringent requirements for data protection and availability, a single replication solution is preferred to address databases from multiple vendors as well as data residing outside the database in operating system files. Solution for Scenario 2: Fabric-based replication strategy using EMC RecoverPoint with compression and bandwidth throttling would be very ideal for this scenario.

14 Conclusion With over 55,000 joint customers, including each other, Oracle and EMC provide the information infrastructure for most of the world s most critical information. Oracle and EMC both provide customers various options for data protection and availability. When combining the best of both technologies from Oracle and EMC, IT organizations can deploy a robust enterprise disaster recovery strategy at the lowest cost. It is recommended to use the guidelines and detailed analysis contained in this document to analyze your cost, recovery point and recovery time objectives and to design the solution that is best for your organization.

15 Disaster Recovery Strategies for Oracle on EMC storage customers Oracle Data Guard and EMC RecoverPoint Comparison Author: Ravi Krishnaswami Contributors: Shankar Jayaganapathy, Bill Gaynor, David Wallace, Matt Sebastian, Jamie Shikiya, and Alex D Anna