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 |
|