Download Oracle 9i Data Guard - Technical White Paper

Oracle Data Guard
Ensuring Disaster Recovery for the Enterprise
An Oracle White Paper
March 2002
Oracle Data Guard
Ensuring Disaster Recovery for the Enterprise
Executive Overview ...................................................................................................... 3
Impact Of Disasters ...................................................................................................... 3
Disaster Recovery Elements ................................................................................... 4
Oracle Data Guard ................................................................................................... 5
Overview Of Oracle Data Guard................................................................................ 5
What Is Oracle Data Guard? .................................................................................. 5
Oracle Data Guard Functionality........................................................................... 6
Benefits Of Oracle Data Guard.............................................................................. 7
Oracle Data Guard Process Architecture................................................................... 7
Key Technology Components ..................................................................................... 8
Physical Standby Databases – Redo Apply........................................................... 9
Logical Standby Databases – SQL Apply ............................................................. 9
Data Protection Modes.......................................................................................... 11
Maximum Protection......................................................................................... 11
Maximum Availability ....................................................................................... 12
Maximum Performance .................................................................................... 12
Failover and Switchover ........................................................................................ 13
Log Shipping and Apply Services Options......................................................... 14
Delayed Apply .................................................................................................... 14
Cascading Standby Databases .......................................................................... 14
Automatic Resynchronization.......................................................................... 15
Configuration Options........................................................................................... 15
Data Guard Broker................................................................................................. 15
Oracle Data Guard And Clustering .......................................................................... 17
Oracle Data Guard And Third-Party Mirroring Solutions.................................... 17
Summary........................................................................................................................ 19
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 2
Oracle Data Guard
Ensuring Disaster Recovery for the Enterprise
EXECUTIVE OVERVIEW
Business continuity and disaster recovery are a top priority for senior
management of most global enterprises. Economic fluctuations, rapid changes
in market trends, and competitive pressures imply that the global enterprise of
today must operate in a 24x7 environment, and must be ready for, and be able
to swiftly and efficiently deal with unforeseen business interruptions.
Oracle Data Guard is the most effective solution available today to protect the
core asset of any enterprise – its data, and make it available on a 24x7 basis even
in the face of disasters and other calamities. This paper discusses Oracle Data
Guard technology, and demonstrates how it is one of the most important
elements in the business continuity infrastructure of any enterprise.
IMPACT OF DISASTERS
The use of the web as a major distribution channel, lean inventory management
systems, technology and business process integration across company and
geographic boundaries imply that an enterprise today operates in an extremely
complex and a highly networked economy. Businesses today are more
susceptible to interruptions – directly, or indirectly. For example, after recent
disasters, a large auto manufacturer was forced to close five North American
plants after the flow of parts was at first halted, then slowed, following
heightened security at the US-Canada border and grounded commercial airline
flights1. That in turn had a negative impact on its earnings for the quarter.
What is the cost of downtime? A research report2 documents the costs of
downtime for various industries:
Business
Average Hourly Impact
Retail Brokerage
Credit Card Sales Authorization
Pay-per-View
Home Shopping Channels
Catalog Sales
Airline Reservation Centers
Tele-Ticket Sales
Package Shipping Service
ATM Fees
$6.5 million
$2.6 million
$150,000
$113,000
$90,000
$90,000
$69,000
$28,000
$15,000
Automakers Look To Reconstruct Supply Chains, InformationWeek, Sep 24, 2001
2000 High Availability And Data Protection Practices, Strategic Research Corporation,
http://www.sresearch.com/reports/hadpp00.htm
1
2
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 3
While these numbers are staggering, the reasons are quite obvious. The Internet
has brought millions of customers directly to the businesses’ electronic
storefronts. Critical and interdependent business issues like customer
relationships, competitive advantages, legal obligations, industry reputation and
shareholder confidence are even more critical now because of their increased
vulnerability to business disruptions.
Disaster Recovery Elements
Whereas technology has been a great enabler for businesses, technology
sometimes fails, and technology disruptions can bring down businesses.
Technology disruptions can be due to hardware or system failures, human
errors, computer viruses, software glitches, natural disasters and malicious acts.
Because of the interlinked nature of today’s networked economy, the impact of
a single disruption is likely to have ripple effects within the company, as well as
within its business partners3. The protection of company assets from
disruptions is one of the foremost concerns of corporate executives today, and
since data, or information, forms the lifeblood of an enterprise, data protection
and data recovery is the top priority of any enterprise with a business continuity
strategy in place. This is confirmed by a recent survey by InformationWeek4.
The survey demonstrated that data recovery is the top-most priority of today’s
business managers, with almost 100% respondents indicating that it is an
essential element in their business continuity plans:
3
4
A Fire in Albuquerque Sparks Crisis For European Cell-Phone Giants, Wall Street Journal, Jan 29, 2001
Playing For Keeps, InformationWeek, Nov 26, 2001
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 4
Oracle Data Guard
Oracle Data Guard has been architected to address this highly important
business continuity need for the enterprise. It provides an extensive set of data
protection and disaster recovery features to help enterprises survive disasters,
human errors, and corruptions that can adversely impact its Oracle database.
The following sections provide further details on Oracle Data Guard.
OVERVIEW OF ORACLE DATA GUARD
What Is Oracle Data Guard?
Oracle Data Guard is the management, monitoring, and automation software
that includes an Oracle production database and one or more Oracle standby
databases to protect enterprise data from failures, disasters, errors, and
corruptions that might otherwise take the database down. It protects critical
data by automating the creation, management, and monitoring of the databases
and other components in its configuration. It automates the otherwise manual
process of maintaining a standby database that can be used if the production
database is taken offline for routine maintenance or becomes damaged.
The following diagram presents a hi-level overview of the Oracle Data Guard
architecture.
Clients
Clients
Primary
Site
Standby
Site
Production
Database
Standby
Database
Broker Agent
Broker Agent
Log Data
Data Guard Broker
Fig. 1: Overview of Oracle Data Guard Architecture
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 5
Oracle Data Guard Functionality
Oracle Data Guard consists of a production database (also known as the primary
database) and one or more standby database(s), which are transactionally consistent
copies of the production database. A standby database can either be a physical
standby database, or a logical standby database. A physical standby database has ondisk database structures that are identical to the primary database on a block-byblock basis. A logical standby database is an independent database that contains
the same data as the primary database. It is updated using SQL statements, and
has the relative advantage that it can be used simultaneously for recovery and
for other tasks such as reporting, and queries.
The transactional consistency between primary and standby databases is
maintained using Oracle online redo logs. As transactions change information
stored in the primary database, the changes are also written to the online redo
logs. These changes are transferred to the standby destinations by Log Transport
Services and applied to the standby databases by Log Apply Services.
Role Management Services work with Log Transport Services and Log Apply
Services to reduce downtime of the primary database for planned outages and
from unplanned failures by facilitating switchover and failover operations.
Data Guard provides several management interfaces, including SQL statements,
initialization parameters, a PL/SQL package, and the Oracle Data Guard Broker.
The Broker is a distributed management framework that automates the creation
and management of Data Guard configurations through the Data Guard
Manager graphical user interface or its command-line interface.
The following diagram shows the Oracle Data Guard components.
Physical
Standby
Database
Sync or Async
Transaction Shipping
Production
Database
Backup
DIGITAL DATA STORAGE
Network
Delay
Redo
Apply
DIGITAL DATA STORAGE
Broker
Logical
Standby
Database
Continuously
Open for Reports
SQL
Apply
Delay
Transform
Redo to SQL
Additional
Indexes & MVs
Fig. 2: Oracle Data Guard Architectural Components
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 6
Benefits Of Oracle Data Guard
Oracle Data Guard offers the following benefits:
•
Robust and efficient solution for high availability and disaster recovery
An Oracle Data Guard configuration combines loosely connected and
geographically dispersed primary and standby databases into a robust, easily
managed disaster recovery solution. It is a superior data recovery solution
compared to backup and recovery from tape, which is inefficient and
inappropriate for data center-wide data recovery. Data Guard provides the
tools and infrastructure required to quickly install, instantiate, monitor and
control standby databases. There is no scripting involved, and it is a true
out-of-the-box deployment.
•
Failover and switchover capabilities
These failover and switchover capabilities allow easy role reversals between
primary and standby databases, minimizing the downtime of the primary
database for planned and from unplanned outages.
•
Flexibility in data protection to suit specific business needs
Oracle Data Guard offers maximum protection (zero data loss), maximum
availability, and maximum performance modes to help enterprises balance
data availability against performance requirements.
•
Safeguard against data corruptions and user errors
Using standby databases, the risk of corruptions is reduced. Primary-side
physical corruptions, due to device failure, do not propagate through the
archived redo logs that are transported to the standby database. Similarly,
logical corruptions or user errors that cause the primary database to be
permanently damaged can be resolved. For example, if a critical table is
accidentally dropped from the primary database, this drop can be prevented
from affecting the standby database by delaying the application of this
change in the standby database.
•
Centralized and simple management
The Data Guard Broker distributed management framework provides
simple easy-to-use Data Guard Manager graphical user interface and the
Data Guard command-line interface to automate the management and
operational tasks across the multiple databases in a Data Guard
configuration. The Broker also monitors all of the systems within a single
Data Guard configuration.
ORACLE DATA GUARD PROCESS ARCHITECTURE
As shown in the following figure, Oracle Data Guard uses several processes of
the Oracle database instance to achieve the automation necessary for disaster
recovery and high availability.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 7
Fig. 3: Oracle Data Guard Process Architecture
On the primary site, Oracle Data Guard uses the Log Writer Process (LGWR) to
collect transaction redo data and ship this data to the standby, and the Fetch
Archive Log Process (FAL) to provide a client-server mechanism for shipping
archived logs to the standby following a network outage, for automatic gap
resolution and resynchronization.
On the standby site, Oracle Data Guard uses the Remote File Server Process (RFS)
to receive redo records from the primary database, the Managed Recovery Process
(MRP) to apply redo information to the physical standby database, and the
Logical Standby Process (LSP) to apply redo information to the logical standby
database.
Oracle Data Guard also uses the Data Guard Broker Monitor Process (DMON) to
manage and monitor the primary and standby databases as a unified
configuration.
KEY TECHNOLOGY COMPONENTS
An Oracle Data Guard configuration can include multiple (up to nine) standby
databases, which can be any combination of physical and logical standby
databases. These standby databases are separate and independent, and can
reside on multiple systems or on a single system. Primary and standby databases
can run on a single node or in a Real Application Clusters environment. By
offering failover and switchover capabilities, Data Guard protects against total
destruction of the primary database and against data corruption, and makes it
easy to perform planned maintenances (e.g. hardware and software upgrades)
on the primary database.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 8
Customer Success
On September 11th, one of the world's leading financial management and advisory companies,
which tests critical applications for disaster readiness quarterly, was challenged with a
previously unthinkable disaster when terrorists struck the Twin Towers in New York. A core
data processing center within two blocks of “Ground Zero” made a decision to redirect
operations to a backup data center at London, England. Within 11 minutes of making the
decision, London had taken over operations by activating their Oracle standby databases with
no loss of data.
Physical Standby Databases – Redo Apply
A physical standby database is kept synchronized with the primary database by
applying the redo log data received from the primary. It is physically identical to
the primary database on a block-for-block basis, because the Oracle media
recovery mechanism is used to apply changes to a physical data block address.
The database schemas, including indexes, are the same, and the standby
database can be opened read-only.
While the standby database is in the read-only mode, the primary database
continues to ship redo data to the standby site. Oracle Data Guard also offers
the flexibility to enable the physical standby database switch between recovery
and read-only modes, e.g. a sequence could involve running in recovery mode,
then opening in read-only mode to run reports, and then returning to recovery
mode to apply outstanding redo data.
The Redo Apply technology using physical standby databases is a proven and
robust apply mechanism. In addition to providing disaster recovery and
protection from user error and data corruption, it provides the following
benefits:
•
Support for all DDL and DML – a physical standby database provides data
protection and disaster recovery capabilities for all Oracle databases, with
no restrictions on datatypes, types of tables, or types of data definition
language (DDL) and data manipulation language (DML) operations.
•
Performance – the Redo Apply technology applies changes using low-level
recovery mechanisms, which bypass all SQL level code layers and therefore
is the most efficient mechanism for applying changes. This makes the Redo
Apply a highly efficient mechanism to propagate changes between
databases.
•
Off-loading backup operations – Oracle Recovery Manager (RMAN) can
use physical standby databases to offload backups from the primary
database saving valuable CPU and I/O cycles.
Logical Standby Databases – SQL Apply
A logical standby database is kept synchronized with the primary database by
transforming the redo log data received from the primary into SQL statements
and then applying the SQL statements. It contains the same logical information
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 9
(rows) as the production database, although physical organization and structure
of the data can be very different.
Because the logical standby database is updated using SQL statements, it can
remain open in read-write mode, and the tables that are being updated from the
primary database can be used simultaneously for other tasks such as reporting,
summations, and queries. These tasks can also be optimized by creating
additional indexes and materialized views on the maintained tables to those
used on the primary database. A logical standby database can host multiple
database schemas, and users can perform normal data manipulation operations
on tables in schemas that are not updated from the primary database.
The following diagram shows the difference in the way logs are applied to the
two types of standby databases.
Log Data
Primary Database
Redo Apply
Transform Archive Log
Files to SQL Statements
Physical
Standby
Database
SQL Apply
Logical
Standby
Database
Fig. 4: Data Guard Apply Modes for Physical and Logical Standby Databases
In addition to providing disaster recovery, data protection, and off-loading the
primary database, logical standby databases provide the following benefits:
•
Efficient use of system resources – a logical standby database is an open
production database and can be used concurrently for both data protection
and reporting.
•
Reporting – because the data in a logical standby database can be presented
with a different physical layout, additional indexes and materialized views
can be created to suit specific business requirements.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 10
Customer Success
“ProQuest Information & Learning is among the world's largest, most progressive publishers
of content in the academic and library markets, and has been testing the new version of Data
Guard in Oracle Database Release 2 since June, 2001," states George Chizmar, VP of
Engineering Services. "The Data Guard SQL Apply technology is a major step forward in
high availability solutions. If an unplanned failure strikes the primary database, the logical
standby database will be able to take over the production environment. And, since we can now
run reports while the standby database is being updated, we get the benefit of leveraging our
hardware and software investment, while maximizing the availability of our data.”
Data Protection Modes
Oracle Data Guard provides three high-level modes of data protection to
balance cost, availability, performance, and transaction protection. Using a
simple SQL statement on the primary database, the Data Guard environment
can be configured to maximize data protection, availability, or performance:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE
{PROTECTION | AVAILABILITY | PERFORMANCE};
To determine the appropriate data protection mode to use, enterprises need to
weigh their business requirements for data availability against user demands for
response time and performance. The following table outlines the suitability of
each mode.
Protection
Mode
Risk of Data Loss
Redo Shipment
Maximum
Protection
Zero data loss; Double
failure protection
Synchronous redo shipping to 2 sites by
LogWriter process
Maximum
Availability
Zero data loss; Single
failure protection
Synchronous redo shipping by
LogWriter process
Maximum
Performance
Minimal data loss – usually
0 to few seconds
Asynchronous redo shipping by
LogWriter process
The following sections describe all of these aspects in more detail.
Maximum Protection
Maximum protection mode offers the highest level of data availability for the
primary database, ensuring a comprehensive zero-data loss disaster recovery
solution. When operating in maximum protection mode, redo records are
synchronously transmitted from the primary database to the standby database, and
a transaction is not committed on the primary database until it has been
confirmed that the transaction data is available on at least one standby database.
This mode is usually configured with at least two standby databases, thus
offering double failure protection. If the last participating standby database
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 11
becomes unavailable, processing automatically halts on the primary database as
well. This ensures that no transactions are lost when the primary database loses
contact with all of its standby databases.
The maximum protection mode provides the highest degree of data protection
at the standby site. However, it can potentially impact primary database
performance. The impact on performance can be minimized by configuring a
network with sufficient throughput for peak transaction load and with low
round trip latency. Stock exchanges, currency exchanges, and financial
institutions are examples of businesses that require maximum protection.
Maximum Availability
Maximum availability mode has the next highest level of data availability for the
primary database, offering zero data loss and protecting against single component
failures. As with the maximum protection mode, redo data are synchronously
transmitted from the primary database to the standby database. The transaction
is not complete on the primary database until it has been confirmed that the
transaction data is available on the standby database. However, if a standby
database becomes unavailable – say, because of network connectivity problems,
processing continues on the primary database. The standby database may
temporarily diverge from the primary database, but when it is available again,
the databases will automatically synchronize, and no data will be lost.
This protection mode can potentially impact response time and throughput.
These can be minimized by configuring a low latency network with sufficient
throughput for peak transaction load.
An example of a business that can use this data protection mode is a
manufacturing plant; the risks of having no standby database for a period of
time and data divergence are acceptable as long as no data is lost if failover is
necessary.
Maximum Performance
Maximum performance mode is the default protection mode. It offers slightly
less primary data protection, but higher performance, than maximum availability
mode. In this mode, as the primary database processes transactions, log data is
asynchronously shipped to the standby database. The commit operation of the
primary database does not wait for the standby to acknowledge receipt before
completing the write on the primary. If any standby destination becomes
unavailable at any time, processing continues on the primary database and there
is little or no effect on performance.
In the case of a failure of the primary, there may be some transactions that were
committed on the primary that had not completed shipping to the standby. If
the network has sufficient throughput to keep up with peaks in log traffic, the
number of lost transactions should be very small or zero.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 12
The maximum performance mode should be used when availability and
performance on the primary database are more important than the risk of losing
a small amount of data.
Failover and Switchover
Oracle Data Guard offers two easy-to-use methods to handle planned and
unplanned outages of the production site. These methods are called Failover and
Switchover, and they are easily initiated using SQL or through the Data Guard
Broker interface.
Failover is the operation of taking the primary database offline on one site and
bringing one of the standby databases online as the new primary database. A
failover operation can be invoked when an unplanned catastrophic failure
occurs on the primary database, and there is no possibility of recovering the
primary database in a timely manner.
The failover operation is invoked on the standby database that will assume the
primary role. After a failover, the original primary database must be reinstantiated to resume its role as a standby database.
The following figure shows the result of a failover operation from a primary
database in San Francisco to a physical standby database in Boston.
Fig. 5: Failover to a Standby Database
The switchover option, on the other hand, is the planned role reversal of the
primary and standby databases, to handle planned maintenance on the primary
database. The main difference between a switchover operation and a failover
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 13
operation is that switchover does not require re-instantiation of the database.
This allows the primary database to resume its role as the standby database
almost immediately. As a result, scheduled maintenance can be performed more
frequently. For example, switchover may be used to perform an upgrade on the
primary site by switching over all of the database clients to the standby site as
hardware is upgraded on the primary site.
Both failover and switchover operations guarantee zero data loss if Data Guard
was being run in the maximum protection mode or maximum availability mode
at the time of the failover or switchover.
Failover and switchover operations also work seamlessly when multiple standby
databases are included in the configuration. For example, if multiple standby
databases are configured and the primary database goes down, the administrator
has the flexibility to choose one of the available standbys to become the
primary. Data Guard fully automates the process of redirecting the other
standby databases to use the new primary, including shipping any missing logs
or incomplete logs.
Log Shipping and Apply Services Options
Delayed Apply
When a primary database is open and active and transactions, are in progress,
redo log data is generated and shipped to standby sites. It is possible to delay
the application of redo data already received at one or more standby databases.
The ability to delay the application of changes to standby databases enables not
only the protection of production data from data center disasters, but also
provides a window of protection from user errors or corruptions. Of course,
the apply process also revalidates the log records to prevent application of log
corruptions.
If operating under the maximum protection or the maximum availability mode,
Data Guard will ensure zero data loss even with this delayed apply in effect.
Cascading Standby Databases
A cascading standby database is a standby database that receives its redo data
from another standby database and not from the original primary database.
Since in this case the primary database sends a set of redo data to only one
standby database and not to all standby databases, this feature reduces the load
on the primary system, and also reduces network traffic and use of valuable
network resources around the primary site.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 14
Automatic Resynchronization
Oracle Data Guard can smoothly handle network connectivity problems that
temporarily disconnect the standby database from the primary database. In this
case transactions are captured locally at the primary database until a standby is
available. When connectivity to the standby is re-established, the accumulated
logs are automatically shipped to the standby, until the standby has
resynchronized with the primary and all archive gaps are resolved. At this point
the standby will re-enter the user selected protection mode (Maximum
Protection, Maximum Availability, or Maximum Performance). Oracle
recommends that network capacity should be sufficient to handle this case if
network outages are common in the vicinity of the primary site.
Configuration Options
Standby databases can be remote (connected over a wide area network (WAN))
or local (connected on a local area network (LAN)).
Remote standby databases are the best solution for disaster recovery because an
event that disables the primary database will be unlikely to also disable the
standby database. However, performance can be affected by the WAN's lower
bandwidth and higher latency.
Local standby databases are better suited to address outages related to human
errors or data corruptions. Since LAN provides an inexpensive and reliable
network link with low latency, having a dedicated LAN segment just for
standby use is an ideal environment for providing the highest levels of data
protection while minimizing performance effects on the primary database. For
example, a planned role reversal or switchover operation that requires the
orderly shutdown of the primary, shipping of the last log and application of it
before the switchover can occur, can be a very fast operation if running locally.
An Oracle Data Guard configuration can contain both local and remote
standby databases and can be configured to provide the benefits of both
approaches.
Data Guard Broker
The Oracle Data Guard Broker is a distributed management framework that
automates and centralizes the creation, maintenance, and monitoring of Data
Guard configurations. All management operations can be performed locally or
remotely through the Broker's easy-to-use interfaces: Oracle Data Guard
Manager, which is the Broker's graphical user interface (GUI) and the Data
Guard command-line interface (CLI). The following screenshot shows a general
page from the Oracle Data Guard Manager main window.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 15
Fig. 6: Oracle Data Guard Manager Main Window
The following list describes some of the operations that the Broker automates
and simplifies:
•
Creating and enabling Data Guard configurations, which include a primary
database and up to nine standby (physical or logical) databases.
•
Managing an entire Data Guard configuration from any site in the
configuration.
•
Invoking switchover or failover operations with a single command to
initiate and control complex role changes across all systems in the
configuration.
•
Monitoring log apply rates, capturing diagnostic information, and detecting
problems quickly with centralized monitoring, testing, and performance
tools.
The Broker's easy-to-use interfaces and centralized management and
monitoring of the Data Guard configuration make the Data Guard an enhanced
high availability and disaster protection solution for the enterprise.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 16
ORACLE DATA GUARD AND CLUSTERING
Oracle Data Guard and cluster solutions, such as Oracle Real Application
Clusters, are complementary to each other. Cluster solutions address system
failures. They provide rapid and automatic recovery from failures that do not
affect data – such as node failures, or instance crashes. Clusters can also provide
increased scalability for an application. However, clusters do not provide data
protection, as there is only a single local copy of the data within the cluster.
Data Guard provides data protection because though the primary and standby
databases are transactionally consistent, they neither share disk nor run in lock
step. This enables recovery from site disasters or data corruptions.
Customers should use a combination of Oracle Data Guard and Real
Application Clusters to get the benefits of both system-level and data-level
protection. Please refer to the Maximum Availability Architecture document5
published by Oracle Corporation for additional details on integrating Oracle
Data Guard and Oracle Real Application Clusters.
Customer Success
A global power management company operates a wholesale market for trading energy between
generators and retailers, supplying power to over 7 million consumers. Their core 24x7 Oracle
database system for managing the spot market for electricity runs in two different locations.
Oracle Real Application Clusters provides fast failover during system failures in one of the
locations, while Data Guard provides disaster protection by using a standby database in the
other location. Data Guard also ensures that the standby database can be queried while
changes from the primary database are applied.
ORACLE DATA GUARD AND THIRD-PARTY
MIRRORING SOLUTIONS
Although Remote Mirroring solutions in concept appear to offer simple and
complete data protection, Oracle Data Guard, with its log-based approach, is
inherently much more efficient, less expensive and better optimized for data
protection than remote mirroring solutions. A customer does not need to buy
or integrate a remote mirroring solution with Oracle Data Guard. Following are
its benefits compared to a remote mirroring solution:
•
Better Network Efficiency
With Oracle Data Guard, only the online logs need to be sent to the remote
site. However, if a remote mirroring solution is used for data protection,
then 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). The ratio of database writes to log file
writes typically varies between three-to-one and ten-to-one. This means that
5
http://otn.oracle.com/deploy/availability/pdf/MaxAvailArch.pdf
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 17
the network bandwidth needed for a database log shipping based solution is
generally one-fifth or less than that of a remote mirroring solution. Even
more importantly, this means far fewer network round trips.
Remote mirroring can be very useful for non-database files, but for
database data, the combination of better protection and lower cost provide
compelling reasons to use Data Guard. An internal Oracle study showed
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.
Network
Bandwidth
Data Guard
Remote Mirroring
Network I/Os
0
5
10
15
20
25
30
Fig. 7: Network Performance: Data Guard vs. Remote Mirroring
•
Better resilience and data protection
Oracle Data Guard processes are aware of data formats as they read and
write information from the primary database. In addition, Oracle Data
Guard allows change application to be delayed. This intelligent
reading/writing and delayed application of changes prevents many human
errors and data corruptions from propagating. 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.
•
Higher ROI
Using Oracle Data Guard, the standby database can be opened read-only
for reporting while changes are still propagating. That is not always the case
for a remote mirroring solution. Besides, Oracle Data Guard is an out-ofthe-box feature of the core Oracle database. It does not involve extra costs,
or extra integration. However, remote mirroring solutions are extra cost
purchases and require complex integration with the database.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 18
SUMMARY
Oracle Data Guard is a comprehensive high availability and disaster recovery
solution for the enterprise. It offers a flexible and easy-to-manage framework
that addresses both planned and unplanned outages. Physical and logical
standby databases complement each other and can be maintained
simultaneously providing high-value data protection, while offloading primary
databases. The various data protection modes provide flexibility to adapt to
various protection, performance and infrastructure requirements. The Data
Guard Broker provides an easy-to-use configuration and management interface.
A global enterprise of today cannot provide a mission-critical level of service to
its customers and various stakeholders without the kind of technology this
white paper talks about. It has to be complete, integrated, easy to manage, serve
multiple purposes and protect all enterprise data. Oracle Data Guard is the only
solution available today that meets all these needs.
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
Page 19
Oracle Data Guard – Ensuring Disaster Recovery for the Enterprise
March 2002
Author: Ashish Ray
Contributing Authors: Ron Weiss, Tammy Bednar, Raymond Dutcher, Lawrence To, Juan Loaiza
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Oracle is a registered trademark of Oracle Corporation. Various
product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Copyright © 2002 Oracle Corporation
All rights reserved.