R Oracle 10gDataGuard Overview
R Oracle 10gDataGuard Overview
Page 2
EXECUTIVE OVERVIEW
Business continuity and disaster recovery are top priorities for the 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 able to swiftly and
efficiently deal with unforeseen business interruptions.
Oracle Data Guard is one of the most effective solutions available today to
protect the core asset of any enterprise its data, and make it available on a
24x7 basis despite disasters and other outages. This paper discusses Data Guard
technology in Oracle Database 10g, and demonstrates how it is a key factor in
the business continuity infrastructure of any enterprise.
IMPACT OF DISASTERS
With the proliferation of e-business, an enterprise today operates in an
extremely complex and a highly networked, global economy, and is more
susceptible to interruptions than in the past. The cost of interruptions, or
downtime, varies across industries and can be as much as millions of dollars an
hour. While that number is staggering, the reasons are quite obvious. The
Internet has brought millions of customers directly to the electronic storefronts.
Critical and interdependent business matters such as customer relationships,
competitive advantages, legal obligations, industry reputation and shareholder
confidence are even more critical now because of their increased vulnerability to
business disruptions and downtimes.
Page 3
Page 4
Clients
Clients
Primary
Site
Standby
Site
Data Changes
Primary
Database
Standby
Database
Page 5
Physical Standby
Database
Sync or Async
Redo Shipping
Production
Database
Backup
Redo Apply
Network
Broker
Logical Standby
Database
Transform
Redo to SQL
SQL
Apply
Open for
Reports
Additional
Indexes & MVs
Disaster recovery and high availability Data Guard provides an efficient and
comprehensive disaster recovery and high availability solution. Easy-tomanage switchover and failover capabilities allow role reversals between
primary and standby databases, minimizing the downtime of the primary
database for planned and unplanned outages.
Efficient utilization of system resources The standby database tables that are
updated with redo data received from the primary database can be used for
other tasks such as backup operations, reporting, summations, and queries,
thereby reducing the primary database workload necessary to perform these
tasks, saving valuable CPU and I/O cycles. With a logical standby database,
Page 6
Centralized and simple management The Data Guard Broker automates 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. Administrators may use either Oracle
Enterprise Manager or the Brokers own specialized command-line
interface (DGMGRL) to take advantage of this integrated management
framework.
Page 7
Physical/Logical
Standby
Database
Oracle Net
Transactions
LGWR
MRP/ LSP
RFS
FAL
Primary
Database
Standby
Redo
Logs
Transform Redo
to SQL for
SQL Apply
ARCH
ARCH
Backup /
Reports
Page 8
restrictions on where the databases are located, provided that they can
communicate with each other. However, for disaster recovery, it is
recommended that the standby databases be hosted at sites that are
geographically separated from the primary site.
Data Guard requires the operating system architecture on the primary and
standby systems to be the same. Thus if the primary database is running the
Linux operating system on an Intel architecture, all its standby databases must
also be running Linux on Intel they cannot be Windows systems, for example.
In addition, the same release of Oracle Database Enterprise Edition must be
installed on the primary database and all standby databases in a Data Guard
configuration.
Page 9
feature in Oracle Database 10g, Real Time Apply, is enabled, MRP reads redo
data directly from the current standby redo log file as it is being filled up by the
RFS process.
MRP (and thus application of redo) can be started on the physical standby
database by mounting the database and using the following command:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT FROM SESSION;
The media recovery processes can be run in parallel for the best performance of
Data Guard Redo Apply. In releases prior to Oracle Database 10g, this required
the use of a PARALLEL clause in the above RECOVER MANAGED
STANDBY DATABASE command. In Oracle Database 10g, MRP can
automatically determine the optimal number of parallel recovery processes at
the time it starts (without requiring the PARALLEL clause), and this number is
based on the number of CPUs available on the standby server.
The physical standby database can be opened read-only, and queries can be run
against the physical standby database at that time. The physical standby database
cannot run recovery at the same time it is opened read-only. Redo data that are
shipped to the standby while it is opened read-only are accumulated at the
standby site, and are not applied. However, recovery operations can be resumed
on the physical standby at any time, and the accumulated redo data will
automatically get applied. This allows the physical standby database to run in a
sequence that could involve running in recovery for a while, then being opened
read-only to run reports, and then returning to running recovery to apply
outstanding redo data.
To open the physical standby read-only, recovery needs to be canceled on the
standby using the following command:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
CANCEL;
and then the database can be opened read-only:
ALTER DATABASE OPEN;
Data protection Using a physical standby database, Data Guard can ensure
no data loss, even in the face of unforeseen disasters. A physical standby
database supports all datatypes, and DDL and DML operations that the
Page 10
Page 11
Redo Data
from
Primary
Database
Redo
Records
Reader
LCR
LCR
:
Preparer
Builder
Shared
Pool
Log Mining
Transaction
groups
Apply Processing
Datafiles
Applier
Analyzer
Coordinator
Transactions
to be applied
Transactions
sorted in
dependency order
Page 12
Page 13
Redo Transport
Mechanism
Maximum
Protection
LGWR SYNC
Maximum
Availability
LGWR SYNC
Maximum
Performance
Maximum Protection
Maximum Protection mode offers the highest level of data protection for the
primary database, ensuring a comprehensive zero-data loss disaster recovery
solution. When operating in Maximum Protection mode, redo records are
synchronously transmitted by the Log Writer process 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 disk
on at least one standby server. This mode should be configured with at least
two standby databases, thus offering double failure protection. If the last
participating standby database becomes unavailable, processing stops on the
primary database. This ensures that no transactions are lost when the primary
database loses contact with all of its standby databases.
Because of the synchronous nature of redo transmission, this Maximum
Protection mode can potentially impact primary database response time. This
impact can be minimized by configuring a low latency network with sufficient
bandwidth for the peak transaction load. Stock exchanges, currency exchanges,
Page 14
and financial institutions are examples of businesses that may require this
Maximum Protection mode.
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 is
synchronously transmitted by the Log Writer process from the primary database
to the standby database, and the transaction is not complete on the primary
database until it has been confirmed that the transaction data is available on disk
on the standby server. However, in this mode, unlike the Maximum Protection
mode, if the last participating standby database becomes unavailable e.g.
because of network connectivity problems, processing continues on the primary
database. The standby database may temporarily fall behind compared to the
primary database, but when it is available again, the databases will automatically
synchronize with no data loss.
Because of synchronous redo transmission, this protection mode can potentially
impact response time and throughput. This impact can be minimized by
configuring a low latency network with sufficient bandwidth for peak
transaction load.
The Maximum Availability mode is suitable for businesses that want the
assurance of zero data loss protection in the event of a severe outage at the
production site (assuming that there are no other failures), but do not want the
production database to be impacted by network/standby server failures.
Maximum Performance
Maximum Performance mode is the default protection mode. It offers slightly
less primary database data protection, but higher performance, than Maximum
Availability mode. In this mode, as the primary database processes transactions,
redo data is asynchronously shipped to the standby database by the Log Writer
process. Alternatively, the Archiver process(es) on the primary database may
also be configured to transmit the redo data in this mode. In any case, 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, processing continues on the primary database
and there is little or no effect on performance. However, in such cases, error
messages are logged to the database alert log and correspondingly, alerts can be
set through Enterprise Manager.
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 redo traffic, the
number of lost transactions should be very small or zero.
Page 15
Page 16
Page 17
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 or
incomplete redo data.
Automatic Resynchronization
Oracle Data Guard can smoothly handle network connectivity problems that
temporarily disconnect the standby (physical or logical) database from the
primary database.
When the standby database becomes unavailable (unless this standby database is
the last available standby in the Maximum Protection mode in which case the
primary database will be shut down), transactions are captured locally at the
primary database. When connectivity to the standby is re-established, the
accumulated archive logs are automatically shipped and applied to the standby,
until the standby has resynchronized with the primary. This process does not
require any administrative intervention. Oracle recommends that network
capacity be sufficient to handle such resynchronizations if network outages are
common in the vicinity of the primary site.
Page 18
Rolling Upgrades
Oracle Database 10g supports database software upgrades for major release and
patchset upgrades (from Oracle Database 10g onwards) in a rolling fashion
with near zero database downtime, by using Data Guard SQL Apply. The steps
involve upgrading the logical standby database to the next release, running in a
mixed mode to test and validate the upgrade, doing a role reversal by switching
over to the upgraded database, and then finally upgrading the old primary
database. While running in a mixed mode for testing purpose, the upgrade can
be aborted and the software downgraded, without data loss. For additional data
protection during these steps, a second standby database may be used.
The following diagram shows the sequence of events in a rolling upgrade
process.
Upgrade
Clients
Redo
A
Version X
1
Logs
Queue
Version X
X+1
Redo
Upgrade
Redo
X+1
X+1
4 Switchover to B, upgrade A
X
3
Patch Set
Upgrades
Major
Release
Upgrades
Cluster
Software &
Hardware
Upgrades
X+1
Page 19
Page 20
CONFIGURATION OPTIONS
Standby databases can be remote (connected over a WAN or MAN) or local
(connected on LAN). A Data Guard configuration can contain both local and
remote standby databases and can be configured to provide the benefits of both
approaches.
Remote standby databases are the best solution for disaster recovery because an
event that disables the primary database is unlikely to also disable the standby
database. However, performance can be affected by higher latency.
Local standby databases are better suited to address outages related to human
errors or data corruptions within a data center. 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 the Maximum
Protection mode.
Please refer to [5] for Data Guard network configuration best practice
recommendations.
Page 21
MAA reduces the implementation costs for a highly available Oracle system
by providing detailed configuration guidelines. The results of performance
impact studies for different configurations are highlighted to ensure that the
chosen highly available architecture can continue to perform and scale
according to business needs.
MAA gives the ability to control the length of time to recover from an
outage and the amount of acceptable data loss under disaster conditions
thus allowing mean time to recovery (MTTR) to be tailored to specific
business requirements.
Page 22
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 analysis of
Oracle's corporate e-mail systems, as shown in the following graph,
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.
Network
Bandwidth
Data Guard
Remote Mirroring
Network I/Os
10
15
20
25
30
Page 23
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. Last, but not
the least, many of these remote mirroring solutions are proprietary and can
be used with only the storage systems from the same vendor (on both the
primary and secondary sites) that manufactures these remote mirroring
solutions. Data Guard, on the other hand, does not force any lock-in with a
particular storage solution for both the primary and standby sites.
CONCLUSION
Oracle Data Guard is a comprehensive data protection, disaster recovery and
high availability solution for the enterprise. It offers a flexible and easy-tomanage 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 overhead from primary databases. The various data protection
modes provide flexibility to adapt to various protection, performance and
infrastructure requirements. The Data Guard Broker in combination with
Oracle Enterprise Manager provides an easy-to-use configuration and
management framework.
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
paper talks about. It has to be complete, integrated, easy-to-manage, serve
multiple purposes and protect all enterprise data. At the same time, such data
protection and disaster recovery technology should not be expensive, and
should enable businesses to extract value out of their DR investments. Oracle
Data Guard is the only solution available today that meets all these needs.
Page 24
REFERENCES
1. Oracle Data Guard Concepts and Administration Manual, 10g Release
1 (10.1)
2. Oracle High Availability Architecture and Best Practices Manual, 10g
Release 1 (10.1)
3. MAA Detailed White Paper,
http://otn.oracle.com/deploy/availability/htdocs/maa.htm
4. Oracle9i Media Recovery Best Practices,
http://otn.oracle.com/deploy/availability/htdocs/maa.htm
5. Oracle9i Data Guard: Primary Site and Network Configuration Best
Practices, http://otn.oracle.com/deploy/availability/htdocs/maa.htm
6. Oracle9i Data Guard: SQL Apply Best Practices,
http://otn.oracle.com/deploy/availability/htdocs/maa.htm
Page 25