Oracle Data Guard: Overview

Copyright 2006, Oracle. All rights reserved.
Oracle Data Guard: Overview

O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
COMPUTER IS STRICTLY PROHIBITED
Oracle Database 10g: Data Guard Administration 1 - 2
Objectives
After completing this lesson, you should be able to do the
following:
Describe the factors that affect planned and unplanned
downtime
Describe the basic components of Oracle Data Guard
Explain the differences between physical and logical
standby databases
Explain the benefits of creating a Data Guard
environment
Explain the use of Data Guard in high-availability
architectures
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Causes of Data Loss
Source: Disaster Recovery Journal
Natural disasters
3%
Software corruption
4%
Computer viruses 7%
Human errors 36%
Hardware & system errors 49%
Causes of Data Loss
According to a survey published in the Disaster Recovery Journal (DRJ), the leading causes of
data loss were not natural disasters but hardware failures and human errors.
The goal of Oracle Data Guard is to provide an effective safeguard against data loss. Data Guard
provides enterprises with complete data protection, data recovery, and data availability, ensuring
round-the-clock business continuity.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Understanding the Causes of Downtime
Planned
downtime
Unplanned
downtime
System
changes
Data
changes
Data
failures
Computer
failures
Corruption
Human
error
Site
failure
Storage
failure
Understanding the Causes of Downtime
Every system faces both unplanned and planned downtime. It is important to consider causes of
both unplanned and planned downtime when designing a fault-tolerant, resilient infrastructure.
Unplanned downtime consists of the following:
Computer failures: Downtime occurs when there is a power outage or a system crash.
Data failures: Data failure is the loss, damage, or corruption of critical enterprise data.
Causes of data failure include:
- Storage failure: Disk crash or space limitations
- Human error: Downtime occurs when someone inadvertently drops a table or the
system administrator makes an error.
- Corruption: Caused by a faulty component in the I/O stack
- Site failure: Downtime occurs when there is some sort of data corruption or natural
disaster such as a flood, fire, or earthquake.
Planned downtime includes routine operations, periodic maintenance, and new deployments.
Planned downtime includes the following:
Data changes: Table redefinition and index rebuild
System changes: Downtime occurs during hardware and operating-system upgrades.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
What Is Oracle Data Guard?
Primary
database
Standby
database
Database Database
copy
Redo transport
O
r
a
c
l
e

N
e
t
What Is Oracle Data Guard?
Oracle Data Guard is a management, monitoring, and automation software infrastructure that
works with a production database and one or more standby databases to protect your data against
failures, errors, and corruptions that might otherwise destroy your database. It protects critical
data by providing facilities to automate the creation, management, and monitoring of the
databases and other components in a Data Guard configuration. It automates the process of
maintaining a copy of an Oracle production database (called a standby database) that can be
used if the production database is taken offline for routine maintenance or becomes damaged.
In a Data Guard configuration, a production database is referred to as a primary database. A
standby database is a synchronized copy of the primary database. Using a backup copy of the
primary database, you can create from one to nine standby databases. The standby databases,
together with the primary database, make up a Data Guard configuration. Each standby database
is associated with only one primary database.
Note: You can use the Cascaded Redo Log Destinations feature to incorporate more than nine
standby databases in your configuration. Refer to the Other Considerations for Oracle Data
Guard lesson for additional information about this feature.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Types of Standby Databases
There are two types of standby databases:
Physical standby database
Identical to the primary database on a block-for-block
basis
Synchronized with the primary database through
application of redo data received from the primary
database
Logical standby database
Shares the same schema definition
Synchronized with the primary database by transforming
the data in the redo received from the primary database
into SQL statements and then executing the SQL
statements
Types of Standby Databases
Physical Standby Database
A physical standby database is physically identical to the primary database, with on-disk
database structures that are identical to the primary database on a block-for-block basis. The
physical standby database is updated by performing recovery using redo data that is received
from the primary database. The physical standby database can be either recovering data or open
for read-only reporting.
Logical Standby Database
A logical standby database contains the same logical information (unless configured to skip
certain objects) as the production database, although the physical organization and structure of
the data can be different. The logical standby database is kept synchronized with the primary
database by transforming the data in the redo received from the primary database into SQL
statements and then executing the SQL statements on the standby database. This is done with the
use of LogMiner technology on the redo log information received from the primary database.
The tables in a logical standby database can be used simultaneously for recovery and for other
tasks such as reporting, summations, and queries.
For more information about LogMiner, refer to Oracle Database Utilities.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Oracle Data Guard Broker Framework
CLI management client
Enterprise Manager
Repository
Primary
database
Data
Guard
broker
Oracle
Management
Server
Data
Guard
broker
Agent
Standby
database
Agent
Oracle 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. After the
broker creates the Data Guard configuration, the broker monitors the activity, health, and
availability of all systems in the Data Guard configuration. You can use Oracle Enterprise
Manager Grid Control or the Data Guard brokers own specialized command-line interface
(DGMGRL) to take advantage of the brokers management capabilities.
Enterprise Manager provides a Web-based interface that combines with the brokers centralized
management and monitoring capabilities so that you can easily view, monitor, and administer
primary and standby databases in a Data Guard configuration.
You can also use the Data Guard command-line interface (CLI) to control and monitor a Data
Guard configuration. You can perform most of the activities that are required to manage and
monitor the databases in the configuration from the CLI prompt (DGMGRL) or in scripts.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Types of Services
There are three types of services provided with Data
Guard:
Redo transport services
Log apply services
Redo Apply
SQL Apply
Role-management services
Types of Services
The following types of services are available with Data Guard:
Redo transport services: Control the automated transmittal of redo information from the
primary database to one or more standby databases or destinations
Log apply services: Control when and how the redo logs are applied to the standby
database
- Redo Apply: Technology used for physical standby databases. Redo data is applied on
the standby database by using the standard recovery techniques of an Oracle database.
- SQL Apply: Technology used for logical standby databases. The received redo data is
first transformed into SQL statements, and then the generated SQL statements are
executed on the logical standby database.
Role-management services: A database operates in one of two mutually exclusive roles:
primary or standby. Role-management services operate in conjunction with the redo
transport services and log apply services to change these roles dynamically as a planned
transition (called a switchover operation) or as a result of a database failure through a
failover operation.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Role Transitions: Switchover and Failover
Oracle Data Guard supports two role-transition
operations:
Switchover
Planned role reversal
Used for OS or hardware maintenance
Failover
Unplanned role reversal
Use in emergency
Zero or minimal data loss depending on choice
of data protection mode
Can be initiated automatically when fast-start failover is
enabled
Role-transition operations are not automatically
invoked.
Role Transitions: Switchover and Failover
Data Guard enables you to change the role of a database dynamically by issuing SQL statements
or by using either of the Data Guard brokers interfaces. Oracle Data Guard supports two role-
transition operations:
Switchover: The switchover feature provides you with the ability to switch the role of the
primary database to one of the available standby databases. The chosen standby database
becomes the primary database, and the original primary database then becomes a standby
database.
Failover: You invoke a failover operation when a catastrophic failure occurs on the primary
database and there is no possibility of recovering the primary database in a timely manner.
During a failover operation, the failed primary database is removed from the Data Guard
environment, and a standby database assumes the primary database role. You invoke the
failover operation on the standby database that you want to fail over to the primary role. In
Oracle Database 10g Release 2, you can enable fast-start failover that allows Data Guard to
automatically and quickly fail over to a previously chosen, synchronized standby database.
Fast-start failover is discussed in detail in the lesson titled Enabling Fast-Start Failover.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Role Transitions: Switchover and Failover (continued)
Databases that have been disabled after a role transition are not removed from the broker
configuration, but they are disabled in the sense that the databases are no longer managed by the
broker. To reenable broker management of these databases, you must reinstate or re-create the
databases. Refer to the lesson titled Performing Switchover and Failover for detailed
information.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Data Protection Modes
Maximum protection
Maximum availability
Maximum performance
Data Protection Modes
Data Guard provides three high-level modes of data protection that you can configure to balance
cost, availability, performance, and transaction protection. You can configure the Data Guard
environment to maximize data protection, availability, or performance.
Maximum Protection
This protection mode guarantees that no data loss occurs if the primary database fails. To
provide this level of protection, the redo data that is needed to recover each transaction must be
written to both the local online redo log and the standby redo log (used to store redo data
received from another database) on at least one standby database before the transaction commits.
To ensure that data loss does not occur, the primary database shuts down if a fault prevents it
from writing its redo stream to at least one remote standby redo log. For multiple-instance Real
Application Clusters (RAC) databases, Data Guard shuts down the primary database if it is
unable to write the redo records to at least one properly configured database instance.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Data-Protection Modes (continued)
Maximum Availability
This protection mode provides the highest possible level of data protection without
compromising the availability of the primary database. As with maximum protection mode, a
transaction does not commit until the redo needed to recover that transaction is written to the
local online redo log and to at least one remote standby redo log. Unlike maximum protection
mode, the primary database does not shut down if a fault prevents it from writing its redo stream
to a remote standby redo log. Instead, the primary database operates in maximum performance
mode until the fault is corrected and all the gaps in the redo log files are resolved. When all the
gaps are resolved, the primary database automatically resumes operating in maximum
availability mode.
This mode guarantees that no data loss occurs if the primary database fails, but only if a second
fault does not prevent a complete set of redo data from being sent from the primary database to
at least one standby database.
Maximum Performance (Default)
This default protection mode provides the highest possible level of data protection without
affecting the performance of the primary database. This is accomplished by allowing a
transaction to commit as soon as the redo data needed to recover that transaction is written to the
local online redo log. The primary databases redo data stream is also written to at least one
standby database, but that redo stream is written asynchronously with respect to the commitment
of the transactions that create the redo data.
When network links with sufficient bandwidth are used, this mode provides a level of data
protection that approaches that of maximum availability mode with minimal impact on primary
database performance.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Benefits of Implementing
Oracle Data Guard
Oracle Data Guard provides the following benefits:
Continuous service through disasters or crippling data
failures
Complete data protection against corruptions and data
loss
Efficient use of system resources
Elimination of idle standby systems
Flexible configuration of your system to meet business
protection and recovery requirements
Centralized management
Benefits of Implementing Oracle Data Guard
Oracle Data Guard provides the following benefits:
Continuous service: With the use of switchover and failover between systems, your
business need not halt because of a disaster at one location.
Complete data protection: Data Guard guarantees no data loss and provides a safeguard
against data corruption and user errors. Redo data is validated when applied to the standby
database.
Efficient use of system resources: Standby databases can be used for reporting in addition
to providing a safeguard for disaster recovery. You can use a logical standby for real-time
reporting and the physical standby database for point-in-time reporting. You can also use
the physical standby database for backups of the primary database.
Elimination of idle standby systems: A standby database does not have to be idle when
you implement a logical standby database. This database is open and ready for reporting at
all times.
Flexible configurations: You can use Data Guard to configure the system to your needs.
With the use of protection modes and several tunable parameters, you can tailor the
configuration to your needs.
Centralized management: You can use Enterprise Manager Grid Control to manage all
configurations in your enterprise.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Role of Data Guard in a
High-Availability Architecture
RAC
ASM
Flashback
technology
Data
failures
Computer
failures
Corruption
Human
error
Site
failure
Storage
failure
Oracle HARD
RMAN
Data Guard
Role of Data Guard in a High-Availability Architecture
Oracle Database offers many features to protect your system from common types of downtime.
This course focuses on the use of Data Guard. Data Guard addresses data failure and disaster
recovery in high-availability architectures.
Real Application Clusters (RAC) enables you to build highly available and scalable database
servers across multiple systems. For more information about Real Application Clusters, you can
attend the Oracle Database 10g: Real Application Clusters course or review the Oracle Real
Application Clusters Administrators Guide.
Oracle Database 10g introduces the Automatic Storage Management (ASM) feature, which
provides a vertically integrated file system and volume manager in the Oracle kernel. For
additional information about ASM, see Oracle Database Concepts and the
Oracle Database Administrators Guide.
Oracle Database 10g includes flashback technologies to address human errors, including
Flashback Query, Flashback Versions Query, Flashback Transaction Query, Flashback
Database, Flashback Table, and Flashback Drop. For additional information about these features,
see the Oracle Database Administrators Guide.
Oracles Hardware Assisted Resilient Data (HARD) is a comprehensive program designed to
prevent data corruptions before they happen. Refer to Oracle High Availability Architecture and
Best Practices for additional information about the HARD initiative.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Role of Data Guard in a
High-Availability Architecture
Data
changes
System
changes
Online schema and
data reorganization
Partitioned tables
and indexes
Dynamic resource
provisioning
Rolling patch updates
Rolling release upgrade
using Data Guard
SQL Apply
Planned
downtime
Role of Data Guard in a High-Availability Architecture (continued)
There are a number of features in Oracle Database to support planned downtime that
encompasses data changes. Tables can be redefined without interruption to users who are
viewing or updating the data. Indexes can be added, rebuilt, or defragmented while the tables
that they index are being queried or updated. See the Oracle Database Administrators Guide for
additional information about these features.
Oracle Database dynamically accommodates a number of hardware configuration changes.
Patches can be applied to a RAC system in a rolling fashion.
Oracle Database 10g supports the installation of database software upgrades (and the application
of patchsets) in a rolling fashion by using Data Guard SQL Apply.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Oracle Data Guard and
Real Application Clusters
Oracle Data Guard and Real Application Clusters are
complementary and can be used together.
Real Application Clusters provides high availability.
Oracle Data Guard provides disaster protection and
prevents data loss.
Oracle Data Guard and Real Application Clusters
RAC provides the following for high availability:
Rapid and automatic recovery from node failures or an instance crash
Increased scalability
Oracle Data Guard provides disaster protection and prevents data loss by:
Maintaining transactionally consistent copies of the primary database
Protecting against data corruption
Protecting against user errors
Not requiring expensive and complex mirroring of hardware or software
RAC is covered in greater detail in the lesson titled Using Data Guard in a Real Application
Clusters Configuration.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Maximum Availability Architecture
RAC
production
database
RAC
physical
standby
database
Oracle
Application
Server
Oracle
Application
Server
WAN traffic
manager
Clients
Data Guard
RAC
logical
standby
database
Maximum Availability Architecture
RAC and Data Guard provide the basis for the database maximum availability architecture
(MAA) solution. MAA provides a comprehensive architecture for reducing downtime for
scheduled outages and preventing, detecting, and recovering from unscheduled outages. The
recommended MAA has two identical sites. The primary site contains the RAC database, and
the secondary site contains both a physical standby database and a logical standby database on
RAC.
Identical site configuration is recommended to ensure that performance is not sacrificed after a
failover or switchover. Symmetric sites also enable processes and procedures to be kept the same
between sites, making operational tasks easier to maintain and execute.
For more information about MAA, refer to the Oracle Database High Availability Overview
manual.
This course focuses on the Data Guard component of MAA.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Summary
In this lesson, you should have learned how to:
Describe the basic components of Oracle Data Guard
Describe the differences between physical and logical
standby databases
Determine when Oracle Data Guard is an appropriate
solution in your Oracle Database configuration
Explain the use of Data Guard in high-availability
architectures
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Practice 1: Overview
This practice covers the following topics:
Reviewing the factors that affect planned and
unplanned downtime
Reviewing the differences between physical and logical
standby databases
Reviewing the components of Oracle Data Guard
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y

Oracle Data Guard: Overview

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Data Guard: Overview

Uploaded by

Copyright:

Available Formats

Copyright 2006, Oracle. All rights reserved.

Oracle Data Guard: Overview

You might also like