Data Guard and Complementary Technologies

Data Guard and Complementary Technologies

 

 

Oracle Real Application Clusters

Oracle Data Guard and Real Application Clusters (RAC) are complementary to each other. RAC addresses system failures. It provides rapid and automatic recovery from failures that do not affect data - such as node failures, or instance crashes. It also provides increased scalability for an application. Data Guard, on the other hand, provides data protection through the use of transactionally consistent primary and standby databases, which neither share disks nor run in lock step. This enables recovery from site disasters or data corruptions.

Both Data Guard Redo Apply (physical standby database) and Data Guard SQL Apply (logical standby database) can be used with RAC. 

Customers should use a combination of Oracle Data Guard and Real Application Clusters to get the benefits of both data-level and system-level protection, resulting in an end-to-end High Availability solution. Please refer to Oracle's Maximum Availability Architecture framework for best practice recommendations on integrating Oracle Data Guard and Oracle Real Application Clusters for a highly available architecture.


Oracle Streams

Oracle Streams and Oracle Data Guard (including Data Guard SQL Apply) are independent features based on some common underlying infrastructure and technology. Data Guard depends on the Log Writer process or the Archiver process to capture and send redo data to the standby. Redo Apply uses media recovery to apply block level changes made at the production database to the physical standby. SQL Apply uses "LogMiner-based technology" on the standby site to "reconstitute" the SQL (that was run on the primary database) and an "Apply Engine" to then apply the SQL to the logical standby database.

Streams on the other hand uses log data captured with LogMiner-based technology on the source system as its capture mechanism from which logical change records (LCR) are generated. Transport is via NET8 and "queues". Subsequently, the "Apply Engine" applies the changes (LCRs) to the Streams "replica". 

Oracle recommends that Data Guard be used for Disaster Recovery and High Availability, and Streams be used for Information Sharing/Distribution. The reason is that Oracle Data Guard is designed specifically for the creation and management of standby databases used as part of an overall Disaster Recovery plan. It automates the procedures necessary to create standby databases, keep them synchronized with the primary, and make it easy to switch over and switch back during planned system outages. In the worst case scenario of a complete loss of a data center, users can again have access to their data in a matter of minutes if the database is protected by Oracle Data Guard. 

On the other hand, Oracle Streams provides much finer granularity and control over what is replicated and how it is replicated. It supports bi-directional replication, data transformations, subsetting, custom apply functions and heterogeneous platforms. It also gives users complete control over the routing of change records from the primary database to a replica database. This allows users to build hub and spoke network configurations that can support hundreds of replica databases.

 

Remote Mirroring Solutions

Remote Mirroring solutions conceptually appear to offer simple and complete data protection. However, for data resident in Oracle databases, Oracle Data Guard, with its in-built zero data loss capability, is more efficient, less expensive and better optimized for data protection and disaster recovery than traditional remote mirroring solutions. 

Remote mirroring solutions do add value by protecting non-Oracle-database-data (e.g. filesystem data, or data in a database that is not Oracle). However, customers do not need to buy or integrate any remote mirroring solution with Oracle Data Guard to get any special data protection benefit for their Oracle databases. 

The following sections provide details on the relative advantages of using Oracle Data Guard compared to using remote mirroring solutions for data protection and disaster recovery scenarios for Oracle databases. Click here for a table summarizing these benefits.

 

  • Better Network Efficiency - With Oracle Data Guard, only the redo data need to be sent to the remote site. However, if a remote mirroring solution is used for data protection, typically the database files, the online logs, the archive logs and the control file must be mirrored. This means that remote mirroring will send each change at least three times to the remote site.

Further, database writes happen a lot more often than log writes because each log write typically contains many changes (known as group commit). This means that the network bandwidth needed for a database log shipping based solution is considerably less than that of a remote mirroring solution. Even more importantly, this means far fewer network round trips.

In an internal analysis of Oracle's corporate e-mail systems, as shown in the following graph, it was demonstrated that 7 times more data was transmitted over the network and 27 times more I/O operations were performed using a remote mirroring solution, compared to using Data Guard.

 

 

  • Better suited for WANs - Remote-mirroring solutions based on storage systems often have a distance limitation due to the underlying communication technology (Fibre Channel, ESCON) used by the storage systems. In a typical example, the maximum distance between these two boxes connected in a point-to-point fashion and running synchronously can be only 10 km. Using specialized devices this can be extended to 66 km. However, when the standby data center is more than 66 km apart, a series of repeaters and converters from third party vendors have to be used. These devices convert ESCON/Fibre Channel to the appropriate IP, ATM or SONET networks. 

This approach adds to the overall cost, because, besides the remote mirroring solution, there is also a cost associated with the converters. Secondly, this may introduce latency in the system, impacting the production database performance and making such a configuration especially unsuitable for synchronous transport (necessary for the zero data loss capability) for any distance greater than a LAN. This problem may be mitigated by introducing intermediate storage boxes in the communication path, but that only adds to the overall cost. The other solution is to use variations of synchronous transmission - however, depending on the remote mirroring solution, anything other than synchronous transmission of data may not preserve write ordering across all mirrored volumes that the database resides on. This means such configurations cannot guarantee data consistency at all times, making them unsuitable as a data protection / disaster recovery solution for OLTP data.

Since Data Guard transmits only redo data to the standby sites, using a standard IP network, and preserves transactional consistency across all the protection modes (i.e. whether using synchronous or asynchronous mode of transport), and does not need expensive interim storage boxes, it is a much better DR and data protection solution for a WAN.

 

  • Better resilience and data protection - Oracle Data Guard ensures much better data protection and data resilience than remote mirroring solutions, since corruptions introduced on the production database are likely to be simply mirrored by remote mirroring solutions to the standby site, but are eliminated by Data Guard. For example, if a stray write occurs to a disk, or there is a corruption in the file system, or the Host Bus Adaptor corrupts a block as it is written to disk, then a remote mirroring solution will most likely propagate this corruption to the DR site. Because Data Guard only propagates the redo data in the logs, and the log file consistency is checked before it is applied, all such external corruptions are eliminated by Data Guard.

In addition, Oracle Data Guard is integrated with the Flashback Database feature, and allows application of changes to be delayed as well. These capabilities prevent many human errors and data corruptions from propagating, and/or affecting the standby database. Remote mirroring does not have that advantage - any inadvertent drop of a critical table will be instantly propagated to the remote copy of the database files.

SQL Apply further improves the resiliency of the standby by translating the redo back to SQL. This inherently validates the changes. Also, it makes it possible to potentially skip certain changes. None of these are possible with remote mirroring solutions.

 

  • Higher Flexibility - Data Guard is implemented on top of pure commodity hardware. It only requires a standard TCP/IP-based network link between the two computers. There is no fancy or expensive hardware required. It also allows the storage to be laid out in a different fashion from the primary. For example, customers can put the files on different disks, volumes, file systems, etc. 

On the contrary, remote mirroring solutions are restrictive in the sense that many of these remote mirroring solutions are proprietary and can be used with only the identically configured storage systems from the same vendor that manufactures these remote mirroring solutions. This restriction is an important point to bear in mind as customers choose the configurations of their DR sites. One Data Guard customer - a large insurance company, who has its primary site storage from one vendor, chose another vendor as the storage for its DR site (for business reasons). They could not have done that if they were using a remote mirroring solution.

 

  • Better Functionality - Data Guard, with its full suite of data protection features - e.g. Redo Apply (physical standby databases), SQL Apply (logical standby databases), multiple protection modes, push-button automated switchover/failover capabilities, automatic gap detection and resolution, GUI-driven management and monitoring framework, cascaded redo log destinations, etc., is a much more comprehensive and effective solution optimized for data protection and disaster recovery, than remote mirroring solutions. 

 

  • Higher ROI - In these economic times, businesses have to ensure that they are getting as much value as possible from their IT investments, and no IT infrastructure is sitting idle. Data Guard has been architected to allow businesses get something useful out of their expensive investment in a DR site. This is typically not possible with remote mirroring solutions.

Using Oracle Data Guard, the logical standby database can be opened read-only (or even read-write) for reporting and queries while changes are still propagating. Besides, the physical standby database may be switched between recovery and read-only modes. However, this is typically not possible for a remote database protected with a remote mirroring solution. In such cases, the remote databases are just idling away and the DR site resources are not effectively utilized, reducing the ROI of such systems.

Data Guard is well-integrated with Recovery Manager (RMAN), allowing backups to be off-loaded to the physical standby database, saving critical system resources at the primary site and enabling efficient utilization of system resources on the standby site. Typically, customers will not have that flexibility if they were to use a remote mirroring solution. 

Data Guard offers an integrated switchover capability to address planned maintenances, e.g. hardware or OS upgrades, minimizing the cost of downtime associated with such scheduled outages. This typically cannot be achieved with a remote mirroring solution.

With SQL Apply, administrators can create additional indexes and materialized views to better suit their reporting requirements. This cannot be done with mirroring. 

SQL apply can also be used to offload the work required to do a reorganization. For example, if the administrator wants to partition a table, then (s)he can stop the apply process on the logical standby, partition the table, and then restart the apply. Again, such advanced functionalities are not possible with remote databases in a remote mirroring configuration.

Finally, Oracle Data Guard is available as an out-of-the-box feature of the core Oracle database. Besides, it is pre-integrated with other HA solutions from Oracle, e.g. Real Application Clusters (RAC), RMAN, etc. However, remote mirroring solutions are extra cost purchases and require complex integration with the database. Not only that, using remote mirroring solutions may also involve capacity pricing in addition to the basic licensing for the product, i.e. remote mirroring vendors may charge for the size of the data replicated (e.g. units of 50 GB of replicated data), which significantly adds up the cost for large OLTP databases.

 

  • Other issues to consider - There are various other issues one should consider while evaluating Data Guard and a remote mirroring solution for disaster recovery purpose. For example, what facility does the remote mirroring solution provide to instantiate the remote database? Note that for very large databases, instantiating a remote database over the network, as may be required by some remote mirroring solutions, may take a significantly long time. With Data Guard, the standby database may simply be instantiated from a tape backup of the primary, cutting down on the initialization time, resources and costs.

Another issue to consider is the handling of network connectivity problems. Data Guard allows the Maximum Availability mode, under which zero data loss is enabled through synchronous redo transmission to the standby site, but if there is a network problem and the standby site is unreachable, processing continues on the primary database. When network connectivity is restored, re-synchronization of the standby databases is automatically and gracefully handled by Data Guard. Customers considering a remote mirroring solution should investigate how it allows such dynamic switching from one variation on synchronous transmission to the other. Similarly, customers should also determine how it recovers from potential network communication problems.

 

Clearly, Oracle Data Guard provides a compelling set of technical and business reasons that justify its adoption as the disaster recovery and data protection technology of choice, over traditional remote mirroring solutions. The following table summarizes these justifications.

 

Data Guard Benefits Over Remote Mirroring Solutions For Protecting Data In Oracle Databases

  Oracle Data Guard
Better network efficiency  
Transmit only redo data Yes
Transmit less data Yes
Use less network I/O-s Yes
   
Better suited for WANs  
No distance limitation Yes
Network transmission based on standard TCP/IP Yes
No protocol conversion Yes
No additional latency Yes
Preserve write-ordering and data consistency Yes
   
Better data resilience/protection  
Zero data loss capability Yes
Protect from logical corruptions and human errors Yes
Prevent storage corruptions Yes
Validate data on the standby site Yes
Skip tables on the standby site Yes
   
Higher flexibility  
Use commodity hardware Yes
Primary/standby storage systems do not have to be identically configured Yes
Primary/standby storage can be from two different vendors Yes
   
Better functionality  
Support both Redo Apply and SQL Apply in the same configuration Yes
Multiple data protection modes to balance data availability and system performance Yes
Push-button automated switchover/failover capabilities Yes
Automatic gap detection and resolution Yes
Graceful handling of network connectivity problems Yes
GUI-based management and monitoring framework Yes
Cascaded redo log destinations Yes
Standby database initialization with tape backups Yes
   
Higher ROI  
Standby database can be opened read-only or read-write Yes
Allow backups to be offloaded on the standby database Yes
Reporting/queries using the standby database Yes
Offload data reorganization Yes
Integrated with other HA features from Oracle Yes
Integrated natively with Oracle Yes
No extra cost Yes

 

 

 

E-mail this page
Printer View Printer View
Oracle Is The Information Company About Oracle | Oracle RSS Feeds | Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Privacy