Oracle Data Guard: Overview

Copyright © 2005, Oracle. All rights reserved.

 Objectives

After completing this lesson, you should be able to do

the following:
Describe the factors that affect planned and
unplanned down time
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

1-2 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration 1-2

 Causes of Data Loss

Hardware & system errors 49%

Human errors 36%

Computer viruses 7%

Software corruption 4%

Natural disasters 3%

Source: Disaster Recovery Journal

1-3 Copyright © 2005, Oracle. All rights reserved.

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
around-the-clock business continuity.

Oracle Database 10g: Data Guard Administration 1-3

 Every System Faces Down Time
Storage
failure
Computer
failures
Unplanned Human
down time error
Data
failures
Corruption

Data Site
changes failure
Planned
down time
System
changes

1-4 Copyright © 2005, Oracle. All rights reserved.

Unplanned Versus Planned Down Time

Every system faces both unplanned and planned down time. It is important to consider causes of
both unplanned and planned down time when designing a fault-tolerant, resilient infrastructure.
Unplanned down time consists of the following:
Computer failures: Down time 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: Down time 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: Down time occurs when there is some sort of data corruption or natural
disaster such as a flood, fire, or earthquake.
Planned down time includes routine operations, periodic maintenance, and new deployments.
Planned down time includes the following:
Data changes: Table redefinition and index rebuild
System changes: Down time occurs during hardware and operating-system upgrades.

Oracle Database 10g: Data Guard Administration 1-4

 What Is Oracle Data Guard?

Production Standby
database Redo transport database

Oracle Net

Database Database
copy

1-5 Copyright © 2005, Oracle. All rights reserved.

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 transactionally consistent 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 on this feature.

Oracle Database 10g: Data Guard Administration 1-5

 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

1-6 Copyright © 2005, Oracle. All rights reserved.

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 is logically identical to the primary database. 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 on LogMiner, refer to Oracle Database Utilities.

Oracle Database 10g: Data Guard Administration 1-6

 Oracle Data Guard Broker Framework

Oracle
Management
Server
Repository

Agent Agent

Primary Standby
database database
Data Data
Guard Guard
broker Enterprise Manager broker

CLI management client

1-7 Copyright © 2005, Oracle. All rights reserved.

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.
Enterprise Manager provides a Web-based interface that combines with the broker's 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.

Oracle Database 10g: Data Guard Administration 1-7

 Types of Services

There are three types of services provided with Data

Guard:
Log transport services
Log apply services
Redo Apply
SQL Apply
Role-management services

1-8 Copyright © 2005, Oracle. All rights reserved.

Types of Services
The following types of services are available with Data Guard:
Log 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 log
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.

Oracle Database 10g: Data Guard Administration 1-8

 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
Role-transition operations are not automatically
invoked.

1-9 Copyright © 2005, Oracle. All rights reserved.

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 broker's 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.

Oracle Database 10g: Data Guard Administration 1-9

Role Transitions: Switchover and Failover (continued)
You should not fail over to a standby database except in an emergency, because the
failover operation may result in the loss of application data. After you perform a failover
operation, there is no going back. This is because the original primary database is disabled
and the standby database that you fail over to the primary role cannot return to the role of a
standby database in the original configuration.

Oracle Database 10g: Data Guard Administration 1-10

 Data-Protection Modes

Maximum protection
Maximum availability
Maximum performance

1-11 Copyright © 2005, Oracle. All rights reserved.

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 to the standby redo log 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.

Oracle Database 10g: Data Guard Administration 1-11

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 gaps in redo log files are resolved. When all 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 database s 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.

Oracle Database 10g: Data Guard Administration 1-12

 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

1-13 Copyright © 2005, Oracle. All rights reserved.

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 to manage all configurations
in your enterprise.

Oracle Database 10g: Data Guard Administration 1-13

 Role of Data Guard in a
High Availability Architecture
Computer RAC
failures

Storage
failure
ASM

Human Flashback
error technology
Data
failures
Oracle HARD
Corruption RMAN

Site
Data Guard
failure

1-14 Copyright © 2005, Oracle. All rights reserved.

Role of Data Guard in a High Availability Architecture

Oracle Database offers many features to protect your system from common types of down time.
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 Administrator s 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 Administrator s 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 Administrator s Guide.
Oracle s 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.

Oracle Database 10g: Data Guard Administration 1-14

 Role of Data Guard in a
High Availability Architecture

Online schema and

data reorganization
Data Partitioned tables
changes and indexes
Dynamic resource
provisioning
Planned
down time

Rolling patch updates

System Rolling release upgrade
changes using Data Guard
SQL Apply

1-15 Copyright © 2005, Oracle. All rights reserved.

Role of Data Guard in a High Availability Architecture (continued)

There are a number of features in Oracle Database to support planned down time 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 Administrator s 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.

Oracle Database 10g: Data Guard Administration 1-15

 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.

1-16 Copyright © 2005, Oracle. All rights reserved.

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 Using Data Guard with RAC lesson.

Oracle Database 10g: Data Guard Administration 1-16

 Maximum Availability Architecture

Clients

Oracle WAN traffic Oracle

Application manager Application
Server Server

Data Guard RAC RAC

RAC
production physical logical
database standby standby
database database

1-17 Copyright © 2005, Oracle. All rights reserved.

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 down time 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 High Availability Architecture and Best Practices
documentation.
This course focuses on the Data Guard component of MAA.

Oracle Database 10g: Data Guard Administration 1-17

 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

1-18 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration 1-18

 Practice 1: Overview

This practice covers the following topics:

Reviewing the factors that affect planned and
unplanned down time
Reviewing the differences between physical and
logical standby databases
Reviewing the components of Oracle Data Guard

1-19 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration 1-19