Oracle10g - Data Guard Administration - D40345

Oracle Database 10g: Data
Guard Administration
Student Guide
D17316GC11
Edition 1.1
January 2005
D40345
Authors Copyright © 2005, Oracle. All rights reserved.
Donna Keesling This documentation contains proprietary information of Oracle Corporation. It is

Ric Van Dyke provided under a license agreement containing restrictions on use and disclosure and
is also protected by copyright law. Reverse engineering of the software is prohibited.
If this documentation is delivered to a U.S. Government Agency of the Department of
Technical Contributors Defense, then it is delivered with Restricted Rights and the following legend is
applicable:
and Reviewers
Restricted Rights Legend
Christopher Andrews
Larry Baumann Use, duplication or disclosure by the Government is subject to restrictions for
Tammy Bednar commercial computer software and shall be deemed to be Restricted Rights software
under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013,
Harald van Breederode Rights in Technical Data and Computer Software (October 1988).
Mary Bryksa
This material or any portion of it may not be copied in any form or by any means
Bernhard de Cock Buning without the express prior written permission of Oracle Corporation. Any other copying
Larry Carpenter is a violation of copyright law and may result in civil and/or criminal penalties.
Sean Connolly
If this documentation is delivered to a U.S. Government Agency not within the
Raymond Dutcher Department of Defense, then it is delivered with “Restricted Rights,” as defined in
Mark Fuller FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).
Joel Goodman The information in this document is subject to change without notice. If you find any
Raymond Guzman problems in the documentation, please report them in writing to Education Products,
Ziemowit Jankowski Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065.
Oracle Corporation does not warrant that this document is error-free.
Nitin Karkhanis
Jiangbin Luo All references to Oracle and Oracle products are trademarks or registered trademarks
of Oracle Corporation.
Ashish Ray
Vivian Schupmann All other products or company names are used for identification purposes only, and
Jim Spiller may be trademarks of their respective owners.
S Matt Taylor
Michael Verheij
John Watson
Publisher
Nita Brozowski
Contents
Preface
1 Oracle Data Guard: Overview
Objectives 1-2
Causes of Data Loss 1-3
Every System Faces Down Time 1-4
What Is Oracle Data Guard? 1-5
Types of Standby Databases 1-6
Oracle Data Guard Broker Framework 1-7
Types of Services 1-8
Role Transitions: Switchover and Failover 1-9
Data-Protection Modes 1-11
Benefits of Implementing Oracle Data Guard 1-13
Role of Data Guard in a High Availability Architecture 1-14
Oracle Data Guard and Real Application Clusters 1-16
Maximum Availability Architecture 1-17
Summary 1-18
Practice 1: Overview 1-19
2 Understanding the Oracle Data Guard Architecture
Objectives 2-2
Data Guard Operational Requirements: Hardware and Operating System 2-3
Data Guard Operational Requirements: Oracle Database Software 2-4
Oracle Data Guard: Architecture 2-6
Primary Database Flow 2-7
Standby Database Flow 2-8
Standby Redo Logs 2-9
Data Guard Redo Apply: Architecture 2-10
Data Guard SQL Apply: Architecture 2-12
SQL Apply Process: Architecture 2-13
Real-Time Apply 2-14
Setting the DB_UNIQUE_NAME Parameter 2-16
Specifying Role-Based Destinations 2-17
Combinations for VALID_FOR 2-19
Identifying Destination Settings 2-20
Standby Redo Log Configuration 2-21
Number of Standby Redo Logs 2-22
Using SQL to Add Standby Redo Logs 2-23
Using Enterprise Manager to Add Standby Redo Logs 2-24
Standby Database Modes 2-25
Summary 2-27
Practice 2-1: Overview (Architecture) 2-28
Practice 2-2: Overview (Installing the Oracle Management Agent) 2-29
Practice 2-3: Overview (Configuring Your Primary Database) 2-30
iii
3 Data Guard Broker and Enterprise Manager
Objectives 3-2
Features of Data Guard Broker 3-3
Data Guard Broker: Components 3-4
Data Guard Broker: Configurations 3-5
Data Guard Broker: Management Model 3-6
Data Guard Broker: Architecture 3-7
Life Cycle of a Broker Configuration 3-8
Data Guard Broker: Requirements 3-9
Data Guard Broker and the SPFILE 3-11
Data Guard Monitor: DMON Process 3-13
Data Guard Monitor: Configuration File 3-14
Benefits of Using the Data Guard Broker 3-15
Data Guard Broker Interfaces 3-17
Using Oracle Enterprise Manager 10g Grid Control 3-19
Data Guard Overview Page 3-20
Enterprise Manager Metrics and Alerts 3-21
Using Data Guard Metrics 3-22
Managing Data Guard Metrics 3-23
Benefits of Using Enterprise Manager 3-24
Using the Command-Line Interface of the Data Guard Broker 3-25
Summary 3-27
4 Creating a Configuration with Enterprise Manager
Objectives 4-2
Enabling FORCE LOGGING Mode 4-3
Using Enterprise Manager to Create a Broker Configuration 4-5
Creating a Configuration 4-6
Using the Add Standby Database Wizard 4-8
Step 1: Specify the Backup Type 4-9
Step 2: Specify the Backup Options 4-10
Step 3: Select the Oracle Home – Instance Name 4-11
Step 3: Select the Oracle Home – Oracle Home 4-12
Step 4: Specify the Standby Database File Locations – Access Method 4-13
Step 4: Specify the Standby Database File Locations – File Locations 4-14
Step 5: Specify Standby Database Configuration Parameters 4-15
Step 6: Review the Configuration Information 4-16
Standby Database Creation: Processing 4-17
Standby Database Creation: Progress 4-19
Standby Database Creation: Job Details 4-20
Verifying a Configuration 4-21
Reviewing Results of the Verify Operation 4-22
Creating Standby Redo Logs 4-23
Viewing the Data Guard Configuration Status 4-24
Viewing Data Guard Performance 4-25
Summary 4-27
iv
5 Creating a Physical Standby Database by Using SQL
Objectives 5-2
Steps to Create a Physical Standby Database 5-3
Preparing the Primary Database 5-4
Initialization Parameters on the Primary Database 5-5
LOG_ARCHIVE_CONFIG 5-6
LOG_ARCHIVE_DEST_n 5-7
LOCATION and SERVICE Attributes 5-8
LOG_ARCHIVE_DEST_STATE_n 5-9
Specifying Values for DB_FILE_NAME_CONVERT 5-10
Specifying Values for LOG_FILE_NAME_CONVERT 5-11
Specifying a Value for LOG_ARCHIVE_FORMAT 5-12
Specifying a Value for STANDBY_FILE_MANAGEMENT 5-13
ARCHIVE_LAG_TARGET 5-14
LOG_ARCHIVE_TRACE Parameter 5-15
LOG_ARCHIVE_TRACE 5-16
Backing Up the Primary Database by Using RMAN 5-17
Creating a Control File for the Standby Database 5-18
Copying Files to the Standby Database System 5-19
Oracle Managed Files (OMF) and Automatic Storage Management (ASM) 5-20
Initialization Parameters on the Standby 5-21
Specifying a Value for STANDBY_ARCHIVE_DEST 5-22
Setting Up the Environment to Support the Standby Database 5-23
Starting Up the Physical Standby Database 5-25
Additional Configuration Tasks 5-26
Special Note: Standby Database on Same System 5-27
Summary 5-28
6 Data Protection Modes and Log Transport Services
Objectives 6-2
Data Protection Modes and Log Transport Modes 6-3
Attributes of LOG_ARCHIVE_DEST_n 6-4
Setting the Log Transport Mode 6-6
Data Protection Modes 6-8
Maximum Protection 6-9
Maximum Availability 6-10
Maximum Performance 6-11
Setting the Data Protection Mode 6-12
Setting the Data Protection Mode by Using the CLI 6-14
Setting the Protection Mode by Using SQL 6-15
Delaying the Application of Redo 6-16
Using Enterprise Manager to Delay the Application of Redo 6-17
Setting LOG_ARCHIVE_DEST_n to Delay the Application of Redo 6-18
Using Flashback Database Instead of Apply Delay 6-19
Additional Attributes That Affect Log Transport Services 6-20
ALTERNATE and NOALTERNATE Attributes 6-21
MAX_FAILURE and NOMAX_FAILURE Attributes 6-22
NET_TIMEOUT and NONET_TIMEOUT Attributes 6-23
REOPEN and NOREOPEN Attributes 6-24
Summary 6-25
v
7 Data Guard SQL Apply Architecture
Objectives 7-2
Benefits of Implementing a Logical Standby Database 7-3
Securing Your Logical Standby Database 7-5
Preparing to Create a Logical Standby Database 7-6
Unsupported Data Types 7-7
Unsupported Objects 7-8
Checking for Tables with Unsupported Data Types 7-9
Unsupported DDL Commands 7-10
Ensuring Unique Row Identifiers 7-11
Adding a Disabled Primary Key RELY Constraint 7-13
Supplemental Logging 7-14
Enabling Supplemental Logging 7-16
Verifying Values of Initialization Parameters 7-17
Creating a Logical Standby Database with Enterprise Manager 7-18
Using the Add Standby Database Wizard 7-19
Step 1: Specifying the Backup Type 7-20
Step 2: Specifying the Backup Options 7-21
Step 3: Selecting the Oracle Home – Instance Name 7-22
Step 4: Specifying the Standby Database File Locations – Access Method 7-23
Step 4: Specifying the Standby Database File Location – File Locations 7-24
Step 5: Specifying Standby Database Configuration Parameters 7-25
Step 6: Reviewing the Configuration Information 7-26
Standby Database Creation Processing 7-27
Resolving a Failed or Canceled Configuration Creation 7-28
Summary 7-29
8 Creating a Logical Standby Database by Using SQL
Objectives 8-2
Preparing to Create a Logical Standby Database 8-3
Creating a Logical Standby Database 8-4
Step 1: Create a Physical Standby Database 8-5
Step 2: Prepare the Primary Database to Support a Logical Standby Database 8-6
Step 3: Prepare to Transition to a Logical Standby Database 8-8
Step 4: Start the Logical Standby Database 8-10
Step 5: Verify That the Logical Standby Database Is Performing Properly 8-12
Additional Configuration Tasks 8-14
Summary 8-15
9 Switchover and Failover
Objectives 9-2
Types of Roles in an Oracle Data Guard Configuration 9-3
Role Management Services 9-4
Role Transitions: Switchover and Failover 9-5
Role Transition Decision Tree 9-7
Switchover 9-8
Switchover: Before 9-9
Switchover: After 9-10
vi
Standby Redo Logs and Switchovers 9-11
Preparing for a Switchover 9-12
Performing a Switchover with Enterprise Manager 9-13
Performing a Switchover to a Physical Standby by Using SQL 9-16
Performing a Switchover to a Logical Standby by Using SQL 9-18
Considerations When Performing a Switchover to a
Logical Standby Database 9-23
Situations That Prevent a Switchover 9-25
Failover 9-26
Failover Considerations 9-27
Performing a Failover with Enterprise Manager 9-28
Performing a Failover to a Physical Standby Database 9-31
Performing a Failover to a Logical Standby Database 9-32
Performing a Failover to a Physical Standby Database by Using SQL 9-33
Performing a Failover to a Logical Standby Database by Using SQL 9-36
Activating a Standby Database 9-38
Using Flashback Database After Failover 9-39
Summary 9-42
10 Using Data Guard with RAC
Objectives 10-2
Real Application Clusters and Data Guard 10-3
Configuration Considerations with RAC 10-4
Multi-Instance Primary with a Single-Instance Standby 10-6
Multi-Instance Primary with a Multi-Instance Standby 10-7
Log Transport with RAC to RAC 10-8
Setting Up a Primary Database with RAC 10-9
Setting Up a Standby Database with RAC 10-10
Assigning Threads to Standby Redo Log Groups 10-11
Apply Instance Failover 10-12
Role Transitions with RAC 10-14
Troubleshooting 10-15
Summary 10-17
11 Other Considerations for Oracle Data Guard
Objectives 11-2
Offloading Backups to a Physical Standby 11-3
Backing Up a Physical Standby Database with RMAN 11-4
Backup and Recovery of a Logical Standby Database 11-6
Using Flashback Database and Real-Time Apply 11-7
Using Flashback Database After RESETLOGS 11-8
Enabling Redo Encryption 11-10
Cascaded Redo Log Destinations 11-11
Configuring Cascaded Redo Log Destinations: Physical Standby 11-12
Configuring Cascaded Redo Log Destinations: Logical Standby 11-14
Role Transitions with Cascaded Redo Log Destinations 11-16
Summary 11-17
vii
12 Workshop
Objectives 12-2
Workshop Premise 12-3
Workshop Flow 12-4
Workshop Scenarios 12-5
Summary 12-8
Workshop Steps 12-10
Appendix A: Practices and Solutions
Appendix B: Oracle Data Guard: History
viii
Preface
Profile
Before You Begin This Course

Before you begin this course, you should have the following qualifications:
• Thorough knowledge of Oracle Database 10g
• Working experience with Oracle Database 10g and Oracle Enterprise Manager Grid Control
Prerequisites
• Oracle Database 10g: Administration Workshop I (D17090GC10)
• Oracle Database 10g: Administration Workshop II (D17092GC20)
• Suggested: Oracle Enterprise Manager 10g Grid Control (D17244GC10)
How This Course Is Organized
Oracle Database 10g: Data Guard Administration is an instructor-led course featuring lectures and
hands-on exercises. Online demonstrations and written practice sessions reinforce the concepts and
skills introduced.
Preface - 3
Related Publications
Oracle Publications
Title Part Number
Oracle Database Administrator's Guide 10g Release 1 (10.1) B10739-01
Oracle Database Concepts 10g Release 1 (10.1) B10743-01
Oracle Database Performance Tuning Guide
10g Release 1 (10.1) B10752-01
Oracle Database Reference 10g Release 1 (10.1) B10755-01
Oracle Database SQL Reference 10g Release 1 (10.1) B10759-01
Oracle Database Utilities 10g Release 1 (10.1) B10825-01
Oracle Data Guard Broker 10g Release 1 (10.1) B10822-01
Oracle Data Guard Concepts and Administration
10g Release 1 (10.1) B10823-01
Additional Publications
• System release bulletins
• Installation and user’s guides
• International Oracle User’s Group (IOUG) articles
• Oracle Magazine
Preface - 4
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
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
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.

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

What Is Oracle Data Guard?
Production Standby
database Redo transport database
Oracle Net
Database Database
copy
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.

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

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

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.

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.

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.

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

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.

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

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

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

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

Summary
In this lesson, you should have learned how to:

• Describe the basic components of Oracle Data
Guard
• Describe the differences between physical and
• Determine when Oracle Data Guard is an
appropriate solution in your Oracle Database
configuration
• Explain the use of Data Guard in high availability
architectures

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
• Reviewing the components of Oracle Data Guard

Understanding the Oracle
Data Guard Architecture

Objectives

the following:
• Describe the Data Guard architecture
• Explain the operational requirements of Data
Guard
• Describe how Data Guard processes, transports,
and applies redo logs
• Describe standby database modes

Data Guard Operational Requirements:
Hardware and Operating System
• The hardware can be different for the primary and

standby databases.
• The operating system and platform architecture
for the primary and standby databases must be
the same.
• The operating system for the primary and standby
databases must be the same, but the operating
system releases can be different.
• If all databases are on the same system, verify that
the OS allows you to mount more than one
database with the same name.
Hardware and Operating System Requirements

These are the operational requirements for Data Guard with respect to the hardware and
operating system:
• The hardware for the primary and standby database systems can be different. For example,
the number of CPUs, the memory size, and the storage configuration can differ.
• The operating system and platform architecture for the primary and standby databases must
be the same.
• The operating system on both databases must be the same, but the operating system release
does not need to be the same.
Note: Standby databases can use a different directory structure from the primary database.
• If both the primary and the standby databases are on the same server, you must ensure that
the operating system allows you to mount two databases with the same name on the same
system simultaneously. There are certain parameters that must be specified to support this
configuration, as discussed in the lesson titled “Creating a Physical Standby Database by
Using SQL.”

Data Guard Operational Requirements:
Oracle Database Software
• Same release of Oracle Database Enterprise

Edition must be installed for all databases.
• SYSDBA privileges are required for the accounts
used to manage the database instances.
• Each database must have its own control file.
• Primary database must operate in ARCHIVELOG
mode.
• Enable FORCE LOGGING on the primary database
before taking data file backups for standby
creation.
• If any databases use ASM and/or OMF, all should
use the same combination.
Oracle Database Software Requirements

These are the operational requirements for Data Guard with respect to Oracle Database software:
• You must install the same release of Oracle Database Enterprise Edition for the primary
database and all standby databases in your Data Guard configuration.
• You must have SYSDBA system privileges for the user accounts that you use to manage the
primary and standby database instances. Furthermore, the SYS user must have the same
password on all databases in the configuration.
• The primary database and each standby database must have their own control files.
• The primary database must be configured in ARCHIVELOG mode.

Oracle Database Software Requirements (continued)
• Some data definition language (DDL) statements permit the NOLOGGING clause, which
causes some database operations not to generate redo records in the database redo log. The
NOLOGGING setting can speed up operations that can be easily recovered outside of the
database recovery mechanisms, but it can negatively affect media recovery and standby
databases. You can enable FORCE LOGGING to force the writing of redo records even
when NOLOGGING has been specified in DDL statements. To protect against unlogged
direct writes in the primary database that cannot be propagated to the standby database,
enable FORCE LOGGING on the primary database before taking data file backups for
standby creation. You should maintain the FORCE LOGGING mode as long as the standby
database is active.
• If you use Oracle Automatic Storage Management (ASM) and Oracle Managed Files
(OMF) in a Data Guard configuration, you should use ASM and OMF symmetrically on
the primary and standby database. If any database in your Data Guard configuration uses
ASM, OMF, or both, then every database in the configuration should use ASM, OMF, or
both, respectively.

Oracle Data Guard: Architecture
Primary
MRP or Standby
database
LSP database
transactions
(MRP only)
LGWR RFS
Oracle net
Online
redo Standby
logs redo logs Backup
FAL Reports
ARC0
ARC0
Archived redo Archived redo

logs logs
Oracle Data Guard: Architecture

Oracle Data Guard leverages the existing database redo generation architecture to keep the
standby databases in the configuration synchronized with the primary database. By using the
existing architecture, Oracle Data Guard minimizes its impact on the primary database.
Oracle Data Guard uses several processes to achieve the automation that is necessary for disaster
recovery and high availability. Some of these processes existed prior to the introduction of Data
Guard; others were created specifically to support Oracle Data Guard. These processes are
discussed in more detail on the next few pages.

Primary Database Flow
Primary
MRP or Standby
database
LSP database
transactions
(MRP only)
LGWR RFS
Oracle net
Online
redo Standby
FAL Reports
ARC0
ARC0

logs logs
Primary Database Flow

On the primary database, Data Guard log transport services use the following processes:
• Log writer (LGWR) process: LGWR collects transaction redo information and updates
the online redo logs. In synchronous mode, it ships redo information directly to the remote
file server (RFS) process on the standby database and waits for a confirmation before
proceeding. In asynchronous mode, it ships the redo information directly but doesn’t wait
before proceeding. In asynchronous mode, LGWR submits the network I/O request to the
network server (LNSn) process for that destination.
• Archiver (ARCn) process: ARCn, or a SQL session performing an archival operation,
creates a copy of the online redo logs locally for use in a primary database recovery. The
ARCn process may also ship the redo stream to the RFS process while simultaneously
archiving the online log. ARCn is also responsible for proactively detecting and resolving
gaps on all standby databases.
• Fetch archive log (FAL) (physical standby databases only): FAL provides a client/server
mechanism for resolving gaps detected in the range of archived redo logs that are generated
at the primary database and received at the standby database. This process is started only
when needed and shuts down as soon as it is finished. It is very likely you will not see this
process running.
Note: You can configure a primary database to ship redo information by using LGWR or ARCn,
but not both.

Standby Database Flow
Primary
MRP or Standby
database
LSP database
transactions
(MRP only)
LGWR RFS
Oracle net
Online
redo Standby
FAL Reports
ARC0
ARC0

logs logs
Standby Database Flow

On the standby database, Data Guard log apply services use the following processes:
• Remote file server (RFS) process: RFS receives redo information from the primary
database. RFS can write the redo into standby redo logs or directly to archived redo logs.
Note: Standby redo logs are optional. The use of standby redo logs is discussed in more
detail later in the lesson.
• Archiver (ARCn) process: The ARCn process archives the standby redo logs.
• Managed recovery process (MRP): For physical standby databases only, MRP applies
archived redo log information to the physical standby database. If you start the managed
recovery with the SQL statement ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE; this foreground session performs the recovery. If you use the optional clause
DISCONNECT [FROM SESSION], the MRP background process starts. If you use Data
Guard broker to manage your standby databases, the broker always starts the MRP
background process for a physical standby database.
• Logical standby process (LSP): For logical standby databases only, LSP controls the
applying of archived redo log information to the logical standby database.

Standby Redo Logs
Standby Archived
Redo from redo logs redo logs
primary database
RFS ARC0
MRP/LSP
Standby database
Standby Redo Logs

A standby redo log is used only when the database is in the standby role to store redo data
received from the primary database. Standby redo logs form a separate pool of log file groups.
Configuring standby redo log files is highly recommended on all standby databases in a Data
Guard configuration, including the primary database to aid in role reversal.
A standby redo log is required to implement:
• The maximum protection and maximum availability levels of data protection
• Real-time apply
• Cascaded redo log destinations
Standby redo logs are recommended for maximum performance data protection mode.
Unless you are using the real-time apply feature, standby redo logs must be archived before the
data can be applied to the standby database. The standby archival operation occurs
automatically.
Note: The real-time apply feature is discussed in more detail later in this lesson.

Data Guard Redo Apply: Architecture
Production Physical standby

database database
Redo Redo
transport apply
Redo
stream
Backup
Primary Physical standby

database database
Data Guard Redo Apply: Architecture

The Data Guard physical standby Redo Apply architecture consists of:
• A production (primary) database, which is linked to one or more standby databases (up to
nine) that are identical copies of the production database
- The limit of nine standby databases is imposed by the LOG_ARCHIVE_DEST_n
parameter. In Oracle Database 10g, the maximum number of destinations is 10. One
is used as the local archive destination, leaving the other nine for uses such as the
standby 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.
- The primary database is open and active. The standby databases are either in recovery
mode or open read-only, but not both.

Data Guard Redo Apply: Architecture (continued)
• The standby database, which is updated by redo that is automatically shipped from the
primary database. The redo can be shipped because it is generated or archived on the
primary database.
- Redo is applied to each standby database by using standard Oracle recovery
techniques.
- During planned down time, you can perform a switchover to a standby database.
- When a failure occurs, you may fail over to one of the standby databases.
- The physical standby database can also be used to back up the primary database.

Data Guard SQL Apply: Architecture
Production Logical standby

database database
SQL
Redo transport Apply
Transform redo
information into
SQL
Reports
Primary Logical standby

database database
Data Guard SQL Apply: Architecture

In a logical standby database configuration, Data Guard SQL Apply uses redo information
shipped from the primary system. However, instead of using media recovery to apply changes
(as in the physical standby database configuration), archived redo log information is transformed
into equivalent SQL statements by using LogMiner technology. These SQL statements are then
applied to the logical standby database. The logical standby database is open in read/write mode
and is available for reporting capabilities.

SQL Apply Process: Architecture
LCR
Reader Preparer LCR Builder
:
Redo Shared
records pool
Redo data from Logical change records not
primary database Log Mining grouped into transactions Transaction
groups
Apply processing
Applier Coordinator Analyzer
Transactions to Transactions
Data files be applied sorted in
dependency
order
SQL Apply Process: Architecture

SQL Apply uses a collection of parallel execution servers and background processes that apply
changes from the primary database to the logical standby database as follows:
• The reader process reads redo records from the archived redo log files.
• The preparer processes convert the block changes into table changes or logical change
records (LCRs). At this point, the LCRs do not represent any specific transactions.
• The builder process assembles completed transactions from the individual LCRs.
• The analyzer process examines the records, possibly eliminating transactions and
identifying dependencies between the different transactions.
• The coordinator process (LSP):
- Assigns transactions
- Monitors dependencies between transactions and coordinates scheduling
- Authorizes the commitment of changes to the logical standby database
• The applier process:
- Applies the LCRs to the database
- Asks the coordinator process to approve transactions with unresolved dependencies
- Commits the transactions

Real-Time Apply
RFS
Primary MRP or LSP

database Standby
redo log
files
ARC0
Archived
redo log
Standby
files
database
Real-Time Apply
When you enable the optional real-time apply feature, log apply services apply the redo data
from standby redo log files in real time (at the same time the log files are being written to) as
opposed to recovering redo from archived redo log files when a log switch occurs. If for some
reason the apply service is unable to keep up (for example, if you have a physical standby in
READ ONLY mode for a period of time), then the apply service automatically goes to the archive
log files as needed. The apply service also tries to catch up and go back to reading the standby
redo log files as soon as possible.
Real-time application of redo information provides a number of benefits, including quicker
switchover and failover operations, instantly up-to-date results after you change a physical
standby database to read-only, up-to-date reporting from a logical standby database, and the
ability to leverage larger logs files.
Having larger log files with real-time apply is desirable because the apply service stays with a
log longer and the overhead of switching has less impact on the real-time apply processing.
The RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view contains the value
MANAGED REAL TIME APPLY when log apply services are running in real-time apply mode.

Real-Time Apply (continued)
If you define a delay on a destination (with the DELAY attribute) and use real-time apply, the
delay is ignored.
For physical standby databases, the managed recovery process (MRP) applies the redo from the
standby redo log files after the remote file server (RFS) process finishes writing. To start real-
time apply for a physical standby database, issue the following command:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT
LOGFILE;
For logical standby databases, the logical standby process (LSP) applies the redo from the
standby redo log files after the RFS process finishes writing. To start real-time apply for a logical
standby database, issue the following command:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Note: Standby redo log files are required for real-time apply. It is highly recommended that you
have one more standby redo log group than the number of online log groups on the primary
database.
Real-time apply is supported by the broker.

Setting the DB_UNIQUE_NAME Parameter
San Francisco
SF1_DB
DB_UNIQUE_NAME = SF1_DB
Setting the DB_UNIQUE_NAME Parameter

Data Guard identifies all the databases in its configuration by using the DB_UNIQUE_NAME
initialization parameter. Choose a unique name for each database and assign it with this
parameter. The DB_UNIQUE_NAME value must remain constant for a given database. Therefore,
you should choose names that are easy for you to remember and identify, and you should not
change the names after you have assigned them.
Each DB_UNIQUE_NAME value can be up to 30 characters long and must be the same for all
instances in a RAC database.
The default is the database name. If you use Enterprise Manager to create a standby database, it
sets this to a unique value for the new standby database.
Note: DB_UNIQUE_NAME replaces LOCK_NAME_SPACE, which is now deprecated.
DB_UNIQUE_NAME takes precedence over LOCK_NAME_SPACE. If you still use
LOCK_NAME_SPACE, it will not halt the starting of your instance.

Specifying Role-Based Destinations
Primary Standby
database database
Not used
LOG_ARCHIVE_DEST_2= location=
"/u01/app/oracle/oradata/orcldg2/arc",
valid_for=(STANDBY_LOGFILE,STANDBY_ROLE)
DB_UNIQUE_NAME = HRDB2
Specifying Role-Based Destinations

The VALID_FOR attribute of the LOG_ARCHIVE_DEST_n initialization parameter allows you
to identify exactly when the archive destination is to be used, as well as for which type of log file
it is used. The attribute uses a keyword pair to identify the source of the archival as well as the
database role.
In the example in the slide, there is a destination on the standby database and the primary
database defined with the VALID_FOR setting shown. This destination is only to be used on the
standby database after a switchover, when the standby becomes a primary. The destination on
the old primary is ignored when it becomes a standby.
You supply two values for the VALID_FOR attribute: archival_source and
database_role.
The archival_source keywords are the following:
• ONLINE_LOGFILE: This destination is used only when archiving online redo log files.
• STANDBY_LOGFILE: This destination is used only when archiving standby redo log files
or receiving archive logs from another database.
• ALL_LOGFILES: This destination is used when archiving either online or standby redo
log files.

Specifying Role-Based Destinations (continued)
The database_role keywords are the following:
• PRIMARY_ROLE: This destination is used only when the database is in the primary
database role.
• STANDBY_ROLE: This destination is used only when the database is in the standby
(logical or physical) role.
• ALL_ROLES: This destination is used when the database is in either the primary or
standby (logical or physical) role.
Note: Because the keywords are unique, the archival_source and database_role
values can be specified in any order. For example,
VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILE) is functionally equivalent to
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE).
Also, if you are using the SERVICE keyword with the VALID_FOR attribute, you must specify
the DB_UNIQUE_NAME keyword as well.

Combinations for VALID_FOR
Combination Primary Physical Logical
ONLINE_LOGFILE, PRIMARY_ROLE Valid Ignored Ignored
ONLINE_LOGFILE, STANDBY_ROLE Ignored Ignored Valid
ONLINE_LOGFILE, ALL_ROLES Valid Ignored Valid
STANDBY_LOGFILE,STANDBY_ROLE Ignored Valid Valid
STANDBY_LOGFILE, ALL_ROLES Ignored Valid Valid
ALL_LOGFILES, PRIMARY_ROLE Valid Ignored Ignored
ALL_LOGFILES, STANDBY_ROLE Ignored Valid Valid
ALL_LOGFILES, ALL_ROLES Valid Valid Valid
Combinations for VALID_FOR

In the table, the word Valid means that the archive log destination is used in a database that is in
the role defined by the column heading. The Ignored value means the archive log destination is
not appropriate and a destination of this type is ignored. An ignored destination does not
generate an error.
ALL_LOGFILES, ALL_ROLES is not a recommended setting for a logical standby for any
destination. Because a logical standby is an open database that is creating its own redo, there is a
real possibility of having the log files overwrite each other. This gives you a system that is
unrecoverable and/or unable to keep synchronized with the primary database.
There is only one invalid combination: STANDBY_LOGFILE, PRIMARY_ROLE. If this is
specified, it causes an error for all database roles. If this is set, you receive the following error at
startup:
ORA-16026: The parameter LOG_ARCHIVE_DEST_n contains an
invalid attribute value
Note: Both the single and plural forms of the keywords are valid. For example, you can specify
either PRIMARY_ROLE or PRIMARY_ROLES, and ONLINE_LOGFILE or
ONLINE_LOGFILES.

Identifying Destination Settings
SQL> SELECT DEST_ID,VALID_TYPE,VALID_ROLE,VALID_NOW
2 FROM V$ARCHIVE_DEST;
DEST_ID VALID_TYPE VALID_ROLE VALID_NOW
------- --------------- ------------ --------------
1 ONLINE_LOGFILE ALL_ROLES YES
2 STANDBY_LOGFILE STANDBY_ROLE YES
3 ALL_LOGFILES ALL_ROLES UNKNOWN
11 ALL_LOGFILES ALL_ROLES YES
11 rows selected.
Identifying Destination Settings

The VALID_NOW column in V$ARCHIVE_DEST indicates whether or not the archive log
destination is used. The column values are the following:
• YES: This value indicates the archive log destination is appropriately defined for the
current database role
• WRONG VALID_TYPE: This value indicates that the archive log destination is
appropriately defined for the current database role but cannot be used. For example,
LOG_ARCHIVE_DEST_2 is set to (STANDBY_LOGFILES,STANDBY_ROLE), but
WRONG VALID_TYPE is returned because this standby destination does not have a
standby redo log implemented.
• WRONG VALID_ROLE: This value indicates that the archive log destination is not
appropriately defined for the current database role. For example,
LOG_ARCHIVE_DEST_3 is set to (ONLINE_LOGFILES,STANDBY_ROLE), but
WRONG VALID_ROLE is returned because this destination is currently running in the
primary database role.
• UNKNOWN: This value indicates that the archive log destination is not defined.
The VALID_TYPE and VALID_ROLE columns are the respective values from the VALID_FOR
attribute that is specified for each archive log destination.

Standby Redo Log Configuration
Online Standby
redo redo
Redo
logs shipment logs
RFS
Primary Standby
database database
Standby Redo Log Configuration

You must create at least the same number of standby redo log files as are contained on the
primary database. It is highly recommended that you have one more standby redo log group than
you have online redo log groups as the primary. In addition, the files must be the same size or
larger than the primary database’s online redo logs. If your online redo log files are of different
sizes, the RFS process automatically uses the same size standby redo log as the online redo log
file.
The RFS process writes to an archive redo log file if any of the following conditions are met:
• There are no standby redo logs.
• It cannot find the same size standby redo log as the incoming online redo log file.
• All of the standby redo logs of the correct size have not yet been archived.

Number of Standby Redo Logs
The following clauses of the CREATE DATABASE

statement affect the number of redo logs that you can
create:
• MAXLOGFILES: Maximum number of groups of
standby redo logs and online redo logs per
database
• MAXLOGMEMBERS: Maximum number of members
per group
Number of Standby Redo Logs

The following clauses limit the number of standby redo log groups that you can add to a
database:
• The MAXLOGFILES clause of the CREATE DATABASE statement for the primary
database determines the maximum number of groups of standby redo logs and online redo
log groups per database. The sum of online log groups and standby redo log groups must be
equal to or less than MAXLOGFILES.
• The MAXLOGMEMBERS clause of the CREATE DATABASE statement that is used for the
primary database determines the maximum number of members per group.
The only way to override the limits that are specified by the MAXLOGFILES and
MAXLOGMEMBERS clauses is to re-create the primary database or the control file.
See Oracle Database SQL Reference and your operating system–specific Oracle documentation
for the default and allowed values of the MAXLOGFILES and MAXLOGMEMBERS clauses.

Using SQL to Add Standby Redo Logs
• Use the ALTER DATABASE statement to create the

standby redo log files:
SQL> ALTER DATABASE ADD STANDBY LOGFILE
2 ('/oracle/dbs/log1c.rdo',
3 '/oracle/dbs/log2c.rdo') SIZE 500K;
• Add members to a group with the following
statement:
SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER
2 '/oracle/dbs/log2b.rdo' TO GROUP 2;
• View information about the groups as follows:
SQL> SELECT * FROM V$LOGFILE
2 WHERE TYPE = 'STANDBY';
Using SQL to Add Standby Redo Logs

You can create standby redo logs by using the ADD STANDBY LOGFILE clause of the ALTER
DATABASE statement. Although standby redo logs are used only when the database is operating
in the standby role, you should create standby redo logs on the primary database so that
switching roles does not require additional DBA intervention.
To verify that standby redo logs have been created, query V$STANDBY_LOG or V$LOGFILE
with SELECT * FROM V$LOGFILE WHERE TYPE = 'STANDBY';.
The standby redo log status is shown as ACTIVE or UNASSIGNED.
The following is an example of output from V$STANDBY_LOG:
SQL> SELECT GROUP#,STATUS,FIRST_CHANGE#
2 FROM V$STANDBY_LOG;
GROUP# STATUS FIRST_CHANGE#
---------- ---------- -------------
3 ACTIVE 144545
4 UNASSIGNED 0
5 UNASSIGNED 0

Using Enterprise Manager
to Add Standby Redo Logs
Using Enterprise Manager to Add Standby Redo Logs

When you create a standby configuration with Enterprise Manager, it recommends a
configuration of standby redo logs. This recommendation includes creating the standby redo logs
on the primary database as well as on any standby databases in the configuration.
Configuring standby redo logs is covered in more detail in the lesson titled “Creating a
Configuration with Enterprise Manager.”

Standby Database Modes
You can maintain the standby data in one of the

following modes:
• For physical standby databases
– Redo Apply
– Open read-only mode
• For logical standby databases
– Open read/write mode
Standby Database Modes

You can use log apply services to maintain your physical standby database in one of the
following modes:
• Redo Apply: In this mode, log transport services archive the logs to the standby database,
and log apply services automatically apply these logs. The database is in the MOUNT state;
no reads of the data are possible.
• Open read-only mode: If you want to use the standby database for reporting purposes,
then open it in read-only mode in a Data Guard environment. Log apply services cannot
apply archived redo logs to the standby database when it is in this mode, but the primary
database continues to ship redo to the standby database.
You can easily change between managed recovery mode and read-only mode. In most
implementations of a Data Guard environment, you may want to make this transition at various
times so that you can do one of the following:
• Update a physical standby database that is used primarily for reporting
• Ensure that data is correctly applied to a physical standby database that is used primarily
for disaster protection

Standby Database Modes (continued)
• Open read/write mode: In this mode, log apply services continue to manage the
application of log information from archived redo logs. In addition, the database is open for
reporting.
The logs are being applied to the logical standby while users are allowed to perform queries on
the tables that are being updated by the log apply service. Users are not allowed to perform DML
on the tables in the schemas that the log apply service is updating. However, users can modify
database objects in other schemas that are not being maintained by the log apply service.

Summary
In this lesson, you should have learned how to

describe the following:
• Data Guard architecture processes
• Operational requirements of a Data Guard
environment
• How Data Guard processes, transports, and
applies redo logs
• Modes of standby databases and when to use
each mode

Practice 2-1: Overview
(Architecture)

• Reviewing the Oracle Data Guard architecture
• Reviewing the processes that Data Guard uses to
transport and apply redo logs
• Reviewing the modes that are used to recover a
primary database

(Installing the Oracle Management Agent)

• Installing the Oracle Management Agent
• Configuring monitoring credentials for your
database

(Configuring Your Primary Database)

• Reviewing your primary database configuration
• Configuring your primary database in preparation
for creating a Data Guard configuration

Data Guard Broker
and Enterprise Manager

Objectives

the following:
• Describe the Data Guard broker architecture
• Describe the Data Guard broker components
• Explain the benefits of the Data Guard broker
• Explain Data Guard broker configurations
• Use Enterprise Manager to manage your Data
Guard configuration
• Invoke DGMGRL to manage your Data Guard
configuration

Features of Data Guard Broker
• The Data Guard broker is a distributed

management framework.
• The broker automates and centralizes the creation,
maintenance, and monitoring of Data Guard
configurations.
• With the broker, you can perform all management
operations locally or remotely through easy-to-use
interfaces:
– Oracle Enterprise Manager 10g Grid Control
– A command-line interface: DGMGRL
Features of 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. The
following are some of the operations that the broker automates and simplifies:
• Automated creation of Data Guard configurations incorporating a primary database, a new
or existing (physical or logical) standby database, log transport services, and log apply
services
Note: Any of the databases might be RAC databases.
• Adding up to eight additional new or existing (physical or logical, RAC or non-RAC)
standby databases to each existing Data Guard configuration, for a total of one primary
database, and from one to nine standby databases in the same configuration
• Managing an entire Data Guard configuration (including all databases, log transport
services, and log apply services) through a client connection to any database in the
configuration
• Invoking switchover or failover with a single command to initiate and control complex role
changes across all databases in the configuration
• Monitoring the status of the entire configuration, capturing diagnostic information,
reporting statistics such as the log apply rate and the redo generation rate, and detecting
problems quickly with centralized monitoring, testing, and performance tools

Data Guard Broker: Components
• Client-side:
– Oracle Enterprise Manager 10g Grid Control
– DGMGRL (command-line interface)
• Server-side: Data Guard monitor
– DMON process
– Configuration files
Data Guard Broker: Components

The Oracle Data Guard broker consists of components that reside on the client and the server in
the configuration.
On the client, you can use the following Data Guard components to define and manage a
configuration:
• Oracle Enterprise Manager
• DGMGRL, which is the Data Guard command-line interface (CLI)
On the server, Data Guard monitor is a broker component that is integrated with the Oracle
database. Data Guard monitor comprises the Data Guard monitor process (DMON) and broker
configuration files, with which you can control the databases of that configuration, modify their
behavior at run time, monitor the overall health of the configuration, and provide notification of
other operational characteristics.
The configuration file contains profiles that describe the states and properties of the databases in
the configuration. Associated with each database are various properties that the DMON process
uses to control the database’s behavior. The properties are recorded in the configuration file as a
part of the database’s object profile that is stored there. Many database properties are used to
control database initialization parameters related to the Data Guard environment.

Data Guard Broker: Configurations
The most common configuration is a primary database

at one location and a standby database at another
location.
Chicago Boston
Oracle Net
Primary Standby
site site
Data Guard Broker: Configurations

A Data Guard configuration consists of one primary database and up to nine standby databases.
The databases in a Data Guard configuration are typically dispersed geographically and are
connected by Oracle Net.
A Data Guard broker configuration is a logical grouping of the primary and standby databases in
a Data Guard configuration. The broker’s DMON process configures and maintains the broker
configuration components as a unified group of resource objects that you can manage and
monitor as a single unit. When you enter a command through Enterprise Manager or the CLI, the
appropriate DMON process does the following:
• Carries out your request on its local database resource object and site object
• Updates the broker configuration file
• Communicates with the DMON process on the other site

Data Guard Broker: Management Model
Data Guard Broker Configuration
Standby database
Broker-controlled Standby database
databases Standby database
Standby database
Standby database
Standby database
Standby database
Primary database Standby database
Standby database
Instances
Instances
Data Guard Broker: Management Model

The Data Guard broker performs operations on logical objects:
• Configuration of databases
• A single database
A broker configuration consists of:
• A configuration object: A named collection of database profiles. A database profile is a
description of a database object, including its current state, current status, and properties.
• Database objects: Objects corresponding to primary or standby databases
• Instance objects: A database object may be comprised of one or more instance objects if it
is a RAC database.
The broker supports one or more Data Guard configurations, each of which includes a profile for
one primary database as well as profiles for up to nine physical, logical, RAC or non-RAC
standby databases.

Data Guard Broker: Architecture
Graphical user interface
or
command-line interface
Data Guard Configuration
Standby site 9
Standby site 2
Primary site Standby site 1
Configuration Configuration
files files Standby
Archived database
redo logs
Primary Log
database apply
Standby services
Online DMON DMON
redo logs
redo logs Archived
redo logs
Log Oracle
transport Net
services
Data Guard Broker: Architecture

The Data Guard broker helps you create, control, and monitor a Data Guard configuration. This
configuration consists of a primary database that is protected by one or more standby databases.
After the broker has created the Data Guard configuration, the broker monitors the activity,
health, and availability of all systems in the Data Guard configuration.
The Data Guard monitor process (DMON) is an Oracle background process that runs on every site
that is managed by the broker. When you start the Data Guard broker, a DMON process is created.
When you use Enterprise Manager or the Data Guard command-line interface (CLI), the DMON
process is the server-side component that interacts with the local instance and the DMON
processes that are running on other sites to perform the requested function. The DMON process is
also responsible for monitoring the health of the broker configuration and for ensuring that every
site has a consistent copy of the configuration files in which the DMON process stores its
configuration data. There are two multiplexed versions of the configuration file on each site.

Life Cycle of a Broker Configuration
Create
configuration
Enable
configuration
Make state or Update database

role changes properties
Monitor and tune

configuration
Life Cycle of a Broker Configuration

You can use the Add Standby Database Wizard in Enterprise Manager to add an existing standby
database to the configuration or create a new standby database and add it to the configuration.
The standby database can be either a physical or a logical database.
Note: If you are creating a new database, it must be a non-RAC database.
If you are using the CLI, the primary database and standby database must already exist. You
must construct the standby database from backups of the primary database control files and data
files, and then prepare it for recovery.
One way to think of this life cycle is in the context of creating and staging a play. In the “create
configuration” phase, you define the actors (resources) and the roles they play (primary or
standby), as well as where they should be on the stage (the site).
When you have made all your decisions and preparations, you go to opening night for the show’s
debut (“enable configuration”).
During the run of the show, changes may be required because the actor playing the main
character falls ill (“make state or role changes,” in which a standby becomes primary) or because
your show is in a new theater (“update database properties”). And as the director, you constantly
watch to make sure the play maintains your standards, so you make modifications as needed
(“monitor and tune configuration”).

Data Guard Broker: Requirements
• Enterprise Edition of Oracle Database 10g Release 1

• Single-instance or multi-instance environment
• COMPATIBLE must be set to 9.2.0 or higher for
primary and standby databases.
• Oracle Net network files must be configured for
databases that you add to the configuration.
• LOCAL_LISTENER on each instance must resolve to
an address that is reachable by all members.
• GLOBAL_DBNAME attribute must be set to a
concatenation of:
db_unique_name_DGMGRL.db_domain

To use the Data Guard broker, you must comply with the following requirements:
• You must use the Enterprise Edition of Oracle Database 10g Release 1.
• You can use a single-instance or multi-instance environment.
• You must set the COMPATIBLE initialization parameter to 9.2.0 or higher for the primary
and standby databases.
• Enterprise Manager automatically configures the Oracle Net network files when it creates a
standby database. If you configure an existing standby database in the broker configuration,
you must configure the network files. You must use TCP/IP protocol.
• The value of the LOCAL_LISTENER initialization parameter on each instance that is part
of your Data Guard broker configuration must resolve to a listener address that is reachable
by all members of the configuration.
• To enable the Data Guard broker CLI to restart instances during the course of broker
operations, a service with a specific name must be statically registered with the local
listener of each instance. The value of the GLOBAL_DBNAME attribute must be set to a
concatenation of db_unique_name_DGMGRL.db_domain.
Note: Oracle Enterprise Manager 10g can manage a 9.2 Data Guard configuration.

• DG_BROKER_START = TRUE
• The primary database must be in ARCHIVELOG
mode.
• All databases must be in MOUNT or OPEN mode.
• Configure DG_BROKER_CONFIG_FILEn for any
RAC databases.
• START_OPTIONS for any RAC databases must be
set to MOUNT in the Oracle Cluster Repository
(OCR).
Data Guard Broker: Requirements (continued)

• You must set the DG_BROKER_START initialization parameter to TRUE. This enables the
DMON process.
Note: Enterprise Manager sets this parameter automatically.
• The primary database must be in ARCHIVELOG mode.
• Any database that is managed by the broker (including, for a RAC database, all instances
of the database) must be mounted or open. The broker cannot start an instance.
• If any database in your configuration is a RAC database, you must configure the
DG_BROKER_CONFIG_FILEn initialization parameters for that database so that they
point to the same shared files for all instances of that database. You cannot use the default
values for these parameters.
Note: The shared files could be files on a cluster file system, if available, or on raw
devices.
• If any database in your configuration is a RAC database, the START_OPTIONS for that
database must be set to MOUNT in the Oracle Cluster Repository (OCR) using SRVCTL, as
follows:
SRVCTL ADD DATABASE -d <db_unique_name> -o <$ORACLE_HOME> -s MOUNT
or
SRVCTL MODIFY DATABASE -d <db_unique_name> -o <$ORACLE_HOME> -s MOUNT

Data Guard Broker and the SPFILE
• You must use a server parameter file (SPFILE) for

initialization parameters.
• Using the SPFILE enables the Data Guard broker
to keep its configuration file and the database
SPFILE consistent.
• If you use the broker, use Enterprise Manager or
DGMGRL to update database parameter values.
Data Guard Broker and the SPFILE

To ensure that the broker can update the values of parameters in both the database instance itself
and in the configuration file, you must use the persistent server initialization parameter file
(SPFILE) to control static and dynamic initialization parameters. Use of the SPFILE gives the
broker a mechanism that enables it to reconcile property values that you have selected when
using the broker with any related initialization parameter values that are recorded in the SPFILE.
Also, the SPFILE permits persistent Data Guard settings, so that Data Guard continues to work
even after the broker is disabled.
When you set definitions or values for database properties in the broker configuration, the broker
records the change in the configuration file and also propagates the changes to the related
initialization parameters in the SPFILE file in the Data Guard configuration.
When the configuration is enabled, the broker keeps the database property values in the Data
Guard configuration file consistent with the values of the database initialization parameters in
the SPFILE.
Even when the configuration is disabled, you can update database property values through the
broker. The broker retains the property settings (without validating the values) and updates the
database initialization parameters in the SPFILE and the in-memory settings the next time you
enable the broker configuration.

Data Guard Broker and the SPFILE (continued)
For dynamic initialization parameters, the broker keeps the value of the database parameter
consistent in the System Global Area (SGA) for the instance, in the Data Guard configuration
files, and in the SPFILE.
For static initialization parameters, the value in the SGA may differ from what is in the
configuration files and in the SPFILE. Typically, the broker reconciles the differences by
updating all parameter and property values the next time the database instance is stopped and
restarted.
Note: When using the broker (with Enterprise Manager or the CLI), do not attempt to manually
set the parameters the broker controls. If you set them manually, one of two things happens.
Either you render your configuration inoperable, or the broker simply resets the parameter to the
setting it has recorded at the next opportunity. If you want to change a parameter value, you must
change it by using one of the broker interfaces.

Data Guard Monitor: DMON Process
• Server-side background process

• Part of each database instance in the
configuration
• Created when you start the broker
• Performs requested functions and monitors the
resource
• Communicates with other DMON processes in the
configuration
• Updates the configuration file
Data Guard Monitor: DMON Process

The Data Guard monitor comprises two components: the DMON process and the configuration
file.
The Data Guard Monitor process (DMON) is an Oracle background process that is part of each
database instance managed by the broker. When you start the Data Guard broker, a portion of the
SGA is allocated and a DMON process is created. The amount of memory allocated is typically
less then 50 KB per site; the actual amount on your system varies.
When you use Enterprise Manager or the CLI, the DMON process is the server-side component
that interacts with the local instance and the DMON processes running on other sites to perform
the requested function.
The DMON process is also responsible for monitoring the health of the broker configuration and
for ensuring that every database has a consistent copy of the broker configuration files in which
the DMON process stores its configuration data.

Data Guard Monitor: Configuration File
• Automatically created and named using a default

path name and file name when the broker is
started
• Override default path name and file name by
setting DG_BROKER_CONFIG_FILEn
• Two files at each managed site
• Managed automatically by the DMON process
• Default names are operating system–specific:
– Default names for Unix and Linux: dr1<SID>.dat
and dr2<SID>.dat
– Default location for Unix and Linux:
ORACLE_HOME/dbs
– Default location for Windows:
ORACLE_HOME\database
Data Guard Monitor: Configuration File

The DMON process maintains persistent configuration data about all databases in the broker
configuration in a broker configuration file. Every database that is part of the Data Guard broker
configuration has two broker configuration files that are maintained and synchronized for each
database in the broker configuration. One of the files is in use and the other acts as a backup. The
configuration files are binary files and cannot be edited.
When the broker is started for the first time, the configuration files are created and named
automatically by using a default name that is specific to the operating system. You can override
this default name by setting the DG_BROKER_CONFIG_FILEn initialization parameters. You
can also change the configuration file names dynamically by issuing the ALTER SYSTEM SQL
statement.
The configuration files contain entries that describe the state and properties of the databases in
the configuration. For example, the files record the databases that are part of the configuration,
the roles and properties of each of the databases, and the state of each of the databases in the
configuration. Two files are maintained so that there is always a record of the last known valid
state of the configuration. The broker uses the data in the configuration file to configure and start
the databases, control each database’s behavior, and provide information to the CLI and
Enterprise Manager.

Benefits of Using the Data Guard Broker
• Enhances the high-availability, data-protection,

and disaster-protection capabilities inherent in
Oracle Data Guard by automating both
configuration and monitoring tasks
• Streamlines the process for any one of the
standby databases to replace the primary
database and take over production processing
• Helps you to logically define and create a Data
Guard configuration consisting of a primary
database and a standby database
• Enables easy configuration of additional standby
databases

By automating the tasks required to configure and monitor a Data Guard configuration, the
broker enhances the high-availability, data-protection, and disaster-protection capabilities that
are inherent in Oracle Data Guard.
If the primary database fails, the broker streamlines the process for any one of the standby
databases to replace the primary database and take over production processing.
The broker helps you to logically define and create a Data Guard configuration consisting of a
primary database and a (physical or logical, RAC or non-RAC) standby database.
The broker enables easy configuration of additional standby databases. After you create a Data
Guard configuration consisting of a primary and standby database, you can add up to eight
standby databases (new or existing, physical or logical) to each Data Guard configuration.

• Provides simplified, centralized, and extended

management
• Automates switchover and failover to a specified
standby database in the broker configuration
• Automatically communicates between the
databases in a Data Guard configuration using
Oracle Net Services
• Provides built-in validation that monitors the
health of all of the databases in the configuration
Benefits of Using the Data Guard Broker (continued)

The broker provides simplified, centralized, and extended management.
The broker automates switchover and failover to a specified standby database in the broker
configuration.
The broker automatically communicates between the databases in a Data Guard configuration
using Oracle Net Services. The database can be local or remote, connected by a LAN or
geographically dispersed over a WAN.
The broker provides built-in validation that monitors the health of all of the databases in the
configuration.

Data Guard Broker Interfaces
• Oracle Enterprise Manager 10g Grid Control:

– Contains wizards to simplify creating and managing
standby databases
• Command-line interface (CLI):
– Started by entering DGMGRL at the command prompt
where the Oracle server is installed
– Enables you to control and monitor a Data Guard
configuration from the CLI prompt or in scripts
Data Guard Broker Interfaces

Oracle Enterprise Manager automates and simplifies the management of a Data Guard
configuration.
Oracle Enterprise Manager 10g Grid Control includes the following Data Guard features:
• Wizard-driven creation of standby databases
• Wizard-driven creation of a broker configuration based on an existing primary and standby
database
• Complete monitoring and proactive event reporting through e-mail or pagers
• Simplified control of the databases through their potential states. For example, with
Enterprise Manager you can take a database offline, put it online, start or stop the log
transport services, start or stop the log apply services, place a standby database in read-only
mode, and so on.
• “Pushbutton” switchover and failover: Grid Control enables you to execute a switchover or
failover between a primary and a standby database by simply clicking a button.

Data Guard Broker Interfaces (continued)
The DGMGRL command-line interface (CLI) includes:
• Configuration and setup tasks
• Management and control of the configuration
• Commands to check the status and health of the configuration
• Commands to execute role changes
For additional information about using these interfaces, see Oracle Data Guard Broker.

Using Oracle Enterprise Manager 10g
Grid Control
Click Data Guard to access

the Data Guard pages.
Using Oracle Enterprise Manager 10g Grid Control

Access the Data Guard features in Grid Control by performing the following steps:
1. Click the Targets tab to go to the Targets page.
2. Click Databases to go to the Databases page.
3. On the Databases page, you can see a listing of all discovered databases, including the
primary database. Click the primary database to go to the primary database home page.
4. Click Administration.
5. Click Data Guard in the High Availability section.

Data Guard Overview Page
Data Guard Overview Page

On the Data Guard Overview page, you can:
• View the protection mode and access the page to edit the protection mode
• View a summary showing the amount of data that the standby has not received
• View information about the primary database
• View or access pages to change information for the standby databases:
- Add a standby database to the broker configuration
- Change the state or properties
- Discontinue Data Guard broker control
- Switch the role from standby to primary
- Transition the standby database to the role of primary database
• Access pages to view performance information for the configuration and status of online
redo log files for each standby database
• Perform a verification process on the Data Guard configuration
You can click Help to access information about using each page.

Enterprise Manager Metrics and Alerts
• Metrics: Units of measurement used to assess the

health of your system
• Thresholds: Boundary values against which
monitored metric values are compared
• Alert: Generated when a threshold is reached
Enterprise Manager Metrics and Alerts

Metrics are units of measurement that are used to assess the health of your system. Each target
comes with a predefined set of metrics. Metrics have thresholds associated with them.
Thresholds are boundary values against which monitored metric values are compared. Some of
the thresholds are predefined by Oracle; others are not.
When a threshold is reached, an alert is generated. An alert is an indicator signifying that a
particular condition has been encountered. An alert is triggered when one of the following
conditions is true:
• A threshold is reached.
• An alert has been cleared.
• The availability of a monitored service changes.
• A specific condition occurs. For example, an alert is triggered whenever an error message
is written to a database alert log file.
Alerts are detected through a polling-based mechanism by checking for the monitored condition
from a separate process at regular, predefined intervals.
You can associate an alert with a notification, the automatic execution of a job, and so on.

Using Data Guard Metrics
Enterprise Manager includes the following Data Guard

metrics:
• Data Guard Status
• Data Not Applied (MB)
• Data Not Applied (log
files)
• Data Not Received (MB)
• Data Not Received (log
files)
Using Data Guard Metrics

You can use Enterprise Manager to monitor the status and log file activity. In addition,
Enterprise Manager automatically monitors the status and archived redo log file activity on the
primary and standby databases and provides the following metrics:
• Data Guard Status: Status of each database in the broker configuration
• Data Not Applied (MB): Difference (in megabytes) between the last log file received and
the last log file applied on each standby database
• Data Not Applied (log files): Difference (in number of archived redo log files) between
the last log file received and the last log file applied on each standby database
• Data Not Received (MB): Difference (in megabytes) between the current log file on the
primary database and the last log file received on each standby database
• Data Not Received (log files): Difference (in number of archived redo log files) between
the current log file on the primary database and the last log file received on each standby
database
You can set up Email Services to notify you with an e-mail message if any of the metrics are
triggered.
Note: These metrics are seen on the primary database only.

Managing Data Guard Metrics
1. Configure notification methods.

2. View the All Metrics page.
3. Set or change Data Guard metric thresholds.
4. View triggered metrics.
Managing Data Guard Metrics

You can specify that an e-mail notification be sent to you when a Data Guard metric is triggered.
Use the following procedure to configure the notification:
1. Configure notification methods in Enterprise Manager.
a. Click Setup at the top of the Database Home page.
b. Click Notification Methods on the Setup page.
c. Enter the appropriate information in the Mail Server section and click Apply. You
can click Test Mail Servers to verify your configuration.
2. View the All Metrics page by clicking All Metrics in the Related Links section on the
Database Home page. Then view all of the Oracle Enterprise Manager metrics, including
the metrics for Data Guard.
3. Set or change Data Guard metric thresholds by clicking Manage Metrics in the Related
Links section on the All Metrics page to access the Manage Metrics page. You can set and
change the five Data Guard metrics from the Manage Metrics page.
4. View triggered metrics: If a metric condition is triggered or a threshold value is exceeded,
an alert is issued. Click Data Guard on the All Metrics page to view triggered metrics. You
can click the metric and then click a particular database to see details.

Benefits of Using Enterprise Manager
• Enables you to manage your configuration using a

familiar interface and event-management system
• Automates and simplifies the complex operations
of creating and managing standby databases
through the use of wizards
• Performs all Oracle Net Services configuration
changes that are necessary to support log
transport services and log apply services
• Provides a verify operation to ensure that log
transport services and log apply services are
configured and functioning properly
• Enables you to select a new primary database
from a set of viable standby databases
Benefits of Using Enterprise Manager

Managing your Data Guard configuration with Oracle Enterprise Manager 10g Grid Control
provides the following benefits:
• Enables you to manage your configuration using the familiar Enterprise Manager interface
and event-management system
• Provides a wizard that automates the complex tasks involved in creating a broker
configuration
• Provides the Add Standby Database Wizard to guide you through the process of adding
more databases
• Performs all Oracle Net Services configuration changes that are necessary to support log
transport services and log apply services across the configuration
• Provides a verify operation to ensure that log transport services and log apply services are
configured and functioning properly
• Enables you to select a new primary database from a set of viable standby databases when
you need to initiate a role change for a switchover or failover operation

Using the Command-Line Interface
of the Data Guard Broker
DGMGRL> connect sys/oracle
Connected.
DGMGRL> show configuration verbose
Configuration
Name: ORCL_EDRSR9P1.oracle.com
Enabled: YES
Protection Mode: MaxPerformance
Databases:
ORCL_EDRSR9P1 - Primary database
site1_edrsr9p1 - Physical standby database
site2_edrsr9p1 - Logical standby database
Current status for "ORCL_EDRSR9P1.oracle.com":

SUCCESS
DGMGRL Commands
The following commands are available in DGMGRL (the Data Guard CLI). Many of these
commands have additional arguments that are not described here. This is simply an overview
listing.
• ADD: Adds a standby database to the broker configuration
• CONNECT: Connects a given username to the specified instance
• CREATE: Enables you to create broker configurations
• DISABLE: Enables you to disable broker control of a configuration or database so that the
object is no longer managed by the broker
• EDIT: Used to edit a configuration, database, or instance
• ENABLE: Enables you to enable broker control of a configuration or database
• EXIT/QUIT: Exits the Data Guard CLI (DGMGRL)
• FAILOVER: Performs a database failover operation in which one of the standby databases
changes to the role of primary database. This is an unplanned transition that may result in
the loss of application data.
• HELP: Displays online help for the commands in DGMGRL
• REMOVE: Removes a broker configuration, including all of its database profiles, a specified
standby database profile, or knowledge of an instance

DGMGRL Commands (continued)
• SHOW: Displays either a brief or a detailed summary of information about the broker
configuration, database, or instance. Also can display the dependency tree and default
online states for the broker configuration, as well as the configuration log or the Oracle
database alert log.
• SHUTDOWN: Shuts down a currently running Oracle database instance
• STARTUP: Starts an Oracle instance with several options, including mounting and opening
a database
• SWITCHOVER: Performs a switchover operation in which the current primary database
becomes a standby database and the standby database to which the CLI is currently
connected becomes the primary database
Note: The ALTER command has been deprecated in Oracle Database 10g. The new EDIT
command provides comparable functionality.

Summary

• Describe the Data Guard broker management
model
• Describe the Data Guard broker architecture
• Describe Data Guard broker components
• Access Enterprise Manager
• Invoke DGMGRL (the Data Guard CLI)

Creating a Configuration
with Enterprise Manager

Objectives

the following:
• Enable FORCE LOGGING
• Use Enterprise Manager to create a broker
configuration
• Use Enterprise Manager to monitor the broker
configuration

Enabling FORCE LOGGING Mode
• Forced logging is recommended to ensure data

consistency.
• FORCE LOGGING forces redo to be generated even
when NOLOGGING operations are executed.
• Temporary tablespaces and temporary segments
are not logged.
• FORCE LOGGING is recommended for both
physical and logical standby databases.
• Issue the following command on the primary
database:
SQL> ALTER DATABASE FORCE LOGGING;
Enabling FORCE LOGGING Mode

FORCE LOGGING mode determines whether or not the Oracle database server logs all
changes in the database, except for changes to temporary tablespaces and temporary
segments. The [NO]FORCE LOGGING clause of the ALTER DATABASE command
contains the following settings:
• FORCE LOGGING: This setting takes precedence over (and is independent of) any
NOLOGGING or FORCE LOGGING settings that you specify for individual tablespaces
and any NOLOGGING setting that you specify for individual database objects. All
ongoing, unlogged operations must finish before forced logging can begin.
• NOFORCE LOGGING: Places the database in NOFORCE LOGGING mode. This is the
default.
The FORCE_LOGGING column in V$DATABASE contains a value of YES if the database is
in FORCE LOGGING mode.

Enabling FORCE LOGGING Mode (continued)
Although the database can be placed in FORCE LOGGING mode when the database is
OPEN, the mode does not change until any operation that is currently running in
NOLOGGING mode has completed. Therefore, it is recommended that you enable FORCE
LOGGING mode when the database is in the MOUNT state.
Note: You should enable FORCE LOGGING before performing the backup operation to
create the standby database, and then maintain FORCE LOGGING mode for as long as the
standby database is active.

Using Enterprise Manager
to Create a Broker Configuration
• Use the Add Standby Database Wizard to:

– Create a broker configuration
– Add a database to a broker configuration
• Primary database must be started with an SPFILE.
Using Enterprise Manager to Create a Broker Configuration

Enterprise Manager automates the process of creating a standby database. The Add Standby
Database Wizard is used to create a new broker configuration and to add databases to an
existing configuration.
Before you invoke the Add Standby Database Wizard, verify that the primary database
instance was started with a server parameter file (SPFILE). If the instance was not started
with an SPFILE, the wizard notifies you.

Click “Add Standby Database”

to start the wizard.
You can access the Data Guard features in Enterprise Manager by clicking Data Guard in
the High Availability section of the Administration page.
If your primary database is not already in a broker configuration, an information page
appears with this indication. Click the Add Standby Database link to invoke the Add
Standby Database Wizard.
Using the Add Standby Database Wizard, you perform the following steps:
1. Specify the backup type to use for the standby database creation.
2. Specify the backup options.
3. Select the Oracle home in which to create the standby database.
4. Specify the location for standby database files.
5. Specify standby database configuration parameters.
6. Review the configuration information.

Creating a Configuration (continued)
During the standby creation process, the following operations are performed:
• The control file, data files, and archived redo log files are backed up to a temporary
location on the primary host.
• The backup pieces from the primary host are transferred to a temporary location on the
standby host.
• Additional required files, such as initialization parameter and password, are created on
the standby host.
• The control file, data files, and archived redo log files are restored to the specified
locations on the standby host.
• Online log files and other files are added to the standby database as needed.
• The recovered database is changed into a physical or logical standby.

Using the Add Standby Database Wizard

The Add Standby Database Wizard begins by asking you to select the type of standby
database that you want to create. You can create a new physical or logical standby database.
Or you can add an existing database, including a RAC database, to the configuration to serve
as a standby database.
Note: You must be connected to the primary database with SYSDBA credentials to invoke
the Add Standby Database Wizard.
If you choose to create a new standby database, the following conditions are verified when
you click Continue:
• All databases in the configuration are using a server parameter file (SPFILE).
• The primary database is in ARCHIVELOG mode.
• The COMPATIBLE initialization parameter for the primary database has a setting
of 9.0 or higher.
If any of these conditions are not met, the wizard returns a message indicating that you must
cancel the wizard and perform the appropriate action to meet the condition.
In addition, the wizard verifies that the primary database is in FORCE LOGGING mode. If it
is not in FORCE LOGGING mode, a warning message appears. You can then cancel the
configuration and enable FORCE LOGGING (as described earlier in this lesson).

Step 1: Specify the Backup Type
Step 1: Specify the Backup Type

You can use the Backup Type page of the wizard to select the type of backup for creation of
the standby database:
• “Perform a live backup of the primary database”: Creates a new backup using the
Recovery Manager utility (RMAN)
• “Use an existing backup of the primary database”: Uses an existing backup of the
primary database that was created by Data Guard during previous creation of a standby
database

Step 2: Specify the Backup Options
Step 2: Specify the Backup Options

If you selected the “Perform a live backup of the primary database” option on the Backup
Type page, you can specify a location on the primary database host to store the backup files.
A default location is specified in the Working Directory Location field, or you can provide
your own location. A unique subdirectory to store the backup files is created in the directory
that you specify.
If you intend to create additional standby databases, you can save the backup by selecting
the “Retain working directory for a future standby creation” option. Otherwise, you should
select the “Delete working directory after standby creation” option.
Note: If you choose to retain the backup, additional space is required (as indicated on the
Backup Options page).
If you selected the “Use an existing backup of the primary database” option on the Backup
Type page, specify the location of the backup in the Working Directory Location field.
Note: This backup must have been taken by Data Guard during a previous standby database
creation and must be of the same type that you are creating.
Specify the operating system credentials of the user who owns the primary database Oracle
server installation in the Primary Host Credentials section.
Note: The credentials are preset to the host preferred credentials that are stored with the
primary database preferred credentials by default.

Step 3: Select the Oracle Home – Instance
Name
Step 3: Select the Oracle Home – Instance Name

Specify the instance name for your new standby database in the Standby Instance Name
field, or use the default instance name that is provided. The instance name must conform to
Oracle naming guidelines.
Note: For a physical standby, the database name is the same as the primary. This is because
a physical standby is an exact, block-by-block copy of the primary. You can make the
instance name the same as the primary. However, you must make the instance name
different from the primary if the standby is on the same machine as the primary.
In the Standby Host Credentials section, specify the operating system credentials of the user
who owns the Oracle installation in the selected Oracle home on the standby host.

Step 3: Select the Oracle Home –
Oracle Home
Step 3: Select the Oracle Home – Oracle Home

The Standby Database Oracle Home section lists all of the available Oracle homes that
match the primary database version and host operating system. From this list, select the host
and Oracle home for your new standby database.

Step 4: Specify the Standby Database
File Locations – Access Method
Step 4: Specify the Standby Database File Locations – Access Method

The Backup File Access section appears only when you are creating a standby database on a
host other than the primary database. You must select a method to be used to make the
primary backup files accessible to the standby host.
• Transfer files: If you choose to transfer files from the primary host working directory
to a standby host directory, you must specify a temporary location on the standby host
to store the backup files copied from the primary host. In addition, you must select the
file transfer method: FTP or HTTP server. FTP is the faster of the two file transfer
methods. Select the HTTP Server option if you know that the primary and/or standby
host does not support FTP.
• Directly access the files: If you select this method, you must supply the network path
name for the standby host. This method is appropriate when the primary host working
directory location is directly accessible from the standby host via NFS, a network
share, or some other network method. This option saves time and disk space because
there is no file transfer to the standby host and because no temporary location is
needed.

Step 4: Specify the Standby Database
File Locations – File Locations
Step 4: Specify the Standby Database File Locations – File Locations

By default, all standby database files are placed in an Oracle Optimal Flexible Architecture
(OFA) directory structure when your primary and standby databases are on the same host.
When your primary and standby databases are on different hosts, you can specify that you
want to convert the standby files to an OFA structure or keep the file names and locations
the same as the primary database. You can optionally change the locations of individual
standby database files by clicking the Customize button to display the File Locations
Customize page of the wizard.
Data Guard automatically adds configuration information for the new standby database to
the listener.ora and tnsnames.ora files in the directory that is specified in the
Configuration File Location field in the Network Configuration File Location section. The
default location is the network administration directory of the Oracle home for the standby
database Oracle home. The default location is correct for most configurations. You can
specify a different directory if you want the new standby database to be serviced by a
listener running in a different Oracle home on the standby host.

Step 5: Specify Standby Database
Configuration Parameters
Step 5: Specify Standby Database Configuration Parameters

On the Standby Configuration page of the wizard, you can specify configuration parameters
for the standby database. The parameters that must be specified depend on whether you are
adding an existing standby database, creating a new physical standby database, or creating a
new logical standby database. The configuration parameters include the instance name,
service provider name, target name, and standby archive location. The default values are
based on corresponding primary database settings.
When you create a new physical database, the following parameters must be configured:
• Database Unique Name: Specify a value for the database DB_UNIQUE_NAME
parameter. This name must be unique within the Data Guard configuration.
Note: This field appears only if you are creating a new physical standby database and
the primary database is an Oracle10g database.
• Target Name: Specify a name for Enterprise Manager to use for the new standby
database. This name will appear in the list of database targets maintained by Enterprise
Manager. This name should be the same as the database unique name.

Step 6: Review the
Configuration Information
Step 6: Review the Configuration Information

The Review page of the wizard displays a summary of your selections and lists the
parameters to be used to create the new standby database.
The new standby database is created in the background by an Oracle Enterprise Manager
job. The name of the job that is submitted is provided at the top of the page.
When you click Finish, the Processing page appears. This page tracks each step through the
submission of the standby creation job. After the job submission is complete, the Data Guard
Overview page appears, where you can monitor the progress of the standby creation job.

Standby Database Creation: Processing
Standby Database Creation: Processing

You can view the progress of the Add Standby Database process on the Processing page. On
completion of the process, Oracle Enterprise Manager displays the Data Guard Overview
page.
The display on the Processing page differs based on whether you are adding an existing
standby database or creating a new standby database. An arrow icon indicates what step is
processing. When it completes, a check icon appears next to the step.
The following steps appear on the Processing page:
• Creating Data Guard Configuration or Updating Data Guard Configuration: The
Data Guard configuration is created during this step if it does not exist. If you are
adding an existing standby database, it is added to the configuration.
• Preparing standby creation job: This step appears only if you are creating a new
standby database. The standby database is actually created by an Enterprise Manager
job; preliminary setup steps to prepare for job submission are accomplished in this
step. You can cancel the Add Standby Database process at any point up to the
completion of this step.

Standby Database Creation: Processing (continued)
• Submitting standby creation job: This step appears only if you are creating a new
standby database. The Enterprise Manager job that creates the standby database in the
background is submitted in this step. The Add Standby Database process cannot be
canceled once this step begins.
• Adding standby database target: In this step, the standby database target in
Enterprise Manager is updated with additional information denoting membership in the
Data Guard configuration. This enables enhanced summary information to be
displayed on the Enterprise Manager home page of the standby database.

Standby Database Creation: Progress
Click “Creation in progress”

to view the job.
Standby Database Creation Progress

After the job is submitted, you return to the Data Guard Overview page. The Status column
indicates that the standby database creation is in progress. Click the “Creation in progress”
link to access the job page and monitor the progress of the creation of the standby database.

Standby Database Creation: Job Details
Standby Database Creation: Job Details

You can monitor creation of the standby database by viewing the details on the job progress
page.

Verifying a Configuration
Verifying a Configuration
After you create your configuration, you should use the Data Guard Verify operation to
check the configuration. You can invoke the Verify operation by clicking Verify in the
Additional Administration section of the Data Guard page. When you invoke the Verify
operation, a series of validation checks is performed on the Data Guard configuration,
including a health check of each database and each agent.
The Verify operation does the following:
• Determines the current data protection mode settings, including the current log
transport mode settings for each database and whether or not the standby redo logs are
configured properly. If standby redo logs are needed for any database, a message
indicates this on the Detailed Results page. You can then add the standby redo logs.
• Validates each database for the current status
• Performs a log switch on the primary database (for non-RAC databases) and verifies
that the log was applied on each standby database
• Checks the agent status for each database. The verify process executes a SQL*Plus job
on the agent if credentials are available. If credentials are not available to run the job,
the agent is pinged instead. If any errors occur during this process, a message appears
on the Detailed Results page.
• Displays the results of the Verify operation, including any errors
Note: You can cancel the Verify operation at any time by clicking Cancel.
Reviewing Results
of the Verify Operation
Reviewing Results of the Verify Operation

You can view the results of the Verify operation on the Detailed Results page. If any errors
occur during the operation, detailed information appears on this page.

Creating Standby Redo Logs
Creating Standby Redo Logs

If standby redo log files are needed for any of the databases, a message appears. You can
click OK to create the standby redo logs.
As discussed in the lesson titled “Understanding the Oracle Data Guard Architecture,”
standby redo logs should be configured on all databases in a configuration, including the
primary database.

Viewing the Data Guard
Configuration Status
Viewing the Data Guard Configuration Status

On the Data Guard page, you can view the status of the primary database and the standby
databases in a configuration.

Viewing Data Guard Performance
Viewing Data Guard Performance

You can click Performance Overview in the Performance section of the Data Guard
Overview page to access the Performance Overview page.
The Performance Overview page displays detailed performance-related statistics for the
Data Guard configuration. The performance charts provide a graphical summary of all redo
log activity in the configuration. You can set the collection interval (which causes the charts
to be refreshed) to determine the rate of sampling of the primary database in the View Data
field.
The Performance Overview page displays performance information for all of the databases
in the configuration as follows:
• Data Archived: Shows the amount of redo data (in megabytes) that has been archived
on the primary database. Each point on the chart represents the amount of redo data
that has been archived since the last time it was refreshed.
• Standby Progress Summary: Shows the approximate amount of potential data loss
• Data Applied: Displays the data applied (in megabytes) on each standby database in
the configuration. Each point on the chart represents the amount of redo data that has
been applied since the last time it was refreshed.

Viewing Data Guard Performance (continued)
• Log Services Summary: Shows the progress of the log services. The Completed
column for the primary database indicates the percentage of the current online redo log
that is filled. The Status column for the standby database typically displays “waiting
for log” or “applying log.”
Note: Data is not collected for any offline or disabled databases.

Summary

• Use Enterprise Manager to create a configuration
• Use Enterprise Manager to monitor the
configuration


• Logging in to Oracle Enterprise Manager 10g
Grid Control
• Using the wizard to create a Data Guard broker
configuration with a physical standby database
• Verifying the configuration

Creating a Physical Standby Database
by Using SQL

Objectives
After completing this lesson, you should be able

to use SQL commands to create a physical standby
database.

Steps to Create
a Physical Standby Database
1. Prepare the primary database.

2. Back up the primary database.
3. Copy files to the standby system.
4. Set parameters on the physical standby database.
5. Start the standby database.
6. Configure Oracle Net Services.
7. Set parameters on the primary database.
8. Start the transport of redo.
Steps to Create a Physical Standby Database

Perform the following steps to create a physical standby database by using SQL commands:
1. Prepare the primary database.
2. Back up the primary database.
3. Copy files to the standby system.
4. Set parameters on the physical standby database.
5. Start the standby database.
6. Configure Oracle Net Services.
7. Set parameters on the primary database.
8. Start the transport of redo.

Preparing the Primary Database
• Enable FORCE LOGGING at the database level.

SQL> ALTER DATABASE FORCE LOGGING;
• Create a password file.

• Set initialization parameters.
• Enable archiving.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
Preparing the Primary Database

FORCE LOGGING mode determines whether or not the Oracle database server logs all
changes in the database, except for changes to temporary tablespaces and temporary
segments. The FORCE_LOGGING column in V$DATABASE contains a value of YES if the
database is in FORCE LOGGING mode.
Every database in a Data Guard configuration must use a password file, and the password
for the SYS user must be identical on every system for redo data transmission to succeed.
For details about creating a password file, see Oracle Database Administrator’s Guide.
On the primary database, you define initialization parameters that control log transport
services while the database is in the primary role. There are additional parameters that you
need to add that control the receipt of the redo data and log apply services when the primary
database is transitioned to the standby role.
If archiving is not enabled, issue the ALTER DATABASE ARCHIVELOG command to put
the primary database in ARCHIVELOG mode and enable automatic archiving. See Oracle
Database Administrator’s Guide for additional information about archiving.
Note: It is no longer necessary to set the LOG_ARCHIVE_START initialization parameter
to start automatic archiving.

Initialization Parameters
on the Primary Database
DB_NAME=chicago
DB_UNIQUE_NAME=chicago
SERVICE_NAMES=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl',
'/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
Setting Initialization Parameters on the Primary Database

On the primary database, you define initialization parameters that control log transport
services while the database is in the primary role. In the example in the slide, assume that
the primary database is named chicago and the standby is named boston. For each,
there is an Oracle Net Services name defined.
There are additional parameters you need to add that control the receipt of the redo data and
log apply services when the primary database is transitioned to the standby role:
FAL_SERVER=boston
FAL_CLIENT=chicago
DB_FILE_NAME_CONVERT=
'/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/'
LOG_FILE_NAME_CONVERT=
'/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/'
STANDBY_FILE_MANAGEMENT=AUTO
Specifying these initialization parameters configures the primary database to resolve gaps,
converts new data file and log file path names from a new primary database, and archives
the incoming redo data when this database is in the standby role.

LOG_ARCHIVE_CONFIG
• Specify the DG_CONFIG attribute to list the

DB_UNIQUE_NAME for the primary database and
each standby database in the Data Guard
configuration.
• The LOG_ARCHIVE_CONFIG parameter also allows
the following values:
– SEND: Enables a database to send redo data to
remote destinations
– RECEIVE: Enables the standby database to receive
redo from another database
– Use the NOSEND and NORECEIVE keywords to
disable these settings.
LOG_ARCHIVE_CONFIG
Specify the DG_CONFIG attribute on the LOG_ARCHIVE_CONFIG parameter to list the
DB_UNIQUE_NAME of the primary and standby databases in the Data Guard configuration.
This setting enables the dynamic addition of a standby database to a Data Guard
configuration that has a Real Application Clusters primary database running in either
maximum protection or maximum availability mode. By default, the
LOG_ARCHIVE_CONFIG parameter enables the database to send and receive redo. After a
role transition, you may need to specify these settings again using the SEND, NOSEND,
RECEIVE, or NORECEIVE keywords.
Use the V$DATAGUARD_CONFIG view to see the current setting.
Note: The LOG_ARCHIVE_CONFIG initialization parameter replaces the
REMOTE_ARCHIVE_ENABLE initialization parameter, which will be deprecated in a future
release. Do not specify both parameters in the same SPFILE or text initialization parameter
file.

LOG_ARCHIVE_DEST_n
• Specify at least two LOG_ARCHIVE_DEST_n

parameters.
• Must contain (at a minimum) one of the
following:
– LOCATION
– SERVICE
• LOG_ARCHIVE_DEST_STATE_n parameter for
each defined destination
LOG_ARCHIVE_DEST_2=
'SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
LOG_ARCHIVE_DEST_n
By using the various LOG_ARCHIVE_DEST_n attributes, you define most of the settings
for the Data Guard configuration. The transport service is directly controlled by these
settings. There are 35 different attributes that can be set for each LOG_ARCHIVE_DEST_n
parameter. Most have defaults that are adequate for most configurations. See Oracle Data
Guard Concepts and Administration for a compete list and description of each.
You should specify at least two LOG_ARCHIVE_DEST_n parameters (where n is an
integer from 1 to 10): one parameter for the required local archiving destination and another
parameter for a standby location. Query the V$ARCHIVE_DEST view to see current
settings of the LOG_ARCHIVE_DEST_n initialization parameter.
All LOG_ARCHIVE_DEST_n parameters must contain, at a minimum, either a LOCATION
or SERVICE attribute. In addition, you must have a LOG_ARCHIVE_DEST_STATE_n
parameter for each defined destination.

LOCATION and SERVICE Attributes
Each archive log destination includes one of the

following attributes:
• LOCATION: Specifies a valid path name
• SERVICE: Specifies a valid Oracle Net Services
name referencing:
– A standby database
– An archive log repository
– A cross-instance archival database
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
LOCATION and SERVICE Attributes

Each LOG_ARCHIVE_DEST_n destination must specify either the LOCATION attribute
or the SERVICE attribute to identify either a local disk directory or a remote database
destination where log transport services can transmit redo data.
LOCATION: Each destination that specifies the LOCATION attribute must identify a unique
directory path name. This is the local destination for archived redo logs.
SERVICE: Specifies a valid Oracle Net Services name. This service may be one of the
following:
• A standby database (either physical logical)
• An archive log repository, allowing for off-site archiving of redo logs. An archive log
repository is created by using a standby control file, starting the instance, and
mounting the database. This destination contains no data files.
Note: The Data Guard broker does not support this type of service.
• A cross-instance archival database environment is possible on both the primary and
standby databases. In a RAC environment, each instance directs its archived redo logs
to a single instance of the cluster. The recovery instance typically has a tape drive
available for RMAN backup and restore support.
Note: The Data Guard broker does not support this type of service.
Note: There are no defaults for these attributes.

LOG_ARCHIVE_DEST_STATE_n
• Defines the current state of an archive log

destination:
– ENABLE (default)
– DEFER
– RESET
– ALTERNATE
• Applies to the primary and standby database
log_archive_dest _3='SERVICE=stby1_path1 NOREOPEN
ALTERNATE=LOG_ARCHIVE_DEST_4'
log_archive_dest _4='SERVICE=stby1_path2 NOREOPEN'
log_archive_dest_state_3=ENABLE
log_archive_dest_state_4=ALTERNATE
LOG_ARCHIVE_DEST_STATE_n
The LOG_ARCHIVE_DEST_STATE_n initialization parameter (where n is an integer from
1 to 10) specifies the state of the corresponding destination that is indicated by the
LOG_ARCHIVE_DEST_n initialization parameter (where n is the same integer). For
example, the LOG_ARCHIVE_DEST_STATE_2 parameter specifies the state of the
LOG_ARCHIVE_DEST_2 destination. The following are the valid values:
• ENABLE: Specifies that a valid log archive destination can be used for a subsequent
archiving operation (automatic or manual). This is the default.
• DEFER: Specifies that valid destination information and attributes are preserved but
that the destination is excluded from archiving operations until reenabled
• RESET: Functions similarly to DEFER but clears any error messages for the
destination if it had previously failed
• ALTERNATE: Specifies that the destination is not enabled but becomes enabled if
communication with another destination fails
In the example on the slide, destination 4 is an alternate for destination 3. Notice that
destination 3 has a state of ENABLE and 4 has a state of ALTERNATE. This has the effect of
making destination 4 wait for 3 to fail. In that case, the state of destination 4 becomes
ENABLE and the state of destination 3 becomes DEFER.

Specifying Values for
DB_FILE_NAME_CONVERT
• Must be defined on standby databases that have

different disk or directory structures from the
primary
• Allows multiple pairs of file names
• Applies to a database when in physical standby
mode
DB_FILE_NAME_CONVERT =('/oracle1/dba/',
'/ora1/stby_dba/',
'/oracle2/dba/',
'/ora2/stby_dba/')
Specifying Values for DB_FILE_NAME_CONVERT

When the standby database is updated, the DB_FILE_NAME_CONVERT parameter is used
to convert the data file name on the primary database to a data file name on the standby
database. The file must exist and be writable on the physical standby database; if it is not,
then the recovery process halts with an error.
Specify the path name and file name location of the primary database data files followed by
the standby location by setting the value of this parameter to two strings. The first string is
the pattern found in the data file names on the primary database. The second string is the
pattern found in the data file names on the physical standby database. You can use as many
pairs of primary and standby replacement strings as required. You can use single or double
quotation marks. The parentheses are optional.
In the example in the slide, /oracle1/dba/ and /oracle2/dba/ are used to match
for file names coming from the primary database. The strings /ora1/stby_dba/ and
/ora2/stby_dba/ are the corresponding ones on the physical standby database.
A file on the primary database named /oracle1/dba/system01.dbf is converted to
/ora1/dba/system01.dbf on the standby database.

Specifying Values for
LOG_FILE_NAME_CONVERT
• Similar to DB_FILE_NAME_CONVERT
• Must be defined on standby databases that have
different disk or directory structures from the
primary
• Online redo log files are used only when the
standby becomes a primary.
• Applies to a database when in physical standby
mode
LOG_FILE_NAME_CONVERT = ('/oracle1/logs/',
'/ora1/stby_logs/')
Specifying Values for LOG_FILE_NAME_CONVERT

The LOG_FILE_NAME_CONVERT parameter is used to convert the name of a redo log file
on the primary database to the name of a redo log file on the standby database. Adding a
redo log file to the primary database requires adding a corresponding file to the standby
database. When the standby database is updated, this parameter is used to convert the log
file name from the primary database to the log file name on the standby database. This
parameter is required if the standby database is on the same system as the primary database
or on a separate system that uses different path names.
Specify the location of the primary database online redo log files followed by the standby
location. The use of parentheses is optional.

Specifying a Value for
LOG_ARCHIVE_FORMAT
• Indicates the format for redo log file names
• Format directives:
– %t: Thread number
– %T: Zero-filled thread number
– %s: Sequence number
– %S: Zero-filled sequence number
– %d: Database ID
– %D: Zero-filled database ID
– %a: Current activation id
– %A: Zero-filled activation ID
– %r: Resetlogs ID
• Default value is operating system dependent.
LOG_ARCHIVE_FORMAT = %d_%t_%s_%r.arc
Specifying a Value for LOG_ARCHIVE_FORMAT

Use a text string and variables to specify the default file name format for archived redo log
files. The string that is generated from this format is appended to the string that is specified
in the LOG_ARCHIVE_DEST_n and STANDBY_ARCHIVE_DEST parameters.
The thread number refers to the redo thread. With a single instance, this is always 1; with
RAC, this corresponds to the order in which the instances were started.
Sequence number is the redo log sequence number. It starts at 0 or 1 and is incremented at
each log switch.
The database identifier (database ID) is calculated when the database is created and stored in
all file headers. This value is not changed for the life of the database.
The activation number is an internal number that is generated the first time the database is
started. Subsequently, it is changed only when the database is opened with the RESETLOGS
option.
The resetlogs ID ensures unique names are constructed for the archived log files across
multiple incarnations of the database. If the COMPATIBLE initialization parameter is set to
10.0 or higher, you must include %r in the LOG_ARCHIVE_FORMAT parameter.
The length of the zero-filled versions of these directives is 8 on most platforms.

STANDBY_FILE_MANAGEMENT
• Used to maintain consistency when you add or
delete a data file on the primary database
– MANUAL (default)
Data files must be manually added on the standby
database.
– AUTO
Add the data file automatically to the standby
database.
Certain ALTER statements are no longer allowed
on the standby database.
• Applies to the primary database and standby
database
STANDBY_FILE_MANAGEMENT = auto
Specifying a Value for STANDBY_FILE_MANAGEMENT

When STANDBY_FILE_MANAGEMENT is set to AUTO, you cannot execute the following
commands on the standby database:
• ALTER DATABASE RENAME
• ALTER DATABASE ADD/DROP LOGFILE [MEMBER]
• ALTER DATABASE ADD/DROP STANDBY LOGFILE MEMBER
• ALTER DATABASE CREATE DATAFILE AS ...
When you add (or drop) a log file to the primary and want to add (or drop) it to the standby
as well, you must do the following:
• Set STANDBY_FILE_MANAGEMENT to MANUAL on the standby.
• Add (or drop) the redo log files on the primary.
• Add (or drop) them to the standbys.
• Reset to AUTO afterward on the standby.

ARCHIVE_LAG_TARGET
• Configure on primary database only

• Set to the number of seconds after which a log
switch must happen even if the log file is not full
• Sets maximum time that a standby database must
wait to process the redo
• Default is 0 (disabled)
• Range of values: 60 to 7,200
• Recommended value: 1,800 (30 minutes)
ARCHIVE_LAG_TARGET = 1800
ARCHIVE_LAG_TARGET
The ARCHIVE_LAG_TARGET parameter defines the mean time to failover in the event
your primary database fails and you must fail over to the standby. Although the redo is
transmitted to the standby during normal operations, it is not applied to the standby database
until the online redo log file on the primary has been completed.
For example, in a configuration where the online redo log file is 100 MB and 80 MB have
been written, a failure at this point would mean that the 80 MB of redo must be applied to
the standby before the failover can complete. If you need to limit the amount of time to get
the standby up and running as a primary after a failover, you can define this parameter to
force a log switch after a certain amount of time, thereby enabling the redo to be applied.
If you set this parameter to too small a value, the primary database log files switch too often
and thus impact performance.

LOG_ARCHIVE_TRACE Parameter
• LOG_ARCHIVE_TRACE is optional and is used for

diagnostic purposes.
• Set this parameter to an integer value to see the
progression of the archiving of redo logs to the
standby system.
– On the primary, processes write an audit trail of the
archived logs sent to the standby system into a
trace file.
– On the standby, processes write an audit trail of the
archived logs received from the primary database
into a trace file.
• Trace files are located in the directory specified by
the USER_DUMP_DEST parameter.
LOG_ARCHIVE_TRACE Parameter
You can set this parameter to trace the transmission of redo data to the standby system.
To enable, disable, or modify the LOG_ARCHIVE_TRACE parameter in a primary database,
do one of the following:
• Shut down the primary database, modify the initialization parameter file, and restart
the database.
• Issue an ALTER SYSTEM SET LOG_ARCHIVE_TRACE=trace_level
statement while the database is open or mounted.
If you change the value of this parameter dynamically with an ALTER SYSTEM statement,
the changes take effect at the start of the next archive operation.
Refer to Oracle Data Guard Concepts and Administration for additional information.

LOG_ARCHIVE_TRACE Parameter (continued)
The integer values for the LOG_ARCHIVE_TRACE parameter represent levels of tracing
data. In general, the higher the level, the more detailed the information. You can combine
tracing levels by setting the value of the LOG_ARCHIVE_TRACE parameter to the sum of
the individual levels. For example, setting the parameter to 6 generates level 2 and level 4
trace output.
The following integer levels are available:
Level Meaning
0 Disables archived redo log tracing (default setting)
1 Tracks archiving of redo log file
2 Tracks archival status per archived redo log destination
4 Tracks archival operational phase
8 Tracks archived redo log destination activity
16 Tracks detailed archived redo log destination activity
32 Tracks archived redo log destination parameter modifications
64 Tracks ARCn process state activity
128 Tracks FAL server process activity
256 Reserved for future use
512 Tracks asynchronous LGWR activity
1024 Tracks RFS physical client
2048 Tracks ARCn or RFS heartbeat
4096 Tracks real-time apply activity

Backing Up the Primary Database
by Using RMAN
• Create a backup copy of the primary database.

• Use of RMAN is recommended.
RMAN> BACKUP DATABASE
Backing Up the Primary Database by Using RMAN

You can use any backup copy of the primary database to create the physical standby
database, as long as you have the necessary archived redo log files to completely recover the
database. It is recommended that you use Recovery Manager (RMAN).
See Oracle High Availability Architecture and Best Practices for backup recommendations
and Oracle Database Backup and Recovery Advanced User’s Guide for additional
information about performing the RMAN backup operation.

Creating a Control File
for the Standby Database
Create a control file on the primary database to be

used for the standby database:
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE
2 AS '/tmp/boston.ctl';
Creating a Control File for the Standby Database

On the primary database, you create the control file for the standby database. Create the
control file by issuing the following command:
ALTER DATABASE CREATE STANDBY CONTROLFILE AS file_name
[REUSE];
If the file already exists, you can use the REUSE option to overwrite it.
Note: You cannot use a single control file for both the primary and standby databases.

Copying Files
to the Standby Database System
Copy the following files to the standby database

system:
• Backup of the data files
• Standby control file
• Initialization parameter file
Primary Standby
Copying Files to the Standby Database System

After you have successfully backed up the data files and created the standby database
control file, copy the files to the standby system by using an operating system utility. If the
physical standby database is on a different system from the primary database, then the
directory paths may be the same. If the physical standby database is on the same system as
the primary database, you must rename the primary data files in the standby control file after
copying them to the standby location.

Oracle Managed Files (OMF) and
Automatic Storage Management (ASM)
• OMF: Use same on each database

• ASM: Use the RMAN DUPLICATE … FOR STANDBY
command
OMF OMF
primary standby
Oracle Managed Files (OMF) and Automatic Storage Management (ASM)

If the primary database is configured to use OMF, Oracle recommends that the standby
database be configured to use OMF as well. To do this, set the DB_CREATE_FILE_DEST
and DB_CREATE_ONLINE_LOG_DEST_n initialization parameters to appropriate values.
Maintenance and future role transitions are simplified if the same disk group names are used
for both the primary and standby databases.
On the standby database, do the following:
1. If the standby database is going to use ASM, create an ASM instance if one does not
already exist on the standby database system.
2. Use the RMAN BACKUP command to create a backup set that contains a copy of the
primary database’s data files, archived log files, and a standby control file.
3. Use the RMAN DUPLICATE … FOR STANDBY command to copy the data files,
archived redo log files, and standby control file in the backup set to the standby
database’s storage area. The DUPLICATE … FOR STANDBY command performs the
actual data movement at the standby instance.
For more information about OMF and ASM, see the Oracle Database Administrator's
Guide. For more information about the DUPLICATE … FOR STANDBY command, see the
Oracle Database Recovery Manager Reference.

Initialization Parameters on the Standby
DB_NAME=chicago
DB_UNIQUE_NAME=boston
SERVICE_NAMES=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl',
'/arch2/boston/control2.ctl'
DB_FILE_NAME_CONVERT= '/arch1/chicago/','/arch1/boston/',
'/arch2/chicago/','/arch2/boston/'
LOG_FILE_NAME_CONVERT='/arch1/chicago/','/arch1/boston/',
'/arch2/chicago/','/arch2/boston/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2= 'SERVICE=chicago
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
INSTANCE_NAME=boston
FAL_SERVER=chicago
FAL_CLIENT=boston
Initialization Parameters on the Standby

Create a text initialization parameter file (PFILE) from the server parameter file (SPFILE)
that is used by the primary database. A PFILE can be copied to the standby location and
modified. Issue the following command to create the PFILE:
SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;
Later, you will convert this file back to a SPFILE after it is modified to contain the
parameter values that are appropriate for use with the physical standby database.
Although most of the initialization parameter settings in the text initialization parameter file
that you copied from the primary system are also appropriate for the physical standby
database, some modifications need to be made. The lines in italic in the slide indicate the
parameters that need to be changed for use with the physical standby. The parameters shown
are valid for the Boston database when it is running in either the primary or the standby
database role.
In addition, ensure that the COMPATIBLE initialization parameter is set to the same value
on both the primary and standby databases. If the values differ, log transport services may be
unable to transmit redo data from the primary database to the standby databases. In a Data
Guard configuration, COMPATIBLE must be set to a minimum of 9.2.0.1.0. However, if you
want to take advantage of new Oracle Database 10g features, set the COMPATIBLE
parameter to 10.1.0.0 or higher.

STANDBY_ARCHIVE_DEST
• Defines the standby database directory where the

archived redo log files are created
• Overrides the directory location that is specified
with the LOG_ARCHIVE_DEST_n parameter
STANDBY_ARCHIVE_DEST = '/standby/arc_dest/'
STANDBY_ARCHIVE_DEST = 'LOCATION=/standby/arc_dest/'
Specifying a Value for STANDBY_ARCHIVE_DEST

You can use the STANDBY_ARCHIVE_DEST initialization parameter on the standby
database to indicate an alternative directory where the archived redo log files are to be
stored when received from the primary database.
The STANDBY_ARCHIVE_DEST initialization parameter overrides the directory location
that is specified with the LOG_ARCHIVE_DEST_n parameter if both parameters are
specified.
You should set STANDBY_ARCHIVE_DEST to the same location as the local archive
destination for the physical standby database so that all necessary archived redo log files for
the standby database are in the same location.
Because logical standbys have at least one local archive destination,
STANDBY_ARCHIVE_DEST is not set in most configurations.
STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT are used to construct a fully
qualified file name.

Setting Up the Environment
to Support the Standby Database
1. Create a Windows-based service.

2. Create a password file.
3. Configure listeners for the primary and standby
databases.
Setting Up the Environment to Support the Standby Database

1. If the standby system is running on a Windows-based system, use the ORADIM tool to
create a Windows service and password file. Here is an example:
WINNT> oradim -NEW -SID boston -INTPWD password -STARTMODE
manual
See Oracle Database Platform Guide for Windows for more information about using
the ORADIM tool.
2. On platforms other than Windows, create a password file and set the password for the
SYS user to the same password that is used by the SYS user on the primary database.
The password for the SYS user on every database in a Data Guard configuration must
be identical for redo transmission to succeed. See Oracle Database Administrator’s
Guide for information about creating a password file.
3. On both the primary and standby sites, use Oracle Net Manager to configure a listener
for the respective databases. To restart the listeners so that they recognize the new
definitions, enter the following Listener Control utility commands on both the primary
and standby systems:
% lsnrctl stop
% lsnrctl start
See Oracle Net Services Administrator’s Guide for additional information about the
Listener Control utility.
Setting Up the Environment
to Support the Standby Database
4. Enable broken connection detection on the

standby system.
5. Create Oracle Net Services names.
6. Create a server parameter file for the standby
database.
Setting Up the Environment to Support the Standby Database (continued)

4. Enable broken connection detection by setting the SQLNET.EXPIRE_TIME
parameter to 2 (minutes) in the SQLNET.ORA parameter file on the standby system.
Here is an example:
SQLNET.EXPIRE_TIME=2
See the Oracle Net Services Administrator’s Guide for additional information.
5. On both the primary and standby systems, use Oracle Net Manager to create a network
service name for the primary and standby databases that will be used by log transport
services. The Oracle Net Services name must resolve to a connect descriptor that uses
the same protocol, host address, port, and SID that you specified when you configured
the listeners for the primary and standby databases. The connect descriptor must also
specify that a dedicated server be used. See the Oracle Net Services Administrator’s
Guide and the Oracle Database Administrator’s Guide.
6. On an idle standby database, use the CREATE SPFILE SQL statement to create a
server parameter file for the standby database from the text initialization parameter file
that was edited earlier, as shown in the following example:
SQL> CREATE SPFILE FROM PFILE='initboston.ora';

Starting Up the Physical Standby Database
To start up the physical standby database:

1. Bring it to the OPEN READ ONLY stage.
2. Create a new temporary file for the physical
standby database.
3. Start Redo Apply.
4. Test archival operations to the physical standby
database:
SQL> STARTUP;
SQL> ALTER TABLESPACE TEMP1 ADD TEMPFILE
2 '/boston/temp01.dbf' SIZE 40M REUSE;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY
2 DATABASE DISCONNECT FROM SESSION;
Starting Up the Physical Standby Database

1. On the standby database, issue the STARTUP SQL statement to start the instance and
open the database in read-only mode.
2. It is beneficial to create a new temporary file on the physical standby database now
rather than later. Temporary files enable disk sorting when the database is open in
read-only mode and prepare the database for future role transitions. Identify the
tablespaces that should contain temporary files by entering the following command on
the standby database:
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES
2 WHERE CONTENTS = 'TEMPORARY';
3. On the standby database, issue the ALTER DATABASE RECOVER MANAGED
STANDBY DATABASE SQL command to start Redo Apply. This statement
automatically mounts the database. Also, include the DISCONNECT FROM SESSION
option so that Redo Apply runs in a background session.
4. The transmission of redo data to the remote standby location does not occur until after
a log switch. Issue the following command on the primary to force a log switch:
SQL> ALTER SYSTEM SWITCH LOGFILE;

Additional Configuration Tasks
Perform the following tasks as appropriate for your

configuration:
• Configure standby redo logs.
• Enable Flashback Database.
• Upgrade the data protection mode.

Perform the following tasks if they are appropriate for your physical standby database:
• Configure standby redo logs: Standby redo logs are required for standby databases
running in the maximum protection mode and maximum availability mode. However,
configuring standby redo logs is recommended on all standby databases because,
during a failover, Data Guard can recover and apply more redo data from standby redo
log files than from the archived redo log files alone. The standby redo logs should exist
on both primary and standby databases and have the same size and names.
• Enable Flashback Database: Flashback Database removes the need to re-create the
primary database after a failover. Flashback Database is similar to conventional point-
in-time recovery in its effects, enabling you to return a database to a recent past state.
Flashback Database is faster than point-in-time recovery because it does not require
restoring data files from backup or the extensive application of redo data. You can
enable Flashback Database on the primary database, the standby database, or both.
• Upgrade the data protection mode: The Data Guard configuration is initially set up
in the maximum performance mode (the default).

Special Note:
Standby Database on Same System
Primary Standby
/oracle/dba /oracle/standby/dba
• Standby database data files must be in a different

location.
• Each database instance must archive to different
locations.
• Service names must be unique.
• The standby database does not protect against
disaster.
Special Note: Standby Database on Same System

If you have a standby database on the same system as the primary database, you must
consider the following:
• The data files must be renamed. The actual file names can be the same, but at least the
directory path must be different. This means that you must use the
DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters.
• If a standby database is located on the same system as the primary database, the
archival directories for the standby database must use a different directory structure
than the primary database. Otherwise, the standby database may overwrite the primary
database files.
• If you do not explicitly specify unique service names and if the primary and standby
databases are located on the same system, the same default global name (consisting of
the database name and domain name, from the DB_NAME and DB_DOMAIN
parameters) will be in effect for both databases.
• If the standby database is on the same system as the primary database, it does not
protect against disaster. A disaster is defined as a total loss of the primary database
system. If the standby database is on the same system, it will be lost as well. This
configuration should be used for testing and training purposes only.

Summary

• Create a physical standby with SQL commands
• Back up the primary database
• Copy files to the standby system
• Set parameters on the physical standby database
• Start the standby database
• Configure Oracle Net Services
• Set parameters on the primary database
• Start the transport of redo

Data Protection Modes
and Log Transport Services

Objectives

the following:
• Describe the data protection modes
• Change the data protection mode of your
configuration
• Modify log transport services to serve your needs

Data Protection Modes and
Log Transport Modes
• A data protection mode requires a specific log

transport mode.
• A log transport mode alone does not define a data
protection mode.
Data Protection Modes and Log Transport Modes

When you define a log transport mode, you are configuring the shipment of log files from
the primary database to the standby database (physical or logical). You must set your log
transport mode to support the protection mode that you want for your configuration.
However, configuring the log transport mode alone does not set up the protection mode.
After you set up the log transport mode, you can put the configuration into the desired data
protection mode. The data protection mode setting causes internal rules to be implemented,
ensuring that your configuration is protected at the level you desire.

Attributes of LOG_ARCHIVE_DEST_n
• ARCH and LGWR

– Specify that either the archiver process or the log
writer process is responsible for transmitting redo
to the standby destination
– ARCH is the default.
• SYNC and ASYNC
– Specify that network I/O operations are to be
performed synchronously or asynchronously when
using the log writer process
– SYNC is the default and also has a parallel option.
• AFFIRM and NOAFFIRM
– Ensure that redo has been successfully written to
disk on the standby destination
– NOAFFIRM is the default.
Attributes of LOG_ARCHIVE_DEST_n
The following attributes of the LOG_ARCHIVE_DEST_n initialization parameter define the
log transport mode that is used by the primary database to send redo to the standby database:
• ARCH: Indicates that redo logs are transmitted to the destination during an archival
operation. A foreground archival operation or the archiver background processes
(ARCn) serve as the redo log transport service. This is the default.
• LGWR: Indicates that redo is transmitted to the destination concurrently while the
online redo log is being written. The log writer background process (LGWR) serves as
the redo log transport service. When transmitting redo to remote destinations, the
LGWR process establishes a network connection to the destination instance. If a
LGWR destination fails, the destination automatically reverts to using the archiver
process until the error is corrected. With the LGWR attribute, you have the following
additional options:
- SYNC=PARALLEL|NOPARALLEL: Specifies that network I/O is to be
performed synchronously for the destination. This means that after the I/O is
initiated, the LGWR process waits for the I/O to complete before

Attributes of LOG_ARCHIVE_DEST_n (continued)
continuing. The SYNC attribute is required when setting up a no-data-loss
environment because it ensures that the redo records have been successfully
transmitted to the standby database before continuing.
If the LGWR process is defined to be the transmitter to multiple standby
destinations that use the SYNC attribute, the user has the option of specifying
SYNC=PARALLEL or SYNC=NOPARALLEL for each of those destinations. If
SYNC=NOPARALLEL is used, LGWR performs the network I/O to each
destination serially. In other words, LGWR initiates an I/O to the first destination
and waits until it completes before initiating the I/O to the next destination. If
SYNC=PARALLEL is used, the network I/O is actually initiated asynchronously
so that I/O to multiple destinations can be initiated in parallel. However, after the
I/O is initiated, the LGWR process waits for each of the I/O operations to
complete before continuing, which in effect is the same as performing multiple,
synchronous I/O operations simultaneously. The use of SYNC=PARALLEL
results in better performance than SYNC=NOPARALLEL when multiple LGWR
SYNC destinations are configured. SYNC=PARALLEL is the default.
- ASYNC[=blocks]: Specifies that network I/O is to be performed
asynchronously for the destination. This means that after the I/O is initiated,
LGWR continues processing the next request without waiting for the I/O to
complete and without checking the completion status of the I/O. Use of the
ASYNC attribute allows standby environments to be maintained with little or no
performance impact on the primary database. The optional block count
determines the size of the SGA network buffer to be used. In general, the slower
the network connection, the larger the block count. The default is 2048.
• AFFIRM: Ensures that all disk I/O to the archived redo log files or standby redo log
files at the standby destination is performed synchronously and completes successfully
before online redo log files on the primary database can be reused. This attribute has
the potential to affect primary database performance. When you use the LGWR, SYNC,
and AFFIRM attributes, the transaction is not committed until the disk I/O is
completed.
• NOAFFIRM: Indicates that all redo disk I/O operations are to be performed
asynchronously, which means that the log writer process does not wait until the disk
I/O has completed before continuing. This is the default.

Setting the Log Transport Mode
Click Edit to access the

Edit Standby Database Properties
page.

Use the following procedure to set the log transport mode with Enterprise Manager:
1. Select your standby database, and then click Edit on the Data Guard page.
2. Click “Standby Role Properties” on the Edit Standby Database Properties page.
3. Click “Show Advanced Properties.”

Select the mode from

the Log Transport
Mode list.
Setting the Log Transport Mode (continued)

You can use the drop-down list to select the log transport mode on the Standby Role
Properties page. The values in the Log Transport Mode list are defined as follows:
• ARCH: Configures log transport services for your standby database using the ARCH
attribute of the LOG_ARCHIVE_DEST_n initialization parameter. You do not need
standby redo log files for this mode. This mode enables the lowest grade of protection
to the primary database as well as the lowest performance impact.
• ASYNC: Configures log transport services for your standby database using the LGWR,
ASYNC, and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization
parameter. This mode, along with standby redo log files, enables a moderate grade of
protection to the primary database and incurs a lower performance impact.
• SYNC: Configures log transport services for your standby database using the LGWR,
SYNC, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization
parameter. This mode, along with standby redo log files, is required for the maximum
protection or maximum availability protection modes. This log transport mode enables
the highest grade of data protection to the primary database, but it also incurs the
highest performance impact.

• Three data protection modes:

– Maximum protection
– Maximum availability
– Maximum performance
• Help to balance data availability and system
performance

Oracle Data Guard offers maximum protection, maximum availability, and maximum
performance modes to help enterprises balance data availability against system performance
requirements.
In some situations, a business cannot afford to lose data. In other situations, the availability
of the database may be more important than the loss of data. Some applications require
maximum database performance and can tolerate a potential loss of data.

Maximum Protection
• Enables zero data loss

• Redo data must be written to both the local online
redo log and the standby redo log on at least one
standby database.
• Primary database shuts down if a fault prevents it
from writing its redo stream to at least one remote
standby redo log.
• Configuration requirements:
– Standby redo log files on at least one standby
database
– SYNC, LGWR, and AFFIRM attributes
for at least one standby database
Maximum Protection
This protection mode ensures that no data loss will occur if the primary database fails. To
provide this level of protection, the redo data needed to recover each transaction must be
written to both the local online redo log and the standby redo log on at least one standby
database before the transaction commits. To ensure that data loss cannot 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 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.
To enable maximum protection mode, perform the following configuration tasks:
• Configure standby redo log files on at least one standby database.
• Set the SYNC, LGWR, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n
parameter for at least one standby database destination.

• Provides the highest possible level of data

protection without compromising the availability
of the primary database
• Redo data must be written to both the local online
redo log and the standby redo log on at least one
standby database.
• Primary database does not shut down if a fault
prevents it from writing its redo stream.
• Configuration requirements:
– Standby redo log files on at least one standby
database
– SYNC, LGWR, and AFFIRM attributes
for at least one standby database
This protection mode provides the highest possible level of data protection without
compromising the availability of the primary database. Like maximum protection mode, a
transaction will 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 will occur 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.
To enable maximum availability mode, perform the following configuration tasks:
• Configure standby redo log files on at least one standby database.
• Set the SYNC, LGWR, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n
parameter for at least one standby database.

Maximum Performance
• Default level of data protection

• Provides highest possible level of data protection
without affecting the performance of the primary
database
• Transaction can commit as soon as the redo data
is written to the local online redo log.
• Redo stream is written asynchronously with
respect to the commitment of the transactions that
create the redo data.
Maximum Performance
This protection mode (the default) 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.
The maximum performance mode enables you to either set the LGWR and ASYNC attributes
or set the ARCH attribute on the LOG_ARCHIVE_DEST_n parameter for the standby
database destination. If the primary database fails, you can reduce the amount of data that is
not received on the standby destination by setting the LGWR and ASYNC attributes.

Setting the Data Protection Mode
Click the Protection Mode

link.

If the data protection mode that you need requires a standby database to use the SYNC or
ASYNC log transport mode, Enterprise Manager will automatically set the log transport
mode for the primary database and the selected standby databases.
Enterprise Manager automatically determines the correct number and size of standby redo
log files needed for all databases in the configuration and adds those log files using the
directory locations you specify.
After you upgrade the protection mode using Enterprise Manager, the primary database will
be restarted automatically. The primary database need not be restarted following a
downgrade of the protection mode.
You can set the data protection mode by using Enterprise Manager as follows:
1. Navigate to the Data Guard page.
2. Click the link in the Protection Mode field to access the Edit Protection Mode: Select
page.

Setting the Data Protection Mode (continued)

3. Select Maximum Protection, Maximum Availability, or Maximum Performance, and
then click Continue.
4. If prompted, log in to the database with SYSDBA privileges, and then click Login.
5. Select one or more standby databases to support the protection mode that you selected.
If standby redo log files are needed, verify the names of the log files. Click OK.
6. On the Confirmation page, click Yes.

by Using the CLI
1. Configure standby redo logs.

2. Set the LogXptMode property (if necessary).
3. Set the data protection mode.
DGMGRL> EDIT DATABASE 'site1_edrsr8p1' SET PROPERTY
'LogXptMode'='SYNC';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
MAXAVAILABILITY;
Setting the Data Protection Mode by Using the CLI

1. If you are setting the protection mode to maximum protection or maximum
availability, ensure that standby redo log files are configured on the standby database.
You must also configure standby redo log files for the primary database or another
standby database in the configuration to ensure that it can support the chosen
protection mode after a switchover.
2. Use the EDIT DATABASE SET PROPERTY command to set the log transport mode
for the standby database. For example, if you are changing the data protection mode to
maximum availability, use the EDIT DATABASE command to specify SYNC for log
transport services as follows:
DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC';
You must also set the log transport services for the primary database or another
standby database in the configuration to ensure that it can support the chosen
protection mode after a switchover.
3. Use the EDIT CONFIGURATION SET PROTECTION MODE AS command to set the
overall configuration protection mode. To set the protection mode to maximum
availability, issue the following command:
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

Setting the Protection Mode
by Using SQL
• You must set attributes to support the type of

protection desired.
• Issue the ALTER DATABASE statement on the
primary database:
ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;
Setting the Protection Mode by Using SQL

You must set attributes of the LOG_ARCHIVE_DEST_n initialization parameter for each
level of protection. For each level of protection, you must have at least one standby database
with the following:
• Maximum protection: LGWR, SYNC, AFFIRM, and standby redo logs files
• Maximum availability: LGWR, SYNC, AFFIRM, and standby redo logs files for
physical standby databases
• Maximum performance: any combination of LGWR or ARCH
Using the following SQL statement on the primary database, you can configure the Data
Guard environment to maximize data protection, availability, or performance:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION |
AVAILABILITY | PERFORMANCE};

Delaying the Application of Redo
Delaying the application of redo helps to safeguard

against:
• Data corruption
• User errors
Oracle Net
Delayed
application
Production Standby
database database
Delaying the Application of Redo

You can delay the application of changes to standby databases, thereby providing protection
from user errors or corruptions. You can protect against the application of corrupted or
erroneous data to the standby database. The apply process also revalidates the log records to
prevent application of log corruptions.
For example, if a critical table is accidentally dropped from the primary database, you can
prevent this action from affecting the standby database by delaying the application of this
change in the standby database.
If operating in maximum protection or maximum availability mode, Data Guard will ensure
zero data loss even with the delayed apply in effect.
If you define a delay for a destination that has real-time apply enabled, the delay is ignored.

Using Enterprise Manager to Delay
the Application of Redo
Specify the delay in

minutes.
Using Enterprise Manager to Delay the Application of Redo

You can configure delayed apply by using Enterprise Manager as follows:
1. On the Data Guard page, select your standby database. Then click Edit.
2. On the Edit Standby Database Properties page, click Standby Role Properties.
3. Click the Show Advanced Properties link.
4. In the Apply Delay field, enter the delay value (in minutes).
5. Click Apply.

Setting LOG_ARCHIVE_DEST_n
to Delay the Application of Redo
Use the attributes of LOG_ARCHIVE_DEST_n to control

the application of redo:
• DELAY: Number of minutes to delay application of
redo (default: 30 minutes)
• NODELAY: Redo applied as received (default
behavior)
Setting LOG_ARCHIVE_DEST_n to Delay the Application of Redo

You can use the DELAY=minutes attribute of the LOG_ARCHIVE_DEST_n initialization
parameter to delay the application of archived redo log files to the standby database on the
primary database and physical standby databases.
Note: If you do not specify a value for minutes, the default is 30 minutes.

Using Flashback Database
Instead of Apply Delay
Standby1
No delay
Primary Standby2
database
4-hour delay
Standby3
8-hour delay
Primary Standby
database
Using Flashback Database Instead of Apply Delay

As an alternative to the Apply Delay configuration option, you can use Flashback Database
to protect against the application of corrupted or erroneous data to the standby database.
Flashback Database can quickly and easily flash back a standby database to an arbitrary time
in the past. You can configure one standby database with Flashback Database to achieve the
same benefit as multiple standby databases with different delays.
Refer to the Oracle Database Backup and Recovery Advanced User’s Guide for additional
information on Flashback Database.

Additional Attributes That Affect
Log Transport Services
• ALTERNATE, NOALTERNATE
• DEPENDENCY, NODEPENDENCY
• MAX_FAILURE, NOMAX_FAILURE
• NET_TIMEOUT, NONET_TIMEOUT
• REOPEN, NOREOPEN
Additional Attributes That Affect Log Transport Services

The following pages present additional attributes of the LOG_ARCHIVE_DEST_n
initialization parameter that affect log transport services. The use of each attribute depends
entirely on your individual business requirements.

ALTERNATE and NOALTERNATE Attributes
• Can specify one alternate destination for the

LOG_ARCHIVE_DEST_n parameter
• Allow a failed destination to change destinations
– Disk full: switch to new disk
– Oracle Net link fails: switch to new network link
• Require NOREOPEN or MAX_FAILURE
• Enabled with LOG_ARCHIVE_DEST_STATE_n
• Default: NOALTERNATE
log_archive_dest_3='SERVICE=stby1_path1 NOREOPEN
ALTERNATE=LOG_ARCHIVE_DEST_4'
log_archive_dest_4='SERVICE=stby1_path2 NOREOPEN
OPTIONAL'
log_archive_dest_state_3=ENABLE
log_archive_dest_state_4=ALTERNATE
ALTERNATE and NOALTERNATE Attributes

You can use the ALTERNATE attribute to specify another LOG_ARCHIVE_DEST_n
destination to be used if archival operations to the original destination fail. A destination can
have a maximum of one alternate destination specified. An alternate destination is used
when the transmission of redo fails. If the archiving to the destination fails and the REOPEN
attribute is specified with a value of zero (0), or if NOREOPEN is specified, the Oracle
database server attempts to transmit the redo to the alternate destination on the next log
switch.
An alternate destination cannot be self-referencing.
An alternate destination must be in the ALTERNATE state; this state is specified using the
LOG_ARCHIVE_DEST_STATE_n initialization parameter. The ALTERNATE state defers
processing of the destination until another destination failure automatically enables this
destination (provided that the alternate destination attributes are valid).

MAX_FAILURE and
NOMAX_FAILURE Attributes
MAX_FAILURE[=count]
• Number of times log transport services attempts
to reestablish communication
• Requires REOPEN
• No default count
NOMAX_FAILURE
• Default
• Same as MAX_FAILURE=0
log_archive_dest_3='SERVICE=o10g1 LGWR
MAX_FAILURE=30 REOPEN'
MAX_FAILURE and NOMAX_FAILURE Attributes

The MAX_FAILURE attribute of the LOG_ARCHIVE_DEST_n initialization parameter
specifies the maximum number of consecutive times that log transport services reattempts
archival operations to a failed destination. Using this attribute, you can provide failure
resolution for archiving destinations to which you want to retry archival operations after a
failure, but not retry indefinitely. When you specify the MAX_FAILURE attribute, you must
also set the REOPEN attribute to specify how often archival operations are retried to the
particular destination.
If you set both the MAX_FAILURE and REOPEN attributes to nonzero values, log transport
services limit the number of archival attempts to the number of times specified by the
MAX_FAILURE attribute. Each destination contains an internal failure counter that tracks
the number of consecutive archival failures that have occurred. You can view the failure
count in the FAILURE_COUNT column of the V$ARCHIVE_DEST fixed view. The related
column REOPEN_SECS identifies the REOPEN attribute value.

NET_TIMEOUT and
NONET_TIMEOUT Attributes
• Enable the LGWR process to avoid a network

timeout issue
• Valid with SYNC=PARALLEL or ASYNC destinations
• Value supplied is the number of seconds to wait.
• Range of values for NET_TIMEOUT: 15 to 1200
• Default: NONET_TIMEOUT
• Use caution in maximum protection mode
log_archive_dest_2='SERVICE=o10g2 LGWR
SYNC=PARALLEL NET_TIMEOUT=30'
NET_TIMEOUT and NONET_TIMEOUT Attributes

The NET_TIMEOUT attribute enables you to bypass the default network timeout interval
established for the system on which the primary database resides. Without the
NET_TIMEOUT attribute (or if NONET_TIMEOUT is explicitly specified), the primary
database can potentially stall for the default network timeout period. By specifying a
smaller, nonzero value for NET_TIMEOUT, you can enable the primary database to mark a
destination as “failed” after the user-specified timeout interval expires.
Note: Be careful to specify a reasonable value when running in maximum protection mode.
False network failure detection may cause the primary instance to shut down.

REOPEN and NOREOPEN Attributes
• REOPEN[=seconds]
– Minimum number of seconds to wait before retrying
a failed destination at log switch
– Failures can be network failures, quota exceptions,
disk full, and so on.
– Default: REOPEN with 300 seconds (5 minutes)
• NOREOPEN
– Failed destinations remain disabled until:
Manually reenabled
ALTER SYSTEM SET
LOG_ARCHIVE_DEST_STATE_n=ENABLE issued
Instance restart
– Required when using ALTERNATE destinations with
NOMAX_FAILURE attributes
REOPEN and NOREOPEN Attributes

The REOPEN and NOREOPEN attributes of the LOG_ARCHIVE_DEST_n parameter specify
the minimum number of seconds before the process shipping the redo should try again to
access a previously failed destination.
REOPEN applies to all errors, not just connection failures. These errors include (but are not
limited to) network failures, disk errors, and quota exceptions.

Summary

• Describe the data protection modes
• Change the data protection mode of your
configuration
• Modify log transport services to suit your needs
• Delay the application of redo
• Use additional transport services attributes


• Changing the data protection mode
• Delaying the application of redo

Data Guard SQL Apply Architecture

Objectives

the following:
• Explain the advantages of SQL Apply
• Explain when to use a logical standby database
• Create a logical standby database by using
Enterprise Manager

Benefits of Implementing a
• Provides an efficient use of system resources:

– Open, independent, and active production database
– Additional indexes and materialized views can be
created for improved query performance.
• Reduces workload on the primary database by
offloading the following workloads to a logical
standby database
– Reporting
– Summations
– Queries
Benefits of Implementing a Logical Standby Database

A logical standby database provides disaster recovery, high availability, and data protection
benefits that are similar to those of a physical standby database. It also provides the
following specialized benefits:
• Efficient utilization of system resources: A logical standby database is an open,
independent, and active production database. It 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. It remains open while the tables are
updated from the primary database, and those tables are simultaneously available for
read-access. Because the data can be presented with a different physical layout,
additional indexes and materialized views can be created to improve your reporting
and query requirements and to suit your specific business requirements.
• Reduction in primary database workload: The logical standby tables that are
updated from the primary database can be used for other tasks (such as reporting,
summations, and queries), thereby reducing the primary database workload.

Benefits of Implementing a
• Provides data protection:

– Primary database corruptions not propagated
• Provides disaster recovery capabilities:
– Switchover and failover
– Minimizes down time for planned and unplanned
outages
Benefits of Implementing a Logical Standby Database (continued)

• Data protection: A logical standby database provides a safeguard against data
corruptions and user errors. Primary-side physical corruptions do not propagate
through the redo data that are transported to the logical standby database. Similarly,
user errors that may cause the primary database to be permanently damaged can be
resolved before application on the logical standby through delay features.
• Disaster recovery: A logical standby database provides a robust and efficient disaster
recovery solution. Easy-to-manage switchover and failover capabilities allow easy role
reversals between primary and logical standby databases, minimizing the down time of
the primary database for planned and unplanned outages.

Securing Your Logical Standby Database
• Configure the database guard to control user

access to tables.
• ALTER DATABASE GUARD command keywords:
– ALL: Prevents users from making changes to any
data in the database
– STANDBY: Prevents users from making changes to
any data maintained by Data Guard SQL Apply
– NONE: Normal security
• Query GUARD_STATUS column in V$DATABASE.
• Database guard level is set to ALL by broker
automatically on the logical standby database.
• Database guard level applies to all users except
SYS.
Securing Your Logical Standby Database

You can control user access to tables in a logical standby database by using the ALTER
DATABASE GUARD command to configure the database guard.
By default, it is not possible for a nonprivileged user to modify data on a Data Guard SQL
Apply database. This is because the database guard is automatically set to ALL. With this
level of security, only the SYS user can modify data.
If you are not using the broker, you can set the security level to the STANDBY level. In this
case, users are able to modify data that is not maintained by the logical apply engine.
A security level of NONE permits any user to access the standby database as long as they
have the correct privileges.
When creating a logical standby database manually with SQL commands, you must issue
the ALTER DATABASE GUARD ALL command before opening the database. Failure to do
so will allow jobs that are submitted through DBMS_JOB.SUBMIT to be scheduled and to
potentially modify tables in the logical standby database.

Preparing to Create a
Perform the following steps on the primary database

before creating a logical standby database:
1. Check for unsupported data types.
2. Be aware of unsupported DDL commands.
3. Ensure row uniqueness.
4. Verify that the primary database is configured for
ARCHIVELOG mode.
5. Enable supplemental logging.
6. Create an alternate tablespace for logical standby
system tables (optional).
Preparing to Create a Logical Standby Database

When creating a logical standby database, you must take several actions before you begin.
The following pages discuss these steps in detail.

Unsupported Data Types
• BFILE, ROWID, and UROWID

• User-defined types
• Object types REFs
• Varrays
• Nested tables
• XMLtype

Ensure that your logical standby database can support the data types of the database objects
that are defined in your primary database. If the primary database contains unsupported
tables, log apply services automatically exclude these tables when applying redo data to the
logical standby database.

Unsupported Objects
• Tables and sequences in the SYS schema

• Tables with unsupported data types
• Tables using table compression
• Tables used to support functional indexes
• Tables used to support materialized views
• Global temporary tables
• Index-organized tables (IOTs) with overflows and
LOB columns
Unsupported Objects
Refer to Oracle Data Guard Concepts and Administration for additional information on
unsupported data types and objects.

Checking for Tables with
Query DBA_LOGSTDBY_UNSUPPORTED on the primary

database for tables with unsupported data types:
SQL> desc DBA_LOGSTDBY_UNSUPPORTED
Name Null? Type

-------------- -------- -------------
OWNER NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)
COLUMN_NAME NOT NULL VARCHAR2(30)
DATA_TYPE VARCHAR2(106)
Checking for Tables with Unsupported Data Types

You can query the DBA_LOGSTDBY_UNSUPPORTED data dictionary view to see all of the
tables that contain data types that are not supported by logical standby databases. These
tables are not maintained (do not have DML applied) in the logical standby database. Any
changes made to unsupported data types, tables, sequences, or views on the primary
database are not propagated to the logical standby database, nor is an error message
returned.
It is a good idea to query this view on the primary database to ensure that those tables
necessary for critical applications are not in this list before you create the logical standby
database.
If the primary database includes unsupported tables that are critical, consider using a
physical standby database instead.
Note: This view does not show any tables from the SYS schema because changes to the SYS
schema object are not applied to the logical standby database. In addition, this view does not
show tables with table compression.

Unsupported DDL Commands
• ALTER DATABASE • CREATE MATERIALIZED
• ALTER SESSION VIEW
• ALTER MATERIALIZED • CREATE MATERIALIZED
VIEW VIEW LOG
• ALTER MATERIALIZED • CREATE SPFILE FROM
VIEW LOG PFILE
• ALTER SYSTEM • DROP DATABASE LINK
• CREATE CONTROL FILE • DROP MATERIALIZED VIEW
• CREATE DATABASE • DROP MATERIALIZED VIEW
• CREATE DATABASE LINK LOG
• CREATE PFILE FROM • EXPLAIN
SPFILE • LOCK TABLE
• CREATE SCHEMA • SET CONSTRAINTS
AUTHORIZATION • SET ROLE
• SET TRANSACTION
Unsupported DDL Commands

Not all data definition language (DDL) commands that are executed on the primary database
are applied to the logical standby database. If you execute any of these commands (shown in
the slide) on the primary database, they are not executed on any logical standby database in
your configuration. You must execute them on the logical standby database to maintain
consistency between the primary database and the logical standby database.

Ensuring Unique Row Identifiers
• Query DBA_LOGSTDBY_NOT_UNIQUE on the

primary database to find tables without a unique
identifier:
SQL> desc DBA_LOGSTDBY_NOT_UNIQUE
Name Null? Type
-------------- -------- ------------
OWNER NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)
BAD_COLUMN VARCHAR2(1)
• BAD_COLUMN possible values:
– Y: Data type is unbounded.
– N: Table contains enough column information.
Ensuring Unique Row Identifiers

Because the row IDs on a logical standby database might not be the same as the row IDs on
the primary database, a different mechanism must be used to match the updated row on the
primary database to its corresponding row on the logical standby database. Primary keys and
unique indexes can be used to match the corresponding rows. It is recommended that you
add a primary key or a unique index to tables on the primary database (whenever appropriate
and possible) to ensure that SQL Apply can efficiently apply data updates to the logical
standby database.
You can query the DBA_LOGSTDBY_NOT_UNIQUE view to identify tables in the primary
database that do not have a primary key or unique index with NOT NULL columns. Issue the
following query to display a list of tables that SQL Apply might not be able to uniquely
identify:
SQL> SELECT OWNER, TABLE_NAME,BAD_COLUMN
2 FROM DBA_LOGSTDBY_NOT_UNIQUE
3 WHERE TABLE_NAME NOT IN
4 (SELECT TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED);

Ensuring Unique Row Identifiers (continued)
The key column in this view is BAD_COLUMN. If this view returns a row for a given table,
you may want to consider adding a primary or unique key constraint on the table.
A value of Y indicates that the table does not have a primary or unique constraint and that
the column is defined using an unbounded data type, such as CLOB. If two rows in the table
match except for values in their LOB column, then the table cannot be maintained properly
and SQL Apply stops.
A value of N indicates that the table does not have a primary or unique constraint but that it
contains enough column information to maintain the table in the logical standby database.
However, the log transport services and log apply services run more efficiently if you add a
primary key. You should consider adding a disabled RELY constraint to these tables (as
described later in this lesson).

Adding a Disabled Primary Key
RELY Constraint
You can add a disabled RELY constraint to uniquely

identify rows:
SQL> ALTER TABLE hr.employees

2 ADD PRIMARY KEY (employee_id, last_name)
3 RELY DISABLE;
Adding a Disabled Primary Key RELY Constraint

If your application ensures that the rows in a table are unique, you can create a disabled
primary key RELY constraint on the table without incurring the overhead of maintaining a
primary key on the primary database.
The RELY constraint tells the system to log the named columns (in this example,
employee_id and last_name) to identify rows in this table. Be careful to select
columns for the disabled RELY constraint that uniquely identify the row. If the columns
selected for the RELY constraint do not uniquely identify the row, SQL Apply does not
apply redo information to the logical standby database.
Note: For this example, assume that the HR.EMPLOYEES table does not have a primary
key.

Supplemental Logging
• Adds supplemental data to the log stream

• Three levels of database supplemental logging:
– Full: Enables database-wide, before-image logging
of primary keys or unique indexes for all updates
– Minimal: Minimal amount of information needed for
LogMiner to identify, group, and merge the redo
operations that are associated with DML changes
– None: No additional redo information added to the
redo stream
• SQL Apply requires full supplemental logging.
Supplemental Logging
For logical standby to work properly, the logs must contain enough information for the
standby database to be created. The supplemental_db_logging clauses of the
ALTER DATABASE command instruct Oracle Database to add or stop adding supplemental
data to the log stream.
Supplemental logging must be enabled on the primary database to support a logical standby
database. Because an Oracle Database only logs the columns that were modified, this is not
always sufficient to uniquely identify the row that changed, and additional (supplemental)
information must be put into the stream of redo data. The supplemental information that is
added to the redo data helps SQL Apply correctly identify and maintain tables in the logical
standby database.
Supplemental logging can be enabled as follows:
• Full supplemental logging (or identification key logging) enables database-wide,
before-image logging of primary keys or unique indexes (in the absence of primary
keys) for all updates. With this type of logging, an application can identify updated
rows logically rather than resorting to row IDs. This type of logging is required by
SQL Apply.

Supplemental Logging (continued)
On the primary database, issue the following statement to add primary key and unique
index information to the archived redo log file:
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
2 (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
• Minimal supplemental logging logs the minimal amount of information that is needed
for LogMiner to identify, group, and merge the redo operations that are associated with
DML changes. It ensures that LogMiner (and any products building on LogMiner
technology) has sufficient information to support chained rows and various storage
arrangements, such as cluster tables.
Issue the following statement to enable minimal supplemental logging:
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Note: The default for supplemental logging is None.

Enabling Supplemental Logging
• Data Guard broker automatically enables

supplemental logging.
• Manually enable full supplemental logging before
your create your logical standby:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
• Verify that the following columns in V$DATABASE
contain a YES value:
– SUPPLEMENTAL_LOG_DATA_MIN
– SUPPLEMENTAL_LOG_DATA_PK
– SUPPLEMENTAL_LOG_DATA_UI
Enabling Supplemental Logging

You must enable full supplemental logging before you create the logical standby database.
The reason is that the logical standby database cannot use archived redo logs that contain
both supplemental log data and nonsupplemental log data.
Note: Enterprise Manager automatically enables supplemental logging when you create the
The following columns in the V$DATABASE view have a YES value after supplemental
logging has been enabled. YES represents the following for the respective columns:
• SUPPLEMENTAL_LOG_DATA_MIN: LogMiner has sufficient information to support
chained rows and various storage arrangements.
• SUPPLEMENTAL_LOG_DATA_PK: All columns of the primary key are placed in the
redo log whenever there is an update.
• SUPPLEMENTAL_LOG_DATA_UI: If any unique key columns are modified, all other
columns belonging to the unique key are also logged.
Note: If you enable full supplemental logging on your primary database and you have
already created physical standby databases, then you must enable supplemental logging on
each physical standby database to ensure that future switchovers work correctly.

Verifying Values of
Initialization Parameters
Verify the values for the following initialization

parameters on the primary database :
• PARALLEL_MAX_SERVERS
• LOG_PARALLELISM
• SHARED_POOL_SIZE
Verifying Values of Initialization Parameters

Verify the values of the following initialization parameters on the primary database before
creating the logical standby database:
• PARALLEL_MAX_SERVERS: Value must be set to 5 or greater. The recommended
value is 9. The SQL Apply Service on the logical standby site uses several parallel
processes when applying the SQL to the logical database.
• LOG_PARALLELISM: Value must be set to 1. This is the default value. If this value is
changed, LogMiner on the logical standby site cannot read the redo logs.
• SHARED_POOL_SIZE: Value should be 160 MB or greater. This is a
recommendation. Your configuration may operate with a lower value, but in a
production environment a lower value may cause performance degradation.

Creating a Logical Standby Database
Click “Add Standby Database.”
Creating a Logical Standby Database with Enterprise Manager

The following series of slides shows you how to add a logical standby database to an
existing configuration.
First, click Add Standby Database to invoke the Add Standby Database Wizard.

Select "Create a new logical

standby database."
Click Continue.

Select “Create a new logical standby database” on the Add Standby Database page, and then
click continue.

Step 1: Specifying the Backup Type
Step 1: Specifying the Backup Type

On the Backup Type page of the wizard, select one of two backup operations to use to create
the standby database (as you did when creating a physical standby database).
When you create a logical standby database, the wizard also identifies tables that cannot be
supported in your logical standby database and displays a list on the Backup Type page.
Click Next to continue.

Step 2: Specifying the Backup Options
Step 2: Specifying the Backup Options

On the Backup Options page, specify the parameters that are required to perform a new
backup of the primary database or to access an existing backup.
See the lesson titled “Creating a Configuration with Enterprise Manager” for additional
information about the parameters on the Backup Options page.

Step 3: Selecting the Oracle Home –
Instance Name
Step 3: Selecting the Oracle Home – Instance Name

On the Standby Oracle Home page, specify the parameters that are required to create the
standby database and select the Oracle home in which to create the standby database. The
standby database can be created in any Oracle home that has been discovered by Oracle
Enterprise Manager. Only Oracle homes on hosts that match the architecture and version of
the primary host are shown.

Step 4: Specifying the Standby Database
File Locations – Access Method
Step 4: Specifying the Standby Database File Locations – Access Method

On the File Locations page, specify the location for the standby database files and customize
other selections based on whether the standby database is being created on a different host
than the primary database.
Note: The Backup File Access section appears only when the standby database is being
created on a host other than the primary database. In this case, you must choose a method to
make the primary backup files accessible to the standby host.

Step 4: Specifying the Standby Database
File Location – File Locations
Step 4: Specifying the Standby Database File Location – File Locations

When the primary and standby databases are on the same host, all standby database files are
put in an Optimal Flexible Architecture (OFA) directory structure by default.
When the primary and standby databases are on different hosts, you can use the Standby
Database File Locations section to put all the standby database files in an OFA directory
structure, or to keep file names and locations the same as the primary database.
You can optionally change the locations of individual standby database files by clicking
Customize, which displays the File Locations Customize page.
Data Guard automatically adds configuration information for the new standby database to
the listener.ora and tnsnames.ora files in the directory that is specified in the
Network Configuration File Location section. The default location is the network
administration directory of the standby database Oracle home.

Step 5: Specifying Standby Database
Configuration Parameters
Step 5: Specifying Standby Database Configuration Parameters

On the Standby Configuration page, you can specify configuration parameters for the
standby database. The configuration parameters include the instance name, service provider
name, target name, and standby archive location. The default values are based on
corresponding primary database settings.
When you create a new physical database, the following parameters must be configured:
• Database Name: This field appears only when you are creating a new logical standby
database. (Physical standby databases use the same database name as the primary.)
A default database name is provided; you can specify any name that conforms to
Oracle naming conventions.
• Database Unique Name: Specify a value for the DB_UNIQUE_NAME parameter.
This name must be unique in the Data Guard configuration.
Note: This field appears only if you are creating a new physical standby database and
the primary database is an Oracle10g database.
• Target Name: Specify a name for Enterprise Manager to use for the new standby
database. This name appears in the list of database targets maintained by Enterprise
Manager. It is recommended that this name be the same as the database unique name.

Step 6: Reviewing the
Configuration Information
Step 6: Reviewing the Configuration Information

The Review page of the wizard displays a summary of your selections and lists the
parameters to be used to create the new standby database.
The new standby database is created in the background by an Oracle Enterprise Manager
job. The name of the job that is submitted is provided at the top of the page.
When you click Finish, the Processing page appears. This page tracks each step through the
submission of the standby creation job. After the job submission is complete, you see the
Data Guard Overview page, where you can monitor the progress of the standby creation job.

Standby Database Creation Processing
Standby Database Creation Processing

You can view the progress of the Add Standby Database process on the Processing page.
When the process completes, Enterprise Manager displays the Data Guard Overview page.

Resolving a Failed or Canceled
Configuration Creation
• On the primary node:

1. Stop the Data Guard broker processes.
2. Remove the Data Guard configuration files.
• On the standby node:
1. Shut down the standby database.
2. Remove the initialization files for the standby
database.
3. Remove the entry pertaining to the standby
database from the Oracle Net listener file.
4. Stop and restart the Oracle Net listener.
5. Remove the standby database data files and online
log files.
Resolving a Failed or Canceled Configuration Creation

If the Add Standby Database Wizard failed or was canceled when creating a configuration
with a new standby database, you may need to perform the following cleanup tasks before
you can reattempt the process. Some, none, or all of the cleanup tasks may be necessary to
clean up the results of the failed or canceled operation.
On the primary node:
1. Stop the Data Guard broker processes. To stop the processes, connect to the primary
database and set the DG_BROKER_START system parameter to FALSE.
2. Remove the Data Guard configuration files. Delete these files with the appropriate
delete command for the operating system.
On the standby node:
1. Shut down the standby database.
2. Remove the initialization files for the standby database. Delete these files with the
appropriate delete command for the operating system.
3. Remove the entry pertaining to the standby database from the Oracle Net listener file
(listener.ora) in the Oracle home for the standby database.
4. Stop and restart the Oracle Net listener.
5. Remove the standby database data files and online log files. The commands that you
use to remove the files depend on where the files are located on the standby node.
Summary
In this lesson you should have learned how to:

• Explain the advantages of a logical standby
database
• Decide when to use a logical standby database
• Create a logical standby by using Enterprise
Manager


• Creating a logical standby database using the
Add Standby Database Wizard
• Verifying the configuration

by Using SQL

Objectives
After completing this lesson, you should be able to use

SQL commands to create a logical standby database.

Preparing to Create a
As preparation for creating a logical standby database,

perform the following steps on the primary database:
• Check for unsupported data types.
• Be aware of unsupported DDL commands.
• Ensure row uniqueness.
• Verify that the primary database is configured for
ARCHIVELOG mode.
• Enable supplemental logging.
• (Optional) Create an alternate tablespace for
logical standby system tables.
• Check the values of initialization parameters.
Preparing to Create a Logical Standby Database

These tasks were covered in the “Data Guard SQL Apply Architecture” lesson. They are
presented again as a reminder that they must be performed whether you are using Enterprise
Manager or SQL commands to create a logical standby database.
Be sure to check that the initialization parameters have the following values:
• PARALLEL_MAX_SERVERS > 5
• LOG_PARALLELISM = 1
• SHARED_POOL_SIZE: 160 MB or higher (recommended)

To create a logical standby database by using SQL

commands:
1. Create a physical standby database.
2. Prepare the primary database to support a logical
standby database.
3. Prepare to transition to a logical standby
database.
4. Start the logical standby database.
5. Verify that the logical standby database is
performing properly.

Each of these steps is outlined in detail in the remainder of this lesson.

Step 1: Create a Physical
Standby Database
a. Create a physical standby database.

b. Ensure that the physical standby database is
caught up to the primary database.
Step 1: Create a Physical Standby Database

You create a logical standby database by first creating a physical standby database. Then
you transition the physical standby database into a logical standby database.
To create the physical standby database:
a. Create a physical standby database as described in the lesson titled “Creating a
Physical Standby Database by Using SQL.”
b. Ensure that the physical standby database is caught up to the primary database by
allowing recovery to continue until the physical standby database is consistent with the
primary database, including all database structural changes (such as adding or
dropping data files).

Step 2: Prepare the Primary Database to
Support a Logical Standby Database
a. Ensure that supplemental logging is enabled.

SQL> SELECT SUPPLEMENTAL_LOG_DATA_PK
2 AS PK_LOG,
3 SUPPLEMENTAL_LOG_DATA_UI AS UI_LOG
4 FROM V$DATABASE;
b. Enable supplemental logging (if necessary).

Step 2: Prepare the Primary Database to Support a Logical Standby Database

Perform the following steps to ensure that supplemental logging is enabled:
a. Supplemental logging must be enabled on the primary database to support a logical
standby database. Determine whether supplemental logging is enabled on the primary
database by querying the V$DATABASE view:
SQL> SELECT SUPPLEMENTAL_LOG_DATA_PK AS PK_LOG,
2> SUPPLEMENTAL_LOG_DATA_UI AS UI_LOG
3> FROM V$DATABASE;
A value of YES in the columns indicates that supplemental logging is enabled.
b. If supplemental logging is not enabled, issue the following statement to add primary
key and unique index information to the archived redo log file:

Step 2: Prepare the Primary Database to
Support a Logical Standby Database
c. Prepare the primary database for role transitions

by setting LOG_ARCHIVE_DEST_n parameters
appropriately.
d. Set the value of UNDO_RETENTION to 3600.
Step 2: Prepare the Primary Database to Support a Logical Standby Database

(continued)
c. To transition the primary database to the logical standby role, you must modify the
initialization parameters on the primary database so that no parameters need to change
after a role transition.
Use the ALTER SYSTEM SET SCOPE=BOTH command to dynamically set the
LOG_ARCHIVE_DEST_n initialization parameters.
d. Set the UNDO_RETENTION initialization parameter to 3600. The
UNDO_RETENTION parameter specifies (in seconds) the amount of committed undo
information to retain in the database. The value of 3600 is recommended for best
results when building a LogMiner dictionary for the logical standby database.

Step 3: Prepare to Transition to a Logical
Standby Database
a. Ensure that supplemental logging is enabled on

the standby database.
b. Prepare an initialization parameter file for the
c. Shut down the logical standby database.
d. Create a control file for the logical standby
database.
e. Copy the control file to the logical standby
database system.
Step 3: Prepare to Transition to a Logical Standby Database

Use the following procedure to prepare to transition to a logical standby database:
a. Enabling supplemental logging on the logical standby database now rather than later is
beneficial to prepare the database for future role transitions. Perform the steps listed
earlier in this lesson for the primary database on the logical standby database.
b. Modify the LOG_ARCHIVE_DEST_n parameters and add the
PARALLEL_MAX_SERVERS parameter to the initialization parameter file (PFILE)
that you created for your physical standby database. You need to modify the
LOG_ARCHIVE_DEST_n parameters because logical standby databases are open
databases that generate redo data and have multiple log files (online redo log files,
archived redo log files, and standby redo log files). It is good practice to specify
separate local destinations for:
- Archived redo log files that store redo data that is generated by the logical
standby database
- Archived redo log files that store redo data that is received from the primary
database
Set PARALLEL_MAX_SERVERS to a minimum value of 9; do not set it to a value less
than 5.

Step 3: Prepare to Transition to a Logical Standby Database (continued)
c. Shut down the logical standby database by issuing the following command:
You mount the logical standby database using the new initialization parameter file
in a later step.
d. On the primary database system, issue the ALTER DATABASE CREATE LOGICAL
STANDBY CONTROLFILE statement to create a control file for the standby database
as shown in the following example. Be sure to include the LOGICAL keyword.
SQL> ALTER DATABASE CREATE LOGICAL STANDBY CONTROLFILE
2 AS '/tmp/site2.ctl';
e. Use an operating system copy utility to copy the standby control file from the primary
database system to the logical standby database system.

Step 4: Start the Logical Standby Database
a. Start and mount the logical standby database.

b. Prepare the logical standby database for SQL
Apply:
SQL> ALTER DATABASE RECOVER
2 MANAGED STANDBY DATABASE;
c. Activate the logical standby database:
SQL> ALTER DATABASE ACTIVATE

2 STANDBY DATABASE;
d. Reset the database name of the logical standby

database by using the DBNEWID utility.

Perform the following steps to start, mount, and activate the logical standby database and
SQL Apply.
a. On the logical standby database, issue the STARTUP MOUNT command to start the
instance and mount the database.
b. On the logical standby database, issue the following command to prepare it for SQL
Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
c. After the command issued in step (b) has completed execution, issue the following
command to activate the database as a logical standby database:
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
d. Shut down the instance, restart it, and mount the database in preparation for executing
the DBNEWID utility. Invoke the Oracle DBNEWID utility on the logical standby
database to change the database name and shut down the database as shown in the
following example:
nid TARGET=SYS/password@boston DBNAME=boston
Note: You must re-create the password file after running the Oracle DBNEWID (nid)
utility.

e. Change the logical standby database name in the

parameter file.
f. Change the logical standby database global name:
SQL> ALTER DATABASE RENAME GLOBAL_NAME TO

2 new_global_name;
g. Create a new temporary file for the logical standby

database.
h. Start SQL Apply:
SQL> ALTER DATABASE START
2 LOGICAL STANDBY APPLY;
Step 4: Start the Logical Standby Database (continued)

e. Modify the DB_NAME initialization parameter in the initialization parameter file.
Connect to an idle instance of the logical standby database. Then create a server
parameter file for the standby database from the text initialization parameter file, as in
the following example:
SQL> CREATE SPFILE FROM PFILE=initboston.ora;
Restart the logical standby database instance and open the logical standby database
with the RESETLOGS option.
f. Execute the following command to change the logical standby database global name:
SQL> ALTER DATABASE RENAME GLOBAL_NAME TO new_global_name;
g. Create new temporary files on the logical standby database as follows. First identify
tablespaces that contain temporary files:
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES
2 WHERE CONTENTS = 'TEMPORARY';
For each tablespace identified in the previous query, add a new temporary file to the
standby database with the ALTER TABLESPACE command.
h. Issue the following statement to begin applying redo data to the logical standby
database:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

Step 5: Verify That the Logical Standby
Database Is Performing Properly
a. Verify that the archived redo log files were

registered:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME,
2 DICT_BEGIN, DICT_END
3 FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
b. Begin sending redo data to the standby database:
c. Query the DBA_LOGSTDBY_LOG view to verify that

the archived redo log files were registered.
Step 5: Verify That the Logical Standby Database Is Performing Properly

After you create your logical standby database and set up log transport services and log
apply services, you should verify that redo data is being transmitted from the primary
database and applied to the standby database. Perform the following steps to verify that the
logical standby database is functioning properly:
a. Connect to the logical standby database and query the DBA_LOGSTDBY_LOG view to
verify that the archived redo log files were registered on the logical standby system:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN,
2 DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
b. Connect to the primary database and issue the following command to begin sending
redo data to the standby database:
c. Connect to the logical standby database and re-query the DBA_LOGSTDBY_LOG view
as shown in step a. This enables you to verify that the new archived redo log files were
registered.

Step 5: Verify That the Logical Standby
Database Is Performing Properly
d. Verify that redo data is being applied correctly:

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
2 WHERE NAME = 'coordinator state';
e. View the V$LOGSTDBY view to see current

SQL Apply activity:
SQL> SELECT TYPE, HIGH_SCN, STATUS
2 FROM V$LOGSTDBY;
f. Check the overall progress of SQL Apply:

SQL> SELECT APPLIED_SCN, NEWEST_SCN
2 FROM DBA_LOGSTDBY_PROGRESS;
Step 5: Verify That the Logical Standby Database Is Performing Properly

(continued)
d. On the logical standby database, query the V$LOGSTDBY_STATS view to verify that
redo data is being applied correctly:
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
2 WHERE NAME = 'coordinator state';
A value of INITIALIZING in the VALUE column indicates that log apply services
are preparing to begin SQL Apply, but data from the archived redo log files is not
being applied to the logical standby database.
e. Query the V$LOGSTDBY view on the logical standby database to see a current
snapshot of SQL Apply activity. A text message describing the current activity of each
process that is involved in reading and applying changes is displayed.
f. Query the DBA_LOGSTDBY_PROGRESS view on the logical standby database to
check the overall progress of SQL Apply:

Perform the following tasks as appropriate for your

configuration:
• Configure standby redo logs.
• Enable Flashback Database.
• Upgrade the data protection mode.

Perform the following tasks as appropriate for your logical standby database:
• Configure standby redo logs: Standby redo logs are required for standby databases
running in maximum protection mode and maximum availability mode. However,
configuring standby redo logs is recommended on all standby databases because,
during a failover, Data Guard can recover and apply more redo data from standby redo
log files than from the archived redo log files alone. The standby redo logs should exist
on both primary and standby databases and have the same size and names.
• Enable Flashback Database: Flashback Database eliminates the need to re-create the
primary database after a failover. Flashback Database is similar to conventional point-
in-time recovery in its effects, enabling you to return a database to its state at a time in
the recent past. Flashback Database is faster than point-in-time recovery because it
does not require restoring data files from backup or the extensive application of redo
data. You can enable Flashback Database on the primary database, the standby
database, or both.
• Upgrade the data protection mode: The Data Guard configuration is initially set up
in maximum performance mode (the default).

Summary
In this lesson, you should have learned how to use

SQL commands to create a logical standby database.

Switchover and Failover

Objectives

the following:
• Explain the database roles
• Perform a switchover
• Perform a failover
• Use Flashback Database after a failover

Types of Roles in an
Oracle Data Guard Configuration
There are two types of roles in an Oracle Data Guard

configuration:
• User role: Identifies the group and determines the
privileges that a user is assigned
• Database role: Identifies what role (primary or
standby) the database plays in a Data Guard
configuration
SQL> SELECT database_role FROM V$DATABASE;
DATABASE_ROLE
----------------
LOGICAL STANDBY
Types of Roles in an Oracle Data Guard Configuration

User roles are named groups of related privileges that you grant to users or other user roles.
User roles are designed to ease the administration of the end-user system and schema object
privileges.
Database roles identify what “part” the database is “playing” in the Data Guard
configuration. A database can be in one of two roles:
• Primary
• Standby
A database that is in the standby role is one of the following types:
• Physical standby
• Logical standby

Role Management Services
• A database operates in one of two mutually

exclusive roles in a Data Guard configuration:
– Primary role: The database is operating in the
primary role, and log transport services are
shipping redo to the standby databases.
– Standby role: The database is operating in the
standby role, and log apply services are applying
the archived redo logs to the standby database.
• With role management services, you can change
these roles dynamically.
Role Management Services

You can use role management services to change the primary and standby roles dynamically
as a planned transition called a switchover operation, or as a result of a database failure
through a failover operation.
For example, you might perform a switchover operation to transition the primary database to
the standby role and transition a standby database to the primary role to perform routine
maintenance tasks.

• Not automatically invoked

• Switchover
– Planned role reversal
– Used for OS or hardware maintenance
• Failover
– Unplanned role reversal
– Used in an emergency
– Minimal or no data loss depending on the
data protection mode

Switchover and failover operations are not invoked automatically. You must initiate
switchover or failover operations by using a SQL statement or by using the Data Guard GUI
or Data Guard broker command-line interface (CLI).
Switchover
You can use the switchover feature 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. There is no need to
re-create any of the databases in the switchover operation. There is no data divergence
between the original and the new primary database after the successful completion of the
database switchover.

Role Transitions: Switchover and Failover (continued)
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 incapacitated 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.
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.

Role Transition Decision Tree
Are you performing a planned role

Switchover to
transition so that you can perform
hardware or software maintenance
Yes best available
standby
on the system that currently hosts
database.
the primary database?
No
Can you run crash recovery to Repair
Yes
repair the primary database in primary
a timely manner? database.
No
Failover to best available
standby database.
Role Transition Decision Tree

The goal of a role transition (switchover or failover) is to bring the new primary database
online as quickly as possible with no data loss or with the least possible data loss. The
decision tree shown in the slide can help you choose the role transition operation that best
minimizes down time and the risk of data loss. In general, you should always consider
performing crash recovery to repair the primary database or performing a switchover before
you consider performing a failover.
Repairing the primary database may be faster than transitioning a standby database to the
primary role, even when you are using a no-data-loss environment. If you can repair the
primary database, you also do not have to reconfigure client applications to connect to a new
database. However, if the repair operation results in any data loss, you may need to re-create
all other standby databases in the configuration from a backup of the repaired primary
database.
In general, the best standby database to transition to is a physical standby database that has
the most redo applied to it.

Switchover
• Transitions the roles of the primary and standby

databases
• No resetting of the online redo logs of the new
primary database
• No data loss
Switchover
A switchover operation transitions the primary database to the standby role and transitions
the standby database to the primary role, without resetting the online redo logs of the new
primary database.
If the switchover operation involves a physical standby database, both the primary database
and the physical standby database that is switching over to the primary role must be shut
down and restarted. However, there is no need to shut down and restart any other standby
databases that are not participants in the switchover operation. If the switchover operation
involves a logical standby database, there is no need to shut down and restart either the
primary database or any of the standby databases. Logical standby databases do not need to
be shut down and restarted.

Switchover: Before
Read/write Primary
transactions database
Application
San Francisco Oracle Net

Boston
Standby Read-only
database reports
Application
Switchover: Before
For example, assume that the primary database is located in San Francisco and the physical
standby database is located in Boston. Switchovers are initiated only on the primary
database. They cannot be initiated from the standby database.

Switchover: After
Read-only Standby
reports database
Application
San Francisco Oracle Net

Boston
Primary Read/write
database transactions
Application
Switchover: After
After the switchover completes, each database has the role opposite to the one that it had
before the switchover. In our example, Boston is now the primary database and San
Francisco is the standby database.
Data Guard does not automatically switch over sessions from one database to the other, so
active sessions for each system need to reconnect.

Standby Redo Logs and Switchovers
Standby redo logs should be configured on the

primary database to ease switchovers.
Standby
Online redo redo
logs Redo logs
shipment
Primary Standby
database database
RFS
Standby
redo
logs
Standby Redo Logs and Switchovers

Standby redo log configuration should be identical on the primary database and on any
physical standby databases. Even though the standby redo logs are not used when the
database is in the primary role, configuring the standby redo logs on the primary database is
recommended in preparation for an eventual switchover operation.

Preparing for a Switchover
Verify the following in preparation for the switchover

operation:
• Network connectivity between the primary and
standby locations
• Standby database that will become the new
primary database must be in ARCHIVELOG mode.
Preparing for a Switchover

Each location in the Data Guard configuration should have connectivity through Oracle Net
to the primary database and to all associated standby databases.
The database that you are planning to switch over to must be in ARCHIVELOG mode.
However, to give yourself the full benefit of your configuration, it is best to have all standby
databases configured in ARCHIVELOG mode. You then have the option of using all of your
standby databases when you want to perform a switchover.

Performing a Switchover
Select the database and

click Switchover.
Performing a Switchover with Enterprise Manager

The following tasks are performed when Enterprise Manager is used for the switchover:
a. A check is made to ensure that the primary database and standby database are not
currently in an error status condition and that broker management of the primary
database is enabled and online.
b. Any active sessions connected to the primary database are automatically closed during
the switchover.
c. The primary database is first changed to the standby role, and then the standby
database is changed to the primary role.
d. If the switchover target is a physical standby database, the target and primary
databases are each restarted.
To initiate a switchover by using Enterprise Manager:
1. On the Data Guard page, select the standby database that you want to become the
primary database.
2. Click Switchover.

Click Yes to confirm.
Performing a Switchover Using Enterprise Manager (continued)

3. The Data Guard Switchover Confirmation page appears.
4. You can view active sessions by clicking the Browse Primary Database Sessions link.
5. Click Yes to continue with the switchover, or click No to cancel.
You cannot cancel the switchover operation after it has begun.

Performing a Switchover Using Enterprise Manager (continued)

The Data Guard Switchover processing page displays the progress of the switchover
operation as it performs the following steps:
• Switch roles between the primary and standby databases. If the switchover target is a
physical standby database, it is restarted along with the primary database.
• Wait for the Data Guard broker to complete the initialization tasks required to switch
the database roles.
You can view the database alert log of the primary and standby databases by clicking the
respective “View alert log” links. A new browser window opens with the content of the alert
log.
After the switchover operation is complete, you are returned to the Data Guard page.

to a Physical Standby by Using SQL
Perform these steps only if you are not using the

Data Guard broker.
On the original primary database:
1. Verify that it is possible to perform a switchover
operation.
2. Initiate the switchover operation on the primary
database:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO
2 PHYSICAL STANDBY;
3. Shut down and restart the instance.
Performing a Switchover to a Physical Standby by Using SQL

You can perform a switchover using SQL, as described in the following steps. You should
not execute these steps when managing your configuration with the Data Guard broker.
Consider using the Data Guard broker to automate and simplify the switchover procedure.
Execute steps 1 through 3 on the original primary database:
1. Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary
database to verify that it is possible to perform a switchover operation.
A TO STANDBY value in the SWITCHOVER_STATUS column indicates that it is
possible to switch the primary database to the standby role.
2. To transition the primary database to a physical standby database role, execute the
following SQL statement:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO
2 PHYSICAL STANDBY WITH SESSION SHUTDOWN WAIT;
The WAIT option specifies that control is not returned to you until the statement
completes.
3. Shut down the instance and restart it without mounting the database:
SQL> STARTUP NOMOUNT;

to a Physical Standby by Using SQL
On the original physical standby database:

4. Verify the switchover status in the V$DATABASE
view.
5. Switch the physical standby database role to the
primary role.
6. Shut down and restart the new primary database.
7. Begin archiving logs to the physical standby
database.
Performing a Switchover to a Physical Standby by Using SQL (continued)

Execute steps 4 through 7 on the original standby database:
4. After you switch the primary database to the standby role and the switchover
notification has been received by the standby database, you should verify that the
switchover notification has been processed by the standby database by querying the
SWITCHOVER_STATUS column of the V$DATABASE fixed view on the standby
database. You should see a value of TO_PRIMARY.
5. Execute the following SQL statement on the physical standby database that you want
to switch to the primary role:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SQL> SHUTDOWN;
SQL> STARTUP;
The selected physical standby database is now transitioned to the primary database
role. There is no need to shut down and restart any other standby databases that were
online at the time of the switchover operation.
7. Issue the following statement on the new primary database to start redo transport:
SQL> ALTER SYSTEM SWITCH LOGFILE;

to a Logical Standby by Using SQL

1. Verify that it is possible to perform a switchover.
2. Prepare the primary database for the switchover:
SQL> ALTER DATABASE PREPARE TO SWITCHOVER
2 TO LOGICAL STANDBY;
Performing a Switchover to a Logical Standby by Using SQL

When you perform a switchover that changes roles between a primary database and a logical
standby database, you must always initiate the switchover on the primary database and
complete it on the logical standby database.
Perform steps 1 and 2 on the original primary database:
1. Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary
database to verify that it is possible to perform a switchover operation.
A TO STANDBY or SESSIONS ACTIVE value in the SWITCHOVER_STATUS
column indicates that it is possible to switch the primary database to the standby role.
2. Issue the following SQL statement to prepare the current primary database for a logical
standby database role:
This statement notifies the current primary database that it will soon switch to the
logical standby role and begin receiving redo data from a new primary database.

On the original logical standby database:

3. Prepare the logical standby database for
switchover:
2 TO PRIMARY;
Performing a Switchover to a Logical Standby by Using SQL (continued)

Perform step 3 on the logical standby database:
3. Issue the following statement to build a LogMiner dictionary on the logical standby
database that is the target of the switchover:
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
This statement also starts log transport services on the logical standby database to begin
transmitting its redo data to the current primary database and to other standby databases in
the Data Guard configuration. The sites receiving redo data from this logical standby
database accept the redo data, but they do not apply it.


4. Verify the switchover status in V$DATABASE.
5. Switch the primary database to the logical standby
database role:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER

Perform steps 4 and 5 on the original primary database:
4. Verify that the LogMiner dictionary was received by the primary database by querying
the SWITCHOVER_STATUS column of V$DATABASE on the primary database.
When the query returns TO LOGICAL STANDBY in the SWITCHOVER_STATUS
column, proceed with step 5.
5. Issue the following SQL statement to transition the primary database to a logical
standby database role:
This statement waits for all current transactions on the primary database to end and
prevents any new users from starting new transactions. It also puts a marker in the redo
data to provide a synchronization point for logical standby database operations.
Executing this statement also prevents users from making any changes to the data
being maintained in the logical standby database. To ensure faster execution, ensure
that the primary database is in a quiet state with no update activity before issuing the
switchover statement. You can query V$TRANSACTIONS for the status of any current
in-progress transactions that could delay execution of this statement.

On the new primary database (original logical standby

database):
6. Verify the switchover status in V$DATABASE.
7. Switch the logical standby database to the primary
database role.
2 TO PRIMARY;
8. Ensure that all standby databases begin receiving
redo data.

Perform steps 6, 7, and 8 on the new primary database (original logical standby database):
6. Verify that the switchover notification was processed by the target standby database by
querying the SWITCHOVER_STATUS column of the V$DATABASE fixed view on the
target standby database. The SWITCHOVER_STATUS value is updated to show
progress during the switchover. When the status is TO PRIMARY, proceed with step 7.
7. Issue the following SQL statement to switch the logical standby database to the
primary role:
8. Issue the following statement to perform a log switch and to ensure that all logical
standby databases begin receiving redo data from the new primary database:

On the new logical standby database:

9. Start SQL Apply.
SQL> ALTER DATABASE
2 START LOGICAL STANDBY APPLY;

Perform step 9 on the new logical standby database:
9. Issue the following statement to start SQL Apply:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

Considerations When Performing a
Switchover to a Logical Standby Database
• Switchover operation does not cause a shutdown

of the primary.
• There is no need to terminate user sessions, but
termination is recommended.
• Logical standby database may not have all data.
• If you do switch over to a logical standby, all
physical standbys are permanently disabled.
Considerations When Performing a Switchover to a Logical Standby Database

Consider the following when performing a switchover to a logical standby database:
• Unlike a switchover to a physical standby database, a switchover to a logical standby
database does note require a shutdown of the primary database.
• If you are switching over to a logical standby database, you do not need to terminate
applications that are connected to the current primary database or to the logical
standby database, because neither database is shut down during the switchover
operation. However, because sessions on the old primary database may fail after the
switchover operation completes and the database guard is turned on, you should
terminate such open sessions now. The database guard prevents users from making
changes in the logical standby database.
• If you switch over to a logical standby database, there may be a loss of data if the
logical standby database contains only a subset of the data that is present in the
primary database.

Considerations When Performing a Switchover to a Logical Standby Database
(continued)
• When you perform a switchover to a logical standby database, any physical standby
databases in the configuration are permanently disabled after the switchover and are no
longer usable. The physical standby databases must be re-created from a copy of the
new primary database to continue to participate in the Data Guard configuration after
the role transition.

Situations That Prevent a Switchover
You cannot perform a switchover In the following

situations:
• Archived redo log files are unavailable.
• Point-in-time recovery is required.
• Production database is not open and cannot be
opened.
Situations That Prevent a Switchover

The following situations prevent the execution of a switchover operation:
• Archived redo log files are unavailable: If there is a gap in the archived redo log
files on the standby database, you are not able to switch over to that standby database.
• Point-in-time recovery is required: When you perform a switchover to a standby
database, you always switch over to the current state of the primary database. You
cannot switch over to a time in the past.
• Production database is not open and cannot be opened: A switchover is initiated on
the primary database while it is in the open state. If you cannot open the primary
database, a switchover is not possible.

Failover
Local
Archiving
Primary Online Redo Archived redo

database Logs logs
San Francisco
Application
Boston
Read/write Local
transactions archiving
Standby Online redo Archived redo

database becomes logs logs
primary 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 primary database is removed from the Data Guard environment and a
standby database assumes the primary database role. Failing over to a standby database is a
permanent operation. You cannot undo the failover and return the database to its former role
as a standby database. Because of this, you should invoke a failover operation only in an
emergency.
It is not always necessary to fail over to the standby database. In some cases, recovery of the
primary database may be faster. Most failures can be resolved at a primary database within a
reasonable amount of time.
In a failover operation:
• The original primary database is presumed to be lost. You must re-create (or flash
back) the original primary database as a new standby database, if desired.
• Standby databases that are online at the time of the failover operation, but are not
involved in the role transition, do not need to be shut down and restarted.

Failover Considerations
• Old primary database is no longer part of the

configuration.
• Data loss is possible.
• Failover should be used only in an emergency.
• Special-case failover: activation of a standby
Failover Considerations
During a failover operation, a standby database transitions to the primary role and the old
primary database is rendered unable to participate in the configuration. Depending on the
protection mode under which the old primary database was operating before the failover,
there may be no or some data loss during a failover. A failover is typically used only when a
primary database becomes incapacitated and there is no possibility of performing a
switchover or successfully repairing the primary database within a reasonable amount of
time. The specific actions that are performed during a failover vary depending on whether a
logical or physical standby database is involved in the failover operation, the state of the
configuration at the time of the failover, and the specific SQL commands that are used to
initiate the failover.
There is also a special-case failover in which the standby database is activated. This should
be avoided unless absolutely necessary because it causes all other databases in the
configuration to become permanently disabled.

Performing a Failover
Select the database and

click Failover.
Performing a Failover with Enterprise Manager

You should perform a failover only in the event of a software or system failure that results in
the loss of the primary database. The failed primary database is disabled by the broker and
must be re-created. The standby database then assumes the primary database role.
To initiate a failover by using Enterprise Manager:
1. On the Data Guard page, select the standby database that you want to become the
primary database.
2. Click Failover.

Select the failover type and

click Yes.
Performing a Failover with Enterprise Manager (continued)

3. On the Data Guard Failover Confirmation page, you must specify the type of failover
that you want to perform:
- Complete: All available redo is applied on the standby database. Oracle
Corporation recommends that you specify this type of failover.
- Immediate: No additional data is applied on the standby database. This is the
fastest type of failover.
4. Select the failover option, and then click Yes to confirm the failover operation.

Performing a Failover with Enterprise Manager (continued)

After you click Yes, the Failover Progress page shows you the progress of the failover
operation.
You cannot cancel this operation after it begins.

to a Physical Standby Database
The physical standby

database is disabled.
Performing a Failover to a Physical Standby Database

During the failover operation, the selected standby database transitions into the primary role.
If the failover target is a physical standby database, it is restarted. If you are failing over to a
logical standby database, it is not restarted. When the operation is completed, the Data
Guard Overview page reflects the updated configuration.
Note: After a complete or immediate failover, the primary database and some standby
databases may need to be re-created.

to a Logical Standby Database
The logical standby database

is now the primary database.
The physical standby
database is disabled.
Performing a Failover to a Logical Standby Database

When you perform a failover to a logical standby database, any physical standby databases
in the configuration are permanently disabled after the failover and are longer usable. These
databases must be re-created from the new primary database.

Performing a Failover to a
Physical Standby Database by Using SQL
1. Identify and resolve any gaps in the archived redo

log files.
2. Repeat step 1 until all gaps are resolved.
3. Copy any other missing archived redo log files.
4. Initiate the failover operation on the target standby
database.
5. Convert the physical standby database to the
primary role.
7. (Optional) Back up the new primary database.
8. (Optional) Restore the failed primary database.
Performing a Failover to a Physical Standby Database by Using SQL

Perform the following steps to fail over to a physical standby database by using SQL.
Note: If the target standby database was operating in maximum protection mode, no gaps in
the archived redo log files should exist, and you can proceed directly to step 4. Otherwise,
begin with step 1 to determine if any manual gap resolution steps must be performed.
1. To determine if there are gaps in the archived redo log files on the target standby
database, query the V$ARCHIVE_GAP view. This view contains the sequence
numbers of the archived redo log files that are known to be missing for each thread.
The data returned reflects the highest gap only.
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE#
2 FROM V$ARCHIVE_GAP;
If possible, copy all of the identified missing archived redo log files to the target
standby database from the primary database and register them. Execute the following
command to register the redo log files:
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
Perform this step for each thread.
2. Repeat step 1 until all gaps are resolved. The query that is executed in step 1 displays
information for the highest gap only. Repeat step 1 until the query returns no rows.

(continued)
3. To determine if there are any other missing archived redo log files, query the
V$ARCHIVED_LOG view on the target standby database to obtain the highest
sequence number for each thread.
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#)
2 OVER (PARTITION BY thread#)
3 AS LAST from V$ARCHIVED_LOG;
Copy to the target standby database any available primary database archived redo log
files that contain sequence numbers higher than the highest sequence number that is
available on the target standby database. Then register those redo log files by issuing
the following SQL statement:
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
Perform this step for each thread.
After registering all available archived redo log files, query the V$ARCHIVE_GAP
view (as described in step 1) to verify that no additional gaps were introduced in step
3.
4. If the target physical standby database has standby redo log files configured, execute
the following SQL statement to initiate the failover:
SQL> ALTER DATABASE RECOVER
2 MANAGED STANDBY DATABASE FINISH;
If the target physical standby database does not have standby redo log files configured,
include the FINISH SKIP STANDBY LOGFILE clause as follows:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2 FINISH SKIP STANDBY LOGFILE;
5. Transition the physical standby database to the primary database role by issuing the
following SQL statement:
After issuing this SQL statement, you can no longer use this database as a standby
database. Any subsequent redo that is received from the original primary database
cannot be applied. During the failover process, the standby redo log files are
automatically archived and recovered on all other standby databases that are derived
from the original primary database if the standby destinations are correctly defined on
the new primary database.
Perform step 6 on the new primary database.
6. To complete the failover, you need to shut down the new primary database and restart
it in read/write mode using the initialization parameter file or server parameter file for
the primary role:
SQL> STARTUP;
7. Perform an open backup of the database after issuing the STARTUP statement.
Although performing a backup immediately is not required, it is recommended because
you cannot recover changes that are made after the failover without a complete backup
copy of the database.

(continued)
8. After a failover, the original primary database no longer participates in the
configuration. After performing a failover, you may be able to optionally restore the
failed primary database as a new standby database using either of the following
methods:
- Use Flashback Database to restore the failed primary database to a point in time
before the failover occurred, and then convert it into a standby database
- Re-create the failed database and add it to the configuration as a new standby
database. To reuse the old primary database in the new configuration, you must
re-create it as a standby database using a backup copy of the new primary
database.
After the failed primary database is restored and is operating in the standby role,
you can optionally perform a switchover to transition the databases to their original
(pre-failure) roles.

Logical Standby Database by Using SQL
1. Copy redo logs to the logical standby database.

2. Register the missing redo logs:
SQL> ALTER DATABASE REGISTER LOGICAL
2 LOGFILE 'filespec';
3. If it exists, register the partially filled archive log

file.
4. Ensure that all redo log files have been applied to
the new primary database.
Performing a Failover to a Logical Standby Database by Using SQL

To perform failover for logical standby databases using SQL:
1. If redo logs exist on the primary database that have not yet been applied on the logical
standby database, manually copy the redo logs to that standby database.
2. You must register the redo log files that you manually copied from the original
primary database. Issue the following SQL statement for each missing redo log file on
the logical standby:
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 'filespec';
3. On the logical standby database, check to see if there is a partially written archived log
file. If it exists, this file has a sequence number that is one greater than the last
registered archived log file. If it exists, register the partially filled archived log file.
4. On the new primary database, ensure that the remaining redo logs have been applied
by checking the DBA_LOGSTDBY_PROGRESS view. When the values in the
APPLIED_SCN and NEWEST_SCN columns are equal, all available redo has been
applied. The logical standby database now contains as much data as possible from the
primary database. Issue the following query:

Logical Standby Database by Using SQL
5. Activate the new primary database:

SQL> ALTER DATABASE STOP
2 LOGICAL STANDBY APPLY;
2 LOGICAL STANDBY DATABASE;
6. Enable archiving of redo logs.
7. Begin SQL Apply operations on all logical standby
databases:
SQL> ALTER DATABASE START LOGICAL STANDBY
2 APPLY NEW PRIMARY dblink;
Performing a Failover to a Logical Standby Database by Using SQL (continued)

5. To stop SQL Apply operations and activate the database in the primary database role,
issue the following statements on the logical standby database that you are
transitioning to the new primary role:
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;
6. Enable archiving of redo logs to all remote logical standby destinations, as in the
following example:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
In general, when the database operates in the primary role, you must enable archiving
of redo logs to remote destinations. When the database operates in the standby role,
you must disable archiving of redo logs to remote destinations..
7. Issue the following command to begin SQL Apply operations on all logical standby
databases in the configuration:
SQL> ALTER DATABASE START LOGICAL STANDBY
2 APPLY NEW PRIMARY dblink;
Note: Any logical standby databases that are more current (have applied more redo
operations) than the standby database to which the primary database has failed over to must
be re-created from a backup of the new primary database and added back to the
configuration.

Activating a Standby Database
When you are unable to fail over, you can activate a

standby database by issuing one of the following
commands (depending on the role of the database):

2 PHYSICAL STANDBY DATABASE;

2 LOGICAL STANDBY DATABASE;
Activating a Standby Database

You can use the ALTER DATABASE ACTIVATE STANDBY DATABASE command to force
the standby database into the primary role. Specify the appropriate option, PHYSICAL or
LOGICAL, for the type of database that you are activating. You can issue this command in
a situation in which you cannot perform a failover operation.
Note: You cannot perform an activation operation to a physical standby database on which
standby redo logs are present unless you indicate that it is acceptable to skip applying the
contents of the standby redo log with the FINISH SKIP STANDBY LOGFILE keywords on
the RECOVER MANAGED STANDBY DATABASE statement.

Using Flashback Database After Failover
Primary Standby
database database
Redo
Flashback Failover
Redo
New standby database New primary database
Using Flashback Database After 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. After a
failover operation, the old standby database becomes the new primary database, and the old
primary database is removed from the Data Guard configuration.
You can use the Flashback Database feature to convert the old primary database into a new
standby database without re-creating the database. You can flash back the old primary
database so that it contains only those changes that are already applied to the old standby
database. This enables you to convert the old primary database into a new standby database
without restoring the old primary database.
Note: You must have the Flashback Database feature enabled on the old primary database.

Using Flashback Database After Failover (continued)
Physical Standby Configuration
In a physical standby configuration, use the following procedure to avoid reinstantiating the
old primary database after a failover:
1. On the new primary database, issue the following query to determine the system
change number (SCN) at which the old standby database became the new primary
database:
SELECT standby_became_primary_scn FROM v$database;
2. After the old primary database site is available, mount the old primary database.
3. Flash back the old primary database to the “standby became primary” SCN that you
determined in step 1:
FLASHBACK DATABASE TO SCN <SCN>;
4. Disable Flashback Database on the old primary database by issuing the following
command:
ALTER DATABASE FLASHBACK OFF;
5. On the old primary database, create a new standby database control file.
6. Shut down the old primary instance.
7. On the old primary database, replace the existing control file with the new standby
control file.
8. Mount the old primary database. The old primary database is now your new standby
database. Also verify that the listener is running:
STARTUP MOUNT;
lsnrctl status listener_name
9. On the new standby, enable Flashback Database:
ALTER DATABASE FLASHBACK ON;
10. On the new primary database, enable log transport to the old primary (new standby).
Check the status of the archive destinations and enable any that are not enabled. Then
archive a new log to the new standby by issuing the following command:
SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE,
DESTINATION, ERROR, SRL FROM V$ARCHIVE_DEST_STATUS;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
ALTER SYSTEM ARCHIVE LOG CURRENT;
11. On the new standby, start managed standby recovery. The role reversal is now
complete:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT;
If you are using real-time apply:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING
CURRENT LOGFILE DISCONNECT;

Using Flashback Database After Failover (continued)
Logical Standby Configuration
In a logical standby configuration, use the following procedure to avoid reinstantiating the
old primary database after a failover:
1. On the new primary database, issue the following query to determine the SCN at which
the old standby database became the new primary database:
SELECT value AS standby_became_primary_scn
FROM dba_logstdby_parameters
WHERE name = 'END_PRIMARY_SCN';
2. After the old primary database site is available, mount the old primary database.
3. Flash back the old primary database to the “standby became primary” SCN that you
determined in step 1:
FLASHBACK DATABASE TO SCN <SCN>;
4. Enable the Data Guard guard to prevent the job queue from executing:
ALTER DATABASE GUARD ALL;
5. Open the database with the RESETLOGS option:
ALTER DATABASE OPEN RESETLOGS;
6. Create a database link to the new primary database, and then start SQL Apply:
CREATE PUBLIC DATABASE LINK mylink CONNECT TO system
IDENTIFIED BY password USING
'service_name_of_new_primary_database';
ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY
mylink;

Summary

• Use the Data Guard GUI to perform switchover and
failover operations
• Use SQL commands to perform switchover and
failover operations
• Use Flashback Database after a failover


• Performing a switchover
• Performing a failover

Using Data Guard with RAC

Objectives
After completing this lesson, you should be able to

deploy Data Guard in a Real Application Clusters
environment.

Real Application Clusters and Data Guard
Possible combinations of instances in the primary and

standby databases:
Primary Single-Instance Multi-Instance

Instance Standby Database Standby Database
Single-Instance Yes Yes
Multi-Instance Yes Yes
Real Application Clusters and Data Guard

You can configure your Real Application Clusters (RAC) environment to switch over to
another RAC environment or a single-instance environment.
If you configure switchover to another RAC environment, each node in the RAC ships its
redo information to a corresponding RAC node. The shipping and receiving of the redo
information are spread across the nodes of the RAC. The apply services are performed on
one node in the RAC. After switchover or failover, your application is in a RAC, which
should give the same performance as the previous configuration.
If you configure switchover to a single instance, performance can be impeded because one
system has to receive and apply all logs from all members of the RAC. Also, switchover and
failover to a smaller system do not allow your application to perform as in the original
configuration. If you are sending redo to a single-instance standby, be sure to configure the
number of standby redo logs on the standby database to be equal to the total number of
online redo logs in all the instances of the RAC system.

Configuration Considerations with RAC
• Format for archived redo log file names: Thread

variable (%t or %T) of LOG_ARCHIVE_FORMAT is
mandatory.
• Archive destination quotas: Use the QUOTA_SIZE
attribute of the LOG_ARCHIVE_DEST_n parameter.
• Data protection modes: Maximum protection or
maximum availability mode; all instances could
stop shipping redo.
Configuration Considerations with RAC

Format for archived redo log file names: The thread variable (%t or %T) in the
LOG_ARCHIVE_FORMAT parameter is mandatory for Real Application Clusters to
uniquely identify the archived redo log files.
Archive destination quotas: You can specify the amount of physical storage on a disk
device to be available for an archiving destination using the QUOTA_SIZE attribute of the
LOG_ARCHIVE_ DEST_n initialization parameter. An archive destination can be
designated as being able to occupy all or some portion of the physical disk that is
represented by the destination.
For example, a physical disk device can be shared by two or more separate nodes in a Real
Application Clusters environment. Because there is no cross-instance initialization
parameter knowledge, none of the Real Application Clusters nodes are aware that the
physical disk device is shared with other instances. This leads to substantial problems when
the destination disk device becomes full; the error is not detected until every instance tries to
archive to the already-full device. This affects database availability.

Configuration Considerations with RAC (continued)
Data protection modes: In a RAC configuration that is configured for maximum protection
or maximum availability mode, any instance that loses connectivity with a standby
destination causes all other instances to stop sending data to that destination. This action
maintains the data integrity of the data that has been transmitted to that destination and can
be recovered.
When the failed standby destination comes back up, Data Guard runs the site in
resynchronization mode until no gaps remain. Then, the standby destination can participate
in the Data Guard configuration again.

Multi-Instance Primary with a
Single-Instance Standby
Multi-Instance Primary with a Single-Instance Standby

You can create a single-instance standby database by using either SQL commands or
Enterprise Manager.
Each instance of the primary database sends redo to the one instance of the standby. The
standby database automatically determines the correct order in which to apply the archived
redo log files.

Multi-Instance Primary with a
Multi-Instance Standby
Multi-Instance Primary with a Multi-Instance Standby

Although the Add Standby Database Wizard does not create a RAC standby database, you
can use it to add an existing RAC standby database to a Data Guard configuration. Click
Add Standby Database to invoke the Add Standby Database Wizard, and then select “Add
an existing standby database.”
The Data Guard broker also has the ability to dynamically discover instances of a database
and add them to a database profile without user intervention. After they are added, the
broker can manage these instances when it comes to conducting state changes, role changes,
and so on. If a new primary instance is added, the broker automatically enables the log
transport service on that instance and gets that instance to ship its redo to the configured set
of standbys. During role changes and protection mode upgrades, the broker also manages the
instance restarts because it is integrated with the RAC Cluster Ready Services (CRS).

Log Transport with RAC to RAC
Primary instance A Standby instance C

Archived logs
LGWR
Standby Physical
redo standby
files database
Online
redo
Primary files
database
LGWR RFS ARCn
Archived
Archived logs logs MRP
Primary instance B Standby recovery instance D
Log Transport with RAC to RAC

The best practice is to send all redo to the recovery instance on the standby RAC.
When both the primary and standby databases are in a Real Application Clusters
configuration, then a single instance of the standby database applies all sets of log files that
are transmitted by the primary instances. In this case, the standby instances that are not
applying redo data cannot be in read-only mode while Redo Apply is in progress.

Setting Up a Primary Database with RAC
Primary instance A
Archived logs
LGWR
Online
redo
Primary files
database
LGWR
Archived logs
Primary instance B
Setting Up a Primary Database with RAC

To configure log transport services on the primary database:
1. On all instances, define the LGWR attribute for the LOG_ARCHIVE_DEST_n
parameter to specify that the LGWR process performs the archival operation.
2. Configure each standby instance to send redo data to the recovery instance by setting
the LOG_ARCHIVE_DEST_n parameter to an appropriate value.

Setting Up a Standby Database with RAC
Standby instance C
Standby Physical
redo standby
files database
RFS ARCn
Archived
logs MRP
Standby recovery instance D
Setting Up a Standby Database with RAC

To configure log transport services on the standby database:
1. Create the standby redo log files.
In a Real Application Clusters environment, the standby redo log files must reside on
disk devices that are shared by all instances.
2. On the recovery instance, define the LOCATION attribute of the
LOG_ARCHIVE_DEST_1 initialization parameter to archive locally.
3. Start log apply services on the recovery instance.

Assigning Threads to
Standby Redo Log Groups
Standby
database
Primary Standby
database redo logs
SQL> ALTER DATABASE ADD STANDBY LOGFILE

2 THREAD 1 'STBY_LOGFILE_1.SRL' SIZE 50M;
Assigning Threads to Standby Redo Log Groups

Use the THREAD n clause in the ALTER DATABASE ADD STANDBY LOGFILE statement
to assign a standby redo log group to a specific thread. With this clause, you can balance the
use of standby redo log groups across all threads. The THREAD n syntax is optional. If the
syntax is omitted, Data Guard automatically assigns the standby redo log to a thread at run
time. This is applicable only if you are using the RAC.
Because standby redo log groups are now assigned to a given thread, you may need more
standby redo log groups. This is because there is no longer a pool of files available for any
thread. If you have threads that generate more redo then others, assign more standby redo
log groups to that thread. It is usually sufficient to assign one or two more than there are
online log files.

Apply Instance Failover
• If the apply instance fails, transport of redo is also
halted by default.
• Broker configuration:
– Set ApplyInstanceTimeout to avoid down time.
– Default is 120 seconds.
– Set to 0 (zero) to disable.
– Optionally set PreferredApplyInstance.
• Non-broker configuration: Set up a list of
destination connect identifiers.
Apply Instance Failover

When the apply instance fails, not only does log apply services stop applying log files to the
standby database, but log transport services stop transmitting redo data to the standby
database. To tolerate a failure of the apply instance, the broker leverages the availability of
the RAC standby database by automatically failing over log apply services to a different
standby instance.
To set up apply instance failover in a Data Guard broker–controlled configuration, set the
ApplyInstanceTimeout property to specify the time period that the broker should wait
after detecting an apply instance failure and before initiating an apply instance failover. To
select an appropriate timeout value, you must consider:
• If there is another mechanism in the cluster that will try to recover the failed apply
instance
• How long the primary database can tolerate not transmitting redo data to the standby
database
• The overhead that is associated with moving the log apply services to a different
instance. The overhead may include retransmitting (from the primary database) all log
files that have accumulated on the failed apply instance that have not been applied if
those log files are not saved in a shared file system that can be accessed from other
standby instances.

Apply Instance Failover (continued)
You can also set the the PreferredApplyInstance property of Data Guard broker
to indicate which instance should take over this task if the current apply instance fails. If
PreferredApplyInstance is not set, the broker picks a random instance that is
currently running to be the new apply instance.
If the Data Guard broker is not enabled for your configuration, Oracle’s high availability
best practices recommend setting up a list of destination connect identifiers in the
tnsnames.ora file on the primary, as in the following example:
CHICAGO=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=chicago_n1-
server)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=chicago_n2-
server)(PORT=1521)))
(CONNECT_DATA=
(SERVICE_NAME=CHICAGO)))
In this case, LGWR chooses the next entry in the list to send redo data to, after a timeout
period that is specified in the NET_TIMEOUT attribute of the log_archive_dest_n
parameter (if NET_TIMEOUT is not specified, it waits until the system’s TCP/IP
timeout). However, the apply process (Redo Apply or SQL Apply) would need to be
manually started in the new instance with SQL*Plus.
The primary instance of the standby cluster will be brought down to ensure no data loss if
all of the following are true:
• A connection list is not specified.
• The Data Guard broker is not enabled for the configuration.
• The apply instance for the last standby fails.
• The LGWR process times out.

Role Transitions with RAC
• Switchovers: Only one primary instance and one

standby instance can be active during a
switchover.
• Failovers: Before performing a failover to a RAC
standby database, you should shut down all but
one standby instance.
Role Transitions with RAC

Switchovers: For a RAC database, only one primary instance and one standby instance can
be active during a switchover. Before a switchover, therefore, you should shut down all but
one primary instance and one standby instance. After the switchover completes, restart the
primary and standby instances that you shut down during the switchover.
Note: The ALTER DATABASE statement that is used to perform the switchover
automatically creates redo log files if they do not already exist. Because this can
significantly increase the time that is required to complete the COMMIT operation, Oracle
Corporation recommends that you always manually add redo log files when configuring raw
devices for physical standby databases.
Failovers: Before performing a failover to a RAC standby database, shut down all but one
standby instance. After the failover completes, restart the instances that were shut down.

Troubleshooting
• Switchover failure
• Avoiding down time during a network outage
Troubleshooting
Switchover failure: When your database is using RAC, active instances prevent a
switchover from being performed. When other instances are active, an attempt to switch
over fails and the following error message appears:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY *
ORA-01105: mount is incompatible with mounts by other
instances
Query the GV$INSTANCE view to determine which instances
are causing the problem:
SQL> SELECT INSTANCE_NAME, HOST_NAME FROM GV$INSTANCE
2 WHERE INST_ID <>
3 (SELECT INSTANCE_NUMBER FROM V$INSTANCE);
INSTANCE_NAME HOST_NAME
------------- ---------
INST2 standby2
Connect to this instance and shut it down.

Troubleshooting (continued)
Avoiding down time: If you configured Data Guard to support a primary database in a RAC
environment and the primary database is running in maximum protection mode, a network
outage between the primary database and all of its standby databases will disable the
primary database until the network connection is restored. The maximum protection mode
dictates that if the last participating standby database becomes unavailable, processing halts
on the primary database.
If you expect the network to be down for an extended period of time, consider changing the
primary database to operate in either maximum availability or maximum performance mode
until network connectivity is restored. If you change the primary database to maximum
availability mode, it is possible for there to be a lag between the primary and standby
databases, but you gain the ability to use the primary database until the network problem is
resolved.
If you choose to change the primary database to maximum availability mode, it is important
to use the following procedures to prevent damage to your data.
The following steps describe what to do if the network goes down and you want to change
the protection mode for the RAC configuration. The example assumes that you are using a
server parameter file (SPFILE) rather than a text initialization parameter file (PFILE).
1. At this point, all RAC primary instances are shut down. Issue the STARTUP MOUNT
command to start one instance:
STARTUP MOUNT;
2. Change the mode from maximum protection to either maximum availability or
maximum performance. For example, the following statement sets the maximum
availability protection mode:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE
AVAILABILITY;
3. Open the RAC primary database for general access.
When the network comes back up later, perform the following steps to revert to maximum
protection mode:
1. Shut down all instances of the RAC primary database.
2. Mount a single instance of the RAC primary database without opening it for general
access.
3. Change the mode on the RAC primary database from its current mode (maximum
availability or maximum performance) to maximum protection mode.
4. Open the RAC primary database for general access.

Summary
In this lesson, you should have learned how to

deploy Data Guard in a Real Application Clusters
environment.

Other Considerations for
Oracle Data Guard

Objectives

the following:
• Back up the primary database with a physical
standby database
• Back up a logical standby database
• Use Flashback Database features in a Data Guard
configuration
• Encrypt redo information
• Configure cascaded redo log destinations

Offloading Backups to a Physical Standby
• Backups of data files and archived redo logs are

fully interchangeable.
• Control file backups are not interchangeable.
• Primary and standby databases must use the
same recovery catalog.
• It is not necessary to register the standby
database.
Offloading Backups to a Physical Standby

Recovery Manager (RMAN) can back up the standby database and its associated archived
redo logs. Standby backups of data files and archived redo logs are fully interchangeable
with primary database backups. In other words, you can execute the RESTORE command to
restore a backup of a standby data file to the primary database, and you can restore a backup
of a primary data file to the standby database. The standby control file and primary control
file, however, are not interchangeable.
Both the primary database and standby database must use the same recovery catalog. Note
that you do not need to register the standby database in the catalog if the primary is already
registered; simply connect to the standby database and execute the BACKUP command.

Backing Up a Physical Standby Database
with RMAN
1. Invoke RMAN.
2. Allocate channels if needed.
3. Issue the BACKUP command.
4. Use the LIST command to verify the backup.
Backing Up a Physical Standby Database with RMAN

Use the RMAN BACKUP command to back up the standby database. Performing a backup
on the standby database is exactly the same as a backup of the primary database, except that
the backup takes place on the standby site.

Restrictions and Usage Notes
• The database you are backing up must be a

physical standby database.
• You must be connected to the recovery catalog
when backing up.
• You cannot back up the standby control file.
• You must connect to the physical standby
database with the TARGET keyword.
Restrictions and Usage Notes

If physical standby database backups are to be usable for restore jobs at the primary site, you
must be connected to the recovery catalog when backing up the standby database or must
resynchronize the physical standby database shortly after the backup. This step is necessary
because there is no way for the primary database to know about the standby backups unless
the backup records are stored in the recovery catalog.
You cannot back up the standby control file. Also, you cannot make an image copy or
non-RMAN backup of the standby control file and then use it to restore the primary
database.
When you back up the standby database, you must connect to the standby database with the
TARGET keyword (not the AUXILIARY keyword). Essentially, the standby database is
“substituting” for the primary database during the backup.

Backup and Recovery of a
• Backup considerations:
– Use same backup method you use for your primary
database.
– Files are not interchangeable with primary
database.
• Recovery considerations:
– Can recover like any other database for loss of
individual files
– Need to re-create if you lose entire database
– Must use a binary copy of control file for control file
recovery
Backup and Recovery of a Logical Standby Database

You can back up your logical standby database by using the same method that you use for
your primary database. The backup files are not interchangeable with the primary database.
Remember that this is a different database.
You can use the same recovery techniques as with any other database for loss of data files or
online log files. You must use the backups of the logical (not the primary) database. If the
entire logical standby database is lost, you must re-create the logical standby.
If you lose all copies of your control file, you must use a binary copy of the control file
when performing the recovery. Using a trace file or the CREATE CONTROLFILE
command for control file recovery does not create a logical standby control file. You can
make a binary copy of the control file by doing either of the following:
• Shut down the logical standby and copy the control file to a backup.
• Issue the following command while the logical standby database is open:
ALTER DATABASE BACKUP CONTROLFILE TO '<filename>';
This command creates a binary copy of the control file with the name that you supply.

Using Flashback Database and
Real-Time Apply
RFS
Primary
database
MRP
Standby
redo log
ARC0
Archived Standby
redo logs database
Using Flashback Database and Real-Time Apply

You can reduce failover time by using the Oracle Data Guard real-time apply feature. You
can protect a physical standby database from logical data corruption or user error by using
Flashback Database.

Using Flashback Database After RESETLOGS
Primary Standby
database database
Redo
RESETLOGS
after
Flashback
point-in-time
recovery
Redo
Primary database Standby database
Using Flashback Database After RESETLOGS

Physical Standby Configuration
Use the following procedure to avoid re-creating a standby database after you have
performed an OPEN RESETLOGS on the primary database and the managed recovery
process has halted on the physical standby database:
1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN
when the OPEN RESETLOGS command was issued. This is necessary to enable the
standby to recover properly through the OPEN RESETLOGS. Use the following query
to find the “before RESETLOGS” SCN:
SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database;
2. On the standby database, obtain the current SCN by using the following query:
SELECT TO_CHAR(current_scn) FROM v$database;

Using Flashback Database After RESETLOGS (continued)
3. Flash back the standby database to the “before RESETLOGS” SCN that you queried in
step 1:
FLASHBACK STANDBY DATABASE TO SCN <before RESETLOGS SCN>;
4. Restart managed recovery on the standby database. The standby database should
now be ready to receive and apply logs from the primary database:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT;
Logical Standby Configuration
For a logical standby database, it is possible that the SQL Apply service might not halt when
it encounters the OPEN RESETLOGS command in the redo information. If the logical
standby database’s SCN is far enough behind the primary database’s SCN, then the SQL
Apply service will be able to interpret the OPEN RESETLOGS command without stopping.
Use the following procedure to avoid re-creating a standby database after you have
performed an OPEN RESETLOGS on the primary database and the SQL Apply process has
halted on the logical standby database:
1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN
when the OPEN RESETLOGS command was issued. This is necessary to enable the
standby to recover properly through the OPEN RESETLOGS. Use the following query
to find the “before RESETLOGS” SCN:
SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database;
2. On the standby database, obtain the current SCN with the following query:
SELECT TO_CHAR(current_scn) FROM v$database;
3. Flash back the standby database to the “before RESETLOGS” SCN that you queried in
step 1:
FLASHBACK STANDBY DATABASE TO SCN <before RESETLOGS SCN>;
4. Restart SQL Apply on the standby database. The standby database should now be
ready to receive and apply logs from the primary database:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Enabling Redo Encryption
Redo
Primary Standby
information
database database
encrypted
Enabling Redo Encryption

You can optionally enable encryption of the redo data by using the following procedure:
1. Install the Oracle Advanced Security option at both the primary and standby database.
2. Configure the appropriate SQLNET.ORA parameters to enable Oracle Net to encrypt
the redo traffic shipped to the standby. An outline of the tasks to configure encryption
on the client and on the server using Oracle Net Manager is as follows:
a. Navigate to the Oracle Advanced Security profile.
b. Choose the Encryption tab.
c. Select CLIENT or SERVER from the list.
d. From the Encryption Type list, select one of the following: REQUESTED,
REQUIRED, ACCEPTED, or REJECTED.
e. (Optional) In the Encryption Seed field, enter between 10 and 70 random
characters; the encryption seed for the client should not be the same as that for
the server.
f. Choose File > Save Network Configuration. The SQLNET.ORA file is updated.
g. Repeat this procedure to configure encryption on the other system.
Refer to the Oracle Database Advanced Security Administrator's Guide for detailed
information.

Cascaded Redo Log Destinations
Primary Standby
database database
Redo
Standby
database
Redo
Cascading Redo Log Destinations

To reduce the load on your primary system, you can implement cascaded redo log
destinations, whereby a standby database receives its redo data from another standby
database instead of directly from the primary database. You can configure:
• A physical standby database to retransmit the incoming redo data that it receives from
the primary database to other remote destinations in the same manner as the primary
database
• A logical standby database (because it is open in read/write mode) to send the redo
data that it generates (after filtering and applying the redo data that it receives from the
primary database) to its own set of standby (physical or logical) databases
Note: You must use SQL commands when managing a cascaded redo log destination
configuration because Data Guard broker does not support this feature.

Configuring Cascaded Redo Log
Destinations: Physical Standby
• On the primary, use the LGWR transport.

• On receiving a standby, configure standby redo
logs.
• On receiving a standby, configure
LOG_ARCHIVE_DEST_n to send redo to the next
standby.
Primary Physical Physical or

database standby logical standby
Configuring Cascaded Redo Log Destinations: Physical Standby

To enable a physical standby database to send the incoming redo data to another set of
destinations, you must do the following:
• Define the LOG_ARCHIVE_DEST_n initialization parameter on the primary database
to set up a physical standby database as the starting point for a cascade to use the
LGWR transport method. Use either SYNC or ASYNC network protocols, depending on
your requirements.
• On the receiving physical standby database, define sufficient standby redo log files and
ensure that archiving is enabled.
• Define the LOG_ARCHIVE_DEST_n initialization parameter on the physical standby
database that will define the end points of the cascade.
Remember that, as part of the original setup of the physical standby database, you should
have defined a local archive destination to be used for local archiving when the physical
standby database transitions to the primary role.
For example, you might define the LOG_ARCHIVE_DEST_1 initialization parameter to be
the 'LOCATION=/physical1/arch' location. When the physical standby database
switches roles, any archived redo log files are put into that directory with the same format
that you defined with the LOG_ARCHIVE_FORMAT initialization parameter.

Configuring Cascaded Redo Log Destinations: Physical Standby (continued)
This local archiving destination can be the same as the one that is defined in the parameter
STANDBY_ARCHIVE_DEST, but this is not required.
A side effect of this configuration is that the archiver process on the standby database now
tries to send the redo data not only to the cascading end points, but also to the other standby
databases and the primary database if they are defined and enabled. The shipping of redo
back to the primary or another standby is not a problem, because the receiving database will
reject it. If the destination is another standby database and it has not received the log file
successfully, then the shipping of redo acts as an active gap resolution. You can avoid the
shipping of redo to the primary and other standbys by setting the state to DEFER for any
destinations not involved in the cascade. However, you must remember to enable them again
if you do a switchover or failover operation.
If you want to have one initialization parameter file handle both the cascaded redo log
destinations and the original primary and standby destinations, define the destinations for the
primary database and other standby databases as well as for the cascading standby databases.
However, the total remote destinations still cannot exceed 10, including the local archiving
destination.

Configuring Cascaded Redo Log
Destinations: Logical Standby
• The cascading standby database is created from a

backup of the logical standby database, not from
the primary database.
• Set up the cascading standby just like any other
standby.
Primary Logical Physical or

database standby logical standby
Configuring Cascaded Redo Log Destinations: Logical Standby

A logical standby database that receives redo data directly from the primary database can be
configured to cascade the redo data that it generates to other standby databases (after it has
filtered and applied the redo data it receives from the primary database). Because redo data
that is cascaded from a logical standby database is not identical to the redo data originally
generated by the primary database, it cannot be applied to any standby database that is
created directly from the primary database. Instead, any standby databases that receive
cascaded redo data from a logical standby database must be created from a copy of the
logical standby database, and the following will be true:
• Physical standby databases that are created from a logical standby database will be a
block-for-block copy of the logical standby database and a logical copy of the original
primary database.
• Logical standby databases that are created from a logical standby database will be
logical copies of the parent logical standby database and might bear only a partial
resemblance to the original primary database. This is because the original primary
database’s data is there and so is anything else that is stored in the parent logical
standby database (including any other changes, such as different indexes or
materialized views).

Configuring Cascaded Redo Log Destinations: Logical Standby (continued)
For standby databases that receive cascaded redo data from a logical standby database, you
must perform the same setup tasks as for a physical or logical standby database that receives
redo data directly from the primary database. You can use any transport mode (LGWR or
ARCH) and network protocol (SYNC or ASYNC). If you use the LGWR transport mode, you
can optionally use standby redo log files on your standby databases.

Role Transitions with
Cascaded Redo Log Destinations
• Standby databases that receive redo data from a

physical standby database:
– No change: Switchover and failover are exactly the
same.
– May take longer
• Standby databases that receive redo data from a
logical standby database cannot participate in a
switchover involving the primary database.
Role Transitions with Cascaded Redo Log Destinations

The process to perform a switchover or failover is exactly the same in a cascaded redo log
destinations configuration, because all physical standby databases that receive retransmitted
primary database redo data are identical and valid for role transitions. The only difference is
that additional time may be required for the end-of-redo data to cascade to the standby
database.
Any standby database that receives redo data that is cascaded from a logical standby
database cannot participate in a switchover involving the primary database. (Only logical
standby databases that receive redo data directly from the primary database can participate
in switchovers.) If you fail over to a database that receives redo data that is generated by a
logical standby database, then only other logical standby databases that receive redo data
cascaded from the same logical standby database are able to continue to participate in the
Data Guard configuration after the failover.

Summary

• Back up the primary database with a physical
standby database
• Back up a logical standby database
• Use Flashback Database features in a Data Guard
configuration
• Encrypt redo information
• Configure cascaded redo log destinations

Workshop

Objectives

the following:
• Explain the workshop methodology
• Explain the workshop setup

Workshop Premise
• You are the DBA at a growing company that has

decided to implement Oracle Data Guard to
protect its Oracle database.
• You use Enterprise Manager and SQL commands
to manage your Data Guard configuration.

Workshop Flow
In this workshop, you perform the following tasks:

• Create one or more standby databases.
• Verify the configurations.
• Change the protection mode.
• Retrieve information from the standby database.
• Perform failovers.

Workshop Scenarios
The workshop is comprised of the following scenarios:

1. Create a Data Guard configuration to ensure high
availability, data protection, and disaster recovery.
2. Verify the configuration and the operation of log
transport and apply services.
3. Verify that the automatic gap detection and
resolution feature is working properly.
4. Change the protection mode to meet stated
requirements.
5. Configure the feature that enables log apply
services to apply redo data as it is received.
General Notes for the Workshop

The scenarios should be performed in order. If you finish them and would like to run some
separately, you can. Just be sure to keep track of what role each database is in before you
start a scenario.

Workshop Scenarios
6. Configure the feature that will ensure you will not

need to re-create the primary database after
failover.
7. Add an additional data file to your primary
database.
8. Configure the standby database so that users can
use it for reporting.
9. Add a standby database that will support
reporting.
10. Verify that the automatic gap detection and
resolution feature is working properly.

Workshop Scenarios
11. Configure SQL Apply so that specified DML

statements are not executed on the logical
standby database.
12. Create a new view on the logical standby
database.
13. Perform a failover operation.
14. Enable your logical standby database after the
failover.
15. Add your original primary database back into the
configuration.

Summary
In this lesson, you should have learned:

• The flow of the workshop
• The setup that is used for the workshop
• Some hints that will help you through the
workshop

Workshop Preparation
To prepare for the workshop, you need to drop your Data Guard configuration and your
standby databases. Perform the following steps:
1. Access the Data Guard page and drop your Data Guard configuration by selecting
Remove Data Guard Configuration in the Additional Administration section. Click Yes
on the Confirmation: Remove Data Guard Configuration page to confirm.
2. To add entries for these databases, edit the /etc/oratab file on the server machine
that your standby databases are on. The entries use the instance name to reference the
instance and database. This step is required so that you will be able to delete the
databases using DBCA.
3. Invoke DBCA on the server machine your standby databases are on and delete your
standby databases.
4. Remove your <HOSTNAME>_SITE1 and <HOSTNAME>_SITE2 databases from
Grid Control.

Workshop Scenarios
In the workshop you will create standby databases and modify your configuration to meet
the business requirements outlined in the workshop scenarios.
1. You need to create a Data Guard configuration to ensure high availability, data
protection, and disaster recovery for your enterprise data. You want to be able to open
your standby database in read-only mode so that queries can be executed. Create your
standby database to meet these requirements with the following specifications:
Standby database unique and target name: <YOUR_HOSTNAME>_SITE1
Location: Create your standby database on the next-highest student PC in your
classroom. For example, if your host name is EDRSR8P1, create your physical
standby database named EDRSR8P1_SITE1 on EDRSR8P2. If you are on
EDRSR8P12, create your standby database on EDRSR8P1.
2. You want to ensure that you have created your standby database successfully and that
the log transport and apply services are working. Use Enterprise Manager to confirm
that your Data Guard configuration is functioning properly.
3. You understand that Data Guard can automatically detect archive gaps and resolve
those gaps by copying the missing sequence of log files to the standby destination. As
an example, if connectivity is lost between the primary and one or more standby
databases (for example, due to network problems), redo data being generated on the
primary database cannot be sent to those standby databases. Once a connection is
reestablished, the missing archived redo log files (referred to as a gap) are
automatically detected by Data Guard, which then automatically transmits the missing
archived redo log files to the standby databases. Verify that this feature is working
properly in your configuration by simulating a loss of connectivity. Disable log
transport services to your standby database, switch the log on your primary database,
and re-enable log transport services to your standby database.
4. Maximum performance is the default protection mode and provides the highest level of
data protection that is possible 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.
You have determined that you need to change the data protection mode to ensure the
redo data needed to recover each transaction is written to both the local online redo log
and to the standby redo log on at least one standby database before the transaction
commits. You also want to configure the protection mode so that the primary database
does not shut down if a fault prevents it from writing its redo stream to a remote
standby redo log. Change the protection mode so that your configuration meets these
requirements.

Workshop Scenarios (continued)
5. You want to ensure fast switchover and failover times should you need to perform
those operations. Configure the Data Guard feature that enables log apply services to
apply redo data as it is received, without waiting for the current standby redo log file to
be archived.
6. You want to ensure that you will not need to re-create the primary database after you
have performed a failover operation. Configure the feature that will enable you to flash
back the failed primary database to a point in time before the failover and convert it
into a standby database for the new primary database.
7. You have been asked to add an additional data file to the EXAMPLE tablespace in your
primary database. Add the data file with the following specifications:
Data file name: /u01/app/oracle/oradata/orcl/example02.dbf
Data file size: 2 MB
Verify that the new data file has been added to your standby database.
8. The application users need to run some additional reports and do not want to impact
the production system. Perform the steps required to make the standby database
available for this reporting task. Verify that you can query tables in the standby
database and then restart real-time apply so that the standby database will be
resynchronized with the primary database.
9. You have determined that the users will need to run reports on a regular basis and do
not want to impact the production database. In addition, you would like to add an
additional standby database to your configuration for additional data protection.
Configure a second standby database that will be available for users to perform
queries, summations, and reporting activities against at all times with the following
specifications:
Standby database unique and target name: <HOSTNAME>_SITE2
Location: Create your standby database on the next-highest student PC in your
classroom. For example, if your host name is EDRSR8P1, create your standby
database on EDRSR8P2. If you are on EDRSR8P12, create your standby database on
EDRSR8P1.
10. Verify that the automatic gap detection and resolution feature is working properly in
your configuration by simulating a loss of connectivity to your new standby database.
Disable log transport services to your standby database, switch the log on your primary
database, and re-enable log transport services to your standby database.

Workshop Scenarios (continued)
11. Because the users want to use some tables in the new standby database to report
against for historical purposes, you need to configure SQL Apply so that certain DML
statements are not executed against those tables on the logical standby database. You
decide to test this feature first by creating a new table on the primary database as
follows:
CREATE TABLE hr.emp_name
AS SELECT first_name, last_name
FROM hr.employees
WHERE 1=2;
Define a filter that prevents SQL Apply from issuing DML statements against the
HR.EMP_NAME table on the logical standby database. Insert a few rows into the
HR.EMP_NAME table on the primary database and commit your changes. Force a log
switch on the primary database and then verify that the new rows are not applied to
your logical standby database.
12. You have been asked to create a view for the users to query on the logical standby
database. Create the view as follows:
CREATE VIEW hr.emp_90_vw
AS SELECT *
FROM hr.employees
WHERE department_id=90;
13. You have experienced a failure on your primary database server. Fail over to your
14. Your logical standby database is disabled after the failover. Enable your logical
standby database.
15. You have been able to restore the server which your primary database was on. Add
your original primary database back into your Data Guard configuration as a physical
standby database.

A
Practices and
Solutions
Practice 1: Oracle Data Guard Overview
1. Which one of the following statements is true?

a. A standby database is a set of log files that will be applied in the event of a
system failure.
b. A primary database is the production database.
c. A logical standby is an extension to the physical standby database.
d. The redo logs contain native SQL that can be applied to the standby database.
Solution: b
2. Which one of the following is not an Oracle Data Guard service?

a. Role management
b. Log transport
c. Redo log
d. Log apply
Solution: c
3. Which one of the following operations would you perform when the primary
database is completely lost?
a. Switchover
b. Apply backups to standby
c. Apply redo logs
d. Failover
Solution: d
4. The Oracle Data Guard broker is a distributed management framework that

automates and centralizes the creation, maintenance, and monitoring of Data Guard
configurations.
a. True
b. False
Solution: a
5. Enterprise Manager provides monitoring, automation, and management of the Data

Guard broker components.
a. True
b. False
Solution: a
Oracle Database 10g: Data Guard Administration A-2

Practice 1: Oracle Data Guard Overview (continued)
6. Which protection mode will cause the primary database to be shut down if contact
with all standby databases is lost?
a. Maximum protection
b. Maximum availability
c. Maximum performance
Solution: a
7. Which protection mode has the lowest impact on the performance of the primary
database but has the possibility of data loss?
a. Maximum protection
b. Maximum availability
c. Maximum performance
Solution: c
8. Real Application Clusters and Oracle Data Guard should not be used together
because they basically do the same thing.
a. True
b. False
Solution: b

Practice 2-1: Architecture Overview
1. Which one of the following statements is true?

a. The ARCn process creates a copy of the online redo logs for use by the LGWR
process.
b. The LGWR process collects transaction redo and updates the data files.
c. The FAL process provides a client/server mechanism for resolving gaps that
are detected in the range of archive redo logs.
d. The MRP process applies archived redo log information to the logical standby
database.
Solution: c
2. Which one of the following is not an operational requirement for the Data Guard
environment?
a. The primary and standby databases must use the same database release.
b. Each primary and standby database must have its own control file.
c. The primary database must operate in ARCHIVELOG mode.
d. The standby must be on the same node as the primary.
Solution: d
3. What are the modes of a physical standby database?

_______________________________________________________
_______________________________________________________
Solution: Managed recovery and open read-only
4. What technology is used to transform the redo log into SQL?

_______________________________________________________
_______________________________________________________
Solution: LogMiner
5. Should you create standby redo logs on the primary database?

______________________________________________________
Solution: Yes
6. How many standby redo log groups should you have?

_______________________________________________________
______________________________________________________
Solution: At least as many as there are online groups on the primary;
one more than this is recommended.

Practice 2-2: Installing the Oracle Management Agent
Oracle Enterprise Manager Grid Control is installed and operational on a server for your
practices. You must install the Oracle Management Agent on your PC so that you can use
Grid Control to monitor, configure, and administer the databases on your PC.
1. Open a terminal window and log on as the oracle user with a password of
oracle.
2. Oracle Enterprise Manager Grid Control software is staged in the

em10103gc_installmedia directory. Change directories to
em10103gc_installmedia/Disk1.
[oracle@EDRSR10P1 oracle]$ cd em10103gc_installmedia/Disk1
3. Set your $ORACLE_HOME environment variable by executing the export

command.
[oracle@EDRSR10P1 oracle]$ export ORACLE_HOME=$AGENT_HOME

[oracle@EDRSR10P1 oracle]$ echo $ORACLE_HOME
/u01/app/oracle/product/10.1.0/agent
4. Invoke the Oracle Universal Installer by issuing the following command:
./runInstaller
5. Click Next on the Welcome page.
6. On the “Specify File Locations” page, accept the defaults in the Source Path and
Destination Name fields. Verify that Destination Path is set to
/u01/app/oracle/product/10.1.0/agent. Click Next.
7. On the “Set a Product to Install” page, select “Additional Management Agent.” Click
Next.
8. On the “Specify Oracle Management Service Location” page, enter the following
information about the host machine that Oracle Enterprise Manager Grid Control is
installed on:
Management Service Host Name: <OMS_host>
Management Service Port: 4889
Click Next.
9. Click OK in the Warning dialog box.

Practice 2-2: Installing the Oracle Management Agent
10. Click Install on the Summary page. The Install page appears showing the progress of
the installation.
11. The “Setup Privileges” dialog box appears instructing you to execute the root.sh
script. Open a new terminal window and log in as the root user.
[oracle@EDRSR10P1 oracle]$ su -
Password:
[root@EDRSR10P1 root]# cd /u01/app/oracle/product/10.1.0/agent
[root@EDRSR10P1 root]# ./root.sh
Accept the default values for all prompts during the execution of the root.sh
script.
After the root.sh script completes, return to the Setup Privileges dialog box and
click OK.
12. The Configuration Assistants page appears. Once the configuration is complete, the
“End of Installation” page appears. Verify that the installation was successful and
click Exit to exit the Oracle Universal Installer. Click Yes in the Exit dialog box.
13. Configure monitoring credentials for your database. Open your browser and enter the
following URL:
http://<oms_host>:7777/em
14. Log in as the user sysman with password oracle1, and change the Monitor
Password for your database to oracle.
a. Log in as the user sysman with password of oracle1 and click Login.
b. Review the licensing information and click “I agree.”
c. Select Targets and click Databases.
d. Select your database (<HOSTNAME>_ORCL) from the list of databases and
click Configure.
e. Enter the Monitor Password of oracle and click Test Connection.
f. Verify the connection is successful and click Next. Click Submit.
g. Click OK.

Practice 2-3: Configuring Your Primary Database
As you proceed through the remaining practices, you may use this page to record
information about your databases.
Primary Database
Database Name: ___________________________________________________
Instance Name: ____________________________________________________
Database Unique Name: _____________________________________________
Target Name: _____________________________________________________
Host: ____________________________________________________________
Oracle Home: _____________________________________________________
Standby Database
Database Name: ___________________________________________________
Instance Name: ____________________________________________________
Target Name: _____________________________________________________
Host: ____________________________________________________________
Oracle Home: _____________________________________________________
Type of standby: ___________________________________________________
Standby Database
Database Name: ___________________________________________________
Instance Name: ____________________________________________________
Target Name: _____________________________________________________
Host: ____________________________________________________________
Oracle Home: _____________________________________________________
Type of standby: ___________________________________________________

Practice 2-3: Configuring Your Primary Database (continued)
1. Invoke Enterprise Manager Grid Control and view your database home page.
a. Enter the URL supplied by your instructor: http://hostname:7777/em
b. Supply the following to log in to Grid Control:
User name: SYSMAN
Password: _________
c. Click Login.
d. Click Targets to access the Hosts page.
e. Click Databases to access the Databases page.
f. Select your database by clicking on the database link name.
Important: Because you are logging in as the SYSMAN user, you will be able to see
and modify all databases in your class room. Be careful as you select only your
database in the list.
2. Configure preferred credentials for your database.

a. Access your database home page.
b. Click Preferences in the top right corner.
c. Click Preferred Credentials on the left side.
d. Click the Set Credentials icon for the Database target type.
e. Locate your database in the Target Credentials region and enter the usernames
and passwords as follows:
Normal username: SYSTEM
Normal password: oracle
SYSDBA username: SYS
SYSDBA password: oracle
Host username: oracle
Host password: oracle
f. Click Test to verify your entries.
g. Click Apply to confirm your entries.
Note: Practice 2-3 continues on the next page.

Practice 2-3: Configuring Your Primary Database (continued)
3. Configure ARCHIVELOG mode for your database. Use the flash recovery area for
the archive log destination. Do not set up any other destinations at this time. You
must be logged in as SYSDBA to complete this task.
a. On your database home page, click Maintenance to access the Maintenance
page.
b. Click Configure Recovery Settings to access the Configure Recovery Settings
page.
c. Because you are logged in as SYSTEM, you must click Logout in the upper
right corner to change the login user.
d. Select “Log out of Database: hostname_ORCL.oracle.com” and “Display
database login page after logout.” Click OK.
e. Enter the username of SYS, password of ORACLE, and select SYSDBA from
the “Connect As” drop-down menu. Click Login.
f. On your database home page, click Maintenance to access the Maintenance
page.
g. Click Configure Recovery Settings to access the Configure Recovery Settings
page.
h. Select “ARCHIVELOG Mode” in the Media Recovery section.
i. Accept the default of USE_DB_RECOVERY_FILE_DEST in destination 10 to
indicate that the flash recovery area should be used.
j. Click Apply.
k. Click Yes on the confirmation page to restart the database instance.
l. Confirm the host and database credentials. Click OK.
m. Click Yes to restart the database instance after shutdown.
n. An Update Message is displayed confirming your change.

Practice 4: Creating a Physical Standby Database with Enterprise Manager
1. Invoke SQL*Plus and enable FORCE LOGGING mode for your database.
a. Open a terminal window and invoke SQL*Plus.
[oracle@EDRSR4P1 oracle]$ sqlplus /nolog
SQL*Plus: Release 10.1.0.3.0 - Production on Wed Dec 1
12:50:51 2004
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL>
b. Connect to your database as SYS with SYSDBA privileges.
SQL> connect / as sysdba
Connected.
c. Issue the ALTER DATABASE FORCE LOGGING SQL command.
SQL> alter database force logging;
Database altered.
2. Invoke Enterprise Manager 10g Grid Control and access your database home page.
a. Enter the URL supplied by your instructor: http://hostname:7777/em
b. Supply the following to log in to Grid Control:
User name: SYSMAN
Password: _________
c. Click Login.
d. Click Targets to access the Hosts page.
e. Click Databases to access the Databases page.
f. Click the link for your database to access the database home page.

(continued)
3. Create a physical standby database with the following specifications by using Grid
Control:
Primary database unique name: <HOSTNAME>_ORCL
Location: Create your physical standby database on the next highest student PC in
your classroom. For example, if your host name is EDRSR8P1, create your physical
standby database named EDRSR8P1_SITE1 on EDRSR8P2. If you are using
EDRSR8P12, create your standby on EDRSR8P1.
Note: Your instructor may modify this configuration.
a. Access your database home page and select Administration to access the
Administration page.
b. Click Data Guard in the High Availability section.
c. Click Add Standby Database to invoke the Add Standby Database Wizard.
d. Select “Create a new physical standby database” and click Continue.
e. Select “Perform a live backup of the primary database” and click Next.
f. Accept the default location for the backup and the default option to delete the
working directory after the standby creation. Click Next.
g. Accept the default instance name of dg2. Enter the credentials for the standby
host machine if they differ from the default supplied. Select the host in the
Standby Database Oracle Home section as described above. Click Next.
h. Accept the default, to transfer files, in the Backup File Access section. Select
“Convert to Oracle OFA” in the Standby Database File Locations section.
Accept the default location for the network configuration file location. Click
Next.
i. Specify Database Unique Name and Target Name as <HOSTNAME>_SITE1.
Accept the default location for the archived redo logs. Click Next.
j. Review your configuration information and click Finish.
k. After you are returned to the Data Guard page, select “Real Time: 1 Minute
Refresh” from the View Data drop-down menu to monitor the creation of your
standby database. The creation is complete when the status changes to Normal.

(continued)
4. After the physical standby creation is complete, use Verify to validate the
configuration and add standby redo logs.
a. Access your Data Guard configuration by selecting your primary database.
Select Data Guard in the High Availability section of the Administration page.
b. Click Verify in the Additional Administration section.
c. Review the information in the “Detailed Results” section.
d. Select “Create standby redo logs for the following database(s)” to create
standby redo logs for your primary and standby databases. Click OK.

Practice 6: Data Protection Modes and Log Transport Services
1. Using Enterprise Manager, change the data protection mode for your standby
database to maximum protection.
a. On the Databases target page, click the link for your primary database.
b. Click Administration.
c. Click Data Guard in the High Availability section.
d. In the Overview section, click the link in the Protection Mode field to access
the Edit Protection Mode: Select page.
e. Select Maximum Protection and click Continue.
f. Accept the default selection of your physical standby database and click OK.
g. Click Yes on the Confirmation: Edit Protection Mode page.
h. You are returned to the Data Guard Overview page. Verify that your protection
mode has been changed to maximum protection.
2. Using Enterprise Manager, configure a delay for the application of redo to the
standby database to allow you to stop the application of any corrupt data. Set the
delay for 2 hours (120 minutes).
a. Select your standby database and click Edit on the Data Guard page.
b. Click Standby Role Properties on the Edit Standby Database Properties page.
c. Enter the delay value of 120 in the Apply Delay field.
d. Click Apply.
3. In preparation for later practices, use Enterprise Manager to change the data
protection mode back to maximum performance.
a. Navigate to the Data Guard page.
b. Click the link in the Protection Mode field to access the Edit Protection Mode:
Select page.
c. Select Maximum Performance and click Continue.
d. Accept the default selection of your physical standby database and click OK.
e. Click Yes on the Confirmation: Edit Protection Mode page.
f. You are returned to the Data Guard Overview page. Verify that your protection
mode has been changed to maximum performance.
4. You decide that you no longer want the delayed application of redo. Use Enterprise
Manager to disable the delay in the application of redo.
a. Select your standby database and click Edit on the Data Guard page.
b. Click Standby Role Properties on the Edit Standby Database Properties page.
c. Enter the delay value of 0 in the Apply Delay field.
d. Click Apply.

Practice 7: Creating a Logical Standby Database Using Enterprise Manager
1. Create a logical standby database with the following specifications using Enterprise
Manager:
Location: Create your physical standby database on the next highest student PC in
your classroom. For example, if your host name is EDRSR8P1, create your physical
EDRSR8P12, create your standby on EDRSR8P1.
Note: Your instructor may modify this configuration.
a. Select your primary database on the Databases target page.
b. Select Administration to access the Administration page.
c. Click Data Guard in the High Availability section.
d. Click Add Standby Database in the Standby Databases section to invoke the
Add Standby Database Wizard.
e. Select “Create a new logical standby database” and click Continue.
f. Select “Perform a live backup of the primary database” and click Next.
g. Accept the default location for the backup and the default option to delete the
working directory after the standby creation. Enter primary host credentials if
needed. Click Next.
h. Accept the default instance name of dg3. Enter the credentials for the host
machine if they differ from the default supplied. Select the host in the Standby
Database Oracle Home section as described above. Click Next.
i. Accept the default, to transfer files, in the Backup File Access section. Select
“Convert to Oracle OFA” in the Standby Database File Locations section.
Accept the default location for the network configuration file location. Click
Next.
j. Accept the default Database Name. Specify Database Unique Name and Target
Name as <HOSTNAME>_SITE2. Accept the default location for the archived
redo logs. Click Next.
k. Review your configuration information and click Finish.
l. Select "Real Time: 1 Minute Refresh" in the View Data drop-down menu to
monitor the creation.
2. After the logical standby database creation is complete, use Verify to validate the
configuration.
a. Access your Data Guard configuration by selecting your primary database.
Select Data Guard in the High Availability section of the Administration page.
b. Click Verify in the Additional Administration section.
c. View progress on the Processing: Verify page.
d. Review results in the Detailed Results window. Click OK to return to the Data
Guard page.

Practice 9: Switchover and Failover
1. Create a table in your primary database defined as follows:

Schema: HR
Name: MY_TABLE
Column Name: COL1 Data type: NUMBER
Tablespace: EXAMPLE
a. Select your primary database on the Databases target page.
b. Select Tables in the Schema section of the Administration page.
c. Click Create.
d. Select Standard, Heap Organized and then click Continue.
e. Enter the table name, schema, tablespace name, and column information. Click
OK.
2. Perform a log switch on your primary database.

a. Return to your primary database home page.
b. Click Redo Log Groups in the Storage section of the Administration page.
c. Select “Switch logfile” in the Actions list.
d. Click Go.
3. Access the Data Guard page for your configuration.

a. Return to the Administration page for your primary database by clicking on the
database breadcrumb.
b. Select Data Guard in the High Availability section of the Administration page.
4. Select your physical standby database and perform a switchover.

a. Select your physical standby database and click Switchover.
b. Supply host login credentials and click Login.
c. Click Yes to confirm the switchover operation.
d. View the progress on the Processing: Switchover page.
5. Verify that the HR.MY_TABLE table you created in step 1 exists on your new
primary database.
a. Access the database home page for your new primary database.
b. Log in to your database as SYS with a password of ORACLE as SYSDBA.
c. Select Tables in the Schema section of the Administration page.
d. Enter HR in the Schema field and MY_TABLE in the Object Name field.
e. Click Go.
Note: Practice 9 continues on the next page.

Practice 9: Switchover and Failover (continued)
6. Perform a complete failover to your physical standby database using Enterprise

Manager.
a. Navigate to the Data Guard page.
b. Select your physical standby database and click Failover.
c. Click Yes to connect to your physical standby database.
d. Select Complete for the type of failover and click Yes.
e. The Processing: Failover page is displayed. When the failover is completed,
you are returned to the Data Guard page.

Practice 12: Workshop Preparation
To prepare for the workshop, you need to drop your Data Guard configuration and your
standby databases. Follow the steps below to accomplish these tasks.
1. Access the Data Guard page and drop your Data Guard configuration by selecting
Remove Data Guard Configuration in the Additional Administration section. Click
Yes on the Confirmation: Remove Data Guard Configuration page to confirm.
2. Open a terminal window and telnet to the machine your standby databases are on.
Log in as the oracle user with password of oracle. Edit the /etc/oratab file
on the machine that your standby databases are on to add entries for these databases.
The entries use the instance name to reference the instance and database. This step is
required so that you will be able to delete the databases using DBCA.
Add entries as follows:
dg2:/u01/app/oracle/product/10.1.0/db_1:N
dg3:/u01/app/oracle/product/10.1.0/db_1:N
3. Invoke DBCA on the server machine your standby databases are on and delete your
standby databases.
In a terminal window, logged on as the oracle user, invoke DBCA by entering dbca
at the command prompt.
a. Click Next on the DBCA Welcome page.
b. Select “Delete a Database” and click Next.
c. Select “dg2” and click Finish.
d. Click Yes to confirm the deletion.
e. Click Yes to perform another operation.
f. Repeat the deletion steps for “dg3.”
g. After you complete the deletion of dg3, click No to exit DBCA.
4. Remove your <HOSTNAME>_SITE1 and <HOSTNAME>_SITE2 databases from

Grid Control.
a. Navigate to the Databases page.
b. Select your <HOSTNAME>_SITE1 database and click Remove.
c. Click Yes to confirm.
d. Repeat for your <HOSTNAME>_SITE2 database.

Practice 12: Workshop Scenarios
1. You need to create a Data Guard configuration to ensure high availability, data
protection, and disaster recovery for your enterprise data. You want to be able to
open your standby database in read-only mode so that queries can be executed.
Create your standby database to meet these requirements with the following
specifications:
Standby database unique and target name: <YOUR_HOSTNAME>_SITE1
Location: Create your standby database on the next highest student PC in your
classroom. For example, if your host name is EDRSR8P1, create your physical
EDRSR8P12, create your standby database on EDRSR8P1.
a. Select your primary database on the Databases page.
b. Select Data Guard in the High Availability section of the Administration page.
c. On the Data Guard page, click Add Standby Database.
d. Select “Create a new physical standby database” and click Continue.
e. Select “Perform a live backup of the primary database” and click Next.
f. Accept the default location for the Working Directory. Enter the Primary Host
Credentials if not already populated. Click Next.
g. Accept the default instance name. Select the host for the Oracle Home and
click Next.
h. Select “Transfer files from the primary host working directory to a standby host
working directory” and “Convert to OFA.” Click Next.
i. Change the Database Unique Name and Target Name to
<HOSTNAME>_SITE1 as described above. Accept the default for the Standby
Archive location. Click Next.
j. Review the information and click Finish.
k. When the Data Guard page reappears, select Real Time: 1 Minute Refresh in
the View Data drop-down menu. You can also click the link in the Status
column to review additional information.
2. You want to ensure that you have created your standby database successfully and
that the log transport and apply services are working. Use Enterprise Manager to
confirm that your Data Guard configuration is functioning properly.
a. Click Verify in the Additional Administration section of the Data Guard page.
b. Click OK to create standby redo logs.

Practice 12: Workshop Scenarios
3. You understand that Data Guard can automatically detect archive gaps and resolve
those gaps by copying the missing sequence of log files to the standby destination.
As an example, if connectivity is lost between the primary and one or more standby
databases (for example, due to network problems), redo data being generated on the
primary database cannot be sent to those standby databases. Once a connection is
reestablished, the missing archived redo log files (referred to as a gap) are
automatically detected by Data Guard, which then automatically transmits the
missing archived redo log files to the standby databases. Verify that this feature is
working properly in your configuration by simulating a loss of connectivity. Disable
log transport services to your standby database, switch the log on your primary
database, and re-enable log transport services to your standby database.
a. Disable log transport services as follows:
On the Data Guard page, select the standby database and click Edit.
Select the Standby Role Properties page.
Expand Show Advanced Properties.
Select OFF in the Log Shipping drop-down menu. Click Apply.
Select the Databases targets tab.
b. Force three to five log switches on the primary database as follows:
Click the link for your primary database on the Databases targets tab.
Select Redo Log Groups on the Administration page for the primary database.
Select Switch Logfile in the Actions drop-down menu and click Go.
Repeat three to five times.
Return to the Data Guard page and observe the difference in the current log
number for the primary database and the last received log for the standby
database.
c. Enable log transport services to the physical standby database as follows:
On the Data Guard page, select the standby database and click Edit.
Select ON in the Log Shipping drop-down menu. Click Apply.
d. Verify that all redo has been applied as follows:
Return to the Data Guard page and observe that the standby database has
received the redo log files from the primary database.

Practice 12: Workshop Scenarios (continued)
4. Maximum performance is the default protection mode and provides the highest level
of data protection that is possible 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.
You have determined that you need to change the data protection mode to ensure the
redo data needed to recover each transaction is written to both the local online redo
log and to the standby redo log on at least one standby database before the
transaction commits. You also want to configure the protection mode so that the
primary database does not shut down if a fault prevents it from writing its redo
stream to a remote standby redo log. Change the protection mode so that your
configuration meets these requirements.
Change the protection mode to maximum availability as follows:
a. On the Data Guard page, click the link in the Protection Mode field.
b. Select Maximum Availability and click Continue.
c. Click OK on the Edit Protection Mode: Standby Databases and Redo Logs
page.
d. Click Yes on the Confirmation: Edit Protection Mode page.
5. You want to ensure fast switchover and failover times should you need to perform
those operations. Configure the Data Guard feature that enables log apply services to
apply redo data as it is received, without waiting for the current standby redo log file
to be archived.
Enable real-time apply for your Data Guard configuration as follows:
a. On the Data Guard page, select your standby database and click Edit.
b. Click Standby Role Properties.
c. Expand Show Advanced Properties.
d. Select ON from the Real Time Apply drop-down menu.
e. Click Apply.
f. Return to the Data Guard page by clicking the Data Guard breadcrumb.

6. You want to ensure that you will not need to re-create the primary database after you
have performed a failover operation. Configure the feature that will enable you to
flash back the failed primary database to a point in time before the failover and
convert it into a standby database for the new primary database.
Enable Flashback Database for your primary database, setting the retention time to
12 hours as follows:
a. Navigate to the Maintenance page for your primary database.
b. Select Configure Recovery Settings in the Backup/Recovery section of the
Maintenance page.
c. Select “Enable flashback logging for fast database point-in-time recovery.”
d. Enter 12 hours in the “Flashback Retention Time” field.
e. Click Apply.
f. Click Yes to restart the database instance.
g. Enter the Host Credentials and Database Credentials if they are not supplied.
Click OK.
h. Click Yes to restart the database instance.
i. Return to the database home page after the database instance has been restarted.
7. You have been asked to add an additional data file to the EXAMPLE tablespace in
your primary database. Add the data file with the following specifications:
Data file name: /u01/app/oracle/oradata/orcl/example02.dbf
Data file size: 2 MB
Verify that the new data file has been added to your standby database.
a. Add the new tablespace as follows:
Select the primary database.
Select Tablespaces in the Storage section of the Administration page.
Select the EXAMPLE tablespace.
Select Add Datafile in the Actions drop-down menu and click Go.
Enter example02.dbf in the File Name field and 2 MB in the File Size field.
Click OK.
An update message is displayed.

b. Force a log switch as follows:

Return to the database home page.
c. Verify that the new data file was added to the standby database as follows:
Open a terminal window and telnet to the machine your standby database is on.
Log in as the oracle user with password of oracle. You must start a
SQL*Plus session to verify that the new data file was added to the standby
database. Because the database is in MOUNT mode, EM does not display the
tablespaces and datafiles. Issue the following query to verify that the file was
added:
SELECT name FROM v$datafile;
Sample output is as follows:
[oracle@EDRSR4P1 oracle]$ export ORACLE_SID=dg2
SQL*Plus: Release 10.1.0.3.0 - Production on Thu Dec 9 13:08:28
2004
Connected.
SQL> SELECT db_unique_name FROM v$database;
DB_UNIQUE_NAME
------------------------------
EDRSR10P1_SITE1
SQL> SELECT name FROM v$datafile;
NAME
----------------------------------------------------------------
/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/system01.dbf
/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/undotbs01.dbf
/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/sysaux01.dbf
/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/users01.dbf
/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/example01.dbf
/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/example02.dbf
6 rows selected.

8. The application users need to run some additional reports and do not want to impact
the production system. Perform the steps required to make the standby database
available for this reporting task. Verify that you can query tables in the standby
database and then restart real-time apply so that the standby database will be
resynchronized with the primary database.
a. On the Data Guard page, select the standby database and click Edit.
b. Select “Read Only” in the Log Apply Services section. Click Apply.
c. Return to the Data Guard page and verify the status of Normal, Read-only for
your standby database.
d. Open a terminal window and telnet to the machine your standby database is on.
Log in as the oracle user with password of oracle. Invoke SQL*Plus.
Connect as the HR user and query the HR.EMPLOYEES table as follows:
SQL> SELECT count(*) FROM employees;
2004
SQL> connect hr/hr

Connected.
COUNT(*)
----------
107
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release
10.1.0.3.0 -
With the Partitioning, OLAP and Data Mining options
e. On the Data Guard page, select the standby database and click Edit.
f. Select Online in the Log Apply Services section. Click Apply.
g. Return to the Data Guard page and verify the status of Normal for your standby
database.

h. Open a terminal window and telnet to the machine your standby database is on.
Log in as the oracle user with password of oracle. Invoke SQL*Plus.
Connect as the HR user and attempt to query the HR.EMPLOYEES table as
follows:
2004
SQL> connect hr/hr
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-01219: database not open: queries allowed on fixed
tables/views only
9. You have determined that the users will need to run reports on a regular basis and do
not want to impact the production database. In addition, you would like to add an
additional standby database to your configuration for additional data protection.
Configure a second standby database that will be available for users to perform
queries, summations, and reporting activities against at all times with the following
specifications:
Location: Create your standby database on the next highest student PC in your
classroom. For example, if your host name is EDRSR8P1, create your standby
database on EDRSR8P2. If you are on EDRSR8P12, create your standby database on
EDRSR8P1.
a. On the Data Guard page, click Add Standby Database.
b. Select “Create a new logical standby database” and click Continue.
c. Select “Perform a live backup of the primary database” and click Next.
d. Accept the default location for the Working Directory. Enter the Primary Host
Credentials if not already populated. Click Next.
e. Accept the default instance name. Select the host for the Oracle Home and
click Next.
f. Select “Transfer files from the primary host working directory to a standby host
working directory” and “Convert to OFA.” Click Next.
g. Change the Database Unique Name and Target Name to
<HOSTNAME>_SITE2 as described above. Click Next.

h. Review the information and click Finish.

i. When the Data Guard page reappears, select “Real Time: 1 Minute Refresh”
from the View Data drop-down menu. You can also click the link in the Status
column to review additional information.
10. Verify that the automatic gap detection and resolution feature is working properly in
your configuration by simulating a loss of connectivity to your new standby
database. Disable log transport services to your standby database, switch the log on
your primary database, and re-enable log transport services to your standby database.
a. Disable log transport services to the logical standby database as follows:
On the Data Guard page, select the logical standby database and click Edit.
Select OFF in the Log Shipping drop-down menu. Click Apply.
Return to the Databases target page.
b. Force three to five log switches on your primary database as follows:
Select your primary database on the Database target page by clicking on the
link
Repeat three to five times.
Return to the Data Guard page and observe the difference in the current log
number for the primary database and the last received log for the logical
standby database.
c. Enable log transport services to the logical standby database as follows:
On the Data Guard page, select your logical standby database and click Edit.
Select ON in the Log Shipping drop-down menu. Click Apply.
d. Verify that all redo has been applied to the logical standby database as follows:
Return to the Data Guard page and observe that the standby database has
received the redo log files from the primary database.

11. Because the users want to use some tables in the new standby database to report
against for historical purposes, you need to configure SQL Apply so that certain
DML statements are not executed against those tables on the logical standby
database. You decide to test this feature first by creating a new table on the primary
database as follows:
CREATE TABLE hr.emp_name
AS SELECT first_name, last_name
FROM hr.employees
WHERE 1=2;
Define a filter that prevents SQL Apply from issuing DML statements against the
HR.EMP_NAME table on the logical standby database. Insert a few rows into the
HR.EMP_NAME table on the primary database and commit your changes. Force a log
switch on the primary database and then verify that the new rows are not applied to
a. Open a terminal window.
b. Change to the labs directory.
c. Invoke SQL*Plus and connect as hr/hr. Execute the lab_12_11_a.sql
script in your labs directory to create the HR.EMP_NAME table as described.
Maintain the SQL*Plus session for later steps.
d. Configure SQL Apply on the logical standby database so that no DML
statements are executed against the HR.EMP_NAME as follows:
Navigate to the Data Guard page.
Select the logical standby database and click Edit.
Click Standby Role Properties.
Click Add in the Skip Table Entries section.
Enter the following information in the specified fields:
SQL Statement: DML
Schema: HR
Object Name: EMP_NAME
Select “Always skip this statement type.”
Click OK.
Verify the information in the Skip Table Entries section and click Apply.
A success message is displayed.

e. In your SQL*Plus session, execute the lab_12_11_c.sql script in the labs

directory to insert two rows in the HR.EMP_NAME table as follows:
INSERT INTO hr.emp_name
VALUES ('Don','Miller');
INSERT INTO hr.emp_name
VALUES ('Sally','Hebert');
COMMIT;
f. On your primary database, force a log switch as follows:
Access the Maintenance page for your primary database.
Click Redo Log Groups.
Select Switch logfile in the Actions drop-down menu and click Go.
g. Access your logical standby database and query the HR.EMP_NAME table to
determine if any rows have been inserted into the table as follows:
Open a terminal window and telnet to the machine your standby database is on.
Log in as the oracle user with password of oracle. Invoke SQL*Plus for
Connect as hr/hr.
Issue the following command:
SELECT count(*) FROM emp_name;
There should be no rows in the emp_name table.
SQL*Plus: Release 10.1.0.3.0 - Production on Fri Dec 10 09:08:55

2004
SQL> connect hr/hr

Connected.
SQL> SELECT count(*) FROM emp_name;
COUNT(*)
----------
0

12. You have been asked to create a view for the users to query on the logical standby
database. Create the view as follows:
CREATE VIEW hr.emp_90_vw
AS SELECT *
FROM hr.employees
a. Invoke SQL*Plus and connect to your logical standby database as the SYS
user. Set the Data Guard guard to STANDBY so that you can create a view by
issuing the following statement:
ALTER DATABASE GUARD STANDBY;
2004
Connected.
SQL> ALTER DATABASE GUARD STANDBY;
Database altered.
b. Connect to your logical standby database as HR, with HR as the password.
Create a view on the HR.EMPLOYEES table as follows:
CREATE VIEW emp_90_vw
AS SELECT *
FROM employees
You can use the lab_12_12_b.sql script to create the view.
c. Connect to your logical standby database as SYS and set the Data Guard guard
back to ALL as follows:
ALTER DATABASE GUARD ALL;
Connected.
SQL> ALTER DATABASE GUARD ALL;
Database altered.

13. You have experienced a failure on your primary database server. Fail over to your
a. On the Data Guard page, select your physical standby database and click
Failover.
On the Confirmation: Redirect page, click Yes to continue with the failover.
On the Confirmation: Failover page, select Complete and click Yes.
The Processing: Failover page is displayed.
The Data Guard page is displayed after processing completes.
b. Force one or two log switches as follows:
Click on the link for your new primary database.
Select the Administration page and click Redo Log Groups.
Select “Switch logfile” in the Actions drop-down menu and click Go. Repeat.
Return to the Data Guard page.
14. Your logical standby database is disabled after the failover. Enable your logical
standby database.
a. Access the Data Guard page. Your logical standby database shows a status of
“Disabled.” Click the “Disabled” link.
b. On the Edit Standby Database Properties page, click Enable. The logical
standby database is reset and is now part of your configuration.
c. Click Verify to verify your Data Guard configuration.
d. Review the results of the verify and click OK to return to the Data Guard
configuration.

15. You have been able to restore the server on which your primary database was
originally located. Add your original primary database back into your Data Guard
configuration as a physical standby database.
a. Open a terminal window and telnet to the machine your standby database is on.
Log in as the oracle user with password of oracle. On the NEW primary
database, issue the follow query in SQL*Plus:
SELECT standby_became_primary_scn FROM v$database;
Make note of the SCN value you obtained in the
query:_____________________
2004
Connected.
SQL> SELECT db_unique_name, database_role
2 FROM v$database;
DB_UNIQUE_NAME DATABASE_ROLE
------------------------------ ----------------
EDRSR10P1_SITE1 PRIMARY
SQL> SELECT standby_became_primary_scn

2 FROM v$database;
STANDBY_BECAME_PRIMARY_SCN
--------------------------
1710595

b. Using SQL*Plus, start the old primary database instance and place the database
in MOUNT mode.
STARTUP MOUNT;
2004
Connected to an idle instance.
SQL> STARTUP MOUNT;
ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778312 bytes
Variable Size 70262712 bytes
Database Buffers 117440512 bytes
Redo Buffers 262144 bytes
Database mounted.
c. Flashback the old primary database to the SCN value you determined in step a.
FLASHBACK DATABASE TO BEFORE SCN <SCN>;
Your old primary database is now serving as a new physical standby database.
SQL> FLASHBACK DATABASE TO BEFORE SCN 1710595;
Flashback complete.
d. On the new physical standby database, disable Flashback Database.
ALTER DATABASE FLASHBACK OFF;
SQL> ALTER DATABASE FLASHBACK OFF;
Database altered.

e. On the new physical standby database, determine the names of the control files
by issuing the following command:
SELECT name FROM v$controlfile;
SQL> SELECT name FROM v$controlfile;
NAME
-----------------------------------------------------------
/u01/app/oracle/oradata/orcl/control01.ctl
f. On the new physical standby database, create the standby control file:
ALTER DATABASE CREATE STANDBY CONTROLFILE AS
'control_file_name';
2 AS '$ORACLE_BASE/oradata/orcl/sb_control.ctl';
2 AS '$ORACLE_BASE/oradata/orcl/sb_control.ctl';
Database altered.
g. Shut down the new physical standby database:
SHUTDOWN IMMEDIATE;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

h. Using operating system commands, copy the newly created control (step f) to
the locations of your existing control files (as determined in step e).
[oracle@EDRSR10P1 oracle]$ cd $ORACLE_BASE/oradata/orcl
[oracle@EDRSR10P1 orcl]$ ls
control01.ctl example02.dbf orcl_srl3.f sb_control.ctl
undotbs01.dbf
control02.ctl orcl_srl0.f redo01.log sysaux01.dbf
users01.dbf
control03.ctl orcl_srl1.f redo02.log system01.dbf
example01.dbf orcl_srl2.f redo03.log temp01.dbf
[oracle@EDRSR10P1 orcl]$ cp sb_control.ctl control01.ctl
cp: overwrite `control01.ctl'? y
i. Start the instance and mount the database using your new control files:
STARTUP MOUNT;
[oracle@EDRSR10P1 orcl]$ sqlplus /nolog
2004
Connected to an idle instance.
SQL> startup mount
ORACLE instance started.
Total System Global Area 188743680 bytes

Fixed Size 778312 bytes
Variable Size 70262712 bytes
Database Buffers 117440512 bytes
Redo Buffers 262144 bytes
Database mounted.

j. Enable flashback database:

ALTER DATABASE FLASHBACK ON;
SQL> ALTER DATABASE FLASHBACK ON;
Database altered.
k. Ensure your listener is started, by issuing the following command at the
operating system prompt:
lsnrctl status listener;
l. You can use Enterprise Manager to enable the physical standby database as
follows:
Access the Data Guard page. Your new physical standby database shows a
status of “Disabled.” Click the “Disabled” link.
On the Edit Standby Database Properties page, click Enable. The new physical
standby database is reset and is now part of your configuration.
Click Verify to verify your Data Guard configuration.
Review the results of the verify and click OK to return to the Data Guard
configuration.

B
Oracle Data Guard: History

History of Oracle Data Guard
• Oracle 7.3: Custom standby database

• Oracle8i: Automated standby
– Read-only database
– Managed recovery
– Remote archiving
• Oracle8i Data Guard:
– Automation
– Single-command switchover and failover
– Oracle Parallel Server (OPS) and Oracle Parallel Fail
Safe (OPFS) support

Oracle 7.3 was the first release to support standby databases. At that time, the process of
transmitting redo logs was completely manual.
The first version of Oracle8i introduced the ability to automatically ship redo log files
from the primary database to the standby database and to have them be automatically
applied. It was also possible to stop the recovery process and open the standby database in
read-only mode.
Oracle8i Data Guard provided a set of scripts for AIX, Solaris, and HP/UX that simplified
the installation, monitoring, and management of an Enterprise Edition standby database. It
also provided a command-line interface with commands such as SWITCHOVER and
FAILOVER to automate the manual steps to perform those actions. The 3.0 versions of the
product supported Oracle Parallel Server (OPS) and Oracle Parallel Fail Safe (OPFS) 3.0.
Oracle8i Data Guard supported all Oracle8i releases.
Oracle Database 10g: Data Guard Administration B-2

• Oracle Data Guard in Oracle9i, Release 1:

– Integrated zero-data-loss capability
– Data Guard broker, with Data Guard Manager GUI
interface and command-line interface (CLI)
– Switchover and failover operations
– Automatic gap resolution and resynchronization
• Oracle Data Guard in Oracle9i, Release 2:
– Logical standby databases
– Maximum protection, maximum availability, and
maximum performance data protection modes
– Enhanced Data Guard broker functionality
– Cascaded redo log destinations
History of Oracle Data Guard (continued)

Oracle9i, Release 1, introduced the new concept of protection mode, preventing the
primary and the standby databases from diverging. The Data Guard broker (with a GUI
interface called Data Guard Manager integrated with Enterprise Manager) was also
introduced. In addition, a command-line interface (CLI) called DGMGRL was made
available.
With Oracle9i, Release 2, Data Guard continued to be enhanced with the addition of
logical standby databases. Three protection modes were introduced to replace the modes of
protection that were available in previous releases. The Data Guard broker was enhanced
to support up to nine physical or logical standby databases. In addition, the broker
supported switchover and failover operations with this release.

Oracle Data Guard Release 10.1
• Real-time apply
• Recovery through OPEN RESETLOGS
• Flashback Database support
• Simplified configuration management with the
VALID_FOR attribute
• Standby redo log support on logical standby
databases
• Improved redo data transmission security
• Improved Data Guard support for RAC
• Zero downtime instantiation of logical
standby databases
Oracle Data Guard Release 10.1

Data Guard in Oracle Database 10g has been enhanced to provide:
• Additional ease-of-use features
• Integration with new Oracle Database high availability features such as Flashback
Database
• Comprehensive features and functionality
This course focuses on the Oracle Data Guard product and all of its features that are
available in Release 10.1.

Oracle10g - Data Guard Administration - D40345

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Oracle10g - Data Guard Administration - D40345

Hochgeladen von

Copyright:

Verfügbare Formate

Oracle Database 10g: Data

Donna Keesling This documentation contains proprietary information of Oracle Corporation. It is

Appendix A: Practices and Solutions

Appendix B: Oracle Data Guard: History

Before You Begin This Course

Copyright © 2005, Oracle. All rights reserved.

After completing this lesson, you should be able to do

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration 1-2

Hardware & system errors 49%

Human errors 36%

Source: Disaster Recovery Journal

Copyright © 2005, Oracle. All rights reserved.

Causes of Data Loss

Oracle Database 10g: Data Guard Administration 1-3

Copyright © 2005, Oracle. All rights reserved.

Unplanned Versus Planned Down Time

Oracle Database 10g: Data Guard Administration 1-4

Copyright © 2005, Oracle. All rights reserved.

What Is Oracle Data Guard?

Oracle Database 10g: Data Guard Administration 1-5

There are two types of standby databases:

Copyright © 2005, Oracle. All rights reserved.

Types of Standby Databases

Oracle Database 10g: Data Guard Administration 1-6

CLI management client

Copyright © 2005, Oracle. All rights reserved.

Oracle Data Guard Broker

Oracle Database 10g: Data Guard Administration 1-7

There are three types of services provided with Data

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration 1-8

• Oracle Data Guard supports two role-transition

Copyright © 2005, Oracle. All rights reserved.

Role Transitions: Switchover and Failover

Oracle Database 10g: Data Guard Administration 1-9

Oracle Database 10g: Data Guard Administration 1-10

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration 1-11

Oracle Database 10g: Data Guard Administration 1-12

Oracle Data Guard provides the following benefits:

Copyright © 2005, Oracle. All rights reserved.

Benefits of Implementing Oracle Data Guard

Oracle Database 10g: Data Guard Administration 1-13

Copyright © 2005, Oracle. All rights reserved.

Role of Data Guard in a High Availability Architecture

Oracle Database 10g: Data Guard Administration 1-14

• Online schema and

• Rolling patch updates

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10g: Data Guard Administration 1-15

Oracle Data Guard and Real Application Clusters are

Copyright © 2005, Oracle. All rights reserved.

Oracle Data Guard and Real Application Clusters

Oracle Database 10g: Data Guard Administration 1-16

Oracle WAN traffic Oracle

Data Guard RAC RAC

Copyright © 2005, Oracle. All rights reserved.

Maximum Availability Architecture

Oracle Database 10g: Data Guard Administration 1-17

In this lesson, you should have learned how to:

Copyright © 2005, Oracle. All rights reserved.