D52161GC30 SG New PDF

HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBIT ED
D67578
May 2010
Edition 3.0
D52161GC30
Student Guide
Administration
Oracle Database 11g: Data Guard
unarski inzenjering d.o.o use only

Authors Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Mark Fuller Disclaimer

HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBIT ED
Donna K. Keesling This document contains proprietary inf ormation and is protected by copy right and
other intellectual property law s. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modif ied or altered in
Technical Contributors any w ay. Except where your use constitutes "fair use" under copyright law , you may
and Reviewers not use, share, download, upload, copy , print, display , perf orm, reproduce, publish,
license, post, transmit, or distribute this document in whole or in part without the
Todd Bao express authorization of Oracle.
Harald van Breederode The inf ormation contained in this document is subject to change without notice. If y ou
Michael Cebulla f ind any problems in the document, please report them in writing to: Oracle Univ ersity ,
500 Oracle Parkway , Redwood Shores, Calif ornia 94065 USA. This document is not
Joel Goodman w arranted to be error-free.
Uwe Hesse
Restricted Rights Notice
Pete Jones
If this documentation is deliv ered to the United States Gov ernment or any one using
Nitin Karkhanis
the documentation on behalf of the United States Gov ernment, the f ollowing notice is
Frank Kobylanski applicable:
Sadhana Kyathappala U.S. GOVERNMENT RIGHTS
Stephen Moriarty The U.S. Gov ernment’s rights to use, modif y , reproduce, release, perf orm, display , or
disclose these training materials are restricted by the terms of the applicable Oracle
Javier Saiz license agreement and/or the applicable U.S. Gov ernment contract.
Madhavi Siddireddy
Trademark Notice
Jim Spiller
Oracle and Jav a are registered trademarks of Oracle and/or its af f iliates. Other names
Milgred Tumolo
may be trademarks of their respectiv e owners.
Branislav Valny
Jean-Francois Verrier
Pam Welford
Editors
Aju Kumar
Amitha Narayan
Nita Pavitran
Graphic Designer
Satish Bettegowda
Publishers
Syed Imtiaz Ali
Sumesh Koshy
Veena Narasimhan
Contents
Preface
1 Introduction to Oracle Data Guard

Objectives 1-2
What Is Oracle Data Guard? 1-3
Oracle University and Digit racunarski inzenjering d.o.o use only

Types of Standby Databases 1-4
Types of Data Guard Services 1-6
Role Transitions: Switchover and Failover 1-7
Oracle Data Guard Broker Framework 1-9
Choosing an Interface for Administering a Data Guard Configuration 1-10
Oracle Data Guard: Architecture (Overview) 1-11
Primary Database Processes 1-12
Standby Database Processes 1-13
Physical Standby Database: Redo Apply Architecture 1-14
Logical Standby Database: SQL Apply Architecture 1-15
Automatic Gap Detection and Resolution 1-16
Data Protection Modes 1-17
Data Guard Operational Requirements: Hardware and Operating System 1-19
Data Guard Operational Requirements: Oracle Database Software 1-20
Benefits of Implementing Oracle Data Guard 1-21
Quiz 1-22
Summary 1-24
2 Creating a Physical Standby Database by Using SQL and RMAN Commands

Objectives 2-2
Steps to Create a Physical Standby Database 2-3
Preparing the Primary Database 2-4
FORCE LOGGING Mode 2-5
Configuring Standby Redo Logs 2-7
Creating Standby Redo Logs 2-8
Using SQL to Create Standby Redo Logs 2-9
Viewing Standby Redo Log Information 2-10
Setting Initialization Parameters on the Primary Database to Control
Redo Transport 2-11
Setting LOG_ARCHIVE_CONFIG 2-12
Setting LOG_ARCHIVE_DEST_n 2-14
iii
Specifying Role-Based Destinations 2-15
Combinations for VALID_FOR 2-17

Defining the Redo Transport Mode 2-18
Setting Initialization Parameters on the Primary Database 2-19
Specifying Values for DB_FILE_NAME_CONVERT 2-20
Specifying Values for LOG_FILE_NAME_CONVERT 2-21
Specifying a Value for STANDBY_FILE_MANAGEMENT 2-22
Example: Setting Initialization Parameters on the Primary Database 2-23
Creating an Oracle Net Service Name for Your Physical Standby Database 2-24
Creating a Listener Entry for Your Standby Database 2-25

Copying Your Primary Database Password File to the Physical Standby
Database Host 2-26
Creating an Initialization Parameter File for the Physical Standby Database 2-27
Creating Directories for the Physical Standby Database 2-28
Starting the Physical Standby Database 2-29
Setting FAL_CLIENT and FAL_SERVER Initialization Parameters 2-30
Creating an RMAN Script to Create the Physical Standby Database 2-31
Creating the Physical Standby Database 2-33
Enabling Real-Time Apply 2-34
Starting Redo Apply 2-36
Special Note: Standby Database on the Same System 2-37
Preventing Primary Database Data Corruption from Affecting the
Standby Database 2-38
Quiz 2-40
Summary 2-42
Practice 2: Overview 2-43
3 Oracle Data Guard Broker: Overview

Objectives 3-2
Oracle Data Guard Broker: Features 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
Data Guard Monitor: DMON Process 3-8
Benefits of Using the Data Guard Broker 3-9
Comparing Configuration Management With and Without the Data
Guard Broker 3-10
Data Guard Broker Interfaces 3-11
Using the Command-Line Interface of the Data Guard Broker 3-12
Using Oracle Enterprise Manager 10g Grid Control 3-14
iv
Data Guard Overview Page 3-15
Benefits of Using Enterprise Manager 3-16

Quiz 3-17
Summary 3-19
4 Creating a Data Guard Broker Configuration

Objectives 4-2
Data Guard Broker: Requirements 4-3
Data Guard Broker and the SPFILE 4-5
Data Guard Monitor: Configuration File 4-7

Data Guard Broker: Log Files 4-8
Creating a Broker Configuration 4-9
Defining the Broker Configuration and the Primary Database Profile 4-10
Adding a Standby Database to the Configuration 4-11
Enabling the Configuration 4-12
Changing Database Properties and States 4-13
Managing Redo Transport Services by Using DGMGRL 4-14
Specifying the Connection Identifier by Using the DGConnectIdentifier
Property 4-15
Managing the Redo Transport Service by Using the LogXptMode Property 4-16
Setting LogXptMode to ASYNC 4-17
Setting LogXptMode to SYNC 4-18
Controlling the Shipping of Redo Data by Using the LogShipping Property 4-19
Disabling Broker Management of the Configuration or Standby Database 4-20
Removing the Configuration or Standby Database 4-21
Quiz 4-22
Summary 4-24
5 Creating a Physical Standby Database by Using Enterprise Manager Grid

Control
Objectives 5-2
Using Oracle Enterprise Manager to Create a Broker Configuration 5-3
Creating a Configuration 5-4
Creating a New Configuration 5-5
Adding a Standby Database to an Existing Configuration 5-6
Using the Add Standby Database Wizard 5-7
Step 1: Specify the Backup Type 5-8
Step 2: Specify the Backup Options (RMAN Direct Copy) 5-9
Step 2: Specify the Backup Options (Staging Areas Example) 5-10
Step 3: Select the Standby Database Location Instance Name 5-11
v
Step 3: Select the Standby Database Location Oracle Home 5-12
Step 4: Specify the Standby Database File Locations (Staging Method) 5-13
Step 4: Specify the Standby Database File Locations 5-14
Step 5: Specify Standby Database Configuration Parameters 5-15
Step 6: Review the Configuration Information 5-16
Standby Database Creation: Processing 5-17
Standby Database Creation: Progress 5-19
Verifying a Data Guard Configuration 5-20
Reviewing Results of the Verify Operation 5-21
Performing Routine Maintenance 5-22

Editing Standby Database Properties 5-23
Managing Apply Services 5-24
Changing the Basic Properties of a Database 5-25
Changing the Advanced Properties of a Database 5-26
Setting the Redo Transport Mode by Using Enterprise Manager 5-27
Quiz 5-28
Summary 5-30
6 Creating a Logical Standby Database

Objectives 6-2
Benefits of Implementing a Logical Standby Database 6-3
Logical Standby Database: SQL Apply Architecture 6-5
SQL Apply Process: Architecture 6-6
Preparing to Create a Logical Standby Database 6-7
Unsupported Objects 6-8
Unsupported Data Types 6-9
Checking for Unsupported Tables 6-10
Checking for Tables with Unsupported Data Types 6-11
SQL Commands That Do Not Execute on the Standby Database 6-12
Unsupported PL/SQL Supplied Packages 6-13
Ensuring Unique Row Identifiers 6-14
Adding a Disabled Primary Key RELY Constraint 6-16
Creating a Logical Standby Database by Using SQL Commands 6-17
Step 1: Create a Physical Standby Database 6-18
Step 2: Stop Redo Apply on the Physical Standby Database 6-19
Step 3: Prepare the Primary Database to Support a Logical Standby Database 6-20
Step 4: Build a LogMiner Dictionary in the Redo Data 6-21
Step 5: Transition to a Logical Standby Database 6-22
Step 6: Open the Logical Standby Database 6-23
Adding a Logical Standby Database to a Data Guard Broker Configuration 6-24
vi
Step 7: Verify That the Logical Standby Database Is Performing
Properly 6-25
Step 7: Verify That the Logical Standby Database Is Performing Properly 6-26
Creating a Logical Standby Database by Using Enterprise Manager 6-27
Using the Add Standby Database Wizard 6-28
Securing Your Logical Standby Database 6-31
Automatic Deletion of Redo Log Files by SQL Apply 6-32
Managing Remote Archived Log File Retention 6-33
Managing SQL Apply Filtering 6-34
Viewing SQL Apply Filtering Settings 6-36

Managing SQL Apply Filtering by Using Enterprise Manager 6-37
Using DBMS_SCHEDULER to Create Jobs on a Logical Standby Database 6-38
Quiz 6-39
Summary 6-41
7 Creating and Managing a Snapshot Standby Database

Objectives 7-2
Snapshot Standby Databases: Overview 7-3
Snapshot Standby Database: Architecture 7-4
Converting a Physical Standby Database to a Snapshot Standby Database 7-5
Activating a Snapshot Standby Database: Issues and Cautions 7-6
Snapshot Standby Database: Target Restrictions 7-7
Viewing Snapshot Standby Database Information 7-8
Using DGMGRL to View Snapshot Standby Database Information 7-9
Converting a Snapshot Standby Database to a Physical Standby Database 7-11
Quiz 7-12
Summary 7-13
8 Using Oracle Active Data Guard

Objectives 8-2
Oracle Active Data Guard 8-3
Using Real-Time Query 8-4
Enabling Real-Time Query 8-5
Disabling Real-Time Query 8-7
Checking the Standby’s Open Mode 8-8
Understanding Lag in an Active Data Guard Configuration 8-9
Monitoring Apply Lag: V$DATAGUARD_STATS 8-10
Monitoring Apply Lag: V$STANDBY_EVENT_HISTOGRAM 8-11
Setting a Predetermined Service Level for Currency of Standby Queries 8-12
vii
Configuring Zero Lag Between the Primary and Standby Databases 8-13
Setting STANDBY_MAX_DATA_DELAY by Using an AFTER LOGON Trigger 8-14

Example: Setting STANDBY_MAX_DATA_DELAY by Using an AFTER
LOGON Trigger 8-15
Forcing Redo Apply Synchronization 8-16
Creating an AFTER LOGON Trigger for Synchronization 8-17
Supporting Read-Mostly Applications 8-18
Example: Transparently Redirecting Writes to the Primary Database 8-19
Enabling Block Change Tracking on a Physical Standby Database 8-20
Creating Fast Incremental Backups 8-21

Enabling Block Change Tracking 8-22
Monitoring Block Change Tracking 8-23
Quiz 8-24
Summary 8-25
9 Configuring Data Protection Modes

Objectives 9-2
Data Protection Modes and Redo Transport Modes 9-3
Data Protection Modes 9-4
Maximum Protection Mode 9-5
Maximum Availability Mode 9-6
Maximum Performance Mode 9-7
Comparing Data Protection Modes 9-8
Setting the Data Protection Mode by Using DGMGRL 9-9
Setting the Data Protection Mode 9-10
Quiz 9-12
Summary 9-13
10 Performing Role Transitions

Objectives 10-2
Role Management Services 10-3
Role Transitions: Switchover and Failover 10-4
Switchover 10-5
Switchover: Before 10-6
Switchover: After 10-7
Preparing for a Switchover 10-8
Performing a Switchover by Using DGMGRL 10-9
Performing a Switchover by Using Enterprise Manager 10-10
viii
Considerations When Performing a Switchover to a Logical Standby
Database 10-13
Situations That Prevent a Switchover 10-14
Failover 10-15
Types of Failovers 10-16
Failover Considerations 10-17
Performing a Manual Failover by Using DGMGRL 10-18
Reenabling Disabled Databases by Using DGMGRL 10-19
Performing a Failover by Using Enterprise Manager 10-20
Performing a Failover to a Physical Standby Database 10-23

Performing a Failover to a Logical Standby Database 10-24
Quiz 10-25
Summary 10-27
11 Using Flashback Database in a Data Guard Configuration

Objectives 11-2
Using Flashback Database in a Data Guard Configuration 11-3
Overview of Flashback Database 11-4
Configuring Flashback Database 11-5
Configuring Flashback Database by Using Enterprise Manager 11-6
Using Flashback Database Instead of Apply Delay 11-8
Using Flashback Database and Real-Time Apply 11-9
Using Flashback Database After RESETLOGS 11-10
Flashback Through Standby Database Role Transitions 11-12
Using Flashback Database After Failover 11-13
Quiz 11-14
Summary 11-15
12 Enabling Fast-Start Failover

Objectives 12-2
Fast-Start Failover: Overview 12-3
When Does Fast-Start Failover Occur? 12-4
Installing the Observer Software 12-5
Fast-Start Failover Prerequisites 12-6
Configuring Fast-Start Failover 12-7
Step 1: Specify the Target Standby Database 12-8
Step 2: Set the Protection Mode 12-9
Step 3: Set the Fast-Start Failover Threshold 12-10
Step 4: Set Additional Fast-Start Failover Properties 12-11
ix
Setting the Lag-Time Limit 12-12
Configuring the Primary Database to Shut Down Automatical y 12-13

Automatic Reinstatement After Fast-Start Failover 12-14
Configuring Automatic Reinstatement of the Primary Database 12-16
Setting a Connect Identifier for the Observer 12-17
Step 5: Configure Additional Fast-Start Failover Conditions 12-18
Configuring Fast-Start Failover Conditions 12-20
Step 6: Enable Fast-Start Failover 12-21
Step 7: Start the Observer 12-22
Step 8: Verify the Configuration 12-24

Initiating Fast-Start Failover from an Application 12-25
Viewing Fast-Start Failover Information 12-27
Determining the Reason for a Fast-Start Failover 12-29
Prohibited Operations After Enabling Fast-Start Failover 12-30
Disabling Fast-Start Failover 12-31
Disabling Fast-Start Failover Conditions 12-33
Using the FORCE Option 12-34
Stopping the Observer 12-35
Performing Manual Role Changes 12-36
Manual y Reinstating the Database 12-37
Using Enterprise Manager to Enable Fast-Start Failover 12-38
Using Enterprise Manager to Enable Fast-Start Failover 12-42
Changing the Protection Mode and Disabling Fast-Start Failover 12-44
Using Enterprise Manager to Disable Fast-Start Failover 12-45
Using Enterprise Manager to Suspend Fast-Start Failover 12-46
Moving the Observer to a New Host 12-47
Quiz 12-48
Summary 12-50
13 Managing Client Connectivity

Objectives 13-2
Understanding Client Connectivity in a Data Guard Configuration 13-3
Understanding Client Connectivity: Using Local Naming 13-4
Preventing Clients from Connecting to the Wrong Database 13-5
Managing Services 13-6
Understanding Client Connectivity: Using a Database Service 13-7
Creating Services for the Data Guard Configuration Databases 13-8
Configuring Role-Based Services 13-9
Adding Standby Databases to Oracle Restart Configuration 13-11
Example: Configuring Role-Based Services 13-12
x
Connecting Clients to the Correct Database 13-13
Creating the AFTER STARTUP Trigger 13-14

Configuring Service Names in the tnsnames.ora File 13-15
Automatic Failover of Applications to a New Primary Database 13-16
Data Guard Broker and Fast Application Notification (FAN) 13-17
Enabling FAN Events in an Oracle Restart Environment 13-18
Automating Client Failover in a Data Guard Configuration 13-19
Client Failover: Components 13-20
Client Failover: Best Practices 13-21
Automating Failover for OCI Clients 13-22

Automating Failover for OLE DB Clients 13-24
Configuring OLE DB Clients for Failover 13-25
Automating Failover for JDBC Clients 13-26
Configuring JDBC Clients for Failover 13-27
Quiz 13-28
Summary 13-30
14 Backup and Recovery Considerations in an Oracle Data Guard Configuration

Objectives 14-2
Using RMAN to Back Up and Restore Files in a Data Guard Configuration 14-3
Offloading Backups to a Physical Standby 14-4
Restrictions and Usage Notes 14-5
Backup and Recovery of a Logical Standby Database 14-6
Using the RMAN Recovery Catalog in a Data Guard Configuration 14-7
Creating the Recovery Catalog 14-8
Registering a Database in the Recovery Catalog 14-10
Setting Persistent Configuration Settings 14-11
Setting RMAN Persistent Configuration Parameters on the Primary Database 14-13
Setting RMAN Persistent Configuration Parameters on the Physical Standby
Database 14-15
Setting RMAN Persistent Configuration Parameters on the Other Standby
Databases 14-16
Configuring Daily Incremental Backups 14-17
Recovering from Loss of a Data File on the Primary Database 14-19
Using a Backup to Recover a Data File on the Primary Database 14-20
Using a Physical Standby Database Data File to Recover a Data File on the
Primary Database 14-21
Recovering a Data File on the Standby Database 14-23
Enhancements to Block Media Recovery 14-24
Executing the RECOVER BLOCK Command 14-26
xi
Excluding the Standby Database 14-27
Quiz 14-28
Summary 14-30
15 Patching and Upgrading Databases in a Data Guard Configuration

Objectives 15-2
Upgrading an Oracle Data Guard Broker Configuration 15-3
Upgrading Oracle Database in a Data Guard Configuration with a Physical

Upgrading Oracle Database in a Data Guard Configuration with a Logical
Using SQL Apply to Upgrade the Oracle Database 15-7
Requirements for Using SQL Apply to Perform a Rolling Upgrade 15-8
Performing a Rolling Upgrade by Using SQL Apply 15-9
Identifying Unsupported Data Types 15-10
Performing a Rolling Upgrade by Using an Existing Logical Standby
Database 15-11
Performing a Rolling Upgrade by Creating a New Logical Standby Database 15-17
Performing a Rolling Upgrade by Using a Physical Standby Database 15-18
Quiz 15-24
Summary 15-26
16 Monitoring a Data Guard Broker Configuration

Objectives 16-2
Monitoring the Data Guard Configuration by Using Enterprise Manager Grid
Control 16-3
Viewing the Data Guard Configuration Status 16-4
Monitoring Data Guard Performance 16-5
Viewing Log File Details 16-6
Enterprise Manager Metrics and Alerts 16-7
Data Guard Metrics 16-8
Managing Data Guard Metrics 16-9
Viewing Metric Value History 16-10
Viewing Data Guard Diagnostic Information 16-11
Using Monitorable Database Properties to Identify a Failure 16-12
Using the SHOW CONFIGURATION DGMGRL Command to Monitor the
Configuration 16-13
Using the SHOW DATABASE DGMGRL Command to Monitor the
Configuration 16-14
Using the SHOW DATABASE VERBOSE DGMGRL Command to Monitor the
xii
Configuration 16-15
Viewing Standby Redo Log Information in V$LOGFILE 16-16

Viewing Standby Redo Log Information in V$STANDBY_LOG 16-17
Identifying Destination Settings 16-18
Setting the LOG_ARCHIVE_TRACE Initialization Parameter 16-19
Monitoring Redo Apply by Querying V$MANAGED_STANDBY 16-21
Evaluating Redo Data by Querying V$DATAGUARD_STATS 16-22
Viewing Data Guard Status Information by Querying V$DATAGUARD_STATUS 16-23
Viewing V$LOGSTDBY_TRANSACTION 16-24

Quiz 16-25
Summary 16-27
17 Optimizing a Data Guard Configuration

Objectives 17-2
Monitoring Configuration Performance by Using Enterprise Manager Grid
Control 17-3
Optimizing Redo Transport Services 17-4
Setting the ReopenSecs Database Property 17-5
Setting the NetTimeout Database Property 17-6
Optimizing Redo Transmission by Setting MaxConnections 17-7
Setting the MaxConnections Database Property 17-8
Compressing Redo Data by Setting the RedoCompression Property 17-9
Delaying the Application of Redo 17-10
Setting the DelayMins Database Property to Delay the Application of Redo 17-11
Using Enterprise Manager to Delay the Application of Redo 17-12
Optimizing SQL Apply 17-13
Adjusting the Number of APPLIER Processes 17-14
Adjusting the Number of PREPARER Processes 17-15
Quiz 17-17
Summary 17-19
xiii
xiv
Preface


Profile
Before You Begin This Course
Before you begin this course, you should be able to perform basic Oracle Database
11g administration.
How This Course Is Organized
Oracle Database 11g: 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 that are introduced.
Preface - 3
Related Publications
Oracle Publications
Title Part Number

Oracle ® Data Guard Concepts and Administration 11g
Release 2 (11.2) E10700-02
Oracle® Data Guard Broker 11g Release 2 (11.2) E10702-02
Oracle® Database High Availability Overview 11g
Release 2 (11.2) E10804-03
Oracle® Database Backup and Recovery Reference 11g
Release 2 (11.2) E10643-02
Oracle® Database Backup and Recovery User's Guide
11g Release 2 E10642-02
Additional Publications
• System release bulletins
• Installation and user’s guides
• read.me files
• International Oracle User’s Group (IOUG) articles
• Oracle Magazine
Preface - 4
Typographic Conventions
The following two lists explain Oracle University typographical conventions for
words that appear within regular text or within code samples.
1. Typographic Conventions for Words Within Regular Text

Convention Object or Term Example
Courier New User input; Use the SELECT command to view
commands; information stored in the LAST_NAME
column, table, and column of the EMPLOYEES table.
schema names;

functions; Enter 300.
PL/SQL objects;
paths Log in as scott
Initial cap Triggers; Assign a When-Validate-Item trigger to

user interface object the ORD block.
names, such as
button names Click the Cancel button.
Italic Titles of For more information on the subject see

courses and Oracle SQL Reference
manuals; Manual
emphasized
words or phrases; Do not save changes to the database.
placeholders or
variables Enter hostname, where
hostname is the host on which the
password is to be changed.
Quotation marks Lesson or module This subject is covered in Lesson 3,

titles referenced “Working with Objects.”
within a course
Preface - 5
Typographic Conventions (continued)
2. Typographic Conventions for Words Within Code Samples

Convention Object or Term Example
Uppercase Commands, SELECT employee_id
functions FROM employees;
Lowercase, Syntax variables CREATE ROLE role;
italic
Initial cap Forms triggers Form module: ORD
Trigger level: S_ITEM.QUANTITY

item
Trigger name: When-Validate-Item
. . .
Lowercase Column names, . . .
table names, OG_ACTIVATE_LAYER
filenames, (OG_GET_LAYER ('prod_pie_layer'))
PL/SQL objects . . .
SELECT last_name
FROM employees;
Bold Text that must CREATE USER scott
be entered by a IDENTIFIED BY tiger;
user
Preface - 6
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

Introduction to Oracle Data Guard

Objectives
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COM PUTER IS STRICTLY PROHIBITED
After completing this lesson, you should be able to:

• Describe the basic components of Oracle Data Guard
• Explain the differences between physical and logical
standby databases
• Explain the benefits of implementing Oracle Data Guard

Oracle Database 11g: Data Guard Administration 1-2

What Is Oracle Data Guard?
Primary Standby
database Redo transport database

Oracle Net
Database Database
copy
What Is Oracle Data Guard?

Oracle Data Guard is a central component of an integrated Oracle Database High Availability (HA)
solution set that helps organizations ensure business continuity by minimizing the various kinds of
planned and unplanned down time that can affect their businesses.
Oracle Data Guard is a management, monitoring, and automation software infrastructure that works
with a production database and one or more standby databases to protect your data against failures,
errors, and corruptions that might otherwise destroy your database. It protects critical data by providing
facilities to automate the creation, management, and monitoring of the databases and other
components in a Data Guard configuration. It automates the process of maintaining a copy of an Oracle
production database (called a standby database) that can be used if the production database is taken
offline for routine maintenance or becomes damaged.
In a Data Guard configuration, a production database is referred to as a primary database.
A standby database is a synchronized copy of the primary database. Using a backup copy of the
primary database, you can create from one to 30 standby databases. The standby databases, together
with the primary database, make up a Data Guard configuration.
All Data Guard standby databases can enable up-to-date read access to the standby database while
redo being received from the primary database is applied. This makes al standby databases excellent
candidates for relieving the primary database of the overhead of supporting read-only queries and
reporting.

Types of Standby Databases
• Physical standby database:

– Is identical to the primary database on a block-for-block
basis
– Is synchronized with the primary database through
application of redo data received from the primary database

– Can be used concurrently for data protection and reporting
• Logical standby database
– Shares the same schema definition
– 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
– Can be used concurrently for data protection, reporting, and
database upgrades

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. Oracle Database 11g enables a physical standby database to
receive and apply redo while it is open in read-only mode.
Logical Standby Database
A logical standby database contains the same logical information (unless configured to skip
certain objects) as the production database, although the physical organization and structure
of the data can be different. The logical standby database is kept synchronized with the
primary database by transforming the data in the redo received from the primary database
into SQL statements and then executing the SQL statements on the standby database. This is
done with the use of LogMiner technology on the redo data 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.
Note: For more information about LogMiner, see Oracle Database Utilities in the Oracle
Database 11g documentation.

• Snapshot standby database:

– Is a fully updatable standby database
– Is created by converting a physical standby database
– Can be used for updates, but those updates are discarded
before the snapshot standby database is converted back into

a physical standby database
– Can be used for testing
Types of Standby Databases (continued)

Snapshot Standby Database
A snapshot standby database is a database that is created by converting a physical standby
database into a snapshot standby database. The snapshot standby database receives redo
from the primary database, but does not apply the redo data until it is converted back into a
physical standby database. The snapshot standby database can be used for updates, but
those updates are discarded before the snapshot standby database is converted back into a
physical standby database. The snapshot standby database is appropriate when you require
a temporary, updatable version of a physical standby database.

Types of Data Guard Services
Data Guard provides three types of services:

• Redo transport services
• Apply services
– Redo Apply
– SQL Apply

• Role management services
Types of Data Guard Services

The following types of services are available with Data Guard:
• Redo transport services: Control the automated transmittal of redo information from
the primary database to one or more standby databases or archival destinations.
• Apply services: Control when and how data is applied to the standby database.
- Redo Apply: Technology used for physical standby databases. Redo data is
applied on the standby database by using Oracle media recovery.
- 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 redo
transport services and apply services to change these roles dynamically as a planned
transition (called a switchover operation) or as a result of database failure due to 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
– Emergency use
– Zero or minimal data loss (depending on choice of data-
protection mode)
– Can be initiated automatically when fast-start failover is
enabled

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. Data Guard supports two
role-transition operations:
• Switchover: The switchover feature enables you 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. 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. You can also enable fast-start failover, which allows Data
Guard to automatically and quickly fail over to a previously chosen synchronized
standby database.
Note: Fast-start failover is discussed in detail in the lesson titled ―Enabling Fast-Start
Failover.‖

Role Transitions: Switchover and Failover (continued)
Databases that are disabled after a role transition are not removed from the broker
configuration, but they are disabled in the sense that the databases are no longer managed by
the broker. To reenable broker management of these databases, you must reinstate or re-create
the databases.
Note: See the lesson titled ―Performing Switchover and Failover‖ for detailed information.

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
creating the Data Guard configuration, the broker monitors the activity, health, and availability
of all systems in the configuration.

Choosing an Interface for Administering
a Data Guard Configuration

• Data Guard broker configuration:
– DGMGRL command-line interface
– Enterprise Manager Grid Control
– SQL commands to query data dictionary views
• Non–Data Guard broker configuration:

– SQL commands
Choosing an Interface for Administering a Data Guard Configuration

You can use Oracle Enterprise Manager Grid Control or the Data Guard broker’s own
specialized command-line interface (DGMGRL) to take advantage of the broker’s
management capabilities.
Enterprise Manager Grid Control 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 DGMGRL 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 DGMGRL prompt or in scripts.
If you do not create a Data Guard broker configuration, you can manage your standby
databases by using SQL commands.
Oracle Database 11g: Data Guard Administration 1 - 10

Oracle Data Guard: Architecture
Primary
(Overview)
database MRP or Standby
transactions LSP database
LNSn RFS
Redo
buffer
Oracle n et
LGWR (Real-time

apply)
Standby Backup
Online redo logs
redo
logs Reports
ARC0
Gap
ARC0 resolution
Archived redo Archived redo

logs logs
Oracle Data Guard: Architecture (Overview)

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 before 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 Processes
Primary
MRP or Standby
database
LSP database
transactions
LNSn RFS
Redo
buffer
Oracle n et
LGWR (Real-time

apply)
Standby Backup
Online redo logs
redo
logs Reports
ARC0
Gap
ARC0 resolution

logs logs
Primary Database Processes

On the primary database, Data Guard uses the following processes:
• Log writer (LGWR): LGWR collects transaction redo information and updates the online
redo logs. For each synchronous (SYNC) standby database, LGWR passes the redo to
an LNS (Log Writer Network Server) process, which ships the redo directly to the remote
file server (RFS) process on the standby database. LGWR waits for confirmation from
the LNS process before acknowledging the commit. For asynchronous (ASYNC)
standby databases, independent LNS processes read the redo from either the redo log
buffer in memory or the online redo log file, and then ship the redo to its standby
database. Other than starting the asynchronous LNS processes, LGWR has no
interaction with any asynchronous standby destination.
• Archiver (ARCn): The ARCn process creates a copy of the online redo log files locally
for use in a primary database recovery operation. ARCn is also responsible for shipping
redo data to an RFS process at a standby database and for proactively detecting and
resolving gaps on all standby databases. For Oracle Database 11g Release 2 (11.2),
there can now be 30 archiver processes. The default value is four.

Standby Database Processes
Primary
MRP or Standby
database
LSP database
transactions
LNSn RFS
Redo
buffer
Oracle n et
LGWR (Real-time

apply)
Standby Backup
Online redo logs
redo
logs Reports
ARC0
Gap
ARC0 resolution

logs logs
Standby Database Processes

On the standby database, Data Guard uses the following processes:
• Remote file server (RFS): RFS receives redo information from the primary database
and can write the redo into standby redo logs or directly to archived redo logs. Each
LNSn and ARCn process from the primary database has its own RFS process.
Note: The use of standby redo logs is discussed in more detail in the lesson titled
―Creating a Physical Standby Database by Using SQL and RMAN Commands.‖
• Archiver (ARCn): The ARCn process archives the standby redo logs.
• Managed recovery (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 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE SQL statement,
this foreground session performs the recovery. If you use the optional DISCONNECT
[FROM SESSION] clause, the MRP background process starts. If you use the Data
Guard broker to manage your standby databases, the broker always starts the MRP
background process for a physical standby database.
• Logical standby (LSP): For logical standby databases only, LSP controls the
application of archived redo log information to the logical standby database.

Physical Standby Database:
Redo Apply Architecture

Production Physical standby
database database
Redo Redo
transport apply

Redo
stream
Backup
Primary Physical standby

database database
Physical Standby Database: 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 30) that are identical copies of the production database. The limit of 30 standby
databases is imposed by the LOG_ARCHIVE_DEST_n parameter. For Oracle Database
11g Release 2 (11.2), the maximum number of destinations is 31. One is used as the
local archive destination, leaving the other 30 for uses such as the standby database.
Note: You can use the Cascaded Redo Log Destinations feature to incorporate more
than 30 standby databases in your configuration.
• The standby database, which is updated by redo that is automatically shipped from the
primary database. The redo can be shipped as it is generated or archived on the primary
database. Redo is applied to each standby database by using Oracle media recovery.
During planned down time, you can perform a switchover to a standby database. When
a failure occurs, you can perform a failover to one of the standby databases. The
physical standby database can also be used to back up the primary database.

Logical Standby Database:
SQL Apply Architecture

Production Logical standby
database database
Redo SQL
transport Apply

Transform redo
information into
SQL
Reports
Primary Logical standby

database database
Logical Standby Database: 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), the redo data 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. By opening the logical standby database in
read/write mode, additional reporting structures such as indexes or materialized views can be
created that do not exist in the primary database.
A logical standby database can be used to perform rolling database upgrades, thereby
minimizing down time when upgrading to new database patch sets or full database releases.

Automatic Gap Detection and Resolution
Primary
MRP or Standby
database
LSP database
transactions
LNSn RFS
Redo
buffer
Oracle n et
LGWR (Real-time

apply)
Standby
Online redo logs Backup
redo
logs Reports
ARC0
ARCH ping
ARC0
Redo to
resolve
Archived redo gap Archived redo
logs logs
Automatic Gap Detection and Resolution

If connectivity is lost between the primary database and one or more standby databases, redo
data that is being generated on the primary database cannot be sent to those standby
databases. When a connection is reestablished, Data Guard automatical y detects that there
are missing archived redo log files (referred to as a gap), and then automatically transmits the
missing archived redo log files to the standby databases by using the ARCn processes. The
standby databases are synchronized with the primary database without manual intervention
by the DBA.

Data Protection Modes
Select the mode to balance cost, availability, performance, and

data protection:
• Maximum protection
• Maximum availability
• Maximum performance


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. For
this level of protection, the redo data that is needed to recover each transaction must be
written to both the local online redo log and the standby redo log (used to store redo data
received from another database) on at least one standby database before the transaction
commits. To ensure that data loss does not occur, the primary database shuts down if a fault
prevents it from writing its redo stream to at least one remote standby redo log.

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 an unsynchronized
mode until the fault is corrected and all the gaps in the redo log files are resolved. When all the
gaps are resolved and the primary database is synchronized with the standby database, 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)
The 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 all ASYNC
standby databases and is written asynchronously with respect to the commitment of the
transactions that create the redo data.

Data Guard Operational Requirements:
Hardware and Operating System

Primary database systems and standby database systems
may have different:
• CPU architectures
• Operating systems
• Operating system binaries (32-bit or 64-bit)

• Oracle Database binaries (32-bit or 64-bit)
Many restrictions exist.
Hardware and Operating System Requirements

These are the requirements for Data Guard:
• 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 systems for both databases and operating system binaries can be
different such as Linux and Windows.
If the primary and standby databases are both on the same server, you must ensure that the
operating system enables you to mount two databases with the same name on the same
system simultaneously. Certain parameters must be specified to support this configuration, as
discussed in the lesson titled ―Creating a Physical Standby Database by Using SQL.‖
Refer to My Oracle Support notes 413484.1, 395982.1, and 414043.1 for additional
information.

Data Guard Operational Requirements:
Oracle Database Software

• The same release of Oracle Database Enterprise Edition
must be installed for all databases except when you
perform a rolling database upgrade by using a logical
standby database.
• If any database uses ASM or OMF, all databases should

use the same combination.
Data Guard Operational Requirements: 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. Oracle Data
Guard is available only as a feature of Oracle Database Enterprise Edition; it is not
available with Oracle Database Standard Edition.
Note: See the course titled Oracle Data Guard Concepts and Administration for
information about simulating a standby database environment when using Oracle
Database Standard Edition.
• 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 the same
combination (that is, ASM, OMF, or both).
Note: An exception to this guideline is if you are using Data Guard as a technique to
migrate to ASM and/or OMF.

Benefits of Implementing
Oracle Data Guard

Oracle Data Guard provides the following benefits:
• Continuous service during disasters or crippling data
failures
• Complete data protection against corruption and data loss
• Elimination of idle standby systems

• Flexible configuration of your system to meet requirements
for business protection and recovery
• Centralized management
Benefits of Implementing Oracle Data Guard

• Continuous service: With the use of switchover and failover between systems, your
business does not need to halt because of a disaster at one location.
• Complete data protection: Data Guard guarantees that there is no data loss and
provides a safeguard against data corruption and user errors. Redo data is validated
when applied to the standby database.
• Elimination of idle standby systems: Standby databases can be used for reporting
and
ad hoc queries in addition to providing a safeguard for disaster recovery. You can also
use the physical standby database to off-load backups of the primary database.
• Flexible configurations: You can use Data Guard to configure the system to your
needs by using the protection modes and several tunable parameters.
• Centralized management: You can use Enterprise Manager Grid Control to manage all
configurations in your enterprise.

Quiz
Which of the following are types of standby databases?

a. Physical
b. Primary
c. Logical
d. Snapshot

Answer: a, c, d

Quiz
What is the maximum number of standby databases supported

by the Data Guard Broker?
a. 10
b. 20
c. 30

d. 40
Answer: c

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

• 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


HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Using SQL and RMAN Commands
Creating a Physical Standby Database by

Objectives

• Configure the primary database and Oracle Net Services
to support the creation of the physical standby database
and role transition
• Create a physical standby database by using the

DUPLICATE TARGET DATABASE FOR STANDBY FROM
ACTIVE DATABASE RMAN command

Steps to Create
a Physical Standby Database

1. Prepare the primary database.
2. Set parameters on the physical standby database.
3. Configure Oracle Net Services.
4. Start the standby database instance.
5. Execute the DUPLICATE TARGET DATABASE FOR

STANDBY FROM ACTIVE DATABASE RMAN command.
6. Start the transport and application of redo.
Steps to Create a Physical Standby Database

You perform the steps listed in the slide to use SQL and RMAN commands to create a
physical standby database. Detailed information about each step is provided in the remaining
slides of the lesson.
Note: See Oracle Data Guard Concepts and Administration for detailed information about
creating a physical standby database by using only SQL commands.

Preparing the Primary Database
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
• Enable FORCE LOGGING at the database level.

• Create a password file if required.
• Create standby redo logs.
• Set initialization parameters.
• Enable archiving.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

Preparing the Primary Database

The FORCE LOGGING mode determines whether the Oracle database server logs all changes in the
database (except for changes to temporary tablespaces and temporary segments).
Note: Additional information about enabling FORCE LOGGING fol ows in this lesson.
Unless you have configured Oracle Advanced Security and public key infrastructure (PKI) certificates,
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 the Oracle Database Administrator’s Guide.
A standby redo log is used to store redo received from another Oracle database.
Note: Additional information about creating standby redo log files is provided in this lesson.
On the primary database, you define initialization parameters that control redo transport services while
the database is in the primary role. There are other 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. Additional information about setting initialization parameters is provided in this lesson.
Note: The Data Guard broker requires the use of a server parameter file.
If archiving is not enabled, issue the ALTER DATABASE ARCHIVELOG command to put the primary
database in ARCHIVELOG mode and enable automatic archiving. See the Oracle Database
Administrator’s Guide for additional information about archiving.

FORCE LOGGING Mode
• FORCE LOGGING mode 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;
FORCE LOGGING Mode

FORCE LOGGING mode determines whether 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.

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 the completion of all operations that are currently running in
NOLOGGING mode. 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 Data Guard
configuration exists.

Configuring Standby Redo Logs
Online Standby
redo Redo redo
logs shipment logs

RFS
Primary Standby
database database
Configuring 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 for all databases in a Data Guard
configuration to aid in role reversal.
A standby redo log is required to implement:
• Synchronous transport mode
• Real-time apply
• Cascaded redo log destinations
Note: By configuring the standby redo log on the primary database, the standby redo log is
created automatically on the standby database when you execute the DUPLICATE TARGET
DATABASE FOR STANDBY FROM ACTIVE DATABASE RMAN command.

Creating Standby Redo Logs
Standby Archived
Redo from redo logs redo logs
primary database

RFS ARC0
MRP/LSP
Standby database
Creating Standby Redo Logs

You must create at least one more standby redo log group than you have online redo log
groups as the primary database. In addition, each standby redo log file must be at least as
large as the largest redo log file in the redo log of the redo source database.
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 a standby redo log that is the same size as or larger than the incoming
online redo log file.
• All standby redo logs of the correct size have not yet been archived.

Using SQL to Create Standby Redo Logs
Create standby redo logs on the primary database to assist role

changes:
SQL> ALTER DATABASE ADD STANDBY LOGFILE
2 '/u01/app/oracle/oradata/orcl/srl01.log'
3 SIZE 50M;

Database altered.
or
SQL> ALTER DATABASE ADD STANDBY LOGFILE

2 '+DATA' SIZE 52428800;
Database altered.
Using SQL to Create 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.
You should create standby redo log files on the primary database prior to using the
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE RMAN command
so that RMAN creates standby redo log files automatically on the standby database.
Create standby redo log file groups by using the following guidelines:
• Each standby redo log file must be at least as large as the largest redo log file in the
redo source database. For administrative ease, Oracle recommends that all redo log
files in the redo source database and the redo transport destination be of the same size.
• The standby redo log must have at least one more redo log group than the redo log on
the redo source database.

Viewing Standby Redo Log Information
View information about the standby redo logs:

SQL> SELECT group#, type, member FROM v$logfile
2 WHERE type = 'STANDBY';
GROUP# TYPE MEMBER
------ ------- -----------------------------------
4 STANDBY /u01/app/oracle/oradata/pc01prmy/s rl01.log

5 STANDBY /u01/app/oracle/oradata/pc01prmy/srl02.log
SQL> SELECT group#, dbid, thread#, sequence#, status

2 FROM v$standby_log;
GROUP# DBID THREAD# SEQUENCE# STATUS
---------- ---------- ---------- ---------- ----------
4 2581955083 1 44 ACTIVE
5 UNASSIGNED 1 0 UNASSIGNED

To verify that standby redo logs were created, query V$STANDBY_LOG or V$LOGFILE. An
example output using Automatic Storage Management (ASM) is shown below:
SQL> SELECT group#, type, member FROM v$logfile WHERE type =
'STANDBY‘;
GROUP# TYPE MEMBER
---------- ------- ------------------------------------------------
4 STANDBY +SBDAT/pc01sby1/onlinelog/group_4.266.711624939
4 STANDBY +SBFRA/pc01sby1/onlinelog/group_4.259.711624941
8 rows selected.

Setting Initialization Parameters on the
Primary Database to Control Redo Transport
Parameter Name Description
LOG_ARCHIVE_CONFIG Specifies the unique database name for each

database in the configuration
Enables or disables sending and receiving of
redo

LOG_ARCHIVE_DEST_n Controls redo transport services
LOG_ARCHIVE_DEST_STATE_n Specifies the destination state
ARCHIVE_LAG_TARGET Forces a log switch after the specified

number of seconds
LOG_ARCHIVE_TRACE Controls output generated by the archiver
process
Setting Initialization Parameters on the Primary Database

On the primary database, you define initialization parameters that control redo transport
services while the database is in the primary role. These parameters are described in more
detail in the following slides.

Setting 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.
LOG_ARCHIVE_CONFIG='DG_CONFIG=(pc01prmy,pc01sby1)'

Setting LOG_ARCHIVE_CONFIG
Specify the DG_CONFIG attribute of the LOG_ARCHIVE_CONFIG parameter to list the
DB_UNIQUE_NAME of the primary and standby databases in the Data Guard configuration. By
default, the LOG_ARCHIVE_CONFIG parameter enables the database to send and receive
redo. The LOG_ARCHIVE_CONFIG parameter can be used to disable the sending of redo logs
to remote destinations or disable the receipt of remote redo logs. The complete syntax for the
LOG_ARCHIVE_CONFIG parameter is as follows:
LOG_ARCHIVE_CONFIG = {
[ SEND | NOSEND ][ RECEIVE | NORECEIVE ]
[ DG_CONFIG=(remote_db_unique_name1
[, ... remote_db_unique_name9) | NODG_CONFIG ] }
Use the V$DATAGUARD_CONFIG view to see the unique database names defined with the
DB_UNIQUE_NAME and LOG_ARCHIVE_CONFIG initialization parameters; you can thus view
the Data Guard environment from any database in the configuration. The first row of the view
lists the unique database name of the current database that was specified with the
DB_UNIQUE_NAME initialization parameter. Additional rows reflect the unique database
names of the other databases in the configuration that were specified with the DG_CONFIG
keyword of the LOG_ARCHIVE_CONFIG initialization parameter.

Setting LOG_ARCHIVE_CONFIG (continued)
The following example illustrates the use of V$DATAGUARD_CONFIG:
SQL> show parameter log_archive_config
NAME TYPE VALUE

------------------- ------- ---------------------------
log_archive_config string dg_config=(pc01prmy,pc01sby1)
SQL> SELECT * FROM v$dataguard_config;

DB_UNIQUE_NAME
------------------------------
pc01prmy
pc01sby1

Setting LOG_ARCHIVE_DEST_n
• Specify LOG_ARCHIVE_DEST_n parameters for:

– Local archiving
– Standby database location
• Include (at a minimum) one of the following:
– LOCATION: Specifies a valid path name

– SERVICE: Specifies a valid Oracle Net Services name
referencing a standby database
• Include a LOG_ARCHIVE_DEST_STATE_n parameter for
each defined destination.
LOG_ARCHIVE_DEST_2=
'SERVICE=pc01sby1
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=pc01sby1'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
Setting 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 Redo Transport Service is directly controlled by these
settings. There are a number of 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 complete list and a
description of each.
You should specify a LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 31)
for the local archiving destination and one for the standby location. In previous versions of the
Oracle Database, LOG_ARCHIVE_DEST_10 was set to USE_DB_RECOVERY_FILE_DEST
when the fast recovery area was being used. For Oracle Database 11g Release 2, this will
now have to be manually set. Query the V$ARCHIVE_DEST view to see current settings of the
LOG_ARCHIVE_DEST_n initialization parameter.
All defined LOG_ARCHIVE_DEST_n parameters must contain, at a minimum, either a
LOCATION attribute or a SERVICE attribute.
In addition, you must have a LOG_ARCHIVE_DEST_STATE_n parameter for each defined
destination. LOG_ARCHIVE_DEST_STATE_n defaults to ENABLE.

Specifying Role-Based Destinations
Primary Standby
database database

Not used
log_archive_dest_2 = log_archive_dest_2 =
'service=pc01sby1 async 'service=pc01prmy async
valid_for= valid_for=
(online_logfile, (online_logfile,
primary_role) primary_role)
db_unique_name=pc01sby1' db_unique_name=pc01prmy'
Specifying Role-Based Destinations

The VALID_FOR attribute of the LOG_ARCHIVE_DEST_n initialization parameter enables you
to identify exactly when the archive destination is to be used, as well as which type of log file it
is used for. The attribute uses a keyword pair to identify the redo log type as well as the
database role. Using this attribute enables you to set up parameters in anticipation of
switchover and failover operations.
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 to be used on the
standby database only 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: redo_log_type and database_role.
The redo_log_type keywords are:
• 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 the
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).

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 in the slide, Valid indicates that the archive log destination is used in a database
that is in the role defined by the column heading. Ignored means that the archive log
destination is not appropriate and that a destination of this type is ignored. An ignored
destination does not generate an error.
There is only one invalid combination: STANDBY_LOGFILE, PRIMARY_ROLE. Specifying this
combination causes an error for all database roles. If it is set, you receive the following error
at startup:
ORA-16026: The parameter LOG_ARCHIVE_DEST_n contains an
invalid attribute value
Note: Both single and plural forms of the keywords are valid. For example, you can specify
either PRIMARY_ROLE or PRIMARY_ROLES, as well as ONLINE_LOGFILE or
ONLINE_LOGFILES.

Defining the Redo Transport Mode
Use the attributes of LOG_ARCHIVE_DEST_n:

• SYNC and ASYNC
– Specify that network I/O operations are to be performed
synchronously or asynchronously when using LGWR.
– ASYNC is the default.

• AFFIRM and NOAFFIRM
– Ensure that redo was successfully written to disk
on the standby destination.
– NOAFFIRM is the default when ASYNC is specified;
AFFIRM is the default when SYNC is specified.
Defining the Redo Transport Mode

The following attributes of the LOG_ARCHIVE_DEST_n initialization parameter define the redo
transport mode that is used by the primary database to send redo to the standby database.
• SYNC: Specifies that redo data generated by a transaction must have been received at a
destination that has this attribute before the transaction can commit; otherwise, the
destination is deemed to have failed. In a configuration with multiple SYNC destinations,
the redo must be processed as described here for every SYNC destination.
• ASYNC (default): Specifies that redo data generated by a transaction need not have
been received at a destination that has this attribute before the transaction can commit
• AFFIRM: Specifies that a redo transport destination acknowledges received redo data
after writing it to the standby redo log
• NOAFFIRM : Specifies that a redo transport destination acknowledges received redo data
before writing it to the standby redo log
If neither the AFFIRM nor the NOAFFIRM attribute is specified, the default is AFFIRM when the
SYNC attribute is specified and NOAFFIRM when the ASYNC attribute is specified.
Note: Specifying the AFFIRM attribute with the SYNC attribute is deprecated and will not be
supported in future releases.

Setting Initialization Parameters
on the Primary Database

• Specify parameters when standby databases have disk or
directory structures that differ from the primary database.
• Use parameters when the primary database is transitioned
to a standby database.
Parameter Name Description

DB_FILE_NAME_CONVERT Converts primary database file names
LOG_FILE_NAME_CONVERT Converts primary database log file names
STANDBY_FILE_MANAGEMENT Controls automatic standby file management

The parameters listed in the slide are required if the disk configuration is not the same for the
primary and standby databases. The parameters are also applicable when the primary
database is transitioned to a standby database.

Specifying Values for
DB_FILE_NAME_CONVERT
• DB_FILE_NAME_CONVERT must be defined on standby
databases that have different disk or directory structures
from the primary.
• Multiple pairs of file names can be listed in the
DB_FILE_NAME_CONVERT parameter.

• DB_FILE_NAME_CONVERT applies only to a physical
standby database.
• DB_FILE_NAME_CONVERT can be set in the DUPLICATE
RMAN script.
DB_FILE_NAME_CONVERT =('/oracle1/dba/',
'/ora1/stby_dba/',
'/oracle2/dba/',
'/ora2/stby_dba/')
Specifying Values for DB_FILE_NAME_CONVERT

When files are added to the standby database, 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, the
recovery process halts with an error.
You 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. Parentheses are optional.
In the example in the slide, /oracle1/dba/ and /oracle2/dba/ are used to match file
names coming from the primary database. /ora1/stby_dba/ and /ora2/stby_dba/ are
the corresponding strings for the physical standby database. A file on the primary database
named /oracle1/dba/system01.dbf is converted to
/ora1/stby_dba/system01.dbf on the standby database.
Multiple pairs can be specified such as ('a','b','1','2').
Note: If the standby database uses Oracle Managed Files (OMF), do not set the
DB_FILE_NAME_CONVERT parameter. There is a 255-character limit on this parameter.
Specifying Values for
LOG_FILE_NAME_CONVERT
• LOG_FILE_NAME_CONVERT is similar to
DB_FILE_NAME_CONVERT.
• LOG_FILE_NAME_CONVERT must be defined on standby
databases that have different disk or directory structures
from the primary.

• LOG_FILE_NAME_CONVERT applies only to a physical
standby database.
• LOG_FILE_NAME_CONVERT can be set in the DUPLICATE
RMAN script.
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.
Both DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters perform simple
string substitutions. For example, ('a','b') will transform the following:
/disk1/primary/mya/a.dbf into
/disk1/primbry/myb/b.dbf
Multiple pairs can be specified such as ('a','b','1','2').
Note: If the standby database uses OMF, do not set the LOG_FILE_NAME_CONVERT
parameter. There is a 255-character limit on this parameter.

Specifying a Value for
STANDBY_FILE_MANAGEMENT
• STANDBY_FILE_MANAGEMENT is used to maintain
consistency when you add or delete a data file on the
primary database.
– MANUAL (default)
— Data files must be manually added to the standby database.

– AUTO
— Data files are automatically added to the standby database.
— Certain ALTER statements are no longer allowed on the standby
database.
• STANDBY_FILE_MANAGEMENT applies to physical standby
databases only, but can be set on a primary database for
role changes.
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 a log file to the primary database and want to add it to the physical standby
database as well (or when you drop a log file from the primary and want to drop it from the
physical), you must do the following:
1. Set STANDBY_FILE_MANAGEMENT to MANUAL on the physical standby database.
2. Add the redo log files to (or drop them from) the primary database.
3. Add them to (or drop them from) the standby database.
4. Reset to AUTO afterward on the standby database.

Example: Setting Initialization Parameters
DB_NAME=pc01prmy
DB_UNIQUE_NAME=pc01prmy
LOG_ARCHIVE_CONFIG='DG_CONFIG=(pc01prmy,pc01sby1)'
CONTROL_FILES='/u01/app/oracle/oradata/pc01prmy/control1.ctl',
'/u01/app/oracle/oradata/pc01prmy/control2.ctl'
LOG_ARCHIVE_DEST_2=

'SERVICE=pc01sby1
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=pc01sby1'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc

In the example in the slide, assume that the primary database is named pc01prmy and the
standby is named pc01sby1. 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:
DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/pc01sby1/',
'/u01/app/oracle/oradata/pc01prmy/'
LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/pc01sby1/',
'/u01/app/oracle/oradata/pc01prmy/'
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.
Note: The convert parameters can also be used to change ASM disk groups, for example:
DB_FILE_NAME_CONVERT=('+DATA','+SBDAT')

Creating an Oracle Net Service Name
for Your Physical Standby Database

Use Oracle Net Manager to update the tnsnames.ora file:
PC01SBY1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)

(HOST = edbvr6p2.us.oracle.com)
(PORT = 12001))
)
(CONNECT_DATA =
(SERVICE_NAME = pc01sby1.us.oracle.com)
)
)
Creating an Oracle Net Service Name for Your Physical Standby Database
Use Oracle Net Manager to define a network service name for your physical standby
database.
The slide shows the entry in the tnsnames.ora file that was generated by Oracle Net
Manager.
Note: This entry is used to connect to the standby database when invoking RMAN and
executing the DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
command. It is also used in the LOG_ARCHIVE_DEST_2 parameter for the SERVICE value to
define the redo transport to the standby database.

Creating a Listener Entry for Your
Standby Database
Use Oracle Net Manager to configure an entry for your standby
database in the listener.ora file:
SID_LIST_LISTENER1 =
(SID_LIST =
(SID_DESC =

(GLOBAL_DBNAME = pc01sby1.us.oracle.com)
(ORACLE_HOME =
/u01/app/oracle/product/11.2.0/dbhome_1)
(SID_NAME = pc01sby1)
)
)
Creating an Entry for Your Standby Database for the Listener

Use Oracle Net Manager to configure a new listener (if necessary) or to update the
listener.ora file with an entry for your physical standby database. The slide shows the
entry in the listener.ora file that was generated by Oracle Net Manager.
Note: This entry is needed because you start the instance in NOMOUNT mode. The labs for
this course use ASM, which runs from the /u01/app/oracle/product/11.2.0/grid
software home location. This location is different from the database software home location
defined as /u01/app/oracle/product/11.2.0/dbhome_1. Both software home
locations contain network configuration files. The ASM software home runs the listener on
port 1521 by the default installation. A second listener on port 12001 is created using the
network configuration files found in the database software home location.

Copying Your Primary Database Password File
to the Physical Standby Database Host

1. Copy the primary database password file to the
$ORACLE_HOME/dbs directory on the standby database
host.
2. Rename the file for your standby database: orapw<SID>.

Copying Your Primary Database Password File to the Physical Standby Database
Host
You must create a password file for your physical standby database by copying the primary
database password file to the physical standby database host and renaming it.

Creating an Initialization Parameter File
for the Physical Standby Database

Create an initialization parameter file containing a single
parameter:
DB_NAME=pc01sby1

Creating an Initialization Parameter File for the Physical Standby Database

Create a text initialization parameter file containing only the DB_NAME initialization parameter.
This initialization parameter file is used to start the physical standby database in NOMOUNT
mode prior to the execution of the DUPLICATE TARGET DATABASE FOR STANDBY FROM
ACTIVE DATABASE RMAN command. When you execute this command, RMAN creates a
server parameter file for the standby database.

Creating Directories
for the Physical Standby Database

1. Create the audit trail directory in $ORACLE_BASE/admin:
[oracle@edbvr6p2-orcl ~]$ cd /u01/app/oracle/admin
[oracle@edbvr6p2-orcl admin]$ ls
orcl
[oracle@edbvr6p2-orcl admin]$ mkdir pc01sby1

[oracle@edbvr6p2-orcl admin]$ cd pc01sby1
[oracle@edbvr6p2-orcl orclsby1]$ mkdir adump
2. Create a directory for the data files in the

$ORACLE_BASE/oradata directory:
[oracle@edbvr6p2-orcl oradata]$ mkdir pc01sby1
[oracle@edbvr6p2-orcl oradata]$ ls
orcl pc01sby1
Creating Directories for the Physical Standby Database

Create a directory for the physical standby database in the $ORACLE_BASE/admin directory.
Create the audit trail directory named adump under the database directory in
$ORACLE_BASE/admin.
Create a directory for the physical standby database data files in the
$ORACLE_BASE/oradata directory.

Starting the Physical Standby Database
Start the physical standby database in NOMOUNT mode:
SQL> startup nomount

pfile=$HOME/dbs/initpc01sby1.ora
ORACLE instance started.

Total System Global Area 150667264 bytes
Fixed Size 1298472 bytes
Variable Size 92278744 bytes
Database Buffers 50331648 bytes
Redo Buffers 6758400 bytes
Starting the Physical Standby Database

Set the ORACLE_SID environment variable to your physical standby database. Start the
physical standby database in NOMOUNT mode by using the text initialization parameter file.
With ASM installed, there will be multiple software home locations on each machine. This will
require that the ORACLE_HOME and PATH location change accordingly. Oracle recommends
the oraenv utility to change environment variables provided entries exist in the
/etc/oratab file. The oraenv utility will adjust ORACLE_SID, ORACLE_BASE,
ORACLE_HOME, PATH and LD_LIBRARY_PATH environment variables. For example:
[oracle@EDBVR6P2-+ASM ~]$ . oraenv
ORACLE_SID = [+ASM] ? pc01sby1
The Oracle base for
ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid is
/u01/app/oracle
Note: Since the initialization parameter file contains an entry only for DB_NAME, memory sizes
for the System Global Area will use default values. Later the DUPLICATE TARGET DATABASE
FOR STANDBY FROM ACTIVE DATABASE RMAN command will copy the initialization
parameter values for memory sizing from the primary database configuration.

Setting FAL_CLIENT and FAL_SERVER
Initialization Parameters
• Fetch archive log (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
– Is applicable for physical standby databases only

– Process is started only when needed, and shuts down as
soon as it is finished
• FAL_CLIENT: Specifies the FAL client name that is used
by the FAL service. It is no longer required.
• FAL_SERVER: Specifies the FAL server for a standby
database
FAL_CLIENT = 'pc01sby1'
FAL_SERVER = 'pc01prmy'
Setting FAL_CLIENT and FAL_SERVER Initialization Parameters

On physical standby databases, fetch archive log (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. The FAL 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.
The FAL_CLIENT initialization parameter specifies the FAL client name (Oracle Net service
name) that is used by the FAL service, configured through the FAL_SERVER parameter, to
refer to the FAL client. This parameter is no longer required for Oracle Database 11g Release
2 (11.2). If it is not set, the fetch archive log (FAL) server will obtain the client’s network
address from the LOG_ARCHIVE_DEST_n parameter that corresponds to the client’s
DB_UNIQUE_NAME.
The FAL_SERVER initialization parameter specifies the FAL server (Oracle Net service name)
for a standby database.

Creating an RMAN Script
to Create the Physical Standby Database

Create an RMAN script to create the physical standby
database:
run {
allocate channel prmy1 type disk;

allocate auxiliary channel stby type disk;
duplicate target database for standby

from active database
Note: The script continues in the next slide.
Creating an RMAN Script to Create the Physical Standby Database

Create an RMAN script containing the DUPLICATE TARGET DATABASE FOR STANDBY FROM
ACTIVE DATABASE command.
Note: You can use the CONFIGURE … PARALLELISM integer command to configure
automatic channels for the specified device type. For additional information, see the Oracle
Database Backup and Recovery Reference.

Creating an RMAN Script
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTL Y PROHIBITED
to Create the Physical Standby Database
spfile
parameter_value_convert 'pc01prmy','pc01sby1'
set db_unique_name='pc01sby1'
set db_file_name_convert='/pc01prmy/','/pc01sby1/'
set log_file_name_convert='/pc01prmy/','/pc01sby1/'
set control_files=

'/u01/app/oracle/oradata/pc01sby1.ctl'
set log_archive_max_processes='5'
set fal_client='pc01sby1'
set fal_server='pc01prmy'
set standby_file_management='AUTO'
set log_archive_config='dg_config=(pc01prmy,pc01sby1)'
set log_archive_dest_2='service=pc01prmy ASYNC
valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE)
db_unique_name=pc01prmy';
}
Creating an RMAN Script to Create the Physical Standby Database (continued)

In the RMAN script, specify the settings for the physical standby initialization parameters.

Creating the Physical Standby Database
1. Invoke RMAN and connect to the primary database and the

physical standby database.
2. Execute the RMAN script to create the physical standby
database.

RMAN> connect target sys/oracle_4U
RMAN> connect auxiliary sys/oracle_4U@pc01sby1
RMAN> @cr_phys_standby
Creating the Physical Standby Database

Connect to the primary database instance (target) and physical standby database instance
(auxiliary). Execute the script that you created.

Enabling Real-Time Apply
RFS
Primary MRP
database Standby

redo log
files
ARC0
Archived
redo log Standby
files database
Enabling 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 archived
redo 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 faster
switchover and failover operations, 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 log files on the primary database resulting in larger standby redo logs on the
standby database.
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.

Enabling 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;
Note: Standby redo log files are required for real-time apply. You must have one more standby
redo log group than the number of online log groups on the primary database.
Real-time apply is supported and automatically enabled by the broker.

Starting Redo Apply
Execute the following command on the standby database to

start Redo Apply:
SQL> ALTER DATABASE
2 RECOVER MANAGED STANDBY DATABASE
3 USING CURRENT LOGFILE

4 DISCONNECT FROM SESSION;
Starting Redo Apply

On the standby database, issue the ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE USING CURRENT LOGFILE SQL command to start Redo Apply. This statement
automatically mounts the database. In addition, include the DISCONNECT FROM SESSION
option so that Redo Apply runs in a background session.
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 database to force a log switch:
SQL> ALTER SYSTEM SWITCH LOGFILE;

Special Note:
Standby Database on the Same System
Primary Standby

/oracle/dba /oracle/standby/dba
• Standby database data files must be at a different location.

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

If you have a standby database on the same system as the primary database, you must use the
following guidelines:
• 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.
Note: If the standby database uses Oracle Managed Files (OMF), do not set the
DB_FILE_NAME_CONVERT or 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 the
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 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 only for
testing and training purposes.

Preventing Primary Database Data Corruption
from Affecting the Standby Database

• Oracle Database processes can validate redo data before
it is applied to the standby database.
• Corruption detection checks occur on the primary
database during redo transport and on the standby
database during redo apply.

• Implement lost write detection by setting
DB_LOST_WRITE_PROTECT to TYPICAL on the primary
and standby databases.
Preventing Primary Database Data Corruption from Affecting the Standby

Database
Data Guard uses Oracle processes to validate redo data before it is applied to the standby
database.
Corruption-detection checks occur at the following key interfaces:
• On the primary database during redo transport by the LGWR, LNS, and ARCn
processes
• On the standby database during redo apply by the RFS, ARCn, MRP, and DBWn
processes
If redo corruption is detected by Redo Apply at the standby database, Data Guard will re-fetch
valid logs as part of archive log gap handling.
A lost write occurs when an I/O subsystem acknowledges the completion of a write but the
write did not occur in persistent storage. On a subsequent block read, the I/O subsystem
returns the stale version of the data block, which is used to update other blocks of the
database, thereby corrupting the database.
Set the DB_LOST_WRITE_PROTECT initialization parameter on the primary and standby
databases to enable the database server to record buffer cache block reads in the redo log so
that lost writes can be detected.

Preventing Primary Database Data Corruption from Affecting the Standby Database
(continued)
You can set DB_LOST_WRITE_PROTECT as follows:
• TYPICAL on the primary database: The instance logs buffer cache reads for read/write
tablespaces in the redo log
• FULL on the primary database: The instance logs reads for read-only tablespaces as
well as read/write tablespaces
• TYPICAL or FULL on the standby database or on the primary database during media
recovery: The instance performs lost write detection
• NONE on either the primary database or the standby database (the default): No lost
write detection functionality is enabled

When a standby database applies redo during managed recovery, it reads the corresponding
blocks and compares the system change numbers (SCNs) with the SCNs in the redo log before
doing the following:
• If the block SCN on the primary database is lower than on the standby database, it detects
a lost write on the primary database and returns an external error (ORA-752).
• If the SCN is higher, it detects a lost write on the standby database and returns an internal
error (ORA-600 3020).
In both cases, the standby database writes the reason for the failure in the alert log and trace
file.
The recommended procedure to repair a lost write on a primary database is to fail over to the
physical standby and re-create the primary. To repair a lost write on a standby database, you
must re-create the standby database or affected files.

Quiz
The DB_FILE_NAME_CONVERT parameter is required when

Oracle Managed Files (OMF) are being used exclusively.
a. True
b. False

Answer: b

Quiz
A standby database cannot be created on the same system as

the primary database.
a. True
b. False

Answer: b

Summary

• Enable FORCE LOGGING
• Create standby redo logs
• Set initialization parameters on the primary database
to support the creation of the physical standby database

and role transition
• Configure Oracle Net Services
• Create a physical standby database by using the
DUPLICATE TARGET DATABASE FOR STANDBY FROM
ACTIVE DATABASE RMAN command
• Start the transport and application of redo

Practice 2: Overview
This practice covers the following topics:

• Preparing the primary database prior to creating a physical
standby database
• Creating the physical standby database
• Verifying that the physical standby database is performing

correctly



Oracle Data Guard Broker: Overview

Objectives
After completing this lesson, you should be able to describe:

• The Data Guard broker architecture
• Data Guard broker components
• Benefits of the Data Guard broker
• Data Guard broker configurations

• How to use Enterprise Manager to manage your Data
Guard configuration
• How to invoke DGMGRL to manage your Data Guard
configuration

Oracle Data Guard Broker: Features
• The Oracle 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 with easy-to-use interfaces:
– Oracle Enterprise Manager Grid Control
– DGMGRL (a command-line interface)
Oracle Data Guard Broker: Features

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 standby database, redo transport services, and log apply services
Note: Any of the databases in the configuration can be a Real Application Clusters
(RAC) database.
• Adding new or existing standby databases to each existing Data Guard configuration, for
a total of one primary database and from one to 30 standby databases in the same
configuration
• Managing an entire Data Guard configuration (including all databases, redo 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 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 both client-side and server-side components.
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, the Data Guard monitor is a broker component that is integrated with the
Oracle database. The Data Guard monitor comprises the Data Guard monitor (DMON) process
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 current state and properties of each
database 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.
pc01prmy pc01sby1

Oracle Net
Primary Standby
site site
Data Guard Broker: Configurations

A Data Guard configuration consists of one primary database and up to 30 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.

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
Standby database
Primary database Standby database
Instances Instances
Data Guard Broker: Management Model

The Data Guard broker performs operations on the following logical objects:
• Configuration of databases
• Single database
A broker configuration consists of:
• 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 comprise 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 30 physical, logical, RAC or non-RAC
standby databases.

Data Guard Broker: Architecture
Graphical user interface

or
command-line interface
Data Guard Configuration Standby site 30

Standby site ..
Primary site Standby site 1
Configuration

Configuration
files files
Standby
database
Standby Log
Primary
redo logs apply
database
Online services
Online DMON DMON redo logs
redo logs Archived
redo logs
Archived
Log redo logs Oracle
transport Net Standby
services redo logs
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 that configuration.
The Data Guard monitor process (DMON) is an Oracle background process that runs on every
instance 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 instance 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 instance.

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
• Creates the drc<SID> trace file in the location set by the
DIAGNOSTIC_DEST initialization parameter
• Modifies initialization parameters during role transitions as
necessary
Data Guard Monitor: DMON Process

The Data Guard monitor comprises two components: the DMON process and the configuration
file.
The DMON process 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
than 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.
The DIAGNOSTIC_DEST parameter defines the location for diagnostic files such as trace files
and core files. The structure of the directory specified by DIAGNOSTIC_DEST is as follows:
<diagnostic_dest>/diag/rdbms/<dbname>/<instance_name>/
This location is known as the Automatic Diagnostic Repository (ADR) Home. The DMON
trace files are located in the <adr-home>/trace subdirectory.

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
• Enables easy configuration of additional standby databases
• Provides simplified, centralized, and extended management
• Automatically communicates between the databases in a
Data Guard configuration by using Oracle Net Services
• Provides built-in validation that monitors the health of all
databases in the configuration
Benefits of Using the Data Guard Broker

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 enables easy configuration of additional standby databases. After creating a Data
Guard configuration consisting of two databases—a primary and standby—you can add up to
29 additional standby databases to the existing two for each Data Guard configuration.

Comparing Configuration Management
With and Without the Data Guard Broker
With the Broker Without the Broker
General Manage databases as one Manage databases separately
Creation of the Use Grid Control wizards Manually create files

standby database

Configuration and Configure and manage from Set up services manually for
management single interface each database
Monitoring • Monitor continuously Monitor each database

• Unified status and reports individually through views
• Integrate with EM events
Control Invoke role transitions with Coordinate sequences of

a single command multiple commands across
database sites for role
transitions
Comparing Configuration Management With and Without the Data Guard Broker
The table in the slide provides an overview of configuration management with and without the
Data Guard broker (source: Table 1-1, ―Configuration Management With and Without the
Broker,‖ in Oracle Data Guard Broker).

Data Guard Broker Interfaces
• Command-line interface (CLI):

– Is started by entering DGMGRL at the command prompt where
the Oracle server or an Oracle client is installed
– Enables you to control and monitor a Data Guard
configuration from the prompt or in scripts

• Oracle Enterprise Manager Grid Control:
– Provides wizards to simplify creating and managing standby
databases
Data Guard Broker Interfaces

The DGMGRL command-line interface 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
Oracle Enterprise Manager 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 databases
• Complete monitoring and proactive event reporting through email or pagers
• Simplified control of the databases through their potential states. For example, with
Enterprise Manager you can start or stop the redo transport services, start or stop the
log apply services, and place a standby database in read-only mode.
• ―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.
Note: After defining a Data Guard broker configuration, you should use DGMGRL or
Enterprise Manager Grid Control to manage your configuration. You should not use SQL
commands to manage the databases because you could cause a conflict with the broker.
Using the Command-Line Interface
of the Data Guard Broker

DGMGRL> connect sys/oracle_4U
Connected.
DGMGRL> show configuration verbose
Configuration - DGConfig1

Protection Mode: MaxPerformance
Databases:
pc01prmy - Primary database
pc01sby1 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
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. See Oracle Data Guard
Broker for detailed information.
• 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 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.)

DGMGRL Commands (continued)
• HELP: Displays online help for the commands in DGMGRL
• REINSTATE: Changes a disabled database into a viable standby database
• REMOVE: Removes a broker configuration, including all of its database profiles, a

specified standby database profile, or knowledge of an instance
• SHOW: Displays either a brief or a detailed summary of information about the broker
configuration, database, or instance; can also 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
• START: Starts the Fast-Start Failover Observer

• STARTUP: Starts an Oracle instance with several options, including mounting and
opening a database
• STOP: Stops the Fast-Start Failover Observer
• 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

Using Oracle Enterprise Manager 10g
Grid Control

Click ―Setup and Manage‖ to
access the Data Guard pages.
Using Oracle Enterprise Manager 10g Grid Control

To access the Data Guard features in Grid Control:
1. Click the Targets tab to go to the Targets page.
2. Click Databases to go to the Databases page, where you can see a list of all discovered
databases, including the primary database.
3. Click the primary database to go to the primary database home page.
4. Click Availability.
5. Click ―Setup and Manage‖ in the Data Guard section of the Availability page to open the
Data Guard Overview page.

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 database 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 the 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
Note: You access the Data Guard Overview page by clicking ―Setup and Manage‖ in the Data
Guard section of the database Availability page.
Benefits of Using Enterprise Manager
• Enables you to manage your configuration by 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 redo transport services and
log apply services
• Provides a verify operation to ensure that redo 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 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
redo transport services and log apply services across the configuration
• Provides a verify operation to ensure that redo 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

Quiz
Which tools are used to interface with the Data Guard Broker?
a. DGMGRL
b. SRVCTL
c. Enterprise Manager
d. CRSCTL

Answer: a, c

Quiz
It is necessary to manage standby databases with the Data

Guard Broker framework.
a. True
b. False

Answer: b

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 command-line interface)


HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRIC TLY PROHIBITED

Creating a Data Guard Broker Configuration

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

DGMGRL commands to:
• Create a Data Guard broker configuration
• Manage the Data Guard broker configuration


Data Guard Broker: Requirements
• Oracle Database Enterprise Edition

• Single-instance or multi-instance environment
• COMPATIBLE parameter: Set to 10.2.0.1.0 or later for
primary and standby databases
• Oracle Net Services network files: Must be configured for

the primary database and any existing standby databases.
Enterprise Manager Grid Control configures files for new
standby databases.
• GLOBAL_DBNAME attribute: Set to a concatenation of
db_unique_name_DGMGRL.db_domain

To use the Data Guard broker, you must comply with the following requirements:
• Use the Enterprise Edition of Oracle Database.
• Use a single-instance or multi-instance environment.
• Set the COMPATIBLE initialization parameter to 11.2.0 to take advantage of new
Oracle Database 11g Release 2 (11.2) features.
• 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.
• To enable the Data Guard broker 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.

• DG_BROKER_START initialization parameter: Set to TRUE

• Primary database: ARCHIVELOG mode
• All databases: MOUNT or OPEN mode
• DG_BROKER_CONFIG_FILEn: Configured for any RAC
databases

Data Guard Broker: Requirements (continued)

• Set the DG_BROKER_START initialization parameter to TRUE. This starts the DMON
process.
Note: When you use Enterprise Manager to create your configuration, this parameter is
automatically set to TRUE.
• 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 or on raw devices, or the
files could be stored using Automatic Storage Management (ASM). For details, see the
section titled ―Managing Broker Configuration Files in an Oracle RAC Environment‖ in
Oracle Data Guard Broker.

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 Grid Control

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
and the configuration file, you must use the persistent server 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. In
addition, 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 changes in the configuration file and also propagates the changes to the
related initialization parameters in the server parameter 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 DGMGRL), do not attempt to
manually set the parameters that the broker controls. If you set them manually, either you render
your configuration inoperable or the broker simply takes the next opportunity to reset the
parameter to the recorded setting. If you want to change a parameter value, you must change it
by using one of the broker interfaces.

Data Guard Monitor: Configuration File
• The broker configuration file is:

– Automatically created and named using a default path name
and file name when the broker is started
– Managed automatically by the DMON process
• The configuration file and a copy are created at each

managed site with default names:
– dr1<db_unique_name>.dat
– dr2<db_unique_name>.dat
• Configuration file default locations are operating system
specific:
– Default location for UNIX and Linux: ORACLE_HOME/dbs
– Default location for Windows: ORACLE_HOME\database
• Use DG_BROKER_CONFIG_FILEn to override the default
path name and file name.
Data Guard Monitor: Configuration File

The DMON process maintains persistent configuration data about all the 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. You can override this default name by setting the
DG_BROKER_CONFIG_FILE n initialization parameters. You can also change the configuration file
names dynamically by issuing the ALTER SYSTEM SQL statement. You must disable the broker
configuration and stop the DMON process before changing the names.
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 DGMGRL and Enterprise Manager.
Note: For Oracle Database 11g Release 2, the broker config files can reside on disks having any sector
size up to 4KB.

Data Guard Broker: Log Files
• The broker log files contain information recorded by the

DMON process.
• There is one file for each instance in the broker
configuration.
• Broker log files are created in the same directory as the

alert log and are named drc<$ORACLE_SID>.log.
Data Guard Broker Log Files

The DMON process records operational and status information in the broker log file for each
instance in the Data Guard broker configuration.

Creating a Broker Configuration
1. Invoke DGMGRL and connect to the primary database.

2. Define the configuration, including a profile for the primary
database.
3. Add standby databases to the configuration.
4. Enable the configuration, including the databases.

Creating a Broker Configuration

To create a broker configuration by using DGMGRL, you first define the configuration, and
then add each database to the configuration and enable the configuration. Each step is
discussed in detail in the following slides.
Note: The databases must exist before you add them to the configuration 9

Defining the Broker Configuration and
the Primary Database Profile
DGMGRL> CREATE CONFIGURATION 'DGConfig1' AS

> PRIMARY DATABASE IS pc01prmy
> CONNECT IDENTIFIER IS pc01prmy;
Configuration "DGConfig1" created with primary database
"pc01prmy"
DGMGRL>

Defining the Broker Configuration and the Primary Database Profile

Execute the CREATE CONFIGURATION command to define the broker creation and create a
profile for the primary database. The following parameters must be specified:
• configuration-name: User-specified name for the configuration.
• database-name: Used by the broker to reference the primary database. You must use
the value of the DB_UNIQUE_NAME initialization parameter for the database name.
• connect-identifier: The value you specify for the connect identifier is a fully
specified connect descriptor or a name to be resolved by an Oracle Net Services
naming method. The broker uses this value to communicate with the other databases
defined in the configuration. The DGConnectIdentifier database property is set to
the connect identifier value.

Adding a Standby Database to the Configuration
DGMGRL> ADD DATABASE pc01sby1 AS

> CONNECT IDENTIFIER IS pc01sby1;
Database "pc01sby1" added
DGMGRL>

Adding a Standby Database to the Configuration

Use the ADD DATABASE DGMGRL command to define the standby database and create a
broker configuration profile. The database name specified must be the same as the value of
the DB_UNIQUE_NAME initialization parameter. The connect identifier is used by Oracle Net
Services to access the database from al other databases in the configuration.
The AS CONNECT IDENTIFIER clause is optional. If you do not specify this clause, the
broker will search the LOG_ARCHIVE_DEST_n initialization parameters on the primary
database for an entry that corresponds to the database being added.
The broker uses the specified connect-identifier to communicate with the specified
database from other databases. Therefore, you must ensure that the connect-identifier
can be used to address the specified database from all databases in your configuration. For
example, if TNS is used as the naming method, you must ensure that the tnsnames.ora file
on every database and instance that is part of the configuration contains an entry for the
connect identifier. The connect identifier must resolve to the same connect descriptor.
Note: The broker will determine the standby type whenever you add an existing standby. In
Oracle database version 10.2, you had to specify "MAINTAINED AS [ PHYSICAL |
LOGICAL ]" when you added an existing standby.

Enabling the Configuration
DGMGRL> ENABLE CONFIGURATION;

Enabled.
DGMGRL> SHOW CONFIGURATION

Databases:
pc01sby1 - Physical standby database
SUCCESS
Enabling the Configuration

After defining the databases in the configuration, you enable the configuration and its
databases by executing the ENABLE CONFIGURATION DGMGRL command.

Changing Database Properties and States
• To alter a database property:

DGMGRL> EDIT DATABASE pc01sby1
> SET PROPERTY LogXptMode='SYNC';
• To alter the state of the standby database:

DGMGRL> EDIT DATABASE pc01sby1 SET STATE='APPLY-OFF';
• To alter the state of the primary database:

DGMGRL> EDIT DATABASE pc01prmy
> SET STATE='TRANSPORT-OFF';
Changing Database Properties and States

Configurable database properties can be viewed and dynamically updated by using the EDIT
DATABASE SET PROPERTY DGMGRL command. Use the SHOW DATABASE VERBOSE
command to obtain a complete list of database properties.
The EDIT DATABASE SET STATE DGMGRL command is used to change the state of the
primary database and standby databases. When the broker configuration is enabled, the
databases are in one of four states:
• TRANSPORT-ON (applicable only to the primary database): Redo transport services
transmit redo data to the standby databases when the primary database is open in
read/write mode.
• TRANSPORT-OFF (applicable only to the primary database): Redo transport services are
stopped on the primary database.
• APPLY-ON (applicable only to a physical or logical standby database): Redo Apply is
started on the physical standby database when it is mounted or in open read-only mode.
SQL Apply is started on a logical standby database when it is opened and the logical
standby database guard is on.
• APPLY-OFF (applicable only to a physical or logical standby database): Redo Apply is
stopped on a physical standby database. SQL Apply is not running on a logical standby
database.
Managing Redo Transport Services
by Using DGMGRL
Specify database properties to manage redo transport services:
• DGConnectIdentifier
• LogXptMode
• LogShipping

Managing Redo Transport Services by Using DGMGRL

Use the DGConnectIdentifier, LogXptMode, and LogShipping configurable database
properties to manage redo transport services. Details about each database property are
provided in the next few slides.
Note: See Oracle Data Guard Broker for information about additional properties that are used
to manage redo transport services.

Specifying the Connection Identifier
by Using the DGConnectIdentifier Property

• DGConnectIdentifier:
– Specifies the connection identifier that is used by the broker
to connect to a database and redo transport services
– Is set when a database is either added to the Data Guard
broker configuration to the value specified in the optional
CONNECT IDENTIFIER CLAUSE, or is extracted from the

SERVICE attribute of the LOG_ARCHIVE_DEST_n
initialization parameter
• The DGConnectIdentifier value is used to set the
FAL_SERVER and FAL_CLIENT initialization parameters.
Specifying the Connection Identifier by Using the DGConnectIdentifier

Property
The DGConnectIdentifier property is set when a database is added to the broker
configuration. Its initial value is the connect identifier that is specified in the CONNECT
IDENTIFIER IS clause of the ADD DATABASE command. If the optional CONNECT
IDENTIFIER IS clause is not specified, the initial value of the DGConnectIdentifier
property is obtained from the SERVICE attribute of the LOG_ARCHIVE_DEST_n initialization
parameter for the database specified in the ADD DATABASE command. If the
DGConnectIdentifier property is changed, the SERVICE attribute of the
LOG_ARCHIVE_DEST_n initialization parameter for that database is also changed.
The DGConnectIdentifier property value is also used to set the FAL_SERVER and
FAL_CLIENT initialization parameters. If the DGConnectIdentifier property is changed,
the FAL_SERVER and FAL_CLIENT initialization parameters are also updated.

Managing the Redo Transport Service
by Using the LogXptMode Property

• The redo transport service must be set up for the chosen
data protection mode.
• Use the LogXptMode property to set the redo transport
services:
– ASYNC

— Sets the ASYNC and NOAFFIRM attributes of
LOG_ARCHIVE_DEST_n
— Required for maximum performance mode
– SYNC
— Sets the SYNC and AFFIRM attributes of
LOG_ARCHIVE_DEST_n
— Required for maximum protection and maximum availability
modes
Managing the Redo Transport Service by Using the LogXptMode Property

Use the Data Guard broker LogXptMode property to set redo transport services.
• ASYNC: Configures redo transport services by setting the ASYNC and NOAFFIRM
attributes of the LOG_ARCHIVE_DEST_n initialization parameter.
• SYNC: Configures redo transport services by setting the SYNC and AFFIRM attributes of
the LOG_ARCHIVE_DEST_n initialization parameter.
Definitions of LOG_ARCHIVE_DEST_n Attributes
• ASYNC: Redo data that is generated by a transaction need not have been received at a
destination that has this attribute before the transaction can commit.
• SYNC: Redo data that is generated by a transaction must have been received by every
enabled destination that has this attribute before the transaction can commit.
• AFFIRM and NOAFFIRM : Control whether redo transport services use synchronous or
asynchronous disk I/O to write redo data to the archived redo log files
- AFFIRM: Specifies that a redo transport destination acknowledges received redo
data after writing it to the standby redo log
- NOAFFIRM : Specifies that a redo transport destination acknowledges received
redo data before writing it to the standby redo log

Setting LogXptMode to ASYNC
Primary
MRP or Standby
database
LSP database
transactions
LNSn RFS
Redo
buffer
Standby ack (Real-time

LGWR apply)
Oracle Net
Standby
redo logs
Online
redo ARC0
logs
Sets the ASYNC and NOAFFIRM

attributes of
LOG_ARCHIVE_DEST_n Archived redo
logs
Setting LogXptMode to ASYNC

When you set the LogXptMode property to ASYNC, the broker configures redo transport
services for this standby database by using the ASYNC and NOAFFIRM attributes of the
LOG_ARCHIVE_DEST_n initialization parameter. ASYNC mode enables a moderate level of
data protection for the primary database with a lower performance impact than SYNC mode.
Standby redo log files are required for ASYNC mode.
In the diagram in the slide, the solid line represents a synchronous operation (writing locally to
the primary database online redo log files). The broken lines represent asynchronous
operations with respect to the transaction commit on the primary database.

Setting LogXptMode to SYNC
Primary
MRP or Standby
database
LSP database
transactions
LNSn RFS
Redo
buffer
Standby ack (Real-time

LGWR apply)
Oracle Net
Standby
redo logs
Online
redo
ARC0
logs
Sets the SYNC and

AFFIRM
attributes of Archived redo
LOG_ARCHIVE_DEST_n logs
Setting LogXptMode to SYNC

When you set the LogXptMode database property to SYNC, the broker configures redo
transport services for this standby database by using the SYNC and AFFIRM attributes of the
LOG_ARCHIVE_DEST_n initialization parameter. SYNC mode is required for maximum
protection and maximum availability data protection modes. This mode enables the highest
level of data protection to the primary database but also incurs the highest performance
overhead.
Standby redo log files are required for SYNC mode.
In the diagram in the slide, the solid line represents a synchronous operation (writing locally to
the primary database online redo log files). The broken lines represent asynchronous
operations with respect to the transaction commit on the primary database.

Controlling the Shipping of Redo Data
by Using the LogShipping Property

• LogShipping controls whether redo transport services
can send redo data to a specified standby database.
• LogShipping is applicable only when the primary
database state is set to TRANSPORT-ON.

Controlling the Shipping of Redo Data by Using the LogShipping Property

Use the LogShipping configurable database property to specify whether redo transport
services can send redo data to a particular standby database. The value specified for the
LogShipping property is applicable only when the primary database is in the TRANSPORT-
ON state. If the value of the LogShipping property is ON, redo transport services are enabled
for that standby database. If the LogShipping property is set to OFF, redo transport services
are disabled for that standby database.

Disabling Broker Management of the
Configuration or Standby Database

• Disable broker management of the configuration:
DGMGRL> DISABLE CONFIGURATION;
• Disable broker management of a standby database:

DGMGRL> DISABLE DATABASE 'pc01sby1';
Disabling Broker Management of the Configuration or Standby Database

You can disable broker management of a configuration or a specific standby database. You
may want to disable broker management to perform maintenance or to temporarily prevent
automated actions for testing.
Disabling broker management does not affect the underlying Data Guard configuration.
Rather, it removes the ability for you to manage the configuration by using DGMGRL or
Enterprise Manager Grid Control.
Use the DISABLE CONFIGURATION DGMGRL command to disable broker management of
the configuration. Use the DISABLE DATABASE DGMGRL command to disable broker
management of the named standby database.
Note: You must use the DISABLE CONFIGURATION command to disable broker
management of a primary database.

Removing the Configuration or Standby Database
• Remove a standby database from the configuration:

DGMGRL> REMOVE DATABASE 'pc01sby1' [PRESERVE
DESTINATIONS];
• Remove the configuration:

DGMGRL> REMOVE CONFIGURATION [PRESERVE DESTINATIONS];
Removing the Configuration or Standby Database

Use the REMOVE DATABASE command to delete the named standby database from the broker
configuration.
Use the REMOVE CONFIGURATION command to delete the configuration. When you execute
the REMOVE CONFIGURATION command, the broker configuration is removed, all database
profiles are removed, the Data Guard broker configuration files is removed, and broker
management of all databases in the configuration is terminated. Execution of this command
does not affect the underlying databases. You cannot remove the configuration when fast-
start failover is enabled.
The PRESERVE DESTINATIONS syntax is available for both the REMOVE DATABASE and
REMOVE CONFIGURATIONS commands. By default, broker settings for
LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_CONFIG initialization parameters are removed
when the REMOVE commands are issued, but PRESERVE DESTINATIONS maintains these
initialization parameters. A common usage for this is to allow the Data Guard broker to
perform all of the setup for the LOG_ARCHIVE_DEST_n initialization parameters and then
remove the broker when it has finished.

Quiz
How many Data Guard broker configuration files are created for
each database unique name?
a. One
b. Two
c. Three

d. Four
Answer: b

Quiz
Which combination of redo transport mode properties is

required for Maximum Availability protection mode?
a. ASYNC NOAFFIRM
b. ASYNC AFFIRM
c. SYNC NOAFFIRM

d. SYNC AFFIRM
Answer: d

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

DGMGRL commands to:
• Create a Data Guard broker configuration
• Manage the Data Guard broker configuration



• Setting the DG_BROKER_START initialization parameter
• Creating the broker configuration
• Enabling the broker configuration




Creating a Physical Standby Database by
Using Enterprise Manager Grid Control

Objectives

• Use Enterprise Manager to create a broker configuration
• Use Enterprise Manager to manage the broker
configuration


Using Oracle Enterprise Manager
to Create a Broker Configuration

• Use the Add Standby Database Wizard to:
– Create a broker configuration
– Create a standby database
– Add a database to a broker configuration
• Primary database must be started with a server parameter

file (SPFILE).
Using Enterprise Manager to Create a Broker Configuration

Oracle Enterprise Manager (Enterprise Manager) automates the process of creating a
standby database. The Add Standby Database Wizard is used to create a new broker
configuration (including standby databases) 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.

Creating a Configuration

Click Add Standby Database
to start the wizard.
Creating a Configuration
You can access the Data Guard features in Enterprise Manager Grid Control by clicking
―Setup and Manage‖ in the Data Guard section on the Availability page.
Click the Add Standby Database link to invoke the Add Standby Database Wizard.

Creating a New Configuration

Creating a New Configuration

Using the Add Standby Database Wizard, 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.
During the standby creation process, the following operations are performed (for online
backup types):
• RMAN automatically copies the server parameter file to the standby host
• The auxiliary instance is started with the parameter file
• A backup control file is restored
• All necessary database files and archive redo logs are copied over the network to the
standby host
• RMAN recovers the standby database, but does not place it in manual or managed
recovery mode

Adding a Standby Database
to an Existing Configuration

Click Add Standby Database
to start the wizard.
Adding a Standby Database to an Existing Configuration

Click the Add Standby Database button to invoke the Add Standby Database Wizard.

Using the Add Standby Database Wizard


With the Add Standby Database Wizard, you first select the type of standby database that you
want to create. You can create a 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 an SPFILE.
• The primary database is in ARCHIVELOG mode.
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, a warning message appears. You can then cancel the configuration and enable FORCE
LOGGING.
The following slides describe the wizard steps in detail.

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 the creation
of the standby database. There are two options:
• Perform an online backup of the primary database: Creates a backup using the
Recovery Manager utility (RMAN)
• Use a backup from a previous standby database creation: Uses an existing backup
of the primary database that was created by Data Guard during a previous creation of a
standby database

Step 2: Specify the Backup Options
(RMAN Direct Copy)

Step 2: Specify the Backup Options (RMAN Direct Copy)

If you selected the ―Perform a live backup of the primary database‖ option on the Backup
Type page with the option to ―Use Recovery Manager (RMAN) to copy database files,‖ then
staging areas are not required. RMAN will copy files directly to destination locations.
In the Primary Host Credentials section, specify the operating system credentials of the user
who owns the primary database Oracle server installation. The credentials are preset to the
host-preferred credentials that are stored with the primary database-preferred credentials by
default.

Step 2: Specify the Backup Options
(Staging Areas Example)

Step 2: Specify the Backup Options (Staging Areas Example)

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

Step 3: Select the Standby Database Location
Instance Name

Step 3: Select the Standby Database Location Instance Name

In the Instance Name field, specify the instance name for your new standby database, 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 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 Database Location section, specify the host machine name and Oracle Home
location for the database software. There may be more than one Oracle Home on the same
machine.
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 Standby Database Location
Oracle Home

Step 3: Select the Standby Database Location Oracle Home

The Standby Database Location section lists all 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.
Note: The standby database home location should not be a Grid Infrastructure home.

Step 4: Specify the Standby Database
File Locations (Staging Method)

Step 4: Specify the Standby Database File Locations (Staging Method)

The Standby Host 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. This is screenshot is valid when
staging areas have been selected as the backup method.
• 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 methods. Select the
―HTTP server‖ option if you know that the primary 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
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FR OM THIS COMPUTER IS STRICTLY PROHIBITED
File Locations

Step 4: Specify the Standby Database 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. As an option, you can change the locations of individual
standby database files by clicking the Customize button to display the File Locations
Customize page of the wizard.
The Flash Recovery Area (now known as Fast Recovery Area) allows you to enable the
feature, define a location for the Fast Recovery Area, and set the Fast Recovery Area size.
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 for the standby database’s 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 that is 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, 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 physical standby database, or creating a 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 physical database, you must configure the following parameters:
• Database Unique Name: Specify a value for the database DB_UNIQUE_NAME
parameter. This name must be unique in the Data Guard configuration.
Note: This field appears only if you are creating a physical standby 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.
In the Standby Database Monitoring Credentials, you can choose between a non-SYSDBA
user such as DBSNMP to monitor the database or choose to use the SYSDBA monitoring
credentials.

Step 6: Review the
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING e KIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Configuration Information

Step 6: Review the Configuration Information

The Review page displays a summary of your selections and lists the parameters to be used
to create the standby database.
The 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

On the Processing page, you can view the progress of the Add Standby Database process.
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 standby database. An arrow indicates which step is being
processed. When the process is completed, 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 (if it does not exist) is created during this step. 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 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 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 after this step begins.
• Adding standby database target: In this step, the standby database target in
Enterprise Manager is updated with additional information indicating 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 Data Guard
Status column indicates that standby database creation is in progress. Click the ―Creation in
progress‖ link to access the job page and monitor the progress.
After creation of the standby database, it appears on the Data Guard Overview page with a
status of Normal.

Verifying a Data Guard Configuration
Click the Verify Configuration link.

Verifying a Data Guard Configuration

After creating your configuration, you should use the Data Guard Verify operation to check the
configuration. (You can use the Verify operation at any other time to check your
configuration.) Invoke the Verify operation by clicking Verify Configuration in the Additional
Administration section of the Data Guard page. The Verify operation performs a series of
validation checks on the Data Guard configuration, including a health check of each database
and agent. The Verify operation:
• Determines the current data protection mode settings, including the current redo
transport mode settings for each database and whether the standby redo logs are
configured properly. If standby redo logs are needed for a 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 errors occur, a message appears on the Results page.
• Displays the results of the Verify operation (including 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

View the results of the Verify operation on the Detailed Results page. If errors occur during
the operation, detailed information appears on this page.

Performing Routine Maintenance
Use Enterprise Manager Grid Control to:

• Change the properties of a database
• Manage apply services
• Set the redo transport mode

Performing Routine Maintenance

You can use Enterprise Manager Grid Control to maintain your broker configuration. Each
task is described in detail in the next few slides.

Editing Standby Database Properties

Click Edit to access the
Edit Standby Database Properties page.
Editing Standby Database Properties

To access the Standby Database Properties page, select your standby database on the Data
Guard overview page and click Edit.

Managing Apply Services

Managing Apply Services

You may need to temporarily stop Redo Apply for routine maintenance tasks. You can stop
apply services by selecting Log Apply Off on the Edit Standby Database Properties page and
then clicking Apply.
When you specify Log Apply Off, Redo Apply is stopped and redo data is not applied to the
standby database. However, the standby database continues to receive data from the primary
database.

Changing the Basic Properties of a Database

Changing the Basic Properties of a Database

To use Enterprise Manager to view or change properties:
1. In the Primary Database section on the Data Guard Overview page (or in the Standby
Databases section, as appropriate), click Edit.
2. Click the Standby Role Properties tab or the Common Properties tab (depending on the
property that you want to change).
3. Make the appropriate change and click Apply.
When the process is completed, a message indicates success.

Changing the Advanced Properties of a Database

Changing the Advanced Properties of a Database

To use Enterprise Manager to view or change properties:
1. In the Primary Database section on the Data Guard Overview page (or in the Standby
Databases section, as appropriate), click Edit.
2. Click the Standby Role Properties tab or the Common Properties tab (depending on the
property that you want to change).
3. Expand the Show Advanced Properties link. The advanced properties will be different
depending on the type of standby database.
4. Make the appropriate change and click Apply.
When the process is completed, a message indicates success.

Setting the Redo Transport Mode
by Using Enterprise Manager
Select the mode from

the Redo Transport
Mode list.
Setting the Redo Transport Mode by Using Enterprise Manager

On the Standby Role Properties page, select the redo transport mode from the fol owing
values in the Log Transport Mode list:
• ASYNC: Configures redo transport services for your standby database by using the
LGWR, ASYNC, and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization
parameter. This mode, along with standby redo log files, provides a moderate level of
protection to the primary database and incurs a moderate performance impact.
• SYNC: Configures redo transport services for your standby database by 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 redo transport mode provides the highest
level of data protection to the primary database, but it also incurs the highest
performance impact.

Quiz
Oracle Enterprise Manager DBConsole can be used to create

and configure a Data Guard configuration.
a. True
b. False

Answer: b

Quiz
The Verify Data Guard Configuration feature of Oracle

Enterprise Manager (EM) can also be performed using
DGMGRL.
a. True
b. False

Answer: b

Summary

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



Creating a Logical Standby Database

Objectives

• Determine when to create a logical standby database
• Create a logical standby database
• Manage SQL Apply filtering


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 benefits in disaster recovery, high availability, and data
protection 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 include data that is not part of the
primary database, and users can perform 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.
Note: Oracle Database 11g includes the Active Data Guard option. Active Data Guard
includes the Real-Time Query feature, which enables you to open a physical standby
database in read-only mode while Redo Apply is active. However, you cannot add
additional structures to the physical standby database as you can with a logical standby
database.
• 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

• Can be used to upgrade Oracle Database software and
apply patch sets
Benefits of Implementing a Logical Standby Database (continued)

• Data protection: A logical standby database provides a safeguard against data
corruption 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 enable easy role
reversals between primary and logical standby databases, thereby minimizing the down
time of the primary database for planned and unplanned outages.
• Database upgrades: A logical standby database can be used to upgrade Oracle
Database software and apply patch sets with almost no down time. The logical standby
database can be upgraded to the new release and switched to the primary database
role. The original primary database is then converted to a logical standby database and
upgraded.
Note: See the lesson titled ―Upgrading Databases in a Data Guard Configuration‖ for
additional information about using a logical standby database to perform upgrades.

Logical Standby Database:
SQL Apply Architecture

Production Logical standby
database database
SQL
Redo transport
Apply

Transform redo
information into
SQL
Reports
Primary Logical standby

database database
Logical Standby Database: 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
be applied sorted in
Data files 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, scheduled appropriately so that the dependencies are resolved.
- Commits the transactions
Preparing to Create a

Perform the following steps on the primary database before
creating a logical standby 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.
Preparing to Create a Logical Standby Database

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

Unsupported Objects
• Log apply services automatically exclude unsupported

objects when applying redo data to the logical standby
database.
• Unsupported objects:
– Tables and sequences in the SYS schema

– Tables used to support materialized views
– Global temporary tables
– Tables with unsupported data types (see list on next page)
Unsupported Objects
If the primary database contains unsupported tables, log apply services automatically exclude
these tables when applying redo data to the logical standby database.

Unsupported Data Types
• Log apply services automatically exclude tables with

unsupported data types when applying redo data to the
logical standby database.
• Unsupported data types:
– BFILE, ROWID, and UROWID

– User-defined types
– Multimedia data types (Spatial, Image, and Oracle Text)
– Collections (VARRAYS and nested tables)
– XMLType stored as OBJECT RELATIONAL
– BINARY XML
Unsupported Data Types

Ensure that your logical standby database can support the data types of the database objects
that are defined in your primary database.
Note: See Oracle Data Guard Concepts and Administration for additional information about
unsupported data types and objects. SecureFile LOB's are supported if the database
compatibility level is set to 11.2 or higher.

Checking for Unsupported Tables
Query DBA_LOGSTDBY_UNSUPPORTED_TABLE on the primary

database for unsupported tables:
SQL> SELECT * FROM dba_logstdby_unsupported_table
2 ORDER BY owner;
OWNER TABLE_NAME

------------------------------ ------------------------------
IX AQ$_STREAMS_QUEUE_TABLE_T
IX AQ$_STREAMS_QUEUE_TABLE_H
…
OE CUSTOMERS
OE WAREHOUSES
PM PRINT_MEDIA
PM ONLINE_MEDIA
SH DIMENSION_EXCEPTIONS
20 rows selected.
Checking for Unsupported Tables

You can query DBA_LOGSTDBY_UNSUPPORTED_TABLE to determine which tables in the
primary database are not supported by log apply services.

Checking for Tables
with Unsupported Data Types

Query DBA_LOGSTDBY_UNSUPPORTED on the primary
database for tables with unsupported data types:
SQL> SELECT table_name, column_name, attributes, data_type
2 FROM dba_logstdby_unsupported WHERE owner = 'OE';
TABLE_NAME COLUMN_NAME ATTRIBUTES DATA_TYPE

-------------- -------------------- ------------ ----------
CUSTOMERS CUST_ADDRESS OBJECT
CUSTOMERS PHONE_NUMBERS VARRAY
CUSTOMERS CUST_GEO_LOCATION OBJECT
WAREHOUSES WH_GEO_LOCATION OBJECT
PURCHASEORDER SYS_NC_ROWINFO$ Object Table OPAQUE
CATEGORIES_TAB CATEGORY_NAME Object Table VARCHAR2
CATEGORIES_TAB CATEGORY_DESCRIPTION Object Table VARCHAR2
CATEGORIES_TAB CATEGORY_ID Object Table NUMBER
CATEGORIES_TAB PARENT_CATEGORY_ID Object Table NUMBER
9 rows selected.
Checking for Tables with Unsupported Data Types

You can query the DBA_LOGSTDBY_UNSUPPORTED data dictionary view to see all tables that
contain data types that are not supported by logical standby databases. These tables are not
maintained (that is, they do not have DML applied) in the logical standby database. Changes
made to unsupported data types, tables, sequences, or views on the primary database are not
propagated to the logical standby database, and no error message is returned.
It is a good idea to query this view on the primary database to ensure that those tables that
are 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.

SQL Commands That Do Not Execute
on the Standby Database

• ALTER DATABASE • EXPLAIN
• ALTER SESSION • LOCK TABLE
• ALTER MATERIALIZED VIEW • SET CONSTRAINTS
• ALTER MATERIALIZED VIEW LOG • SET ROLE
• ALTER SYSTEM • SET TRANSACTION
• CREATE CONTROL FILE

• CREATE DATABASE
• CREATE DATABASE LINK
• CREATE PFILE FROM SPFILE
• CREATE SCHEMA AUTHORIZATION
• CREATE MATERIALIZED VIEW
• CREATE MATERIALIZED VIEW LOG
• CREATE SPFILE FROM PFILE
• DROP DATABASE LINK
• DROP MATERIALIZED VIEW
• DROP MATERIALIZED VIEW LOG
SQL Commands That Do Not Execute on the Standby Database

Not all data SQL commands that are executed on the primary database are applied to the
logical standby database. If you execute any of the 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 if needed to maintain
consistency between the primary database and the logical standby database.

Unsupported PL/SQL Supplied Packages
Unsupported PL/SQL supplied packages include:

• DBMS_JAVA
• DBMS_REGISTRY
• DBMS_ALERT
• DBMS_SPACE_ADMIN

• DBMS_REFRESH
• DBMS_REDINITION
• DBMS_AQ
Unsupported PL/SQL Supplied Packages

Oracle PL/SQL supplied packages that modify system metadata typically are not supported
by SQL Apply, and therefore their effects are not visible on the logical standby database.
Oracle PL/SQL supplied packages that do not modify system metadata but may modify user
data are supported as long as the modified data belongs to the supported data types.
Example of such packages are DBMS_LOB, DBMS_SQL, and DBMS_TRANSACTION. Specific
support for DBMS_JOB has been provided. Jobs created on the primary database are
replicated on the standby database, but will not run as long as the standby maintains its
standby role. Specific support for DBMS_SCHEDULER has been provided to allow jobs to run
on the standby database with the database_role attribute of jobs.
Note: See Oracle Data Guard Concepts and Administration for additional information about
unsupported data types and objects.

Ensuring Unique Row Identifiers
• Query DBA_LOGSTDBY_NOT_UNIQUE on the primary

database to find tables without a unique identifier:
SQL> SELECT * FROM dba_logstdby_not_unique;
OWNER TABLE_NAME BAD_COLUMN

------ -------------------------- ----------
HR EMP_HIST N
SCOTT BONUS N
SCOTT SALGRADE N
SH SUPPLEMENTARY_DEMOGRAPHICS N
SH COSTS N
SH SALES N
• Add a primary key or unique index to ensure that SQL

Apply can efficiently apply data updates.
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 the 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 columns, 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 redo 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 in the next slide).

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.
To improve the performance of SQL Apply, add a unique constraint/index to the columns to
identify the row on the logical standby database. Failure to do so results in full table scans
during UPDATE or DELETE statements carried out on the table by SQL Apply.
Note: For this example, assume that the HR.EMPLOYEES table does not have a primary key.

by Using SQL Commands

To create a logical standby database by using SQL commands:
1. Create a physical standby database.
2. Stop Redo Apply on the physical standby database.
3. Prepare the primary database to support a logical standby
database.

4. Build a LogMiner dictionary in the redo data.
5. Transition to a logical standby database.
6. Open the logical standby database.
7. Verify that the logical standby database is performing
properly.
Creating a Logical Standby Database by Using SQL Commands

The remainder of this lesson covers each of these steps in detail.

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

b. Ensure that the physical standby database is current with

Step 1: Create a Physical Standby Database

You create a logical standby database by first creating a physical standby database. Then
you convert 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 and RMAN Commands.‖
b. Ensure that the physical standby database is current with 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: Stop Redo Apply
on the Physical Standby Database

• Before converting the physical standby database to a
logical standby database, stop Redo Apply.
• Stopping Redo Apply is required to avoid applying
changes past the redo that contains the LogMiner
dictionary.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY
2 DATABASE CANCEL;
or
DGMGRL> EDIT DATABASE 'pc01sby1' set state='apply-off';
Succeeded.
Step 2: Stop Redo Apply on the Physical Standby Database

To stop Redo Apply, issue one of the following commands:
• If the configuration is not managed by the broker
SQL > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
• If the configuration is managed by the broker
DGMGRL > EDIT DATABASE '<database name>' set state='apply -off';

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

a. Set the LOG_ARCHIVE_DEST_n initialization parameter for
transitioning to a logical standby role.
LOG_ARCHIVE_DEST_2=
'LOCATION=<directory>
VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE)

DB_UNIQUE_NAME=pc01prmy'
LOG_ARCHIVE_DEST_STATE_2=enable
b. Set the value of UNDO_RETENTION to 3600.
Step 3: Prepare the Primary Database to Support a Logical Standby Database

a. 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. To do this, include the LOG_ARCHIVE_DEST_2 destination on the
primary database. This parameter takes effect only when the primary database is
transitioned to the standby database role.
b. 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 to prevent ora-1555 errors when
there are a number of active transactions.

Step 4: Build a LogMiner Dictionary
in the Redo Data

• Build a LogMiner dictionary in the redo data so that SQL
Apply can properly interpret changes in the redo.
• Supplemental logging is automatically enabled.
• Execute the procedure on the primary database:

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
Step 4: Build a LogMiner Dictionary in the Redo Data

SQL Apply requires a LogMiner dictionary in the redo data so that it can properly interpret
changes in the redo. When you execute the DBMS_LOGSTDBY.BUILD procedure, the
LogMiner dictionary is built and supplemental logging is automatically enabled for logging
primary key and unique key columns. Supplemental logging ensures that each update
contains enough information to logically identify the affected row.
Note: The DBMS_LOGSTDBY.BUILD procedure waits for all existing transactions to complete
so that long-running transactions executing on the primary database will affect its operation.

Step 5: Transition to a Logical Standby Database
a. Execute the following command on the standby database

to convert it to a logical standby database:
SQL> ALTER DATABASE RECOVER TO
2 LOGICAL STANDBY db_name;

b. Shut down the logical standby database instance and
restart it in MOUNT mode.
c. Adjust initialization parameters: LOG_ARCHIVE_DEST_n
Step 5: Transition to a Logical Standby Database

To prepare the physical standby database to transition to a logical standby database:
a. Issue the ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name command to
continue applying redo data to the physical standby database until it is ready to convert
to a logical standby database. Specify a database name (db_name) to identify the new
The redo log files contain the information needed to convert your physical standby
database to a logical standby database. The statement applies redo data until the
LogMiner dictionary is found in the redo log files.
b. Shut down the logical standby database instance and restart it in MOUNT mode.
c. Modify the LOG_ARCHIVE_DEST_n parameters to specify separate local destinations
for:
- Archived redo log files that store redo data generated by the logical standby
database
- Archived redo log files that store redo data received from the primary database

Step 6: Open the Logical Standby Database
a. Open the new logical standby database with the

RESETLOGS option:
SQL> ALTER DATABASE OPEN RESETLOGS;

b. Start the application of redo data to the logical standby
database:
SQL> ALTER DATABASE START LOGICAL STANDBY

2 APPLY IMMEDIATE;
Step 6: Open the Logical Standby Database

To open the logical standby database and start SQL Apply:
a. On the logical standby database, issue the ALTER DATABASE OPEN RESETLOGS
command to open the database.
b. On the logical standby database, issue the following command to start SQL Apply:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE

Adding a Logical Standby Database
to a Data Guard Broker Configuration

Use DGMGRL to add a logical standby database to an existing
Data Guard configuration:
DGMGRL> ADD DATABASE 'pc01sby2' AS
> CONNECT IDENTIFIER IS pc01sby2;
Database "pc01sby2" added

DGMGRL>
Adding a Logical Standby Database to a Data Guard Broker Configuration

Use the ADD DATABASE DGMGRL command to define the standby database and create a
broker configuration profile. The database name that is specified must be the same as the
value of the DB_UNIQUE_NAME initialization parameter. The connect identifier is used by
Oracle Net Services to access the database from all other databases in the configuration.
Note: If the existing Data Guard broker configuration has not been enabled, you will need to
enable it to allow the broker to manage the new logical standby database.

Step 7: 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:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
c. Query the DBA_LOGSTDBY_LOG view to verify that the

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

After creating your logical standby database and setting up redo 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.
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,
2 DICT_BEGIN,DICT_END
3 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:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
c. Connect to the logical standby database and requery 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 7: 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. Query the V$LOGSTDBY_PROCESS view to see current

SQL Apply activity:

SQL> SELECT sid, serial#, spid, type, high_scn
2 FROM v$logstdby_process;
f. Check the overall progress of SQL Apply:

SQL> SELECT applied_scn, latest_scn
2 FROM v$logstdby_progress;
Step 7: 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 that data from the archived redo log files is not being
applied to the logical standby database.
e. Query the V$LOGSTDBY_PROCESS view to see information about the current state of the
SQL Apply processes.
f. Query the V$LOGSTDBY_PROGRESS view on the logical standby database to check the
overall progress of SQL Apply:
SQL> SELECT APPLIED_SCN, LATEST_SCN
2 FROM V$LOGSTDBY_PROGRESS;


Select ―Create a new logical
standby database.‖
Creating a Logical Standby Database by Using Enterprise Manager

To create a logical standby database by using Enterprise Manager:
1. Click Add Standby Database on the Data Guard overview page to invoke the Add
Standby Database Wizard.
Note: If the logical standby database is the first database to be created in your
configuration, access the Add Standby Database Wizard by clicking ―Setup and
Manage‖ in the Data Guard section on the Availability page. Next, click the Add Standby
Database link to invoke the Add Standby Database Wizard.
2. Select ―Create a new logical standby database‖ on the Add Standby Database page,
and click Continue.
3. The wizard guides you through a procedure that is similar to adding a physical standby
database.



On the Add Standby Database: Backup Type page, you determine if you have tables or
columns that are not supported by SQL Apply. In the SQL Apply Unsupported Tables section,
select ―Table Columns and Data Types‖ in the drop-down list and click Go to see the
unsupported tables.


Using the Add Standby Database Wizard (continued)

On the Add Standby Database: Configuration page, specify the values for the DB_NAME and
DB_UNIQUE_NAME parameters for your logical standby database. In addition, specify the
target name to be used by Enterprise Manager Grid Control.
In the Standby Database Monitoring Credentials section, you can choose between a non-
SYSDBA user such as DBSNMP to monitor the database or choose to use the SYSDBA
monitoring credentials.


Using the Add Standby Database Wizard (continued)

After completing all pages in the wizard, you see the Add Standby Database Review page.
Review the information on this page and click Finish to submit a job to create your logical
standby database.

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 the GUARD_STATUS column in V$DATABASE.
• The database guard level is automatically set to ALL by
the broker on the logical standby database.
• The database guard level applies to all users except SYS.
Securing Your Logical Standby Database

The database guard controls user access to tables in a logical standby database. Use 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, because the database guard is automatically set to ALL. With this level of
security, only the SYS user can modify data.
When you set the security level to STANDBY, users are able to modify data that is not
maintained by the logical apply engine. A security level of NONE permits any users to access
the standby database if they have the appropriate 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
allows jobs that are submitted through DBMS_JOB.SUBMIT to be scheduled and to potentially
modify tables in the logical standby database.
Note: Be careful not to let the primary and logical standby databases diverge while the
database guard is disabled.

Automatic Deletion of Redo Log Files
by SQL Apply

Redo logs SQL Transform redo Logical
from Apply information into standby
primary SQL database
database
Delete redo log files
Automatic Deletion of Redo Log Files by SQL Apply

Archived redo logs on the logical standby database are automatically deleted by SQL Apply
after they are applied. This feature reduces the amount of space consumed on the logical
standby database and eliminates the manual step of deleting the archived redo log files.
You can enable and disable the auto-delete feature for archived redo logs by using the
DBMS_LOGSTDBY.APPLY_SET procedure. By default, the auto-delete feature is enabled.
Note: If you are using a flash recovery area, auto deletion is based on the flash recovery
area’s space pressure.

Managing Remote Archived Log File Retention
The LOG_AUTO_DEL_RETENTION_TARGET parameter:

• Is used to specify the number of minutes that SQL Apply
keeps a remote archived log after completely applying its
contents
• Is applicable only if LOG_AUTO_DELETE is set to TRUE and

the flash recovery area is not being used to store remote
archived logs
• Has a default value of 1,440 minutes
SQL> execute DBMS_LOGSTDBY.APPLY_SET

('LOG_AUTO_DEL_RETENTION_TARGET','2880');
Managing Remote Archived Log File Retention

By default, SQL Apply deletes an archived redo log file after applying the contents. This
behavior is controlled by the LOG_AUTO_DELETE parameter. During a flashback operation or
point-in-time recovery of the logical standby database, SQL Apply must stop and re-fetch all
remote archived redo log files.
In Oracle Database 11g, you use the LOG_AUTO_DEL_RETENTION_TARGET parameter to
specify a retention period for remote archived redo log files. You can modify
LOG_AUTO_DEL_RETENTION_TARGET by using the DBMS_LOGSTDBY.APPLY_SET and
DBMS_LOGSTDBY.APPLY_UNSET procedures.
Note: This parameter is applicable only when you are not using the fast recovery area.

Managing SQL Apply Filtering
Use the following configurable database properties to define a

SQL Apply filter:
• LsbyASkipCfgPr: SQL Apply should ignore (skip) SQL
statements as specified.
• LsbyASkipErrorCfgPr: SQL Apply should ignore (skip)

errors as specified.
• LsbyASkipTxnCfgPr: SQL Apply should ignore (skip)
transactions as specified.

You can use SQL Apply filters to control what to apply and what not to apply. To define a SQL
Apply filter, use the following configurable database properties:
• LsbyASkipCfgPr: Provides a way to indicate to SQL Apply that it should ignore (skip)
SQL statements that you do not want to apply to the logical standby database. Valid
values for this property are a valid set of arguments to the DBMS_LOGSTDBY.SKIP
procedure.
• LsbyASkipErrorCfgPr: Provides criteria to determine if an error should cause SQL
Apply to stop. All errors to be skipped are stored in system tables that describe how
exceptions should be handled. Valid values for this property are a valid set of arguments
to the DBMS_LOGSTDBY.SKIP_ERROR procedure. The string must contain comma
separators between the arguments.
• LsbyASkipTxnCfgPr: Enables you to specify the transaction ID (XIDSQN NUMBER) of
a problematic transaction that you want SQL Apply to ignore. Valid values for this
property are a valid set of arguments to the DBMS_LOGSTDBY.SKIP_TRANSACTION
procedure.
See the Oracle Database PL/SQL Packages and Types Reference for detailed information
about the DBMS_LOGSTDBY package and its procedures.

Use the following configurable database properties to delete a

previously defined SQL Apply filter:
• LsbyDSkipCfgPr: Deletes an existing SQL Apply skip
specification
• LsbyDSkipErrorCfgPr: Deletes an existing SQL Apply

skip error specification
• LsbyDSkipTxnCfgPr: Reverses or removes the actions
of the LsbyASkipTxnCfgPr property
Managing SQL Apply Filtering (continued)

Use the following configurable database properties to delete a previously defined SQL Apply
filter:
• LsbyDSkipCfgPr: Deletes an existing SQL Apply skip specification. Valid values are a
valid set of arguments to the DBMS_LOGSTDBY.UNSKIP procedure
• LsbyDSkipErrorCfgPr: Deletes an existing SQL Apply skip error specification. Valid
values are a valid set of arguments to the DBMS_LOGSTDBY.UNSKIP_ERROR
procedure.
• LsbyDSkipTxnCfgPr: Reverses or removes the actions of the LsbyASkipTxnCfgPr
property. Valid values are a valid set of arguments to the
DBMS_LOGSTDBY.UNSKIP_TRANSACTION procedure.
about the DBMS_LOGSTDBY package and its procedures.

Viewing SQL Apply Filtering Settings
Query DBA_LOGSTDBY_SKIP to view SQL Apply filtering

settings:
SQL> SELECT error, statement_opt, name
2 FROM dba_logstdby_skip
3 WHERE owner='HR';

ERROR STATEMENT_OPT NAME
---------- -------------------- ----------
N DML JOBS
Viewing SQL Apply Filtering Settings

You can query the DBA_LOGSTDBY_SKIP view on the logical standby database to determine
the SQL Apply filtering settings. The view contains the following columns:
• ERROR: Indicates whether the statement should be skipped or should return an error for
the statement
• STATEMENT_OPT: Specifies the type of statement that should be skipped (It must be
one of the SYSTEM_AUDIT statement options.)
• OWNER: Name of the schema under which the skip option is used
• NAME:Name of the table that is being skipped
• USE_LIKE: Indicates whether the statement uses a SQL wildcard search when
matching names
• ESC: Escape character to be used when performing wildcard matches
• PROC: Name of a stored procedure that is executed when processing the skip option
You can query DBA_LOGSTDBY_SKIP_TRANSACTION to view settings for transactions to be
skipped.


Managing SQL Apply Filtering by Using Enterprise Manager

You can use Enterprise Manager to implement SQL Apply filtering by navigating to the Edit
Standby Database Properties page. On the Standby Role Properties tabbed page, expand
Advanced Properties to access the Skip Table Entries section.
Use the Add Skip Table Entry page to specify the following skip criteria:
• Identify SQL statements that are not applied to the standby database by specifying the
schema and database object to be skipped.
• Specify criteria to be used to determine if an error should cause log apply services to
stop. All errors to be skipped are stored in system tables that describe how exceptions
should be handled.
• Specify additional processing that should be done (such as execution of a stored
procedure).

Using DBMS_SCHEDULER to Create Jobs
on a Logical Standby Database

• Scheduler jobs can be created on a standby database.
• When a Scheduler job is created, it defaults to the local
role.
• Activate existing jobs by using the DATABASE_ROLE
attribute of DBMS_SCHEDULER.SET_ATTRIBUTE, which

has the following settings:
– PRIMARY: The job runs only when the database is in the role
of the primary database.
– LOGICAL STANDBY: The job runs only when the database is
in the role of a logical standby.
Using DBMS_SCHEDULER to Create Jobs on a Logical Standby Database

Use the DBMS_SCHEDULER package to create Scheduler jobs so that they are executed when
intended. Scheduler jobs can be created on a standby database.
When a Scheduler job is created, it defaults to the local role. If the job is created on the
standby database, it defaults to the role of a logical standby. The Scheduler executes jobs
that are specific to the current database role. Following a role transition (switchover or
failover), the Scheduler automatically switches to executing jobs that are specific to a new
role.
Scheduler jobs are replicated to the standby, but they do not run by default. However, existing
jobs can be activated under the new role by using the DBMS_SCHEDULER.SET_ATTRIBUTE
procedure. If you want a job to run for all database roles on a particular host, you must create
two copies of the job on that host: one with a database_role of 'PRIMARY' and the other
with a database_role of 'LOGICAL STANDBY'. Query the DBA_SCHEDULER_JOB_ROLES
view to determine which jobs are specific to which role.
about using the DBMS_SCHEDULER package.

Quiz
By default, users are able to create additional indexes and

materialized views in a logical standby database.
a. True
b. False

Answer: b

Quiz
Scheduler jobs created on the primary database are replicated

to the logical standby database, but do not execute by default.
a. True
b. False

Answer: a

Summary

• Create a logical standby database
• Manage SQL Apply filtering


This practice covers using Enterprise Manager to create a

logical standby database


Database

Creating and Managing a Snapshot Standby

Objectives

• Create a snapshot standby database to meet the
requirement for a temporary, updatable snapshot of a
physical standby database
• Convert a snapshot standby database back to a physical

standby database

Snapshot Standby Databases: Overview
• A snapshot standby database is a fully updatable standby

database created by converting a physical standby
database.
• Snapshot standby databases receive and archive—but do
not apply—redo data from a primary database.

• When the physical standby database is converted, an
implicit guaranteed restore point is created and Flashback
Database is enabled.
Snapshot Standby Databases: Overview

A snapshot standby database is a fully updatable standby database that is created by
converting a physical standby database to a snapshot standby database. A snapshot standby
database receives and archives—but does not apply—redo data from a primary database.
Redo data received from the primary database is applied when a snapshot standby database
is converted back to a physical standby database, after discarding all local updates to the
snapshot standby database.
You can create a snapshot standby database by using DGMGRL commands or SQL
commands.
When the standby database is converted to a snapshot standby database, an implicit
guaranteed restore point is created and Flashback Database is enabled. After performing
operations on the snapshot standby database, you can convert it back to a physical standby
database.
Data Guard implicitly flashes the database back to the guaranteed restore point and
automatically applies the primary database redo that was archived by the snapshot standby
database since it was created. The guaranteed restore point is dropped after this process is
completed.

Snapshot Standby Database: Architecture
Primary
database MRP Snapshot
transactions standby
database
LGWR LNSn RFS
Transactions
Oracle n et

Online
redo Standby
logs redo logs
ARC0
ARC0

logs logs
Snapshot Standby Database: Architecture

After a physical standby database is converted to a snapshot standby database, Redo Apply
no longer applies the redo data. The redo data continues to be received using the defined
transport method (SYNC or ASYNC), but it is not applied until the snapshot standby database is
converted back to a physical standby database.

Converting a Physical Standby Database
to a Snapshot Standby Database

To convert a physical standby database to a snapshot standby
database:
DGMGRL> CONVERT DATABASE pc01sby1
>TO SNAPSHOT STANDBY;

Converting database "pc01sby1" to a Snapshot Standby
database, please wait...
Database "pc01sby1" converted successfully
Converting a Physical Standby Database to a Snapshot Standby Database

Use the CONVERT DATABASE DGMGRL command to convert a physical standby database to
a snapshot standby database, as in the following example:
DGMGRL> convert database pdb1 to snapshot standby;
Converting database "pdb1" to a Snapshot Standby database,
please wait...
Database "pdb1" converted successfully

Activating a Snapshot Standby Database:
Issues and Cautions

When activating a snapshot standby database, be aware of:
• Potential data loss with a corrupted log file
• Lengthy conversion of the snapshot standby database to a
primary database in the event of a failure of the primary
database

Activating a Snapshot Standby Database: Issues and Cautions

Keep the following in mind when activating a snapshot standby database:
• Potential data loss when there is a corrupted log file: The snapshot standby
database accepts redo log files but does not apply them. If there is a corrupted redo log
file at the snapshot standby database, it is not discovered until the database is
converted back to a physical standby database and the managed recovery process
(MRP) is started. If the primary database is unavailable at that time, there is no way to
retrieve that log. Also, the loss or corruption of a flashback log file might prevent
conversion back to a physical standby database.
• Lengthy conversion of the snapshot standby database to a primary database: In
the event of a failure of the primary database, the snapshot standby database can be
converted back to a physical standby database. The redo that has been received can
then be applied, and the database can be converted to a primary database. If the
snapshot standby database lags far behind the primary database, it may take a long
time to apply the redo that has been received and convert it to the primary database.

Snapshot Standby Database: Target Restrictions
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHI BITED
A snapshot standby database cannot be:

• The only standby database in a maximum protection
configuration
• The target of a switchover
• A fast-start failover target

Snapshot Standby Database: Target Restrictions

When you convert the physical standby database to a snapshot standby database, it cannot
be the only standby database in the configuration if your configuration is in maximum
protection mode. In addition, you cannot make changes to the configuration after converting to
a snapshot standby database that would create this situation.
You cannot perform a switchover to a snapshot standby database.
A snapshot standby database cannot be configured as a fast-start failover target.

Viewing Snapshot Standby Database Information
View the database role by querying V$DATABASE:

SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------

SNAPSHOT STANDBY
Viewing Snapshot Standby Database Information

The DATABASE_ROLE column of the V$DATABASE view indicates that the database is a
snapshot standby database.

Using DGMGRL to View
Snapshot Standby Database Information

View snapshot standby information by using the SHOW
CONFIGURATION and SHOW CONFIGURATION VERBOSE
commands:
DGMGRL> show configuration

Databases:
pc01sby1 - Snapshot standby database
pc01sby3 - Logical standby database
SUCCESS
Using DGMGRL to View Snapshot Standby Database Information

Use the SHOW CONFIGURATION and SHOW CONFIGURATION VERBOSE DGMGRL commands
to display information about the snapshot standby database.

Using DGMGRL to View
Snapshot Standby Database Information

View snapshot standby information by using the SHOW
DATABASE and SHOW DATABASE VERBOSE commands:
DGMGRL> show database pc00sby1
Database - pc01sby1

Enterprise Manager Name: pc01sby1.us.oracle.com
Role: SNAPSHOT STANDBY
Intended State: APPLY-OFF
Transport Lag: 0 seconds
Apply Lag: 42 seconds
Instance(s):
pc01sby1
Database Status:
SUCCESS
Using DGMGRL to View Snapshot Standby Database Information (continued)

When you execute the SHOW DATABASE and SHOW DATABASE VERBOSE commands for a
snapshot standby database, ―SNAPSHOT STANDBY‖ is displayed in the role field.

Converting a Snapshot Standby Database
to a Physical Standby Database

Convert the snapshot standby database back to a physical
standby database:
DGMGRL> CONVERT DATABASE pc01sby1
>TO PHYSICAL STANDBY;

Converting a Snapshot Standby Database to a Physical Standby Database

Use the CONVERT DATABASE command to convert the database back to a physical standby
database.

Quiz
A snapshot standby database can be created from a logical

standby database.
a. True
b. False

Answer: b

Summary

• Create a snapshot standby database
• Convert a snapshot standby database back to a physical
standby database



• Converting a physical standby database to a snapshot
standby database
• Updating the primary database and the snapshot standby
database

• Converting the snapshot standby database back to a


Using Oracle Active Data Guard

Objectives

• Use Real-time Query to access data on a physical standby
database
• Enable RMAN block change tracking for a physical
standby database


Oracle Active Data Guard
• Is an option for Oracle Database 11g Enterprise Edition

• Enhances quality of service by offloading resource-
intensive activities from a production database to a
standby database
• Includes the following features:

– Real-time query
– RMAN block change tracking on a physical standby
database
Oracle Active Data Guard

Oracle Active Data Guard is a separately licensed database option for Oracle Database 11g
Enterprise Edition. It includes the Real-time Query feature, which enables a physical standby
database to be open read-only while Redo Apply is active. With this feature, users who are
connected to a physical standby database can query and report against data that is up-to-
date with the primary database.
Oracle Active Data Guard also enables you to configure RMAN block change tracking for a
physical standby database. With RMAN block change tracking, you can offload fast
incremental backups from the production database to the physical standby database.

Using Real-Time Query
Redo Redo
transport apply

Redo
Primary stream Physical standby Queries
database database
Using Real-Time Query

With Oracle Active Data Guard, you can use a physical standby database for queries while
redo is applied to the physical standby database. This feature enables you to use a physical
standby database for disaster recovery and to offload work from the primary database during
normal operation.
Note: If you need to create additional structures (such as indexes and materialized views),
you can create a logical standby database as described in the lesson titled ―Creating a
Logical Standby Database.‖
In addition, this feature provides a loosely coupled read/write clustering mechanism for OLTP
workloads when configured as follows:
• Primary database: Recipient of all update traffic
• Several readable standby databases: Used to distribute the query workload
The physical standby database can be opened in read-only mode only if all files were
recovered up to the same system change number (SCN). Otherwise, the open fails.

Enabling Real-Time Query
1. Verify that real-time query mode is not enabled:

2. Open the database for read-only access:

SQL> ALTER DATABASE OPEN READ ONLY;

Database altered.
3. Verify that real-time query mode is now enabled:

Enabling Real-Time Query

With Oracle Database 11g Release 2 (11.2), it is no longer necessary to stop redo apply on a
physical standby database when opening the database to enable real-time query mode if and
only if the physical standby is managed by the Data Guard broker. The Data Guard broker
automatically stops redo apply when an open is attempted. After the instance is opened, the
Data Guard broker automatically restarts redo apply according to the settings recorded in the
broker configuration file.
Database - pc01sby1
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Real Time Query: OFF
Instance(s):
pc01sby1

Enabling Real-Time Query (continued)
Database Status:
SUCCESS
SQL> alter database open read only;

Database altered.

Database - pc01sby1

Real Time Query: ON
Instance(s):
pc01sby1
Database Status:
SUCCESS
The second SHOW DATABASE command may show an Apply Lag depending on redo activity
since Redo Apply had to be stopped during transition.
If your standby database is not managed by the Data Guard broker, you must temporarily stop
Redo Apply to open the physical standby database in read-only mode. After opening the
database, restart Redo Apply. This enables the physical standby database to stay current with
the primary database as users perform queries against data. This can be performed with the
following commands:
DGMGRL> edit database 'pc01sby1' set state='apply-off';
SQL> alter database open read only;
DGMGRL> edit database 'pc01sby1' set state='apply-on';
Note: There is no DGMGRL command to enable Real-time Query.

Disabling Real-Time Query
1. Shut down the standby database instance.

2. Restart the standby database instance in MOUNT mode.

Disabling Real-Time Query

To disable Real-time Query, you must shut down the standby database instance and restart it
in MOUNT mode.

Checking the Standby’s Open Mode
• A physical standby database opened in read-only mode:

SQL> SELECT open_mode FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY

• A physical standby database opened in real-time query
mode:
SQL> SELECT open_mode FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
Checking the Standby’s Open Mode

You can use the OPEN_MODE column of V$DATABASE to check the open mode of a physical
standby database. If the physical standby database stops redo apply in order to open the
database in read-only mode, then the OPEN_MODE column will indicate 'READ ONLY'.
After the database has been opened read-only, Redo Apply can be restarted to enable Active
Data Guard real-time query mode with the following command:
SQL> alter database recover managed standby database using
current logfile disconnect;
After Redo Apply has been started on an open read-only physical standby database, the
OPEN_MODE column will indicate 'READ ONLY WITH APPLY'.

Understanding Lag in an Active Data Guard
Configuration
• A standby database configured with real-time apply can
lag behind the primary database as a result of:
– Insufficient CPU capacity
– High network latency
– Limited bandwidth

• Queries on the standby database need to return current
results and/or be within an established service level.
• Ways to ―manage‖ the standby database lag and take
necessary action:
– Configure Data Guard configuration with a maximum data
lag that will trigger an error when it is exceeded.
– Monitor the redo apply lag and take action when the lag is
unacceptable.
Understanding Lag in an Active Data Guard Configuration

Active Data Guard can improve performance by off-loading a read-only workload to a physical
standby database. However, due to hardware and network issues, the data on a standby
database may lag behind the data on the primary database. The standby database may not
always be current with the primary database if it does not have the capacity to apply redo as
quickly as it is received. Limited bandwidth may prevent the primary database from shipping
redo as quickly as it is generated, particularly during periods of peak workload.
Oracle Database 11g Release 2 (11.2) includes features to enable you to determine the lag
time and take appropriate action.
You can establish a tolerance level for data staleness by configuring a maximum value for
apply lag. Query results are returned to the application if the lag is within the acceptable
tolerance level; otherwise, an error results.
If you determine that you want your application to receive the results of a query, regardless of
the ―staleness‖ of the data, you can monitor the apply lag via the V$DATAGUARD_STATS view
and then take appropriate action if the lag is unacceptable.

Monitoring Apply Lag: V$DATAGUARD_STATS
• Apply lag: This is the difference, in elapsed time, between

when the last applied change became visible on the
standby and when that same change was first visible on
the primary.
• The apply lag row of the V$DATAGUARD_STATS view

reflects statistics that are computed periodically and to the
nearest second.
SQL> SELECT name, value, datum_time, time_computed
2> FROM v$dataguard_stats
3> WHERE name like 'apply lag';
NAME VALUE DATUM_TIME TIME_COMPUTED

--------- ------------- -------------------- --------------------
apply lag +00 00:00:00 27-MAY-2009 08:54:16 27-MAY-2009 08:54:17
Monitoring Apply Lag: V$DATAGUARD_STATS

Apply lag has been redefined in Oracle Database 11g Release 2 (11.2). Apply lag is a
measure of the degree to which a standby database lags behind the primary database, due to
delays in propagating and applying redo to the standby database.
The apply lag metric is computed using data that is periodically received from the primary
database. The DATUM_TIME column contains a timestamp of when this data was last
received by the standby database. The TIME_COMPUTED column contains a timestamp taken
when the apply lag metric was calculated. The difference between the values in these
columns should be less than 30 seconds. If the difference is larger than this, the apply lag
metric may not be accurate. This metric is computed to the nearest second.

Monitoring Apply Lag:
V$STANDBY_EVENT_HISTOGRAM
• View histogram of apply lag on a physical standby
database.
• Use to assess value for STANDBY_MAX_DATA_DELAY.
• Use to focus on periods of time when the apply lag
exceeds desired levels so that issue can be resolved.

S QL> S ELECT * FROM V$S TANDBY_EVENT_HIS TOGRAM
2> WHERE NAME = 'apply lag' AND COUNT > 0;
NAME TIME UNIT COUNT LAS T_TIME_UPDATED

--------- --------- -------- ----------- ------------------------
apply lag 0 seconds 79681 06/18/2009 10:05:00
6 rows selected
Monitoring Apply Lag: V$STANDBY_EVENT_HISTOGRAM

V$STANDBY_EVENT_HISTOGRAM is a new view that is available on the standby database.
This view displays the histogram of the apply lag on the physical standby database.
Use the histogram to focus on periods of time when the apply lag exceeds desired levels.
Determine the cause of the lag during those time periods and take steps to resolve the
excessive lag.
Each distinct value of apply lag has its own bucket. The count in the bucket is incremented
when the physical standby database samples its data delay.

Setting a Predetermined Service Level for
Currency of Standby Queries

• STANDBY_MAX_DATA_DELAY session parameter:
Specifies a session-specific limit for the amount of time (in
seconds) allowed to elapse between when changes are
committed on the primary and when those same changes
can be queried on the standby database

ALTER SESSION
SET STANDBY_MAX_DATA_DELAY = {INTEGER|NONE}
• If the limit is exceeded, an error message is returned:

ORA-3172 STANDBY_MAX_DATA_DELAY has been exceeded
• This setting is ignored for the SYS user.
Setting a Predetermined Service Level for Currency of Standby Queries

You can configure a limit through the use of the STANDBY_MAX_DATA_DELAY session
parameter. Use this session parameter to specify a limit for the amount of time (in seconds)
allowed to elapse between when changes are committed on the primary database and when
those same changes can be queried on the active standby database.
If the specified limit cannot be met, an error is returned to the query as follows:
ORA-3172 STANDBY_MAX_DATA_DELAY has been exceeded
This guarantees that a query will not receive a ―stale result‖ if the apply lag exceeds the
service level agreement. In addition, a warning message is written to the standby database
alert log.
The default value is NONE, which indicates that queries issued to the physical standby
database will be executed regardless of the apply lag on that database.

Configuring Zero Lag Between the Primary and
Standby Databases
• Certain applications have zero tolerance for any lag.
• Query on the standby database must return the same
result as though it were executed on the primary database.
• Enforce by setting STANDBY_MAX_DATA_DELAY to 0.
• The standby database must have advanced to a value

equal to that of the current SCN on the primary database
at the time the query was issued.
• Results are guaranteed to be the same as the primary
database, else ORA-3172 error is returned to the query.
• The primary database must operate in maximum
availability or maximum protection mode.
• SYNC must be specified for redo transport.
• Real-time query must be enabled.
Configuring Zero Lag Between the Primary and Standby Databases

You can ensure that your application querying data on the standby database sees all data
that has been committed on the primary database by setting STANDBY_MAX_DATA_DELAY to
0.
A query does not execute until the query SCN on the standby database has advanced to a
value equal to that of the current SCN on the primary database at the time the query was
issued.
To support zero lag, the primary database must operate in maximum availability or maximum
protection mode.
Specify SYNC for redo transport mode.
Real-time query must be enabled as a prerequisite for configuring zero lag.

Setting STANDBY_MAX_DATA_DELAY by Using an
AFTER LOGON Trigger

Create an AFTER LOGON trigger that:
• Is database role aware
– It uses DATABASE_ROLE, a new attribute in the USERENV
context.
– SQL and PL/SQL clients can retrieve the database role

programmatically using the SYS_CONTEXT function.
– It enables you to write role-specific triggers.
• Sets STANDBY_MAX_DATA_DELAY when the application
logs on to a real-time query–enabled standby database
• Allows for configuration of a maximum data delay without
changing the application source code
Setting STANDBY_MAX_DATA_DELAY by Using an AFTER LOGON Trigger

You can create an AFTER LOGON trigger that sets the STANDBY_MAX_DATA_DELAY session
parameter when the database is a physical standby database that is operating in real-time
query mode.
In Oracle Database 11g Release 2 (11.2), the DATABASE_ROLE attribute of the USERENV
context enables you to determine the role of the database. SQL and PL/SQL clients can
retrieve this information by using the SYS_CONTEXT function. This enables you to write
triggers that perform certain actions based on the database role.

Example: Setting STANDBY_MAX_DATA_DELAY by
Using an AFTER LOGON Trigger
CREATE OR REPLACE TRIGGER sla_logon_trigger

AFTER LOGON
ON APP.SCHEMA
BEGIN

IF (SYS_CONTEXT('USERENV', 'DATABASE_ROLE')
IN ('PHYSICAL STANDBY'))
THEN execute immediate
'alter session set standby_max_data_delay=5';
ENDIF;
END;
Example: Setting STANDBY_MAX_DATA_DELAY by Using an AFTER LOGON Trigger

The slide presents an example of an AFTER LOGON trigger that is used to set the value of
STANDBY_MAX_DATA_DELAY based on the database role.

Forcing Redo Apply Synchronization
• The ALTER SESSION SYNC WITH PRIMARY command:

– Performs a blocking wait on the standby database upon
execution
– Blocks the application until the standby database is in sync
with the primary database as of the time this command is

executed
• When the ALTER SESSION SYNC WITH PRIMARY
command returns control, the session can continue to
process queries without having to wait for standby redo
apply.
• An ORA-3173 Standby may not be synced with
primary error is returned if redo apply is not active or is
canceled before the standby database is in sync with the
primary database as of the time this command is executed.
Forcing Redo Apply Synchronization

You can execute the ALTER SESSION SYNC WITH PRIMARY command to ensure that the
standby database is completely synchronized with the primary database at the time of
execution. The use of this command is particularly applicable in a reporting environment.
ALTER SESSION SYNC WITH PRIMARY performs a blocking wait on the standby database
upon execution. This command causes the application to be blocked until the standby
database is in sync with the primary database as of the time this command is executed.
When the ALTER SESSION command returns control to the session, the session can continue
to process queries without having to wait for redo apply on the standby database.
If redo apply is not active or is canceled before the standby database is in sync with the
primary database, an ORA-3173 Standby may not be synced with primary error is
returned.

Creating an AFTER LOGON Trigger for
Synchronization
• Use an AFTER LOGON trigger to force a wait for
synchronization between primary and standby databases.
• Use for dedicated connection only.
• This ensures that the reporting application starts with the
current data without requiring a change to the application

source code.
CREATE TRIGGER adg_logon_sync_trigger
AFTER LOGON ON user.schema
BEGIN
IF (SYS_CONTEXT('USERENV','DATABASE_ROLE') IN
('PHYSICAL STANDBY'))
THEN
execute immediate 'alter session sync with primary';
END IF;
END;
Creating an AFTER LOGON Trigger for Synchronization

This type of trigger is useful when you are using the standby database for reporting and want
to be sure that the reports have the most current data. The standby-only AFTER LOGON trigger
executes the ALTER SESSION SYNC WITH PRIMARY command to force a wait for
synchronization between the primary database and the standby database. A standby-only
trigger is created and enabled on the primary database, and then becomes part of the redo
that is propagated to the standby database. However, the trigger logic is designed only to take
certain actions if the database role is set to ―physical standby.‖

Supporting Read-Mostly Applications
• Read-mostly applications are predominantly read-only

applications, but require limited read-write database
access.
• Active Data Guard supports the read-only portion of read-
mostly applications if writes are redirected to the primary

database or a local database.
• Redirection of read-write workload does not require
application code changes.
• Writes can be transparently redirected to the primary
database if the application adheres to the following:
– Modified objects must not be qualified by a schema name.
– SQL commands must be issued directly from the client, not
in stored procedures.
Supporting Read-Mostly Applications

Reporting applications that are predominantly read-only, but require limited read-write
database access are referred to as read-mostly applications. Active Data Guard enables a
standby database to support the read-only portion of read-mostly applications if writes are
redirected to the primary database or a local database.

Example: Transparently Redirecting Writes to the
Primary Database
• Application characteristics:
– Executes as user U
– Reads table U.R (R) and writes to table U.W (W)
– User S has S.R synonym for U.R and S.W synonym for
U.W@primary.

• Create an AFTER LOGON trigger on the standby database:
CREATE TRIGGER adg_logon_switch_schema_trigger
AFTER LOGON ON u.schema
BEGIN
IF (SYS_CONTEXT('USERENV','DATABASE_ROLE')
IN ('PHYSICAL STANDBY'))
THEN
execute immediate
'alter session set current_schema = S';
END IF;
END;
Example: Transparently Redirecting Writes to the Primary Database

Consider an application as described in the slide. The application executes as user U, reading
the U.R table and writing to the U.W table. The application connects as user U when
executing on the primary database.
User S accesses U.R with the S.R synonym and U.W with the S.W synonym.
The AFTER LOGON trigger is created on the standby database for another user, R.
When the application executes on the standby database, it connects as the U user. The
AFTER LOGON trigger fires and transparently switches to the S schema. All reads on R
execute as reads to the U.R table on the standby database. All reads and writes to W execute
as reads and writes to U.W@primary.

Enabling Block Change Tracking
on a Physical Standby Database

• Enable block change tracking on a physical standby
database for fast incremental backups.
• Data file blocks that are affected by each database update
are tracked in a block change tracking file.
• The block change tracking file is a binary file used by

RMAN to record changed blocks to improve incremental
backup performance.
Enabling Block Change Tracking on a Physical Standby Database

With the Oracle Active Data Guard option, you can enable block change tracking on a
physical standby database. When you back up the physical standby database, RMAN uses
the block change tracking file to quickly identify the blocks that have changed since the last
incremental backup. RMAN reads only the changed blocks rather than the entire data file.

Creating Fast Incremental Backups
• Block change tracking optimizes incremental backups:

– Tracks the blocks that have changed since the last backup
• Oracle Database has integrated change tracking:
– A change tracking file is used.
– Changed blocks are tracked as redo is generated.

– Database backup automatically uses the changed-block list.
List of changed
blocks 1011001010110 Change-
CTWR
0001110100101 tracking
Redo 1010101110011 file
generation
SGA Redo log
Creating Fast Incremental Backups

The goal of an incremental backup is to back up only those data blocks that have changed
since a previous backup. You can use RMAN to create incremental backups of data files,
tablespaces, or the entire database. During media recovery, RMAN examines the restored
files to determine whether it can recover them from an incremental backup. RMAN always
chooses incremental backups over archived redo logs because applying changes at a block
level is faster than reapplying individual changes.
If you enable the block change tracking feature, Oracle Database tracks the physical location
of all database changes in the change tracking file. RMAN uses this change-tracking data to
determine which blocks to read during an incremental backup, creating much faster
incremental backups by eliminating the need to read the entire data file. The maintenance of
this file is fully automatic and does not require your intervention. The size of the change
tracking file is proportional to the following:
• Database size in bytes
• Number of enabled threads in a RAC environment
• Number of old backups maintained by the change tracking file
The minimum size for the change tracking file is 10 MB; new space is allocated in 10 MB
increments. By default, the Oracle Database server does not record block-change
information.

ALTER DATABASE
{ENABLE|DISABLE} BLOCK CHANGE TRACKING
[USING FILE '...']

You enable block change tracking from the database home page. Click the Policy tab on the
Backup Settings page. You do not need to set the change tracking file destination if the
DB_CREATE_FILE_DEST initialization parameter is set, because the file is created as an
Oracle Managed File (OMF) file in the DB_CREATE_FILE_DEST location. You can, however,
specify the name of the change tracking file and place it in any location you choose.
You can also enable or disable block change tracking by using an ALTER DATABASE SQL
command. If the change tracking file is stored in the database area with your database files, it
is deleted when you disable change tracking.
You can rename the change tracking file by using the ALTER DATABASE RENAME SQL
command. Your database must be in the MOUNT state to rename the tracking file. The ALTER
DATABASE RENAME FILE command updates the control file to refer to the new location. Use
the following syntax to rename the change tracking file:
ALTER DATABASE RENAME FILE '...' TO '...';

Monitoring Block Change Tracking
SQL> SELECT filename, status, bytes

2 FROM v$block_change_tracking;
SQL> SELECT file#, avg(datafile_blocks),

2 avg(blocks_read),
3 avg(blocks_read/datafile_blocks)
4 * 100 AS PCT_READ_FOR_BACKUP,
5 avg(blocks)
5 FROM v$backup_datafile
6 WHERE used_change_tracking = 'YES'
7 AND incremental_level > 0
8 GROUP BY file#;
Monitoring Block Change Tracking

The output of the V$BLOCK_CHANGE_TRACKING view shows where the change tracking file
is located, the status of block change tracking (ENABLED/DISABLED), and the size (in bytes)
of the file.
Querying the V$BACKUP_DATAFILE view shows the effectiveness of block change tracking in
minimizing the incremental backup I/O (the PCT_READ_FOR_BACKUP column). A high value
indicates that RMAN reads most blocks in the data file during an incremental backup. You can
reduce this ratio by decreasing the time between incremental backups.
Sample Formatted Output from the V$BACKUP_DATAFILE Query
FILE# BLOCKS_IN_FILE BLOCKS_READ PCT_READ_FOR_BACKUP BLOCKS_BACKED_UP
----- -------------- ----------- ------------------- ----------------
1 56320 4480 7 462
2 3840 2688 70 2408
3 49920 16768 33 4457
4 640 64 10 1
5 19200 256 1 91

Quiz
The STANDBY_MAX_DATA_DELAY parameter can be set at the

system level.
a. True
b. False

Answer: b

Summary

• Use Real-time Query to access a physical standby
database
• Enable block change tracking on a physical standby
database



• Using Real-time Query
• Enabling block change tracking



Configuring Data Protection Modes

Objectives

• Describe the data protection modes
• Change the data protection mode of your configuration


Data Protection Modes and
Redo Transport Modes

• A data protection mode requires a specific redo transport
mode.
• A redo transport mode alone does not define a data
protection mode.

Data Protection Modes and Redo Transport Modes

When you define a redo 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 redo
transport mode to support the protection mode that you want for your configuration. However,
configuring the redo transport mode alone does not set up the protection mode.
After setting up the redo transport mode, you can put the configuration into a data protection
mode. The data protection mode setting causes internal rules to be implemented, ensuring
that your configuration is protected at the necessary level.

• 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 the potential loss of data.

Maximum Protection Mode
• Maximum protection mode ensures zero data loss in the

event of a failure of the primary database, the network, or
all standby databases.
• The primary database shuts down if a fault prevents it from
writing its redo stream to at least one synchronized

standby database.
• Redo data must be written to both the local online redo log
and the standby redo log on at least one synchronized
standby database.
• Configuration requirements: At least one standby database
must have a standby redo log, and that standby database
destination must be configured with the SYNC and AFFIRM
redo transport attributes.
Maximum Protection Mode

This protection mode ensures that no data loss occurs if the primary database fails. To
provide this level of protection, the redo data that is needed to recover each transaction must
be written to both the local online redo log and the standby redo log 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.
Maximum protection mode requirements:
• Configure standby redo log files on at least one standby database.
• Set the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter for at
least one standby database destination.
Note: Oracle recommends a minimum of two standby databases for maximum protection
mode.

Maximum Availability Mode
• Maximum availability mode ensures zero data loss 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 synchronized
standby database.
•

The primary database does not shut down if it cannot write
to at least one synchronized standby database.
• If no synchronized standby databases are available, the
primary database operates in an unsynchronized mode
until at least one standby database is synchronized.
• Configuration requirements: At least one standby database
must have a standby redo log, and that standby database
destination must be configured with the SYNC and AFFIRM
redo transport attributes.
Maximum Availability Mode

This protection mode provides the highest possible level of data protection without
compromising the availability of the primary database. A transaction does not commit until the
redo that is needed to recover that transaction is written to the local online redo log and to at
least one remote standby redo log. 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 an unsynchronized mode until the fault is corrected and all gaps in redo
log files are resolved. When all gaps are resolved and the standby database is synchronized,
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 availability mode requirements:
• Configure standby redo log files on at least one standby database.
• Set the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter for at
least one standby database.

Maximum Performance Mode
• Maximum performance mode is the default level of data

protection.
• This mode provides the highest possible level of data
protection without affecting the performance of the primary
database.

• Transactions can commit as soon as the redo data is
written to the local online redo log.
• Redo data is shipped to the standby database
asynchronously with respect to the commitment of the
transactions that create the redo data.
• Configuration requirements:
• Standby redo log on at least one standby database
• At least one standby database that is configured with the
ASYNC and NOAFFIRM redo transport attributes
Maximum Performance Mode

Maximum performance is the default protection mode and 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 is
also written to at least one standby database, but that redo data 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.
Maximum performance mode requirement: Set the ASYNC and NOAFFIRM redo transport
attributes of the LOG_ARCHIVE_DEST_n parameter on at least one standby database.

Comparing Data Protection Modes
Mode Risk of Data Loss Transport If no acknowledgment

is received:
Maximum Zero data loss SYNC Stall primary until an
Protection Double failure protection acknowledgement is
received

Maximum Zero data loss SYNC Stall primary until threshold
Availability period expires, then
resume processing
Maximum Potential for minimal ASYNC Primary never waits for

Performance data loss standby acknowledgement
Comparing Data Protection Modes

Consider the characteristics of each protection mode. You must balance cost, availability,
performance, and transaction protection when choosing the protection mode.
Note: If you plan to enable fast-start failover, you must set the protection mode to maximum
availability or maximum performance. See the lesson titled ―Enabling Fast-Start Failover‖ for
additional information.

Setting the Data Protection Mode
by Using DGMGRL
1. Configure standby redo logs.
2. Set the LogXptMode property (if necessary).
• Maximum protection: SYNC
• Maximum availability: SYNC
• Maximum performance: ASYNC

3. Set the data protection mode.
DGMGRL> EDIT DATABASE 'pc01sby1' SET PROPERTY

'LogXptMode'='SYNC';
Property "LogXptMode" updated
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
MAXAVAILABILITY;
Succeeded.
Setting the Data Protection Mode by Using DGMGRL

1. You must 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 redo 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 redo
transport services:
DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY
'LogXptMode'='SYNC';
You must also set the redo 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, use
the following command:
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
MAXAVAILABILITY;

Click the

Protection Mode link.

If the data protection mode that you need requires a standby database to use the SYNC or
ASYNC redo transport mode, Enterprise Manager automatical y sets the redo 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 that are needed for all databases in the configuration and adds those log files using the
directory locations that you specify.
To set the data protection mode with Enterprise Manager:
1. Navigate to the Data Guard page.
2. Click the link in the Protection Mode field to access the Change Protection Mode: Select
Mode page.


Setting the Data Protection Mode (continued)

3. Select Maximum Protection, Maximum Availability, or Maximum Performance, and click
Continue.
4. If prompted, enter the username and password of a user with SYSDBA privileges. 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.

Quiz
Which of the following are allowed Data Guard protection

modes?
a. Maximum Protection
b. Maximum Availability
c. Maximum Throughput

d. Maximum Performance
Answer: a, b, d

Summary

• Describe the data protection modes
• Change the data protection mode of your configuration


This practice covers setting the data protection mode:

• To meet specific business requirements
• By using DGMGRL
• By using Enterprise Manager


Performing Role Transitions

Objectives

• Explain the database roles
• Perform a switchover
• Perform a failover


Role Management Services
• In a Data Guard configuration, a database operates in one

of two mutually exclusive roles:
– Primary role
– Standby role (Physical, Logical, Snapshot subtypes)
• 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.

• Switchover
– Planned role transition
– Used for operating-system or hardware maintenance
– Manually invoked on primary database
• Failover

– Unplanned role transition
– Used in an emergency
– Minimal or no data loss (depending on the
data-protection mode)
– Fast-start failover can be enabled for automatic failover
– Initiated at standby database

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 involved in the switchover operation. There is no data
divergence between the original and new primary databases after successful completion of
the switchover.
Failover
You invoke a failover operation when a 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 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.
Note: You can enable fast-start failover to fail over automatically when the primary database
becomes unavailable. When fast-start failover is enabled, the broker determines if a failover is
necessary and initiates the failover to the specified target standby database automatically,
with no need for DBA intervention and with no loss of data. For details, see the lesson titled
―Enabling Fast-Start Failover.‖

Switchover
• Transitions the roles of the primary and standby databases

• Requires no resetting of the online redo logs of the new
primary database
• Incurs 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.
The primary database at the start of a switchover operation will need to be shutdown and
restarted. The physical standby database is not shutdown and restarted during a switchover.
If the physical standby database is in the Active Data Guard mode, it is closed for the
transition then opened again after the switchover completes, but it is never totally shutdown to
require a restart.
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.
Note: When necessary, the broker automatically starts and stops all but one instance in a
Real Application Clusters (RAC) environment for the primary database. If the broker is not
used, this must be done manually. Starting with Oracle Database 11g Release 2 (11.2), the
secondary RAC instances of a physical standby database no longer need to be shutdown
during the switchover. They can stay in the mounted or Active Data Guard state. The primary
still requires only one instance be running during a switchover.

Switchover: Before
Read/write Primary database

transactions (Instance Name: SFO1)
Application

San Francisco Oracle Net
Boston
Standby database Read-only

(Instance Name: BOS1) reports
Application
Switchover: Before
As an example, suppose that the primary database is located in San Francisco and the
physical standby database is located in Boston. Switchovers are started only on the primary
database and completed on the target standby database. You can be connected to any
database in the configuration through DGMGRL to execute the SWITCHOVER command.

Switchover: After
Read-only Standby database

reports (Instance Name: SFO1)
Application

San Francisco Oracle Net
Boston
Primary database Read/write

(Instance Name: BOS1) transactions
Application
Switchover: After
After the switchover is completed, each database has the role opposite to the one that it had
before the switchover. In this example, Boston is now the primary database and San
Francisco is the standby database.
Because Data Guard does not automatically switch over sessions from one database to the
other, active sessions for each system need to reconnect. See the lesson titled ―Managing
Client Connectivity‖ for information about configuring automatic methods to reconnect
sessions.

Preparing for a Switchover
To prepare for the switchover operation, verify that:

• Network connectivity exists between the primary database
and all standby database locations
• State of the primary database is TRANSPORT-ON and state
of the standby database is APPLY-ON

• Standby database properties are set on the primary
database
• Standby redo log files are configured on the primary
database
• LogXptMode is set to SYNC on the current primary
database if the configuration protection mode is set to
maximum availability or maximum protection
Preparing for a Switchover

Before you execute the SWITCHOVER command, verify the fol owing:
• Each location in the Data Guard configuration has connectivity through Oracle Net to the
primary database and to all associated standby databases.
• The state of the primary is set to TRANSPORT-ON and the state of the standby
databases is APPLY-ON.
• There are no errors or warning for any of the participating databases.
• The standby LogXptMode, DbFileNameConvert, LogFileNameConvert,
StandbyArchiveLocation, and LogArchiveFormat database properties are set
on the primary database, so that the primary database can function correctly when
transitioned to a standby database.
• The LogXptMode configurable database property is set to SYNC on the current primary
database if the configuration is set to in either maximum availability mode or maximum
protection mode.
• Standby redo log files are configured on the primary database. 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.
Performing a Switchover by Using DGMGRL
After verifying the conditions required for a switchover, execute

the SWITCHOVER command:
DGMGRL> SWITCHOVER TO 'pc01sby1';
Performing switchover NOW, please wait...
New primary database "pc01sby1" is opening...
Operation requires shutdown of i nstance "pc01prmy" on

database "pc01prmy"
Shutting down instance "pc01prmy"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "pc01prmy" on
database "pc01prmy"
Starting instance "pc01prmy"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "pc01sby1"
Performing a Switchover by Using DGMGRL

After verifying the conditions required for executing a switchover, execute the SWITCHOVER
command to perform the switchover operation. The Data Guard broker performs the following
operations:
1. Verifies that the primary database and target standby database are in the correct states
2. Shuts down any instances as necessary
3. Switches roles between the primary and standby databases
4. Updates the broker configuration file with the new role information
5. Restarts the new standby database
6. Opens the new primary database in read/write mode and starts redo transport services
Note: For detailed information about each step, see Oracle Data Guard Broker.

Performing a Switchover

Select the database and
click Switchover.
Performing a Switchover by Using Enterprise Manager

When it is used for the switchover, Enterprise Manager:
a. Checks 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. Automatically closes any active sessions connected to the primary database during the
switchover
c. First changes the primary database to the standby role, and then changes the standby
database to the primary role
d. Opens the target database if it is a mounted physical standby database and restarts the
former primary database
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.
The Data Guard Switchover Confirmation page is displayed.


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

3. Click the Browse Primary Database Sessions link to view active sessions.
4. Click Yes to continue with the switchover, or click No to cancel.
You cannot cancel the switchover operation after it begins.


Performing a Switchover by Using Enterprise Manager (continued)

The Data Guard Switchover Processing page displays the progress of the switchover
operation as it:
• Switches roles between the primary and standby databases (If the switchover target is a
physical standby database and mounted, it is opened without restarting. The former
primary database is restarted.)
• Waits 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.

Considerations When Performing a Switchover
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHI BITED
to a Logical Standby Database

• The switchover operation does not cause a shutdown of
the primary database instance.
• Although there is no need to terminate user sessions,
termination is recommended.
• The logical standby database may not have all data.

• Switchover to a logical standby database invalidates and
disables all physical and snapshot standby databases in
the broker managed Data Guard configuration.
Considerations 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 not 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 is completed and the database guard is turned on, you should terminate such
open sessions now. The database guard prevents users from making changes in the
• If you switch over to a logical standby database, be aware that you may not have all of
the data that was in your primary database if the logical standby database is only a
subset of the primary database.
• A switchover to a logical standby database invalidates and disables all physical and
snapshot standby databases in the configuration. You must re-create the physical
standby databases from a backup of the new primary database before you can reenable
them.

Situations That Prevent a Switchover
You cannot perform a switchover if:

• Archived redo log files are unavailable.
• Point-in-time recovery is required.
• The production database is not open and cannot be
opened.

Situations That Prevent a Switchover

You cannot perform a switchover if:
• Archived redo log files are unavailable: If there is a gap in the archived redo log files
on the standby database, you cannot 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.
• The 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
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROH IBITED
Local
Archiving
Primary database Online Redo Archived redo

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 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 disabled from the Data Guard environment and a standby database
assumes the primary database role. Failing over to a standby database is a one-way
operation. You cannot "fallback" 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 in a
reasonable amount of time.
In a failover operation:
• The original primary database is presumed to be lost. (If you want, you can reinstate or
re-create the original primary database as a new standby database. You may then
initiate a switchover operation compared to a failover operation to return the databases
to their original roles.)
• 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 unless they
were ahead of the failover target due to differences in apply lag situations. In that case,
they may need to be flashed back to the point the standby became a primary or re-
created.

Types of Failovers
• Manual failover: Invoked by the DBA

– Complete: Attempts to minimize data loss by applying all
available redo on the standby database
– Immediate: No additional data is applied on the standby
database

• Fast-start failover: Invoked automatically by the Data
Guard broker
Types of Failovers
A manual failover is invoked through DGMGRL or Enterprise Manager. There are two types of
manual failover:
• Complete: The maximum amount of redo data for the protection mode is recovered. In
this type of failover, the broker avoids disabling any standby databases that are not the
failover target. Complete failover is the default and recommended type of failover.
• Immediate: No additional redo data is applied to the standby database after the failover
is invoked. This is the fastest type of failover. After an immediate failover, you must re-
create or reinstate the original primary database and all standby databases that were
not a target of the failover.
Note: You should always try to perform a complete failover. Perform an immediate failover
only when a complete failover is unsuccessful. Depending on the destination attributes of redo
transport services, a complete failover can take place without incurring any data loss, while an
immediate failover usually results in the loss of data.
You can configure fast-start failover so that the broker automatically fails over to a chosen
standby database in the event of the loss of the primary database. For details, see the lesson
titled ―Enabling Fast-Start Failover.‖

Failover Considerations
• The old primary database is disabled from the Data Guard

configuration.
• Data loss is possible.
• Failover should be used only in an emergency.
• When choosing a standby database to fail over to, you

should:
– Choose a physical standby database when possible
– Choose the standby database that is most current
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 some or no 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 in 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
• The specific SQL commands that are used to initiate the failover

Performing a Manual Failover by Using DGMGRL
1. Execute the FAILOVER command to initiate the failover

operation on the standby database host:
DGMGRL> FAILOVER TO 'pc01sby1' [IMMEDIATE];
2. Reset the protection mode (if necessary).
3. Reinstate the primary database to serve as a standby

database in the configuration.
4. Reinstate or re-create other disabled standby databases in
the configuration.
Performing a Failover by Using DGMGRL

After determining that the primary database cannot be recovered in a timely manner, execute
the FAILOVER command to perform the failover operation.
If you specify the IMMEDIATE option, no attempt is made to apply any unapplied redo that
has been received.
The Data Guard broker performs the following operations for a complete failover:
a. Verifies that the target standby database is enabled
b. Stops Redo Apply after all unapplied redo data is applied to the target standby database
c. Transitions the target standby database to the primary database role by:
- Opening the new primary database in read/write mode
- Determining if any standby databases need to be reinstated or recreated
- Starting redo transport services
For an immediate failover, the broker does not wait for all available redo data to be applied
(as described in step b). For details about each step, see Oracle Data Guard Broker.

Reenabling Disabled Databases
by Using DGMGRL
• Disabled databases must be reinstated or re-created to
reenable broker management.
• Reinstate a database using REINSTATE DATABASE:
DGMGRL> REINSTATE DATABASE pc01prmy;

• If you cannot reinstate a database, re-create it from a copy
of the primary database and then reenable the database
by using ENABLE DATABASE:
DGMGRL> ENABLE DATABASE pc01prmy;
Reenabling Disabled Databases by Using DGMGRL

After a failover, you may need to reinstate or re-create databases in your configuration.
If a database can be reinstated, the database has the following status after a complete
failover:
ORA-16661: the standby database needs to be reinstated
Note: To reinstate a database, Flashback Database must have been enabled on the
database prior to the failover and flashback logs must be available.
To reinstate the database:
1. Start the database instance and mount the database.
2. Invoke DGMGRL and connect to the new primary database.
3. Use the REINSTATE DATABASE DGMGRL command to reinstate the database.
If a database must be re-created, it has the following status after the failover:
ORA-16795: the standby database needs to be re-created
You must re-create the standby database from a copy of the primary database and then
reenable it by using the ENABLE DATABASE DGMGRL command.

Performing a Failover

Select the database and
click Failover.
Performing a Failover by Using Enterprise Manager

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.


Performing a Failover with Enterprise Manager (continued)

3. On the Data Guard Failover Confirmation page, 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, resulting in a
data-loss failover. An immediate failover should be used only when a complete
failover is not possible.
4. Select the failover option, and click Yes to confirm the failover operation.
.


Performing a Failover with Enterprise Manager (continued)

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

to a Physical Standby Database

The physical standby database
needs to be reinstated.
Performing a Failover to a Physical Standby Database

During the failover operation, the selected standby database transitions into the primary role.
The failover target (a physical standby database) is restarted. When the operation finishes,
the Data Guard Overview page reflects the updated configuration.
After a complete or immediate failover, the primary database and some standby databases
may need to be reinstated or re-created. To reinstate the database, click the ―Database must
be reinstated‖ link. Then click Reinstate on the General Properties page. Enterprise Manager
reinstates the database as a standby database to the new primary database.
Note: Flashback Database must have been enabled on the database prior to the failover, and
the required flashback logs must be available on that database for reinstatement to succeed.
In addition, the database to be reinstated and the new primary database must have network
connectivity.

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 no longer usable. These
databases must be re-created from the new primary database.

Quiz
The target for a failover operation can be a snapshot standby

database.
a. True
b. False

Answer: a

Quiz
After a failover operation, the old primary database is removed

from the Data Guard configuration and must be re-created from
a backup.
a. True
b. False

Answer: b

Summary

• Use DGMGRL to perform switchover and failover
operations
• Use Enterprise Manager to perform switchover and failover
operations


This practice covers performing a switchover:

• With DGMGRL
• With Enterprise Manager Grid Control


Configuration

Using Flashback Database in a Data Guard

Objectives

• Explain the advantages of using Flashback Database in a
Data Guard configuration
• Configure Flashback Database


Using Flashback Database in a
Data Guard Configuration

• Flashback Database provides the following in a Data
Guard configuration:
– An alternative to restoring and recovering the primary
database
– A way to reinstate the primary database that was disabled as

part of a failover to any standby database operation
– An alternative to delaying the application of redo to protect
against user errors or logical corruptions
• Flashback Database is used by the following features in a
Data Guard configuration:
– Fast-start failover
– Snapshot standby
Using Flashback Database in a Data Guard Configuration

Flashback Database provides the following advantages in a Data Guard configuration:
• Provides an alternative to delaying the application of redo to protect against user errors
or logical corruptions. By using Flashback Database in this context, standby databases
are more closely synchronized with the primary database, thereby reducing failover and
switchover times.
• Eliminates the need to completely re-create the original primary database after a
failover. The failed primary database can be flashed back to a point in time before the
failover and converted to be a standby database for the new primary database.
Flashback Database is used in a Data Guard configuration for the following features:
• Fast-start failover: You must enable Flashback Database and set up a fast recovery
area on the primary database and the target standby database before enabling fast-start
failover. (See the lesson entitled ―Enabling Fast-Start Failover‖ for additional
information.)
• Snapshot standby: To convert a physical standby database to a snapshot standby
database, you must configure the Fast Recovery Area and size. If Flashback Database
is not enabled, it will be enabled when the primary database is converted to a snapshot
standby database. (See the lesson titled ―Creating and Managing a Snapshot Standby
Database‖ for additional information.)
Overview of Flashback Database
The Flashback Database operation:

• Works like a ―rewind‖ button for the database
• Can be used when users make logical data corruptions

Errors are The database "Press the rewind button" The
generated. is corrupted. (FLASHBACK DATABASE). database is
"rewound."
Overview of Flashback Database

With Flashback Database, you can quickly bring your database to an earlier point in time by
undoing all changes that took place since that time. This operation is fast because you do not
need to restore backups. You can use this feature to undo changes that resulted in logical
data corruptions.
When you use Flashback Database, Oracle Database uses past block images to back out
changes to the database. During normal database operation, Oracle Database occasionally
logs these block images in flashback logs, which are written sequentially and are not
archived. Oracle Database automatically creates, deletes, and resizes flashback logs in the
fast recovery area. You need to be aware of flashback logs only for monitoring performance
and deciding how much disk space to allocate to the fast recovery area for flashback logs.
The time it takes to rewind a database with Flashback Database is proportional to how far
back in time you need to go and the amount of database activity after the target time. The
time it would take to restore and recover the whole database could be much longer. The
before images in the flashback logs are used only to restore the database to a point in the
past, and forward recovery is used to bring the database to a consistent state at some time in
the past. Oracle Database returns data files to the previous point in time—but not auxiliary
files such as initialization parameter files.
Flashback Database can also be used to complement Data Guard and Recovery Advisor and
to synchronize clone databases.
Configuring Flashback Database

1. Configure the fast 2. Set the retention 3. Enable Flashback
recovery area. target. Database.
SQL> ALTER SYSTEM

SET
2> DB_FLASHBACK_RETENTION_TARGET=2880 SCOPE=BOTH;
SQL> ALTER DATABASE FLASHBACK ON;

As of Oracle Database 11g Release 2 (11.2), the database can be open when you enable
flashback. In prior versions, the database had to be mounted after a clean shutdown prior to
enabling flashback.
1. Configure the fast recovery area.
2. Set the retention target with the DB_FLASHBACK_RETENTION_TARGET initialization
parameter.
You can specify an upper limit, in minutes, on how far back you want to be able to flash
back the database. The example uses 2,880 minutes, which is equivalent to two days.
This parameter is only a target and does not provide any guarantee. Your flashback time
interval depends on how much flashback data was kept in the fast recovery area.
3. Enable Flashback Database with the following command:
ALTER DATABASE FLASHBACK ON;
Before you can issue the command to enable Flashback Database, the database must
be configured for archiving.
Determine whether Flashback Database is enabled with the following query:
SELECT flashback_on FROM v$database;
Disable Flashback Database with the ALTER DATABASE FLASHBACK OFF command. As a
result, all existing Flashback Database logs are deleted automatically.


Verify that the database is in ARCHIVELOG mode:

Configuring Flashback Database by Using Enterprise Manager

1. On the Availability page, select Recovery Settings in the Backup/Recovery region.
2. Ensure that your database is in ARCHIVELOG mode. If not, select ARCHIVELOG Mode.


Set the flash recovery area and enable Flashback Database:

Configuring Flashback Database by Using Enterprise Manager (continued)

3. Review the flash recovery area location.
The flash recovery area is a unified storage location for all recovery-related files and
activities in an Oracle database. All files that are needed to completely recover a
database from a media failure are part of the flash recovery area. The recovery-related
files that can be created in the flash recovery area include archived redo log files, control
files, backups created by Recovery Manager (RMAN), flashback logs, and the change
tracking file. By allocating a storage location and unifying recovery-related files in a
specific area, the Oracle database server relieves the database administrator from
having to manage the disk files created by these components. If you want it in a different
location, specify the location in the Flash Recovery Area Location field.
4. Set the flash recovery size in the Flash Recovery Area Size field.
5. Select Enable Flashback Database. You can also set the flashback retention time, and
you can view important information regarding your flashback database window.
6. Scroll down to the bottom of the Recovery Settings page, and click Apply.
Note: ―Flash recovery area‖ has been renamed ―fast recovery area‖ in Oracle 11g Release 2
(11.2). Enterprise Manager is still at version 10.2.0.5.2 as of the writing of this course and
uses the old name.

Using Flashback Database
Instead of Apply Delay

Standby1
Primary Standby2
database No delay

Standby3
4-hour delay
Primary 8-hour delay

database Standby
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.
Note: Apply delay will be discussed in the lesson titled "Optimizing a Data Guard
Configuration".

Using Flashback Database and
Real-Time Apply
RFS
Primary
database
MRP
Standby

redo log
ARC0
Archived Standby
redo logs database
Copy right © 2010, Oracle and/or its af f iliates. All rights reserv ed.
Using Flashback Database and Real -Time Apply

The Oracle Data Guard real-time apply feature reduces failover time. Flashback Database
protects a physical standby database from logical data corruption and user error.
The Data Guard broker automatically enables real-time apply.

Using Flashback Database After RESETLOGS
Primary Standby
database database
Redo
RESETLOGS

Flashback
after
point-in-time
1 2
recovery
Redo
Using Flashback Database After RESETLOGS

Physical Standby Configuration
For a physical standby database, it is possible that the Redo Apply service might not halt
when it encounters the OPEN RESETLOGS command in the redo information. If the physical
standby database’s SCN (system change number) is far enough behind the primary
database’s SCN, then the Redo Apply service can interpret the OPEN RESETLOGS command
without stopping.
Note: Recall that the ―recovery through RESETLOGS‖ feature was implemented in Oracle
Database 10g.
Use the following procedure to avoid re-creating a standby database after you issue an OPEN
RESETLOGS command on the primary database and the managed recovery process is 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 OPEN RESETLOGS. Use the following query to find
the ―before RESETLOGS‖ SCN:
SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database;

Using Flashback Database After RESETLOGS (continued)
2. On the standby database, obtain the current SCN by using 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 managed recovery on the standby database. The standby database will 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, 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 perform 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 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;
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 will be ready to
receive and apply logs from the primary database.
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Flashback Through Standby Database
Role Transitions
• Use Flashback Database to flash back a database to a
point in time before a switchover or failover.
• Primary and standby databases retain their current roles
when you flash back through physical standby switchovers
or failovers.

• Database roles are flashed back when you flash back
through logical standby switchovers or failovers.
• Flashback Database can be used to undo a physical
database activation.
Flashback Through Standby Database Role Transitions

Use Flashback Database to revert a database to a point in time before a physical standby
database switchover or failover. The database role does not change when flashing back
through a physical standby switchover, failover, or activation.
In a logical standby database, the FLASHBACK DATABASE command reverts the database to
a system change number (SCN) or time stamp before a switchover or failover. For a logical
standby database, the database reverts to its original role at the time of the flashback SCN or
flashback time.
You can also use Flashback Database to undo a physical standby activation.
Note: For detailed information about switchover and failover, see the lesson titled ―Performing
Role Transitions.‖

Using Flashback Database After Failover
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS C OMPUTER IS STRICTLY PROHIBITED
Primary Standby
database database
Redo 1
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 placed in the ―needs reinstatement‖ state.
Note: Detail on reinstating the database is provided in the lesson titled ―Performing Role
Transitions.‖
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.
The STANDBY_BECAME_PRIMARY_SCN column in V$DATABASE can provide the SCN
number corresponding to the failover. The old primary database should use the "FLASHBACK
DATABASE TO SCN .." command to rewind to this point. It can then be converted into a
standby database with the SQL command "ALTER DATABASE CONVERT TO PHYSICAL
STANDBY".
Note: You must enable the Flashback Database feature on the old primary database prior to
the failover.
Quiz
Flashback database can be performed only on databases that

are in the primary role.
a. True
b. False

Answer: b

Summary

• Enable Flashback Database
• Use Flashback Database effectively in a Data Guard
configuration


This practice covers enabling Flashback Database:

• On the primary database
• On the standby database



Enabling Fast-Start Failover

Objectives

• Configure fast-start failover
• View information about the fast-start failover configuration
• Manage the observer
• Perform role changes in a fast-start failover configuration

• Manually reinstate the primary database

Fast-Start Failover: Overview

Observer
Primary Fast-start failover

database standby database
Fast-Start Failover: Overview

Fast-start failover enables Data Guard to rapidly and automatically fail over to a previously
chosen standby database without requiring manual intervention. This feature increases the
availability of your database in the event of a disaster by reducing the need for you to perform
a failover operation manually.
The observer is an Oracle Cal Interface (OCI) client-side component that typically runs on a
separate computer and monitors the availability of the primary database.

When Does Fast-Start Failover Occur?

Observer
Loss of connectivity >
fast-start failover threshold

When Does Fast-Start Failover Occur?

Fast-start failover occurs when any of the following conditions are met:
• Loss of connectivity between both the primary database and the observer—and
between the primary database and the fast-start failover target standby database—
exceeds the fast-start failover threshold.
• The database health-check mechanism determines any of the following (as optionally
configured):
- A data file is offline because of a write error.
- Dictionary corruption of a critical database object occurs.
- Control file is permanently damaged because of a disk failure.
- LGWR is unable to write to any member of the log group because of an I/O error.
- Archiver is unable to archive a redo log because the device is full or unavailable.
• An instance crash occurs for a single-instance database.
• All instances of a Real Application Clusters (RAC) primary database crash.
• Shutdown abort of the primary database occurs.
• An application initiates a fast-start failover by cal ing the
DBMS_DG.INITIATE_FS_FAILOVER function.

Installing the Observer Software
• The observer is a separate OCI client-side component that

monitors the availability of the primary database.
• Install observer software on a different computer from the
primary and standby databases.
• Manage the observer by using Oracle Enterprise Manager

or DGMGRL commands.
Observer
Installing the Observer Software

To use fast-start failover, you should install the DGMGRL program (which contains the
observer software) on a computer system that is separate from the primary database and
standby database systems.
To install DGMGRL on the observer computer, use one of the following methods:
• Install the complete Oracle Client Administrator by choosing the Administrator option in
the Oracle Universal Installer. This installation includes DGMGRL but it does not include
the Oracle Enterprise Manager agent. This type of installation enables you to manage
the observer by using DGMGRL commands but not Oracle Enterprise Manager.
• Install the full Oracle Database software kit. This installation includes DGMGRL.
Note: To manage the observer from Oracle Enterprise Manager (EM) Grid Control, the EM
Grid Control agent will need to be installed on the observer machine in addition to DGMGRL.
The observer host should be located on the client network or the location that contains the
most client activity or highest priority activity. This method could introduce a false failover,
that is a fast-start failover occurs even though the primary is running and accessible locally,
but if the clients can't get to the primary it may as well be down.

Fast-Start Failover Prerequisites
The following prerequisites must be met to enable fast-start

failover:
• Configuration must be in maximum availability or maximum
performance mode.
• LogXptMode property of target must be set as follows:

– SYNC in maximum availability mode
– ASYNC in maximum performance mode
• Flashback Database must be enabled on the primary
database and target standby database.
• Configure tnsnames.ora entries for the observer.
• Create a static service name so that the observer can
automatically restart databases.
Fast-Start Failover Prerequisites

• The broker configuration must be operating in maximum availability or maximum
performance mode.
• The primary database must be configured with standby redo log files.
• The standby database that is the target of fast-start failover must have its LogXptMode
property set to SYNC to enable fast-start failover in maximum availability mode or to
ASYNC to enable fast-start failover in maximum performance mode.
• Flashback Database must be enabled on the primary database and target standby
database.
• The primary database and target standby database must have connectivity.
• Configure the tnsnames.ora file on the observer system so that the observer is able to
connect to the primary database and the preselected target standby database.
• Create a static service name so that the observer can automatically restart a database
as part of reinstatement.

Configuring Fast-Start Failover
1. Specify the target standby database.

2. Set the protection mode.
3. Set the FastStartFailoverThreshold property.
4. Set additional database properties.
5. Set additional fast-start failover conditions.

6. Enable fast-start failover.
7. Start the observer.
8. Verify the configuration.
Configuring Fast-Start Failover

The manual steps to configure fast-start failover are described in detail on the next few pages.
Configuring fast-start failover by using Enterprise Manager Grid Control is described later in
the lesson.

Step 1: Specify the Target Standby Database
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS ST RICTLY PROHIBITED
pc01sby2
pc01prmy pc01sby1

Standby
Primary Fast-start failover database
EDIT DATABASE pc01prmy

SET PROPERTY FastStartFailoverTarget = pc01sby1;
EDIT DATABASE pc01sby1
SET PROPERTY FastStartFailoverTarget = pc01prmy;
Step 1: Specify the Target Standby Database

In a Data Guard configuration with multiple standby databases, you must set the
FastStartFailoverTarget database property on the primary database and your chosen
target standby database before enabling fast-start failover.
On the primary database, set the FastStartFailoverTarget property to the fast-start
failover target standby database. Execute the command when connected to the primary
database or to any standby database in the configuration that has connectivity to the primary
database. The command syntax is:
EDIT DATABASE database-name
SET PROPERTY FastStartFailoverTarget = FSFO-database-name;
You need not set the FastStartFailoverTarget property in a configuration with only one
standby database: The Data Guard broker automatically sets it appropriately for the primary
database and the standby database when fast-start failover is enabled.

Step 2: Set the Protection Mode

> SET PROPERTY LogXptMode=SYNC;
> SET PROPERTY LogXptMode=SYNC;
DGMGRL> EDIT CONFIGURATION
> SET PROTECTION MODE AS MaxAvailability;

> SET PROPERTY LogXptMode=ASYNC;
> SET PROPERTY LogXptMode=ASYNC;
> SET PROTECTION MODE AS MaxPerformance;
Step 2: Set the Protection Mode

You can enable fast-start failover when the configuration is in maximum availability mode or
maximum performance mode. For details about each mode, see the lesson titled ―Configuring
Data Protection Modes.‖
In maximum performance mode, set the FastStartFailoverLagLimit configuration
property to an acceptable limit (in seconds) by which the standby database is permitted to fall
behind the primary database in terms of redo applied. If the standby database is further
behind than this value, fast-start failover is not allowed.

Step 3: Set the Fast-Start Failover Threshold
pc01prmy

Primary
database
EDIT CONFIGURATION
SET PROPERTY FastStartFailoverThreshold =
threshold-val;
Step 3: Set the Fast-Start Failover Threshold

The fast-start failover threshold specifies how long the observer and target standby database
should simultaneously wait to hear from the primary database before initiating a fast-start
failover. The threshold value is specified as a positive, nonzero number of seconds. The
default value for the FastStartFailoverThreshold property is 30 seconds. When
choosing a value for this property, you must balance the increased risk of an unnecessary
failover (for example, if the network connection was temporarily broken for a few seconds)
against the benefits of faster failover and less down time during a critical outage.
Recommended settings for the FastStartFailoverThreshold property:
• Single-instance primary, low-latency reliable network = 10–15 seconds
• Single-instance primary, high-latency network over WAN = 30–45 seconds
• RAC primary = (CSS misscount + reconfiguration time) + (24–40 seconds)
Execute the EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold =
threshold-val command when connected to the primary database or to any standby
database in the Data Guard broker configuration with connectivity to the primary database.
Note: You can modify this property whether fast-start failover is enabled or disabled.

Step 4: Set Additional Fast-Start Failover
Properties
• FastStartFailoverLagLimit: Establishes an
acceptable length of time for the standby to fall behind the
primary database with respect to applied redo
• FastStartFailoverPmyShutdown: Determines
whether the primary database shuts down if redo

generation has stalled and the primary database has lost
connectivity with the observer and target standby database
for a longer time than FastStartFailoverThreshold
• FastStartFailoverAutoReinstate: Determines
whether the old primary database should be automatically
reinstated if a fast-start failover was initiated because it lost
for a longer time than FastStartFailoverThreshold
Step 4: Set Additional Fast-Start Failover Properties

You can set additional properties to control fast-start failover operation.
The FastStartFailoverPmyShutdown property enables users to decide whether the
primary database shuts down if redo generation has stalled and the primary database has lost
connectivity with the observer and target standby database for longer than the value specified
in FastStartFailoverThreshold. Redo generation stalls because the primary database
has lost connectivity to both the observer and the target standby database concurrently. This
property cannot be used to prevent the primary database from shutting down if a fast-start
failover occurred because a user-configurable condition was detected or was requested by an
application calling the DBMS_DG.INITIATE_FS_FAILOVER function.
The FastStartFailoverAutoReinstate property enables users to decide whether the
old primary database should be automatically reinstated if a fast-start failover was initiated
because it lost connectivity with the observer and target standby database for longer than the
value specified in FastStartFailoverThreshold. This property cannot be used to cause
automatic reinstatement if a fast-start failover occurred because a user-configurable condition
was detected or was requested by an application calling the
DBMS_DG.INITIATE_FS_FAILOVER function.
Note: Each of these three properties is discussed in more detail on the following pages.

Setting the Lag-Time Limit
• Set the FastStartFailoverLagLimit property to

configure a lag-time limit for a configuration in maximum
performance mode:
> SET PROPERTY FastStartFailoverLagLimit = {n};

• Destinations that ship redo in ASYNC mode are acceptable
fast-start failover target standby databases.
• Real-time apply is required on the target standby
database.
Setting the Lag-Time Limit

You can configure fast-start failover for configurations operating in maximum performance
protection mode. Use the FastStartFailoverLagLimit property to specify an acceptable
lag-time limit in seconds. If the standby database’s applied redo point is within the specified
number of seconds of the primary database’s redo generation point, a fast-start failover is
allowed. If the standby database’s applied point lags beyond this limit, a fast-start failover is
not allowed. The lag limit is ignored for SYNC destinations. This is applicable only to
configurations when fast-start failover is enabled in maximum performance modes.
Real-time apply must be enabled on the target standby database to ensure a valid calculation
of the lag time.
Configure the FastStartFailoverLagLimit property as follows:
EDIT CONFIGURATION
SET PROPERTY FastStartFailoverLagLimit = {n};
The minimum value for n is 10. The default value is 30.
You can perform a manual failover to a maximum performance fast-start failover target. The
maximum performance failover target must be within the specified lag limit of the primary
database for the failover to be allowed. If the failover target is more than the specified lag limit
behind the primary database, an error is returned.

Configuring the Primary Database
to Shut Down Automatically

• Use FastStartFailoverPmyShutdown to control
whether the primary database shuts down if redo
generation stalls and the primary database loses
for a longer time than the value of

FastStartFailoverThreshold .
• Default value: TRUE
DGMGRL> EDIT CONFIGURATION SET PROPERTY
> FastStartFailoverPmyShutdown = {TRUE|FALSE};
Configuring the Primary Database to Shut Down Automatically

If you do not want the old primary database to shut down automatically after a fast-start
failover is triggered due to the primary redo generation being stalled and the primary database
loosing connectivity with the observer and target standby database for longer than the number
of seconds specified by the FastStartFailoverThreshold configuration property , set
the FastStartFailoverPmyShutdown property to FALSE. When the property is set to
FALSE, the old primary database stalls awaiting diagnosis of the condition that caused the
fast-start failover.
DGMGRL> edit configuration set property
> FastStartFailoverPmyShutdown = false;
Property "faststartfailoverpmyshutdown" updated
A value of TRUE causes the primary database to shut down with the ABORT option after the
elapse of the number of seconds specified in the FastStartFailoverThreshold property
and the primary database has no contact from its fast-start failover partners. TRUE is the
default.
Note: The primary database is always shut down if a user configurable fast-start failover
condition is detected or if an application initiated a fast-start failover by calling the
DBMS_DG.INITIATE_FS_FAILOVER function even if FastStartFailoverPmyShutdown
is set to FALSE.
Automatic Reinstatement
After Fast-Start Failover

pc01prmy pc01sby1
Fast-start failover Primary database

standby database
Automatic Reinstatement After Fast-Start Failover

Reinstatement of the original primary database is critical for reestablishing high availability
after a fast-start failover. The original primary database can act as the fast-start failover target
standby database for the new primary database after being reinstated as a standby database.
Unless you reconfigure the fast-start failover environment, you cannot perform a subsequent
fast-start failover until the original primary database is reinstated.
Automatic reinstatement of the original primary database is triggered when all of the following
conditions are met:
• FastStartFailoverAutoReinstate is set to TRUE.
• The original primary database and the new primary database comprise the same fast-
start failover configuration before the failover occurs and after the original primary
database restarts.
• In a multi-standby database configuration, you have not performed a subsequent
failover or switchover before the original primary database restarting.
• The observer can connect to the original primary database.
• The original primary database must be able to connect to the new primary database to
complete the reinstatement operation.

Automatic Reinstatement After Fast-Start Failover (continued)
If all conditions are not met, automatic reinstatement of the original primary database does not
take place and appropriate errors are logged. You can then request manual reinstatement of the
original primary database by using DGMGRL or Enterprise Manager (as described later in this
lesson).

Configuring Automatic Reinstatement
of the Primary Database

• Use the FastStartFailoverAutoReinstate property
to determine whether the old primary database should be
automatically reinstated if a fast-start failover was initiated
because of a loss of connectivity .
• Default value: TRUE

DGMGRL> EDIT CONFIGURATION SET PROPERTY
> FastStartFailoverAutoReinstate = {TRUE | FALSE};
Configuring Automatic Reinstatement of the Primary Database

The FastStartFailoverAutoReinstate property enables you to determine whether the
observer should automatically reinstate the old primary database after a fast-start failover. In
some fast-start failover situations, you may want to diagnose the cause of the fast-start
failover before reinstating the primary database; you should set the property to FALSE. The
default value is TRUE.
DGMGRL> edit configuration set property
> FastStartFailoverAutoReinstate = false;
Property "faststartfailoverautoreinstate" updated
DGMGRL> show fast_start failover
Fast-Start Failover: ENABLED
Threshold: 90 seconds
Target: pc01sby1
Observer: EDBVR6P2
Lag Limit: 60 seconds
Shutdown Primary: TRUE
Auto-reinstate: FALSE

Setting a Connect Identifier for the Observer
• Set the ObserverConnectIdentifier property to

specify how the observer should connect to and monitor
the primary and standby database:
> SET PROPERTY ObserverConnectIdentifier = ' ';

• The default connect identifier is the value of the
DGConnectIdentifier property.
Setting a Connect Identifier for the Observer

Use the ObserverConnectIdentifier configurable database property to specify how the
observer should connect to and monitor the primary and standby database. Set this property
for the primary and target standby database if you want the observer to use a different
connect identifier than the one that is used to ship redo data (that is, the connect identifier
specified by the DGConnectIdentifier property).

Step 5: Configure Additional
Fast-Start Failover Conditions

• Use ENABLE/DISABLE FAST_START FAILOVER
commands to specify conditions for fast-start failover:
ENABLE FAST_START FAILOVER CONDITION " value";
• Observer initiates a fast-start failover without waiting for

FastStartFailoverThreshold to expire.
• Configurable conditions:
– Conditions detectable through database health check
– Errors raised by the Oracle server
• Use the SHOW FAST_START FAILOVER command to
obtain a list of valid conditions.
Step 5: Configure Additional Fast-Start Failover Conditions

Use the ENABLE/DISABLE FAST_START FAILOVER broker commands to specify the
conditions under which a fast-start failover should occur. The Oracle Database server detects
when a specified condition occurs and informs the observer. The observer initiates a fast-start
failover without waiting for FastStartFailoverThreshold to expire (if the standby is in a
valid fast-start failover state to accept a failover).
Use the SHOW FAST_START FAILOVER command to obtain a list of valid conditions and
confirm your changes. They include the following:
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle Error Conditions
(none)

Step 5: Configure Additional Fast-Start Failover Conditions (continued)
For specified Oracle ORA-Error conditions, the primary database will notify the observer if the
error is signaled and the observer will immediately initiate a fast-start failover, assuming the
standby is in a valid fast-start failover state (observed and either synchronized or within lag
limits) to accept a failover. For example, if you experiencing a large amount of block corruptions
(ORA-1578), you can specify the following syntax:
ENABLE FAST_START FAILOVER CONDITON '1578'
Fast-start failover will then occur when the ORA-1578 is encountered. This will work for all
errors except ORA-7445 or ORA-600.

Configuring Fast-Start Failover Conditions
• Specify additional conditions for a fast-start failover:
Health Default Description

Condition Value
Datafile ENABLED Data file offline due to a write error
Offline

Corrupted ENABLED Corrupted control file
Controlfile
Corrupted ENABLED Dictionary corruption of a critical database
Dictionary object
Inaccessible DISABLED LGWR unable to write to any member of a
Logfile log group due to an I/O error
Stuck DISABLED Archiver unable to archive a redo log
Archiver because the device is full or unavailable
Configuring Fast-Start Failover Conditions

Additional database health conditions for a fast-start failover are displayed in the table.
The conditions Datafile Offline, Corrupted Controlfile, and Corrupted
Dictionary are enabled by default. An error is returned if the value you specify is not
recognized.
If the condition was already set, no error is displayed.
Example: Enable a database health condition for a fast-start failover:
DGMGRL> enable fast_start failover condition "Inaccessible
Logfile"
DGMGRL> show fast_start failover
…
Health Conditions:
Inaccessible Logfile YES
Stuck Archiver NO
Step 6: Enable Fast-Start Failover

pc01prmy pc01sby1

DGMGRL> ENABLE FAST_START FAILOVER;
Step 6: Enable Fast-Start Failover

You can enable fast-start failover by using DGMGRL. When you issue the ENABLE
FAST_START FAILOVER command, the observer is able to observe the primary database
and the standby database and can initiate a fast-start failover when necessary.
In addition to enabling fast-start failover, you must start the observer (as described on the next
page).

Step 7: Start the Observer

Observer

DGMGRL> START OBSERVER;
Step 7: Start the Observer

Execute the START OBSERVER command, which directs the broker to begin ―observing‖ the
Data Guard configuration to which DGMGRL is connected. You must execute this command
on the computer where the observer will reside.
When you execute the START OBSERVER command, the observer retrieves the primary
database and the fast-start failover target standby database connect identifiers and begins
observation. It provides the name of its host computer to the Data Guard broker.
The primary database must be available for the START OBSERVER command to succeed.
There can be only one observer for a Data Guard configuration at any one time. If you attempt
to start a second observer for the configuration, you receive an error message.
If you disable fast-start failover while the observer is observing the configuration, the observer
idles while waiting for fast-start failover to become enabled.

Step 7: Start the Observer (continued)
The observer maintains a small configuration file for persistently recording key information about
the Data Guard configuration that it is observing. The file contains a description of the primary
and target standby databases, including connect descriptors. Use the FILE qualifier with the
START OBSERVER command to specify an explicit directory path and name for the configuration
file on the observer computer:
DGMGRL> START OBSERVER FILE=$ORACLE_HOME/dbs/Boston.dat;
If you do not specify the FILE qualifier, the current working directory is searched for a file
named FSFO.dat. If the file does not exist, a new file is created. If the configuration file exists,
the observer checks whether the file describes a valid fast-start failover environment for the
Data Guard configuration to which the observer is connected.
Note: You can execute the START OBSERVER command regardless of whether fast-start failover

is enabled.
Control is not returned to you when the observer is successfully started. The observer is a
continuous foreground process; as a result, the command-line prompt on the observer computer
does not return until you issue the STOP OBSERVER command from another DGMGRL session.
To issue commands and interact with the broker configuration, you must connect through
another DGMGRL client session. If you stop the observer with the STOP OBSERVER command,
the observer’s DGMGRL process is terminated.

Step 8: Verify the Configuration
DGMGRL> show fast_start failover;
Fast-Start Failover: ENABLED
Threshold: 90 seconds
Target: pc01sby1
Observer: EDBVR6P2
Lag Limit: 60 seconds

Shutdown Primary: TRUE
Auto-reinstate: TRUE

Health Conditions:
Inaccessible Logfile NO
Stuck Archiver NO
Oracle Error Conditions:

(none)
Step 8: Verify the Configuration

You can also use the SHOW FAST_START FAILOVER command to display all fast-start
failover information.

Initiating Fast-Start Failover from an Application

Observer
Application

DBMS_DG.INITIATE_FS_FAILOVER

In Oracle Database 11g, an application can initiate a fast-start failover by invoking the
DBMS_DG.INITIATE_FS_FAILOVER function. The function is used to alert the primary
database server that the application wants a fast-start failover to occur immediately. The
primary database server notifies the observer of this request, and the observer immediately
initiates a fast-start failover. The standby database must be in a valid fast-start failover state—
observed and synchronized or within the lag limit of the primary database—to accept a
failover.

• DBMS_DG package contains the

INITIATE_FS_FAILOVER function that is used to initiate
a fast-start failover from an application:
FUNCTION dbms_dg.initiate_fs_failover
(condstr IN VARCHAR2) RETURN BINARY_INTEGER;

• The DBMS_DG package is defined as an invoker's rights
package to address privilege concerns.

Initiating Fast-Start Failover from an Application (continued)

The DBMS_DG PL/SQL package contains the INITIATE_FS_FAILOVER function, which
enables an application to request a fast-start failover.
The application-initiated failover is an invocation of the FAILOVER command and requires the
SYSDBA privilege. The DBMS_DG package is defined as an invoker’s rights package to
address privilege concerns. The DBMS_DG.INITIATE_FS_FAILOVER function calls
DBMS_DRS.INITIATE_FS_FAILOVER. This implementation restricts access to the definer’s
right procedure, DBMS_DRS.INITIATE_FS_FAILOVER, while allowing you to grant the
EXECUTE privilege for the DBMS_DG.INITIATE_FS_FAILOVER procedure.
If the configuration is not in a valid fast-start failover state, the INITIATE_FS_FAILOVER
function returns an ORA error, informing the caller that a fast-start failover operation cannot be
performed.

Viewing Fast-Start Failover Information
SELECT fs_failover_status as STATUS,

fs_failover_current_target as CURR_TGET,
fs_failover_threshold as THRESHOLD,
fs_failover_observer_present as OBS_PRES,
fs_failover_observer_host as OBS_HOST

FROM v$database;
STATUS CURR_TGET THRESHOLD OBS_PRES

---------------------- --------- --------- --------
TARGET UNDER LAG LIMIT pc01sby1 90 YES
OBS_HOST
-----------------------
edbvr6p2.us.oracle.com
Viewing Fast-Start Failover Information

V$DATABASE contains the following columns that provide detailed information about fast-start
failover. They include:
• FS_FAILOVER_STATUS:
- BYSTANDER: Fast-start failover is enabled, but this standby database is not the
target of the fast-start failover.
- DISABLED: Fast-start failover is disabled.
- LOADING DICTIONARY: This status appears only on a logical standby database
that has not completed loading a copy of the primary database data dictionary.
- PRIMARY UNOBSERVED : This status occurs only on the target standby database
when it is synchronized with or is TARGET UNDER LAG LIMIT of the primary
database and has connectivity with the observer, but the primary database does
not have a connection to the observer.
- REINSTATE FAILED: Reinstatement of the failed primary database as a new
standby database failed. See the Data Guard broker drc* log files for additional
information.

Viewing Fast-Start Failover Information (continued)
- REINSTATE REQUIRED: The failed primary database requires reinstatement as a
new standby database to the new primary database. The observer automatically
starts the reinstatement process.

- STALLED: This status appears on the primary database if redo generation is
stalled because the primary database cannot continue without violating the data
loss guarantee.
- SUSPENDED: This status appears on the target standby database when either the
primary database or the target standby database is shut down in a controlled
fashion.
- SYNCHRONIZED: The primary database and the fast-start failover target standby
database are synchronized and the configuration is operating in maximum

availability mode.
- TARGET OVER LAG LIMIT: (Only for maximum performance mode) The standby
database redo applied point lags the primary database redo generation point by
more than the number of seconds specified by the
FastStartFailoverLagLimit configuration property.
- TARGET UNDER LAG LIMIT: (Only for maximum performance mode) The standby
database redo applied point does not lag the primary database redo generation
point by more than the number of seconds specified by the
FastStartFailoverLagLimit configuration property.
- UNSYNCHRONIZED : The target standby database does not have all the redo from
the primary database and the configuration is operating in maximum availability
mode. Fast-start failover is not possible.
• FS_FAILOVER_CURRENT_TARGET: DB_UNIQUE_NAME of the standby database that is
the current fast-start failover target standby database for the Data Guard configuration
• FS_FAILOVER_THRESHOLD: Time (in seconds) during which the observer attempts to
reconnect with a disconnected primary database before attempting fast-start failover
with the target standby database
• FS_FAILOVER_OBSERVER_PRESENT:
- YES: Observer is connected to the local database.
- NO: Observer is not connected to the local database.
• FS_FAILOVER_OBSERVER_HOST: Name of the machine that hosts the observer
process

Determining the Reason for a Fast-Start Failover
Determine the reason for fast-start failover by querying the

V$FS_FAILOVER_STATS view:
SQL> SELECT last_failover_time, last_failover_reason
2> FROM v$fs_failover_stats;

LAST_FAILOVER_TIME LAST_FAILOVER_REASON
-------------------- ------------------------------
03/02/2010 22:30:12 Primary Disconnected
Determining the Reason for a Fast-Start Failover

You can query the V$FS_FAILOVER_STATS view on the primary database to learn why a
fast-start failover operation took place. The view shows the time of the last fast-start failover
and the reason for the operation.

Prohibited Operations
After Enabling Fast-Start Failover

Disable or delete
Configuration the fast-start failover
Protection Mode standby database
DGMGRL> EDIT DATABASE

> SET PROPERTY LogXptMode;
DGMGRL> EDIT DATABASE
> SET PROPERTY FastStartFailoverTarget;
Prohibited Operations After Enabling Fast-Start Failover

After enabling fast-start failover, you cannot perform any of the following operations (which
undermine the fast-start failover environment):
• Change the configuration protection mode.
• Change the LogXptMode property for the primary database or target standby database.
• Perform a failover or switchover to a standby database that is not the fast-start failover
target.
• Disable the Data Guard broker configuration.
• Delete the Data Guard broker configuration.
• Disable the standby database that is the target of fast-start failover.
• Remove the standby database that is the target of fast-start failover.
• Alter the FastStartFailoverTarget database-level property of either the primary
database or the standby database.
• Fail over to an unsynchronized fast-start failover target.

Disabling Fast-Start Failover

Observer

DGMGRL> DISABLE FAST_START FAILOVER [FORCE];
Disabling Fast-Start Failover

You can disable fast-start failover to prevent the observer from initiating a failover to the target
standby database.
When you execute the DISABLE FAST_START FAILOVER command, the Data Guard broker
disables fast-start failover on the target standby database and then disables fast-start failover
on the primary database. The Data Guard broker records this change persistently in the Data
Guard broker metadata and propagates the change to all standby databases in the Data
Guard broker configuration.
If the primary database and the fast-start failover target standby database do not have
connectivity with each other, you can use the FORCE option to disable fast-start failover. If this
command is executed on the primary database or on a bystander (non-fast-start failover
target) standby database that has connectivity with the primary database, the Data Guard
broker disables fast-start failover locally. The Data Guard broker then records this change
persistently in the Data Guard broker metadata and propagates the change to all databases in
the Data Guard broker configuration to which the primary database has connectivity.

Disabling Fast-Start Failover (continued)
If the standby database does not have connectivity with the primary database when you
execute the DISABLE FAST_START FAILOVER command with the FORCE option on the fast-
start failover target standby database, fast-start failover is disabled only on that target standby
database. If the target standby database regains connectivity with the primary database, the
primary database disables fast-start failover (as previously described).
If the standby database does not have connectivity with the primary database when you
execute the DISABLE FAST_START FAILOVER command with the FORCE option on a
bystander standby database, it is ignored by the primary database. Fast-start failover is
reenabled on the bystander standby database automatically when connectivity with the
primary database is restored. You must issue the DISABLE FAST_START FAILOVER
command on the primary database or on a bystander standby database that has connectivity

with the primary database (or with the fast-start failover target standby database itself) if you
want to permanently disable fast-start failover.
Note: Disabling fast-start failover does not stop the observer. Stopping the observer is
discussed later in the lesson.

Disabling Fast-Start Failover Conditions
Remove specific conditions for which a fast-start failover should

be performed:
DGMGRL> DISABLE FAST_START FAILOVER CONDITION value;

Disabling Fast-Start Failover Conditions

Use the DISABLE FAST_START FAILOVER CONDITION command to disable fast-start
failover for specified conditions. (You specify conditions as described earlier in the lesson.)

Using the FORCE Option
Use the FORCE option in the following situations:

• When the fast-start failover environment is synchronized
and the primary has lost connectivity to the observer and
the target standby database
• To prevent a fast-start failover from occurring on the target

standby database
• To conduct a manual failover when the fast-start failover
environment is unsynchronized
Using the FORCE Option

Use the FORCE option when:
• You want to disable fast-start failover when the environment is synchronized and the
primary database has lost connectivity with the observer and the target standby
database. The FORCE option enables you to disable fast-start failover without requiring
connectivity with the target standby database or the observer.
• You want to prevent a fast-start failover from occurring on the target standby database
because you know that the primary database will resume service before the fast-start
failover threshold expires.
• You want to conduct a manual failover to either the target standby database or a
bystander standby database when the fast-start failover environment is unsynchronized.
In this case, you must be willing to accept a data-loss failover.

Stopping the Observer

Observer

DGMGRL> STOP OBSERVER;
Stopping the Observer

If you no longer want to use fast-start failover, or if you want to move the observer to a
different host computer, use the STOP OBSERVER command to stop the observer.
Note: The STOP OBSERVER command does not disable fast-start failover. You can issue this
command whether or not fast-start failover is enabled.
You must issue this command on the primary database or on a standby database in the
configuration that has connectivity to the primary database. If you execute this command
when fast-start failover is enabled, the fast-start failover target standby database must have
connectivity to the primary database.
The observer does not immediately stop when you execute the STOP OBSERVER command.
The broker informs the observer the next time it is contacted by the observer. After you
execute the STOP OBSERVER command, the Data Guard broker can accept a new observer
whether or not the stopped observer is terminated.

Performing Manual Role Changes

Failover
Switchover
Performing Manual Role Changes

You can perform manual role changes in a fast-start failover configuration if the role change is
directed to the fast-start failover target standby database and if the configuration is
synchronized.
The following conditions must be met:
• If the configuration is operating in maximum availability mode, the target standby
database must be synchronized with the primary database.
• If the configuration is operating in maximum performance mode, the target standby
database must be within the specified lag limit of the primary database.
• For manual failover, the observer must be started and must be communicating with the
target standby database.

Manually Reinstating the Database

pc01prmy pc01sby1
Fast-start failover Primary database

standby database
DGMGRL> REINSTATE DATABASE pc01prmy;
Manually Reinstating the Database

Use the REINSTATE DATABASE command to reinstate the database. If the conditions for
reinstatement are not satisfied, the request fails and the specified database remains disabled.
If the database name specified is the original primary database and fast-start failover is
enabled, the original primary database is reinstated as a standby database to the new primary
database. The fast-start failover configuration is updated to reflect the availability of the new
standby database. It accepts archived redo log files from the new primary database and
serves as the fast-start failover target if the new primary database fails.
Issue this command while connected to either the primary database or to a standby database
in the configuration that has connectivity to the primary database other than the original
primary database to be reinstated.
Note: The REINSTATE DATABASE command does not require fast-start failover to be
enabled. It can also be used to reinstate an original primary database after a conventional no-
data-loss failover.

Using Enterprise Manager
to Enable Fast-Start Failover
Click Disabled to invoke the

fast-start failover wizard.

Using Enterprise Manager to Enable Fast-Start Failover

On the Data Guard page, click the Disabled link (next to Fast-Start Failover) to invoke the
fast-start failover wizard.


Select the database.
Click Configure
Observer.
Using Enterprise Manager to Enable Fast-Start Failover (continued)

Select the fast-start failover target database and (optional) the observer host. If the observer
was not started, click the Configure Observer button.



Specify the observer host and observer Oracle home to indicate where the observer will be
started.
You can also specify an alternate observer host and alternate observer Oracle home.
Enterprise Manager will provide high availability for the observer with this setup. If the origi nal
observer or observer node dies, Enterprise Manager will automatically start the observer on
the alternate node.
Note: Enterprise Manager ensures that each observer has uniquely named data and
DGMGRL log files. As a result, there is no problem if observers for different Data Guard
configurations are started in the same Oracle Home.
The observer data files, named afoXXXXX.dat, are stored in the $ORACLE_HOME/dbs
directory. The DGMGRL log file, named dgmgrlXXXXX.log, is stored in the
$ORACLE_HOME/rdbms/log directory.
XXXXX is a unique number generated by Enterprise Manager and is the same for the observer
data file and the DGMGRL log file for a given primary standby database configuration. XXXXX
changes each time an observer is restarted.



Flashback logging must be enabled on both the primary database and the standby database
to enable fast-start failover. If either database does not have flashback logging enabled, the
Enable Flashback Logging page is displayed. Specify the flash recovery area location, flash
recovery area size, and flashback retention time for each database.

Using Enterprise Manager to
Enable Fast-Start Failover


On the Confirmation: Enable Fast-Start Failover page, confirm that you want to enable fast-
start failover to the named database.



After you confirm that you want to enable fast-start failover to a specific database, the fast-
start enabling process begins. After the processing steps are complete, you are returned to
the Data Guard page.
On the Data Guard Fast-Start Failover Processing page, you can observe the progress of the
fast-start failover enabling operation as the following actions are performed:
• Standby redo log files are created on the primary and standby databases.
• The protection mode is upgraded to Maximum Availability (if required).
• The primary database and standby database are restarted (if required).
• Fast-start failover is enabled.
• The observer process is started.

Changing the Protection Mode
and Disabling Fast-Start Failover

Changing the Protection Mode and Disabling Fast-Start Failover

If you change the protection mode to a mode that does not support fast-start failover, you
implicitly disable fast-start failover.
Note: Enterprise Manager Grid Control 10g does not support maximum performance mode
with fast-start failover.

Disable Fast-Start Failover
Click the Enabled link to access

the Change Mode page.

Using Enterprise Manager to Disable Fast-Start Failover

Click the Enabled link to access the Fast-Start Failover: Change Mode page, where you
select the Disable option and the ―Stop observer‖ check box to disable fast-start failover.

Suspend Fast-Start Failover

Using Enterprise Manager to Suspend Fast-Start Failover

To suspend fast-start failover, select Disable on the Fast-Start Failover: Change Mode page.
Do not select the ―Stop observer‖ check box.

Moving the Observer to a New Host
To move the fast-start failover observer to a new host:

1. Execute the STOP OBSERVER command to sever the link
between the original observer and the broker configuration.
2. Execute the SHOW CONFIGURATION VERBOSE and SHOW
DATABASE commands to verify that the observer is

stopped.
3. Start the observer on your new host.
Moving the Observer to a New Host

If the observer host machine fails, you may need to move the observer to a new host.
To stop the original observer and start the observer on a new host:
1. Execute the STOP OBSERVER command to sever the link between the original observer
and the broker configuration:
DGMGRL> STOP OBSERVER;
2. Execute the SHOW CONFIGURATION VERBOSE and SHOW DATABASE commands to
verify that the observer is stopped and the configuration is no longer being observed.
3. Invoke DGMGRL, connect to a database in your configuration, and start the observer on
your new host.

Quiz
If the observer is on a different machine than the primary and

standby databases, and that machine is lost, a failover will be
triggered.
a. True
b. False

Answer: b

Quiz
If an independent host is not available for the observer, which

one of the following hosts is best suited to start the observer
on?
a. Host with the standby database
b. Host with the primary database

Answer: a

Summary

• Configure fast-start failover
• View information about the fast-start failover configuration
• Manage the observer
• Perform role changes in a fast-start failover configuration

• Manually reinstate the primary database


• Enabling fast-start failover
• Starting the observer
• Simulating a failure of the primary database and observing
the fast-start failover operation

• Observing the automatic reinstatement of the new physical
standby into the Data Guard configuration
• Switching back to your primary database
• Stopping the observer and disabling fast-start failover



Managing Client Connectivity

Objectives

• Configure client connectivity in a Data Guard configuration
• Implement failover procedures to automatically redirect
clients to a new primary database


Understanding Client Connectivity
in a Data Guard Configuration

Be aware of the following issues when you manage client
connectivity in a Data Guard configuration:
• Databases reside on different hosts in a Data Guard
configuration.
• Clients must connect to the correct database:

– Primary
– Logical standby
– Snapshot standby
– Physical standby with real-time query
• If clients send connection requests to the wrong host, they
may be connected to the wrong database or receive an
error.
• Clients must automatically reconnect to the correct
database in the event of a failover.
Understanding Client Connectivity in a Data Guard Configuration

Consider the issues listed in the slide when managing client connectivity in a Data Guard
configuration.

Understanding Client Connectivity:
Using Local Naming
Using DG_PROD

Listener
Oracle Net
DG_PROD
Primary Standby
database database
Understanding Client Connectivity: Using Local Naming

The diagram illustrates client connectivity using local naming.
The tnsnames.ora file would look similar to the following:
PROD = (DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)
(HOST = EDBVR6P1)(PORT = 1521))
(ADDRESS=(PROTOCOL = TCP)
(HOST = EDBVR6P2)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = DG_PROD)))

Preventing Clients from Connecting
to the Wrong Database

• Use database services to prevent clients from connecting
to the wrong database in the Data Guard configuration.
• Database services act as an abstraction layer between the
client and database instances.
• Database services register with listeners.

• Clients connect to database services instead of database
instances.
• Listeners use registration details to determine which
instances support a particular service at a particular
moment in time.
• Listeners then direct connection requests to the correct
instances; otherwise, the appropriate error is returned.
Preventing Clients from Connecting to the Wrong Database

Clients who send connection requests to the wrong host might be connected to the wrong
database instance, or they might receive an error message such as the following:
ORA-01033: ORACLE initialization or shutdown in progress
You can prevent clients from connecting to the wrong database by using database services.

Managing Services
• Database services can be managed by using the

DBMS_SERVICE package when Oracle Restart is not used.
• Database services attributes:
– Service Name: For administration of the service
– Network Name: For services that are implemented for

external client connections
– Transparent Application Failover (TAF) attributes: For TAF-
enabled client connections
Managing Services
Database services are implemented with the DBMS_SERVICE package. This package
provides for the creation, deletion, starting, and stopping of services for a single database
instance.
Note: For Oracle Real Application Clusters (RAC) and single-instance databases managed
by Oracle Restart or Oracle Clusterware (which includes ASM), the DBMS_SERVICE
procedure is deprecated in Oracle Database 11g Release 2 (11.2) and srvctl should be
used instead to create services.

Understanding Client Connectivity:
Using a Database Service
Using DG_PROD

Listener Listener
Oracle Net
DG_PROD service
Primary Standby
database database
Understanding Client Connectivity: Using a Database Service

The diagram in the slide illustrates client connectivity when using a database service.

Creating Services for the Data Guard
Configuration Databases
DBMS_SERVICE.CREATE_SERVICE( -
SERVICE_NAME => 'DG_PROD', -
NETWORK_NAME => 'DG_PROD', -
FAILOVER_METHOD => 'BASIC', -
FAILOVER_TYPE => 'SELECT', -
FAILOVER_RETRIES => 180, -
FAILOVER_DELAY => 1);

SERVICE_NAME => 'DG_RTQ', -
NETWORK_NAME => 'DG_RTQ');
SERVICE_NAME => 'DG_LSBY', -
NETWORK_NAME => 'DG_LSBY');
SERVICE_NAME => 'DG_SNAP', -
NETWORK_NAME => 'DG_SNAP');
Creating Services for the Data Guard Configuration Databases

By using the DBMS_SERVICE.CREATE_SERVICE procedure, you define a service to
represent each role or state in which the databases in your Data Guard configuration can
operate. A service created with DBMS_SERVICE.CREATE_SERVICE is not aware of the
actual database role. This functionality is only available with the SRVCTL interface for both
Real Application Clusters and Oracle Restart. In the examples above, the service name is
being used to imply the database role, which could be inaccurate after role transitions. The
CREATE_SERVICE procedure creates a service name in the data dictionary.
You should create services for the physical standby database when it is opened in read-only
mode (using Real-time Query) and when it is converted into a snapshot standby database.
The DBMS_SERVICE.CREATE_SERVICE will fail to execute on a physical standby database
even if it is open read-only. The service must be created on the primary and allowed to
propagate to the physical standby. In addition, create a service for logical standby databases
in your configuration.
Note: Database service names in the slide are examples.

Configuring Role-Based Services
• Use SRVCTL to configure Oracle Clusterware–managed

services on each database in the Data Guard
configuration.
• Role changes managed by the Data Guard broker
automatically start services appropriate to the database

role.
• The service is started when ROLE matches the current role
of the database and MANAGEMENT POLICY is set to
AUTOMATIC.
• Services can be started manually.
srvctl add service -d <db_unique_name> -s <service_name>
[-l [PRIMARY][,PHYSICAL_STANDBY][,LOG ICAL_STANDBY]
[,SNAPSHOT_STANDBY]]
[-y {AUTOMATIC | MANUAL}]
Configuring Role-Based Services

You can configure database services with a database role on an Oracle RAC database or a
single-instance database registered with Oracle Restart. The Data Guard broker interacts with
Oracle Clusterware or Oracle Restart to ensure that the correct database services are active
after a role change. This is available on Oracle Database 11g Release 2 (11.2) only if the Data
Guard configuration is broker managed.
The SRVCTL ADD SERVICE and MODIFY SERVICE commands support the following new
attributes:
• -l: ROLE attribute with values of PRIMARY, PHYSICAL_STANDBY, LOGICAL_STANDBY,
and SNAPSHOT_STANDBY. Default is PRIMARY. This attribute is used to specify the
database role for which a given database service should be active.
• -y: MANAGEMENT POLICY attribute with values of AUTOMATIC and MANUAL. Default is
AUTOMATIC.
When the database instance starts, the service is started automatically if the MANAGEMENT
POLICY attribute is set to AUTOMATIC and the value of the ROLE attribute matches the
database role. Users can also start a service manually if the database instance is started.
Note: If the service is created on a database instance that has already been started, then it will
be necessary to manually start the service the first time. The following syntax illustrates using
SRVTL to manually start a service:
srvctl start service –d pc01sby1 –s pc01prod

Configuring Role-Based Services (continued)
For stand-alone servers not using Real Application Clusters (RAC), the following options to the
SRVCTL ADD SERVICE command are applicable in Oracle Data Guard environments only:
• Failover type ( -e ) with values { NONE | SESSION | SELECT }

• Failover method ( -m ) with values { NONE | BASIC }
• Failover delay ( -w ) integer value measured in seconds
• Failover retries ( -z ) integer value indicating a count

Adding Standby Databases to Oracle Restart
Configuration
• Standby databases created with Enterprise Manager are
not automatically added to the Oracle Restart
configuration.
• Use SRVCTL to add the standby databases.
srvctl add database -d <db_unique_name> -o <oracle_home>

[-m <domain_name>] [-p <spfile>] [-r {PRIMARY | PHYSICAL_STANDBY
| LOGICAL_STANDBY | SNAPSHOT_STANDBY }] [-s {start_options}]
[-t {stop_options}] [-n <db_name>] [-y {AUTOMATIC | MANUAL}]
[-a "<diskgroup_list>"]
• Example:
srvctl add database -d pc01sby1 –o
/u01/app/oracle/product/11.2.0/dbhome_1 –m example.com –p
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilepc01sb1.ora
-r PHYSICAL_STANDBY –n pc01prmy –a "SBDAT,SBFRA"
Adding Standby Databases to Oracle Restart Configuration

When Enterprise Manager Grid Control 10g is used to create standby databases with the
wizard-driven approach, the newly created standby databases are not automatically
registered with the Oracle Restart configuration. Use SRVCTL to create the database object
in the Oracle Restart Configuration before database services can be associated with the
standby databases. The syntax for SRVCTL is displayed in the slide to create a new database
object. The values for start_options include open, mount, or nomount. The values for
stop_options include normal, transactional, immediate, or abort.

Example: Configuring Role-Based Services
• PAYROLL: Read-write service that always runs on the

database with the primary role
• ORDERSTATUS: Read-only service that always runs on an
Active Data Guard standby database
srvctl add service -d boston -s payroll -l PRIMARY

–m BASIC –e SELECT –w 1 –z 180
srvctl add service –d dallas –s payroll –l PRIMARY

–m BASIC –e SELECT –w 1 –z 180
srvctl add service -d dallas -s orderstatus

-l PHYSICAL_STANDBY

Example: Configuring Role-Based Services

The example in the slide shows the configuration of two role-specific services:
• PAYROLL is a read-write service that always runs on the database with the primary role.
• ORDERSTATUS is a read-only service that always runs on an Active Data Guard standby
database, which is currently defined as the Dallas database while it is in the
PHYSICAL_STANDBY role. A role transition can stop this service.
Note: Database services are linked to a specific DB_UNIQUE_NAME in the Oracle Restart
Configuration. For the PAYROLL service to be associated with both the primary database and
standby database, it will have to be registered to each database individually. The role is set to
PRIMARY, so it will start only on one of the two databases.

Connecting Clients to the Correct Database
• Use a database event trigger to ensure that clients connect

to a database in the Data Guard configuration that is in the
correct state and role.
• If no database is in the correct state and role, the trigger
ensures that clients do not connect to a database.

• Use the trigger to start database services.
– DG_PROD: Primary database
– DG_RTQ: Physical standby database opened in READ ONLY
mode (Real-time Query)
– DG_SNAP: Physical standby database converted to a
snapshot standby database
– DG_LSBY: Logical standby database
Connecting Clients to the Correct Database

Ensure that clients connect to the database instance that is in the correct state and role in the
Data Guard configuration by using a database event trigger. The AFTER STARTUP trigger
starts the appropriate service on the database.
Note: Database service names in the slide are shown as an example. It is not necessary to
employ an AFTER STARTUP trigger if the services are managed by Oracle Clusterware.

Creating the AFTER STARTUP Trigger
CREATE TRIGGER MANAGE_SERVICES AFTER STARTUP ON DATABASE

DECLARE
ROLE VARCHAR(30);
OMODE VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO ROLE FROM V$DATABASE;
SELECT OPEN_MODE INTO OMODE FROM V$DATABASE;
IF ROLE = 'PRIMARY' THEN

DBMS_SERVICE.START_SERVICE ('DG_PROD');
ELSIF ROLE = 'PHYSICAL STANDBY' THEN
IF OMODE LIKE 'READ ONLY%' THEN
DBMS_SERVICE.START_SERVICE ('DG_RTQ');
END IF;
ELSIF ROLE = 'LOGICAL STANDBY' THEN
DBMS_SERVICE.START_SERVICE ('DG_LSBY');
ELSIF ROLE = 'SNAPSHOT STANDBY' THEN
DBMS_SERVICE.START_SERVICE ('DG_SNAP');
END IF;
END;
/
Creating the AFTER STARTUP Trigger

The AFTER STARTUP trigger is invoked when the database is opened. The trigger checks the
database role and the open mode of the database and, based on the values, invokes the
DBMS_SERVICE.START_SERVICE procedure to start the appropriate service. The CREATE
TRIGGER SQL command needs to be run only in the primary database. It will be replicated to
all standby databases.
Note: The trigger shown in the slide is an example using the service names defined earlier in
the lesson. Additional trigger functionality may be necessary based on your circumstances. It
is not necessary to employ an AFTER STARTUP trigger if the services are managed by Oracle
Clusterware.

Configuring Service Names in the
tnsnames.ora File
PROD = (DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)(HOST = EDBVR6P1)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = DG_PROD)))
RTQ = (DESCRIPTION =

(CONNECT_DATA = (SERVICE_NAME = DG_RTQ)))
SNAP = (DESCRIPTION =
(CONNECT_DATA = (SERVICE_NAME = DG_SNAP)))
LSBY = (DESCRIPTION =
(CONNECT_DATA = (SERVICE_NAME = DG_LSBY)))
Configuring Service Names in the tnsnames.ora File

To ensure that clients connect to a database in the correct state and role for a particular
service, configure a Net service name for each service in the tnsnames.ora file.
Note: The example in the slide corresponds to the service names and trigger defined earlier
in the lesson.

Automatic Failover of Applications to a New
Primary Database
Primary site Standby site
Application Tier
Oracle Application
Server Clusters
3

Database Tier
Oracle Real
Application
Clusters
2
Database
services 1
Primary Manual or
database automatic failover
Automatic Failover of Applications to a New Primary Database

In previous Oracle Database releases, user-written database triggers were required to
implement automatic failover as follows:
• A startup trigger was used to start database services on the new primary database.
• A role-change trigger was used to publish a FAN ONS event to break JDBC clients still
connected to the original primary database out of a TCP timeout.
In Oracle Database 11g Release 2 (11.2), you can automate fast failover of applications to a
new primary database without the need for user-written triggers. You must use the Data
Guard broker to use this feature.
Automatic fast failover of application clients to a new primary database following failover
requires:
1. Fast database failover
2. Restarting database services on the new primary database
3. Notifying clients that a failure has occurred in order to break them out of TCP timeout
and redirect them to the new primary database

Data Guard Broker and Fast Application
Notification (FAN)
• The Data Guard broker publishes FAN events at failover
time.
• Applications respond to FAN events without programmatic
changes if using Oracle-integrated database clients:
– Oracle Database JDBC

– Oracle Database Oracle Call Interface (OCI)
– Oracle Database ODP.NET
• Clients that receive FAN events can be configured for Fast
Connection Failover (FCF) to automatically connect to a
new primary database.
• Clients connect to the new primary database using an
Oracle Net connect descriptor configured for connect-time
failover.
Data Guard Broker and Fast Application Notification (FAN)

When a failover operation is complete, the Data Guard broker publishes a Fast Application Notification
(FAN) event to notify applications that the old primary database is down, and that services on the old
primary database are down. This enables applications to transparently fail over to the new primary
database.
FAN notification is sent after failover for databases configured with Cluster Ready Services (CRS) and
for single-instance databases registered with Oracle Restart.
Applications using the following Oracle integrated database clients can be configured for Fast
Connection Failover (FCF) to automatically connect to a new primary database after a failover:
• Oracle Database JDBC
• Oracle Database Oracle Call Interface (OCI)
• Oracle Database ODP.NET.
These clients can use FAN without programmatic changes.
Applications can use FAN programmatically by using the Oracle Notification Service (ONS) Application
Programming Interface to subscribe to FAN events and to execute event-handling actions upon the
receipt of an event.
Refer to Oracle Real Application Clusters Administration and Deployment Guide 11g Release 2 for
detailed information about configuring FAN, FCF, and ONS in an Oracle RAC environment.

Enabling FAN Events in an Oracle Restart
Environment
To enable FAN events in an Oracle Restart environment:
1. Choose the correct SRVCTL to run.
2. Add the database to the Oracle Restart configuration.
3. Add ONS and eONS to the configuration.
srvctl add ons

srvctl add eons
4. Start ONS and eONS.

srvctl start ons
srvctl start eons
5. Add the service to the Oracle Restart configuration.

6. Enable each client for fast connection failover.
Enabling FAN Events in an Oracle Restart Environment

To enable Oracle Restart to publish Fast Application Notification (FAN) events, you must
create an Oracle Notification Services (ONS) network that includes the Oracle Restart servers
and the integrated clients. These clients can include Oracle Connection Manager (CMAN),
Java Database Connectivity (JDBC), and Universal Connection Pool (UCP) clients. If you are
using Oracle Call Interface or ODP.NET clients, you must enable Oracle Advanced Queuing
(AQ) HA notifications for your services. In addition, ONS and eONS must be running on the
server.
To enable FAN events in an Oracle Restart environment:
1. Prepare to run SRVCTL from the Oracle Grid Infrastructure environment. SRVCTL can
also be found in the ORACLE_HOME database, but it should not be used from there.
2. Add the database to the Oracle Restart configuration if it is not already managed by
Oracle Restart. Oracle Enterprise Manager 10g wizards do not automatically add newly
created standby databases to the Oracle Restart configuration.
3. Add ONS and eONS to the configuration.
4. Start ONS and eONS.
5. Add the service to the Oracle Restart configuration.
6. Enable each client for fast connection failover.
Automating Client Failover

• Relocating database services to the new primary database
as part of a failover operation
• Notifying clients that the failure has occurred
• Redirecting clients to a new primary database

Automating Client Failover in a Data Guard Configuration

Automating client failover in a Data Guard configuration includes:
• Relocating database services to the new primary database as part of a Data Guard
failover
• Notifying clients that the failure occurred in order to break them out of TCP timeout
• Redirecting clients to the primary database that is established during the failover
operation

Client Failover: Components
The following features are used to implement client failover and

minimize the impact of planned and unplanned outages:
• Connect time failover
• Transparent Application Failover (TAF)
• Fast Application Notification (FAN)

• Fast Connection Failover (FCF)
• DB_ROLE_CHANGE system event
Client Failover: Components

• Connect time failover: Redirects failed connection requests to a secondary listener.
• Transparent Application Failover (TAF): Enables Oracle Call Interface (OCI) client
applications to automatically reconnect to a database if the original connection fails. TAF
fails over only the session and SELECT statements. SELECT statements are
automatically restarted in the new session when TAF is configured for SELECT failover.
INSERT, UPDATE, and DELETE statements must be rolled back by the application. In
addition, any session customizations (for example, ALTER SESSION statements) must
be reexecuted by the application. Process state variables (such as PL/SQL session
level variables) are not reestablished but can be reestablished by using a TAF callback.
• Fast Application Notification (FAN): Provides quick notification when a resource (such
as an instance, service, node, or database) fails. FAN is available to all applications by
using either Fast Connection Failover with a FAN-integrated Oracle client (clients using
JDBC, OCI, or OLE DB) or by using the FAN API to read FAN events directly.
• Fast Connection Failover: Provides fast failover of database connections by enabling
you to configure FAN-integrated JDBC clients to automatically subscribe to FAN high-
availability events and react to service, instance, and database UP and DOWN events.
• DB_ROLE_CHANGE system event: Is fired when any database is first opened after a
Data Guard role transition occurs. Using this system event, you can write a trigger to
perform post-role change actions.

Client Failover: Best Practices
• Configure OCI clients for FAN OCI:

– AQ_HA_NOTIFICATIONS
• Configure DBC clients for Fast Connection Failover and
FAN ONS:
– ONS daemons on primary and standby clusters

– JDBC client uses remote subscription to all daemons
• Implement fast ADDRESS_LIST transversal:
– OCI: OUTBOUND_CONNECT_TIMEOUT
– JDBC: SQLnetDef.TCP_CONNTIMEOUT_STR
Client Failover: Best Practices

Additional information about each type of client follows in this lesson. For detailed examples,
see the white paper titled ―Client Failover Best Practices for Highly Available Oracle
Databases: Oracle Database 10g Release 2.‖

Automating Failover for OCI Clients
• On the database instance:

– Use DBMS_SERVICE.CREATE_SERVICE or SRVCTL to
create a database service, enable high-availability
notification, and configure server-side TAF settings.
– Create a trigger on the system startup event to relocate the

database service after a role transition if needed.
• To configure your OCI clients:
– Use the OCI_EVENTS parameter to initialize the
environment.
– Link the OCI client applications with the thread library.
– Set the SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter
in the sqlnet.ora file to a value of 3 seconds.
– Register an event callback.
Automating Failover for OCI Clients

To automate failover for OCI clients, perform the following steps to configure your database:
1. Ensure that your configuration is managed by the Data Guard broker.
2. Execute the DBMS_SERVICE.CREATE_SERVICE procedure to create the database
service, enable high-availability notification, and configure server-side TAF settings.
3. Create a trigger that fires on the system startup event.
This trigger relocates the database to the service (created in step 2) to a Data Guard
standby database after a role transition.
To automate failover for OCI clients, perform the following steps to configure your OCI clients
to receive notification of FAN high-availability events and avoid reconnecting to a failed
instance:
1. Create an Oracle Net service name that includes an ADDRESS entry for the primary
database host and all standby databases hosts.
2. Use the OCI_EVENTS parameter to initialize the environment so that OCI clients receive
FAN notifications:
OCIEnvCreate(...OCI_EVENTS...)
Note: See the Oracle Call Interface Programmer’s Guide for additional information.
3. Link the OCI client application to the libthread or libpthread thread library.
Automating Failover for OCI Clients (continued)
4. Set the SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter in the sqlnet.ora file to
a value of 3 seconds.
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT M ATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
This parameter enables clients to quickly traverse an address list in the event of a
failure. If a client attempts to connect to a host that is unavailable, the connection
attempt is bounded to the time specified by the
SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter, after which the client attempts to
connect to the next host in the address list. This behavior continues for each host in the
address list until a successful connection is made.
5. Register a callback that is invoked when a high-availability event occurs.
Note: For details, see the Oracle Call Interface Programmer’s Guide.

Automating Failover for OLE DB Clients
1. On the database instance, ensure Data Guard broker

management of the configuration.
2. Execute the DBMS_SERVICE.CREATE_SERVICE
procedure or SRVCTL to create the database service,
enable high availability notification, and configure server-

side TAF settings.
3. Create a trigger on the system startup event to relocate the
Automating Failover for OLE DB Clients

To automate failover for OLE DB clients, perform the following steps to configure your
database:
1. Ensure that your configuration is managed by the Data Guard broker.
2. Execute the DBMS_SERVICE.CREATE_SERVICE procedure or SRVCTL to create the
database service, enable high-availability notification, and configure server-side TAF
settings.
3. Create a trigger that fires on the system startup event if needed.
This trigger relocates the database after a role transition to the service that was created
in step 2.

Configuring OLE DB Clients for Failover
1. Set the DBNotifications and DBNotificationPort

OraOLEDB connection string attributes.
2. Set the SQLNET.OUTBOUND_CONNECT_TIMEOUT
parameter in the client sqlnet.ora file to a value of
3 seconds.

Configuring OLE DB Clients for Failover

To configure OLE DB clients to receive notification of FAN high-availability events:
1. Set the following OraOLEDB connection string attributes:
a. DBNotifications = true
b. DBNotificationPort = [unsigned integer]
Setting the DBNotificationPort attribute allows the port to be specified. If this
attribute is not set, the port is randomly selected.
2. Set the SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter in the sqlnet.ora file to
a value of 3 seconds.
This parameter enables clients to quickly traverse an address list if a failure occurs.
If a client attempts to connect to a host that is unavailable, the connection attempt is
bounded to the time specified by the SQLNET.OUTBOUND_CONNECT_TIMEOUT
parameter, after which the client attempts to connect to the next host in the address list.
This behavior continues for each host in the address list until a successful connection is
made.

Automating Failover for JDBC Clients
1. On the database instance, execute the

DBMS_SERVICE.CREATE_SERVICE procedure or
SRVCTL to create the database service.
2. Configure ONS in the $ORACLE_HOME/opmn/conf
directory.

3. Start the ONS daemon.
4. Create a trigger on the system startup event to relocate the
5. Create a trigger on the DB_ROLE_CHANGE system event if
needed.
Automating Failover for JDBC Clients

To automate failover for JDBC clients, perform the following steps to configure your database:
1. Execute the DBMS_SERVICE.CREATE_SERVICE procedure or SRVCTL to create the
database service for JDBC clients.
Because JDBC clients use FCF rather than TAF, database services for JDBC clients are
not configured for AQ HA events. Instead, a trigger is required to notify JDBC clients
when a Data Guard failover occurs.
2. Configure and start ONS daemons on all hosts that may contain a primary database.
Configure ONS in the $ORACLE_HOME/opmn/conf directory (similar to the example in
the slide). See the Oracle Database JDBC Developer’s Guide and Reference for details.
3. Start the ONS daemon.
4. Create a trigger on the system startup event to relocate the database service after a role
transition if needed. The trigger is not needed when using Oracle Restart.
5. Create a trigger enabled for the DB_ROLE_CHANGE system event that calls a C program
named the FAN ONS Publisher.
This trigger is required because the primary host where the ONS daemons reside are no
longer available. By calling the FAN ONS Publisher program based on a trigger enabled
on the DB_ROLE_CHANGE system event, JDBC clients are notified of the primary site
failure and instructed to reconnect to the new primary database. See the white paper
titled ―Client Failover Best Practices for Highly Available Oracle Databases: Oracle
Database 10g Release 2‖ for information about the FAN ONS Publisher.

Configuring JDBC Clients for Failover
1. Set the FastConnectionFailoverEnabled

DataSource property to True.
2. Set the
oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR
property on the data source to a value of 3 seconds.

3. Create an Oracle Net service name that includes the
primary database host and all standby database hosts in
the address list.
4. Configure a remote ONS subscription on the JDBC client.
5. Enable SSL for communications.
Configuring JDBC Clients for Failover

To configure JDBC clients for failover:
1. Set the FastConnectionFailoverEnabled DataSource property to True
so that the client application uses implicit JDBC connection cache on its data source.
2. Set the oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR property to a value of
3 seconds on the data source.
This property enables the JDBC client to quickly traverse an address list in the event of
a failure. If the client attempts to connect to a host that is unavailable, the connection
attempt is bounded to the time specified by the SQLnetDef.TCP_CONNTIMEOUT_STR
property, after which the client attempts to connect to the next host in the address list.
The behavior continues for each host in the address list until a successful connection is
made.
3. Create an Oracle Net service name that includes an ADDRESS entry for the primary
database host and all standby database hosts.
4. Configure a remote ONS subscription on the JDBC client so that an ONS daemon is not
required on the client. The remote ONS subscription should contain all hosts that have
the potential to become a primary database.
5. Enable SSL for communications.
SSL should be used for all ONS communications.
Quiz
Role-based services can be created only with SRVCTL and not

DBMS_SERVICE.
a. True
b. False

Answer: a

Quiz
FAN events are not enabled or started during the installation of

Grid Infrastructure for Standalone Servers for Data Guard.
a. True
b. False

Answer: a

Summary

• Configure client connectivity in a Data Guard configuration
• Implement failover procedures to automatically redirect
clients to a new primary database



• Creating a service
• Creating Oracle Net service names
• Testing your implementation




Oracle Data Guard Configuration
Backup and Recovery Considerations in an

Objectives

• Use Recovery Manager (RMAN) to back up and restore
files in a Data Guard configuration
• Offload backups to a physical standby database
• Recover your primary database by using a file from the


Using RMAN to Back Up and Restore Files

• RMAN can be used to back up and recover databases in a
• Standby database backups are usable on the primary
database.
• Backups of logical standby databases are not usable at the

primary database.
• The recovery catalog is required when using RMAN in a
Data Guard configuration for physical standby databases.
• RMAN and Data Guard best practices:
– Perform backups at the primary and standby databases to
reduce mean time to recover (MTTR).
– Take daily incremental backups.
Using RMAN to Back Up and Restore Files in a Data Guard Configuration

Recovery Manager (RMAN) can be used to back up and recover a standby database.
Backups that you make on a physical standby database are usable at a primary database or
another standby database.
A recovery catalog is required when you use RMAN in a Data Guard configuration containing
physical standby databases. Metadata for the primary database and all standby databases is
stored in the recovery catalog.
Oracle Maximum Availability Architecture (MAA) best practices recommend that backups be
taken at both the primary and the standby databases to:
• Reduce mean time to recover (MTTR)
• Handle outages at multiple sites
• Avoid introducing new site practices during switchover and failover

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

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

Restrictions and Usage Notes
• You must back up a physical standby database.

• You must be connected to the recovery catalog when
backing up.
• 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 you
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.
Furthermore, 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). The standby database essentially
―substitutes‖ for the primary database during the backup.

Backup and Recovery
of a Logical Standby Database

• Backup considerations:
– Use the same backup method that you use for your primary
database.
– Files are not interchangeable with the primary database.
• Recovery considerations:

– If you lose individual files, perform recovery as you would for
any other database.
– Re-create the logical standby database if you lose the entire
database.
– Use a binary copy of the 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 you use 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.) 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 the RMAN Recovery Catalog

• Use of the RMAN recovery catalog permits backups taken
on one database server to be restored to another database
server.
• RMAN uses the recovery catalog metadata to behave
transparently across different physical databases in the

• Configure a separate server for the recovery catalog so
that a disaster at any site in the Data Guard configuration
does not affect the ability to recover from the latest
backups.

Using the RMAN Recovery Catalog in a Data Guard Configuration

In a Data Guard configuration, you should use an RMAN recovery catalog. This permits
backups taken on one database server to be restored to another database server. If you use
only the control file as the RMAN repository, the primary database will have no knowledge of
backups taken on the standby database.

Creating the Recovery Catalog
HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIAL S FROM THIS COMPUTER IS STRICTLY PROHIBITED

1. Configure the 2. Create the
3. Create the
recovery catalog recovery catalog
recovery catalog.
database. owner.
Creating the Recovery Catalog

1. Configure the database in which you want to store the recovery catalog.
a. Determine the database in which you will install the recovery catalog schema. Be
sure to consider your backup and recovery procedures for this database.
b. Create a tablespace for the recovery catalog, which becomes the default
tablespace for the recovery catalog owner. The amount of space required by the
recovery catalog schema depends on the number of databases monitored by the
catalog. The typical space requirement is 15 MB for each database registered in
the recovery catalog.
SQL> CREATE TABLESPACE rc_ts DATAFILE SIZE 30M;
2. Create a user to serve as the recovery catalog owner. Set the default tablespace for this
user to the tablespace that you created for the recovery catalog. Be sure to provide
UNLIMITED quota on this tablespace for the user. After creating the user, grant the
RECOVERY_CATALOG_OWNER role to the user.
SQL> CREATE USER rcowner IDENTIFIED BY rcpass
2 TEMPORARY TABLESPACE temp
3 DEFAULT TABLESPACE rc_ts
4 QUOTA UNLIMITED ON rc_ts;
SQL> GRANT recovery_catalog_owner TO rcowner;

Creating the Recovery Catalog (continued)
3. Use the CREATE CATALOG RMAN command to create the catalog tables in the default
tablespace of the catalog owner.
$ rman
RMAN> CONNECT CATALOG rcowner/rcpass
RMAN> CREATE CATALOG;

Registering a Database in the Recovery Catalog
• Only the primary database must be explicitly registered:

$ rman TARGET / CATALOG
username/password @net_service_name
RMAN> REGISTER DATABASE;
• A standby database is automatically registered when you

connect to it or when the CONFIGURE DB_UNIQUE_NAME
command is executed.
• RMAN performs the following actions:
– Creates rows in the recovery catalog tables for the target
database
– Copies data from the target database control file to the
recovery catalog tables
Registering a Database in the Recovery Catalog

After creating the recovery catalog, you must register the target databases in the recovery
catalog. Only the primary database must be explicitly registered by using the REGISTER
DATABASE command. A standby database is automatically registered in the recovery catalog
when you connect to it or when the CONFIGURE DB_UNIQUE_NAME command is executed to
specify the net service name for the physical standby database.
To register your primary database:
1. Invoke RMAN and connect to the recovery catalog database and to the target database,
as shown in the following example:
% rman TARGET / CATALOG rcowner/rcpass@reccatdb
2. Ensure that the target database is mounted or open.
3. Issue the REGISTER command to register the target database in the recovery catalog:
RMAN> REGISTER DATABASE;

Setting Persistent Configuration Settings
• Use the CONFIGURE command with the FOR

DB_UNIQUE_NAME clause to create a persistent
configuration for a database in a Data Guard configuration.
• You do not have to connect to the standby database or
primary database as TARGET.
• RMAN must be connected to a recovery catalog when you

create or alter a configuration for a database in the Data
Guard configuration.
RMAN> configure controlfile autobackup on for db_unique_name
pc01sby1;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored
Setting Persistent Configuration Settings

Use the CONFIGURE RMAN command to register and configure settings for databases in your
RMAN uses the DB_UNIQUE_NAME initialization parameter to distinguish the databases in the
Data Guard configuration. You can use the CONFIGURE command with the FOR
DB_UNIQUE_NAME clause to create a persistent configuration for a database in a Data Guard
configuration without connecting to the database as TARGET. Use the SET DBID command to
set the DBID in the RMAN session so that you can configure a standby database when
RMAN is not connected as TARGET to a database in the Data Guard environment. You can
also use this technique to create a configuration for a standby database that is not yet
created.
RMAN must be connected to a recovery catalog when you create or alter a configuration for a
database in the Data Guard environment.

Setting Persistent Configuration Settings (continued)
Configuring a Persistent Setting: Example
[oracle@EDBVR6P1-pc01prmy labs]$ rman target / catalog rcowner@pc01db11
Recovery Manager: Release 11.2.0.1.0 - Production on Tue Feb 23 19:33:45 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: PC01PRMY (DBID=2581955083)

recovery catalog database Password: rcpass
connected to recovery catalog database

RMAN> configure controlfile autobackup on;
new RMAN configuration parameters:
new RMAN configuration parameters are successfully stored
RMAN> show all for db_unique_name pc01sby1;
RMAN configuration parameters for database with db_unique_name PC01SBY1 are:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR
LOAD TRUE ; # default
CONFIGURE DB_UNIQUE_NAME 'pc01prmy' CONNECT IDENTIFIER 'pc01prmy';
CONFIGURE DB_UNIQUE_NAME 'pc01sby1' CONNECT IDENTIFIER 'pc01sby1';
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_pc01sby1.f'; # default

Setting RMAN Persistent Configuration
Parameters on the Primary Database

• Configure the backup retention policy:
RMAN> CONFIGURE RETENTION POLICY TO
2> RECOVERY WINDOW OF <n> DAYS;
• Specify deletion of archived redo logs:

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO

2> SHIPPED TO ALL STANDBY;
2> APPLIED ON ALL STANDBY;
• Configure the connect identifier for the primary database
and the standby databases:
RMAN> CONFIGURE DB_UNIQUE_NAME pc01prmy
2> CONNECT IDENTIFIER 'pc01prmy';
RMAN> CONFIGURE DB_UNIQUE_NAME pc01sby1
2> CONNECT IDENTIFIER 'pc01sby1'
Setting RMAN Persistent Configuration Parameters on the Primary Database

• Configure the retention policy to determine the backups that need to be kept to recover
to the specified point in time. This setting specifies that necessary backups should be
kept to perform database recovery to any point in time within the specified number of
days.
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <n> DAYS;
Execute the DELETE OBSOLETE command to delete any backups that are not required
by the retention policy.
• Use the CONFIGURE ARCHIVELOG DELETION POLICY command to specify when
archived logs can be deleted.
- To delete logs after ensuring that they shipped to all destinations:
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL
STANDBY;
- To delete logs after ensuring that they were applied on all standby destinations:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL
STANDBY;

Setting RMAN Persistent Configuration Parameters on the Primary Database
(continued)
• Configure the connect identifier for the primary database and all standby databases so
that RMAN can connect remotely and perform resynchronization when the RESYNC
CATALOG FROM DB_UNIQUE_NAME command is executed. The connect identifier is the
Oracle Net service name that can be used from any database site to connect to the
specified database site. CONFIGURE DB_UNIQUE_NAME implicitly registers the database.

Parameters on the Physical Standby Database

Set the following parameters on the physical standby database
where you will perform backups:
• Enable automatic backup of the control file and the server
parameter file:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

• Skip backing up data files for which there already exists a
valid backup with the same checkpoint:
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
• Specify when the archived logs can be deleted:

2> BACKED UP 1 TIMES TO DEVICE TYPE DISK;
Setting RMAN Persistent Configuration Parameters on the Physical Standby

Database
On the physical standby database that you will be using for backups, set RMAN persistent
configuration parameters as follows:
• Enable automatic backup of the control file and the server parameter file.
• Set backup optimization to ON so that RMAN does not back up data files for which there
is valid backup with the same checkpoint.
CONFIGURE BACKUP OPTIMIZATION ON;
• Specify the archived log file deletion policy to indicate when archived redo log files are
deleted.
CONFIGURE ARCHIVELOG DELETION POLICY TO
BACKED UP 1 TIMES TO DEVICE TYPE DISK;
When backing up to tape, configure tape channels as required by the media management
software. For details about backups to tape and the use of media management software, see
Oracle Data Guard Concepts and Administration.

Parameters on the Other Standby Databases

On the standby databases where you will not be performing
backups, specify that the archived logs can be deleted after
they are applied at the standby database:
2> APPLIED ON ALL STANDBY;

Setting RMAN Persistent Configuration Parameters on the Other Standby

Databases
You specify the archived log file deletion policy to indicate that archived logs are deleted after
they are applied at the standby database.

Configuring Daily Incremental Backups
• Configure a daily backup strategy:

– Day 1: Create a full database backup.
– Day 2: Create an incremental backup.
– Day 3: Create an incremental backup.
The previous day's incremental backup is merged with the

data file copy, and a current incremental backup is taken.
• A single RMAN script can be created to implement this
strategy:
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
RECOVER COPY OF DATABASE WITH TAG 'dgbkup';
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER
OF COPY WITH TAG 'dgbkup' DATABASE;
BACKUP DEVICE TYPE DISK ARCHIVELOG ALL;
BACKUP BACKUPSET ALL;
DELETE ARCHIVELOG ALL;
Configuring Daily Incremental Backups

Oracle Corporation recommends that you implement a daily incremental backup strategy. In
this backup strategy, data file image copies are rolled forward with the latest incremental
backups. The resulting up-to-date data file image copy is used by RMAN for media recovery.
Perform a full database backup on the first day, followed by an incremental backup on day
two. Archived redo logs can be used to recover the database to any point during either day.
Beginning on day three, the previous day’s incremental backup is merged with the data file
copy and a current incremental backup is taken, allowing fast recovery to any point within the
last day. Redo logs can be used to recover the database to any point during the current day.
You can create an RMAN script to take all of the backups (as shown in the slide):
• RESYNC CATALOG FROM DB_UNIQUE_NAME ALL : Resynchronizes the information from
all database sites (primary and other standby databases) in the Data Guard
configuration that are known to the recovery catalog.
• RECOVER COPY OF DATABASE WITH TAG 'dgbkup': Rolls forward the level 0 copy of
the database by applying the level 1 incremental backup taken the day before.
- On day 1, there is no roll forward because there is no incremental level 1 backup.
- On day 2, there is no roll forward because there is only a level 0 incremental
backup at this time.

Configuring Daily Incremental Backups (continued)
- On day 3 and the following days, the roll forward is performed using the level 1
incremental backup created on the previous day.
• BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG
'dgbkup' DATABASE: Creates a new level 1 incremental backup.
- On day 1, a level 0 incremental backup is created.
- On day 2 and the following days, a level 1 incremental backup is created.
• BACKUP DEVICE TYPE DISK ARCHIVELOG ALL: Backs up archived logs to disk.
• BACKUP BACKUPSET ALL: Backs up any backup sets that were created as a result of
incremental backup.
• DELETE ARCHIVELOG ALL: Deletes archived logs according to the log deletion policy set

by the CONFIGURE ARCHIVELOG DELETION POLICY command. If the archived logs are in
a flash recovery area, they are automatically deleted when more open disk space is
required. Therefore, you need to use this command only if you explicitly want to delete
logs each day.

Recovering from Loss of a Data File

• Using backups
• Using a file on the standby database

Recovering from Loss of a Data File on the Primary Database

These two methods are covered on the following pages.

Using a Backup to Recover a Data File
RMAN> RESTORE DATAFILE 5;

RMAN> RECOVER DATAFILE 5;

Using a Backup to Recover a Data File on the Primary Database

Invoke RMAN and connect to the primary database and the recovery catalog.
• Execute the RESTORE DATAFILE command to restore the data file.
• Execute the RECOVER DATAFILE command to recover the data file.
For detailed information about the RESTORE and RECOVER commands, see the Oracle
Database Backup and Recovery Reference.

Using a Physical Standby Database Data File
to Recover a Data File on the Primary Database

1. Connect to the standby database as the target database
and connect to the primary database as the auxiliary
database:
RMAN> CONNECT TARGET sys/oracle@pc01sby1
RMAN> CONNECT AUXILIARY sys/oracle@pc01prmy

2. Back up the data file on the standby database host to a
location on the primary database host:
RMAN> BACKUP AS COPY DATAFILE 5
2> AUXILIARY FORMAT '/u02/oracle/restore/df5copy.dbf';
Primary Database
To use a current data file from the physical standby database to recover a data file on the
primary database:
1. Connect to the standby database as the target database:
CONNECT TARGET sys/oracle@pc01sby1
Connect to the primary database as the auxiliary database:
CONNECT AUXILIARY sys/oracle@pc01prmy
2. Back up the data file on the standby host across the network to a location on the
primary host, as in the following example:
BACKUP AS COPY DATAFILE 5
AUXILIARY FORMAT '/u02/oracle/restore/df5copy.dbf';

Using a Physical Standby Database Data File
to Recover a Data File on the Primary Database

3. Connect to the primary database as the target database
and connect to the recovery catalog:
RMAN> CONNECT TARGET sys/oracle@pc01prmy
2> CATALOG rcowner/rcpass@pc01db11;
4. Catalog the data file copy for RMAN use:

RMAN> CATALOG DATAFILECOPY
2> '/u02/oracle/restore/df5copy.dbf';
5. Switch the data file copy so that it becomes the current
data file:
RMAN> RUN {
2> SET NEWNAME FOR DATAFILE 5 TO
3> '/u02/oracle/restore/df5copy.dbf';
4> SWITCH DATAFILE 5;
5> }
Primary Database (continued)
3. Exit the RMAN session. Invoke RMAN again and connect to the primary database as
the target database and connect to the recovery catalog, as in this example:
CONNECT TARGET sys/oracle@pc01prmy
CATALOG rcowner/rcpass@pc01db11;
4. Use the CATALOG DATAFILECOPY command to catalog this data file copy so that
RMAN can use it.
CATALOG DATAFILECOPY '/u02/oracle/restore/df5copy.dbf';
5. Use the SWITCH DATAFILE command to switch the data file copy so that the cataloged
file becomes the current data file.
RUN {
SET NEWNAME FOR DATAFILE 5 TO
'/u02/oracle/restore/df5copy.dbf';
SWITCH DATAFILE 5;
}

Recovering a Data File on the Standby Database
• If all archived redo log files needed for recovery are

accessible on disk:
1. Restore the data file by using the RESTORE DATAFILE
command.
2. Restart Redo Apply.

• If all archived redo log files needed for recovery are not
accessible on disk:
1. Restore the data file by using the RESTORE DATAFILE
command.
2. Use the RECOVER DATABASE command to recover the data
file to an SCN that is greater than the last log applied to the
standby database.
3. Restart Redo Apply.
• Use a current data file from the primary database.
Recovering a Data File on the Standby Database

Using a Backup to Recover a Data File on the Standby Database
To recover a data file on the standby database, you must restore the lost file to the standby
database from the backup by using the RESTORE DATAFILE RMAN command. If all archived
redo log files that are required for recovery of the file are accessible on disk by the standby
database, you only need to restart Redo Apply.
If the archived redo log files that are required for recovery are not accessible on disk, use
RMAN to recover the restored data files to an SCN or log sequence that is greater than the
last log applied to the standby database. Next, restart Redo Apply to continue the application
of redo data.
Using a Data File From the Primary Database
You can use a current data file from the primary database to recover a file on the standby
database.

Enhancements to Block Media Recovery
• Corrupted blocks in the primary database are automatically

repaired by using blocks from a physical standby
database.
• Real-time query and Active Data Guard must be enabled
on the physical standby database.

Automatic Block Repair
Primary Physical standby Queries

database database with
real-time query

In past releases of Oracle Database, if a block was corrupted you had to identify the corrupt
block and manually perform block media recovery by executing the RECOVER … BLOCK
command.
The Automatic Block Repair feature in Oracle Database 11g Release 2 (11.2) enables block
media recovery to use blocks from a physical standby database to perform the recovery
without manual intervention. The physical standby database must have real-time query
enabled to take advantage of this feature.
When a query is executed on a physical standby database configured with real-time query
and a corrupted block is detected, a valid block is retrieved from the primary database.
When a corrupted block is detected during a recovery operation on the standby database, the
recovery process will retrieve a valid block from the primary database.
This feature reduces the amount of time that production data cannot be accessed due to block
corruption by automatically repairing the corruption as soon as it is detected. Block recovery
time is reduced because up-to-date good blocks from a real-time, synchronized physical
standby database are used rather than blocks from disk or tape backups, or flashback logs.
Note: Automatic Block Repair is applicable only for physical block corruption (when the
checksum is invalid, the block contains all zeros, or the block header is fractured).

• Corrupted blocks in the physical standby database are

automatically repaired by using blocks from the primary
database
• Real-time query and Active Data Guard must be enabled
on the physical standby database

Automatic Block Repair
Primary Physical standby Queries

database database with
real-time query
Enhancements to Block Media Recovery (continued)

Automatic Block Repair also enables the automatic repair of corrupt blocks on the physical
standby database. Block media recovery is performed by using blocks retrieved from the
primary database. Real-time query must be enabled on the physical standby database to take
advantage of this feature.

Executing the RECOVER BLOCK Command
• Block media recovery can also be performed manually by

using the RECOVER BLOCK command.
RECOVER DATAFILE 6 BLOCK 3; Recover a single block
RECOVER Recover multiple blocks

DATAFILE 2 BLOCK 43,79 in multiple data files
DATAFILE 6 BLOCK 183;
• Search for usable blocks for the recovery proceeds as

follows:
1. Physical standby database
2. Flashback logs
3. Blocks in full or level 0 incremental backup
Executing the RECOVER BLOCK Command

In past releases of Oracle Database, when you executed the RECOVER … BLOCK command
to perform block media recovery, RMAN searched the flashback logs for good copies of the
blocks, and then searched in full or level 0 incremental backups. In Oracle Database 11g
Release 2 (11.2), RMAN first attempts to restore blocks from a physical standby database that
is configured with real-time query. If RMAN does not find a valid block in the physical standby
database, the flashback logs are searched. Finally, the full or level 0 incremental backups are
searched.

Excluding the Standby Database
• By default, block media recovery searches the physical

standby database first for blocks to use.
• Exclude the standby database from the search by
including the EXCLUDE STANDBY clause.

RECOVER BLOCK … EXCLUDE STANDBY
Excluding the Standby Database

By default, the RECOVER … BLOCK command tries to retrieve a good block from a physical
standby database. You can disable the search on the physical standby database by
specifying the EXCLUDE STANDBY clause with the command. You may use the EXCLUDE
STANDBY clause when you know there is a network issue or other reason that the standby
database is not available.

Quiz
You need to register the standby database to the RMAN

recovery catalog in order to exchange backup files with the
primary database.
a. True
b. False

Answer: b

Quiz
If a logical standby database has applied all data from the

primary database, the data files can be exchanged with that of
a. True
b. False

Answer: b

Summary

• Use RMAN to back up and restore files in a Data Guard
configuration
• Offload backups to a physical standby database
• Recover your primary database by using a file from the



• Creating a recovery catalog
• Setting RMAN persistent configuration parameters
• Performing a backup of the physical standby database
• Recovering a primary database data file by using a data

file from your standby database


Guard Configuration

Patching and Upgrading Databases in a Data

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

databases in your Data Guard configuration:
• By using traditional upgrade methods
• By performing rolling upgrades

Objectives
The methods outlined in this lesson are applicable for a patch, a critical patch update (CPU),
a patch set, or a major release.

Upgrading an Oracle Data Guard
Broker Configuration
• If you are using the Data Guard broker, you must perform
the following steps before upgrading your databases:
1. Disable broker management of the configuration.
2. Stop the Data Guard broker.

SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;
• After completing the upgrade:

1. Start the Data Guard broker.
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;
2. Enable broker management of the configuration.

DGMGRL> ENABLE CONFIGURATION;
Upgrading an Oracle Data Guard Broker Configuration

To upgrade the databases in your Data Guard configuration:
1. Disable broker management of the databases in the Data Guard configuration by
executing the following DGMGRL command:
2. Execute the following SQL*Plus statement to stop the broker:
SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;
After completing the upgrade:
1. Start the Data Guard broker by executing the following command in SQL*Plus:
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;
2. Enable broker management of the configuration by executing the following DGMGLR
command:
DGMGRL> ENABLE CONFIGURATION
Note: The first time the release 11.2 broker starts, it detects the existence of release 10.n
broker configuration files and automatically upgrades them to include new properties
introduced in release 11.2.

Upgrading Oracle Database in a Data Guard
Configuration with a Physical Standby Database

To perform a traditional upgrade:
1. Perform the preparation steps for an upgrade.
2. Shut down the primary database.
3. Shut down the physical standby databases.
4. Stop all listeners, agents, and other processes running in

the Oracle homes that are to be upgraded.
5. If Oracle Automatic Storage Management (ASM) is in use,
shut down all databases that use ASM, and then shut down
the ASM instances.
6. Install the Oracle Database software on physical standby
database systems and the primary database system.
7. Restart all listeners, agents, and other processes stopped
in step 4.

Standby Database
Perform the steps in the slide to upgrade to Oracle Database 11g Release 2 (11.2) when your
Data Guard configuration contains one or more physical standby databases.
Note: For detailed information about these steps, see the Oracle Database Upgrade Guide
(including the ―Preparing to Upgrade‖ chapter).

Configuration with a Physical Standby Database

8. Mount the physical standby databases.
9. Upgrade the primary database as described in the Oracle
Database Upgrade Guide. Redo Transport will propagate
this to the standby databases.

10.Start Redo Apply on the physical standby databases.
11.Open the upgraded primary database.
12.If Active Data Guard was being used prior to the upgrade, it
will need to be reenabled.

Standby Database (continued)
Data Guard configuration contains one or more physical standby databases.
Note: For detailed information about these steps, see the Oracle Database Upgrade Guide
(including the ―Preparing to Upgrade‖ chapter).

Configuration with a Logical Standby Database

1. Perform the preparation steps for an upgrade.
2. Set the data protection mode to MAXIMUM PERFORMANCE.
3. Stop all user activity on the primary database and defer the
logical standby database remote archival destination.

4. Stop SQL Apply on the standby database.
5. Install Oracle Database software on the primary database
system and upgrade the primary database.
6. Install Oracle Database software on the logical standby
database system and upgrade the standby database.
7. Restart SQL Apply on the standby database.
8. Open the upgraded primary database.
9. Reset the data protection mode, if necessary.
Upgrading Oracle Database in a Data Guard Configuration with a Logical Standby

Database
Data Guard configuration contains a logical standby database.
Note: For detailed information about the steps for upgrading to Oracle Database 11g
Release 2 (11.2) when your Data Guard configuration contains a physical standby database,
see the Oracle Database Upgrade Guide (including the ―Preparing to Upgrade‖ chapter).

Using SQL Apply to Upgrade the Oracle Database
• Use a logical standby database to perform a rolling

upgrade of Oracle Database 10g software from patch set
release n to any higher-versioned patch set or major
version release.
• Incur minimal down time by using different releases of

Oracle Database on the primary database and logical
standby database while upgrading.
SQL Apply

Oracle Database 10g Oracle Database 11g
Using SQL Apply to Upgrade the Oracle Database

You can use a logical standby database to perform a rolling upgrade of Oracle Database 10g
software. During a rolling upgrade, different releases of Oracle Database can be on the
primary database and logical standby databases while you upgrade them one at a time,
incurring minimal down time on the primary database.
Using Data Guard SQL Apply, you can perform a rolling upgrade of the Oracle Database
software from patch set release n to any higher-versioned patch set or major version release.
Note: The minimum supported release is 10.1.0.3.

Requirements for Using SQL Apply
to Perform a Rolling Upgrade

• Databases must not be part of a Data Guard broker
configuration.
• Data Guard protection mode must be maximum availability
or maximum performance.
• The LOG_ARCHIVE_DEST_n initialization parameter for

the logical standby destination must not be set to
MANDATORY.
• The COMPATIBLE initialization parameter value must
match the software release prior to the upgrade.
Requirements for Using SQL Apply to Perform a Rolling Upgrade

Prior to performing the rolling upgrade, complete the following requirements:
• Remove the databases from the Data Guard broker configuration.
• Set the Data Guard protection mode to either maximum availability or maximum
performance.
• The LOG_ARCHIVE_DEST_n initialization parameter for the logical standby destination
must not be set to MANDATORY.
• Set the COMPATIBLE initialization parameter so that it matches the software release
prior to the upgrade. A rolling upgrade from release x to release y requires that the
COMPATIBLE initialization parameter be set to release x on the primary database and
the standby database.

Performing a Rolling Upgrade
by Using SQL Apply

• Create a new logical standby database to perform the
rolling upgrade.
• Use an existing logical standby database to perform the
rolling upgrade.
• Use an existing physical standby database to perform the

rolling upgrade (Oracle Database 11g only).
Performing a Rolling Upgrade by Using SQL Apply

You can use SQL Apply to perform a rolling upgrade in several different configurations. Each
of the configurations is outlined in detail in this lesson.

Identifying Unsupported Data Types
Identify data types and storage attributes on the primary

database that are not supported in a logical standby database:
• Query DBA_LOGSTDBY_UNSUPPORTED and
DBA_LOGSTDBY_SKIP.
• Determine how to handle unsupported objects during the

rolling upgrade.
Identifying Unsupported Data Types

You identify data types and storage attributes on the primary database that are not supported
in a logical standby database by querying the DBA_LOGSTDBY_UNSUPPORTED and
DBA_LOGSTDBY_SKIP views on the primary database. If your primary database contains
unsupported objects, you may be able to perform the upgrade by temporarily suspending
changes to the unsupported tables for the period of time it takes to perform the upgrade
procedure.
If you cannot prevent changes to unsupported tables during the upgrade, you may be able to
use Oracle Data Pump or the Import utility to import the changed tables to the upgraded
databases. Unsupported transactions that occur are recorded in the
DBA_LOGSTDBY_EVENTS table on the logical standby database.

Performing a Rolling Upgrade by Using
an Existing Logical Standby Database

1. Prepare for the rolling upgrade by stopping SQL Apply and
setting the COMPATIBLE initialization parameter.
2. Upgrade the Oracle Database software on the logical
standby database and upgrade the logical standby
database.

Oracle Database,
Oracle Database, Release y
Release x
Primary Standby
database database
Performing a Rolling Upgrade by Using an Existing Logical Standby Database

To perform a rolling upgrade by using a logical standby database in your Data Guard
configuration:
1. Prepare for the rolling upgrade as follows:
a. Stop SQL Apply by issuing the following statement on the logical standby
database:
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
b. Set the COMPATIBLE initialization parameter to the highest value. Ensure that the
COMPATIBLE initialization parameter specifies the release number for the Oracle
Database software running on the primary database prior to the upgrade.
2. Upgrade the Oracle Database software on the logical standby database to release y.
While the logical standby database is being upgraded, it does not accept redo data from
the primary database. See the Oracle Database Upgrade Guide for detailed information.


3. Restart SQL Apply on the upgraded logical standby
database.

SQL Apply
Oracle Database, Oracle Database,

Release x Release y
Primary Standby
database database

(continued)
3. Restart SQL Apply by executing the following statement on the standby database:
The redo data that was accumulating on the primary database system is automatically
transmitted and applied on the logical standby database. To monitor how quickly the
logical standby database is catching up to the primary database, query the
V$LOGSTDBY_PROGRESS view on the logical standby database. For example:
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY
HH24:MI:SS';
Session altered.
SQL> SELECT SYSDATE, APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;

SYSDATE APPLIED_TIME
------------------ ------------------
27-FEB-10 17:07:06 27-FEB-10 17:06:50


4. Query DBA_LOGSTDBY_EVENTS to monitor the upgraded
5. Begin a switchover to the upgraded logical standby
database:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER

2 TO LOGICAL STANDBY;
SQL Apply
Release x Release y

(continued)
4. Query DBA_LOGSTDBY_EVENTS to determine whether there are any DDL and DML
statements that were not applied on the logical standby database:
SELECT EVENT_TIMESTAMP, EVENT, STATUS
FROM DBA_LOGSTDBY_EVENTS
ORDER BY EVENT_TIMESTAMP;
5. Begin a switchover to the upgraded logical standby database by executing the following
statement on the primary database:
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
This statement waits for existing transactions to complete. To minimize the time it takes
to complete the switchover, users connected to the primary database should log off
immediately and reconnect to the standby database.


6. Import any tables that were unsupported and modified.
7. Complete the switchover and activate user applications:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER

2 TO LOGICAL PRIMARY;

Release x Release y
Standby database Primary database

(continued)
6. Import any tables that were modified during the upgrade from the primary database that
were unsupported in the logical standby database.
7. Complete the switchover by executing the following statement on the logical standby
database:
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL PRIMARY;
After the switchover, you cannot send redo data from the new primary database (using
the new Oracle Database software release) to the new standby database (using the
older Oracle Database software release).


8. Upgrade the original primary database.
9. Start SQL Apply on the original primary database.

SQL Apply
Release y Release y
Standby Primary
database database

(continued)
8. Upgrade the Oracle Database software on the original primary database to release y.
See the Oracle Database Upgrade Guide for detailed information.
9. Start SQL Apply on the original primary database. You may also need to create a
database link to the new primary database:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
NEW PRIMARY db_link;


10.Monitor events on the new logical standby database.
11.Optional: Perform a switchover to return to the original
configuration.
12.Optional: Raise the compatibility level on both databases.

SQL Apply

Release y Release y
Primary Standby
database database

(continued)
10. Monitor events on the new logical standby database by querying the
DBA_LOGSTDBY_EVENTS view.
11. Optional: Perform a switchover to return to the original configuration.
12. Optional: Raise the compatibility level on both databases by setting the COMPATIBLE
initialization parameter on the standby database before you set it on the primary
database.

Performing a Rolling Upgrade by Creating
a New Logical Standby Database

1. Identify data types and storage attributes on the primary
database that are not supported in a logical standby
database.
2. Create a logical standby database.
3. Perform a rolling upgrade.

Performing a Rolling Upgrade by Creating a New Logical Standby Database

1. Identify data types and storage attributes on the primary database that are not supported
in a logical standby database (as described earlier in this lesson).
2. Create a logical standby database (as described in the lesson titled ―Creating a Logical
Standby Database‖).
3. Perform a rolling upgrade (as described earlier in this lesson).


1. Prepare the primary database for a rolling upgrade.
a. Enable Flashback Database.
b. Create a guaranteed restore point.

Redo Redo
Transport Apply
Redo
Oracle Database, stream Oracle Database,
Release x Release x
Primary database Physical standby

database
Performing a Rolling Upgrade by Using a Physical Standby Database

Note: Use the following technique only when you are upgrading an Oracle Database 11g
database to a later release.
To perform a rolling upgrade when your configuration contains a physical standby database:
1. Prepare the primary database for a rolling upgrade:
a. Enable Flashback Database.
b. Create a guaranteed restore point:
CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK
DATABASE;


2. Convert the physical standby database to a logical standby
database.
a. Create a logical standby database and execute:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY
2 KEEP IDENTITY;

b. Disable automatic deletion of foreign archived logs at the
c. Start SQL Apply.
SQL Apply
Release x Release x
Primary database Logical standby

database
Performing a Rolling Upgrade by Using a Physical Standby Database (continued)

2. Convert the physical standby database to a logical standby database. This is only
temporarily done for the duration of the rolling upgrade.
a. Create a logical standby database and execute the following command:
ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;
Note: A logical standby database created with the KEEP IDENTITY clause retains the
same DB_NAME and DBID as those of its primary database.
b. Disable automatic deletion of foreign archived logs at the logical standby database:
execute DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE',
'FALSE');
c. Start SQL Apply:


3. Upgrade the logical standby database (steps 1–7 of
―Performing a Rolling Upgrade by Using a Logical Standby
Database‖).

Release x Release y
Logical standby Primary

database database

After completing these steps, your original primary database will be the logical standby
database and your original physical standby database will be your primary database with an
upgraded version of the Oracle Database software.


4. Flash back the original primary database to the guaranteed
restore point:
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> FLASHBACK DATABASE TO RESTORE POINT pre_upgrade;
SQL> SHUTDOWN IMMEDIATE

5. Mount the original primary database using the new version
of the software:
SQL> startup mount

4. Flash back the original primary database to the guaranteed restore point that you
created in step 1.
5. Mount the original primary database using the new version of the software. You will not
run the upgrade scripts because this database will be turned into a physical standby,
and will be upgraded automatically as it applies redo data generated from the new
primary database.


6. Convert the original primary database to a physical
standby:
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
7. Start managed recovery on the original primary database:

SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2 USING CURRENT LOGFILE DISCONNECT FROM SESSION;

6. Convert the original primary database to a physical standby database:
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
7. Start the managed recovery process on the original primary database:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT FROM SESSION;


8. Perform a switchover to return your original primary
database to the primary database role. (Optional)
9. Clean up the guaranteed restore point created in step 1.


8. To perform a switchover to return to your original configuration, execute the following
commands on the new primary database:
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
On the original primary database, execute the following commands:
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN IMMEDIATE;
STARTUP
9. Clean up the guaranteed restore point created in step 1.
DROP RESTORE POINT PRE_UPGRADE;

Quiz
You can perform a rolling upgrade using a logical standby SQL

apply technique with zero down time.
a. True
b. False

Answer: b

Quiz
The Data Guard broker can be enabled and running throughout

the upgrade procedures.
a. True
b. False

Answer: b

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

databases in your Data Guard configuration:
• By using traditional upgrade methods
• By performing rolling upgrades


Configuration

Monitoring a Data Guard Broker

Objectives

• Use Enterprise Manager Grid Control to monitor the
configuration
• Use DGMGRL to view the configuration status


Monitoring the Data Guard Configuration by
Using Enterprise Manager Grid Control

On the Data Guard Overview page, you can:
• View the Standby Progress Summary graph that shows
the transport lag and the apply lag
• Access additional performance and configuration
information

– Performance Overview page: Information about data
archived and applied, standby database progress, and log
services
– Log File Details page: Information about the primary
database online redo log file
• Perform a Verify operation
Monitoring the Data Guard Configuration by Using Enterprise Manager Grid

Control
Enterprise Manager Grid Control provides a graphical user interface for monitoring the Data
Guard configuration. The following pages in this lesson describe the information that you can
view on the Data Guard Overview page and its related pages.

Viewing the Data Guard Configuration Status

Viewing the Data Guard Configuration Status

On the Data Guard Overview page, you can view the status of the primary database and the
standby databases in a configuration. In the Standby Progress Summary section, you can
view information about transport and apply lags.
The apply lag shows the approximate number of seconds that the standby database is behind
the primary database. A large apply lag may indicate that Redo Apply needs to be tuned or
that there is a gap.
The transport lag shows the approximate number of seconds of redo not yet available on the
standby database and provides an indication of potential data loss in the event of a disaster.
A significant transport lag may be caused by:
• A gap in the redo
• Network bandwidth constraints
• An overloaded log writer network server (LNS) process on the primary database
• Redo generation that is faster than the LNS and network can handle
• I/O issues on the remote file server (RFS) process side
• An overloaded RFS process
• An inadequate number of standby redo log files causing the RFS process to stall or to
use archived log files
Monitoring Data Guard Performance

Viewing Data Guard Performance

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 following charts display performance information for all databases in the configuration:
• Redo Generation Rate: Redo generation rate (in KB per second).
• Lag Times: Approximate amount of potential data loss. Lag Times -- Shows the
Transport Lag (the approximate number seconds of redo not yet available on the
standby database) and Apply Lag (The approximate number of seconds the standby is
behind the primary database).
• Apply Rate: Data applied 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.
Click any of the charts to obtain historical information.

Viewing Log File Details

Viewing Log File Details

The Log File Details page displays information about the log files that were generated on the
primary database and received by the standby database. The information is presented in a
tabular format for each standby database in the configuration. The table contains the following
columns:
• Log: Contains the log file sequence number
• Status: ―Partially Applied,‖ ―Not Applied,‖ ―Not Received‖
• ResetLogs ID: Identifier that changes after a terminal recovery and an open with
RESETLOGS
• First Change # (SCN): First system change number (SCN) in the log file
• Last Change # (SCN): Last SCN in the log file
• Size (KB): Size of the log file
• Time Generated: Time at which the log file was generated
• Time Completed: Time at which the log file completed

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

health of your system
• Thresholds: Boundary values against which monitored
metric values are compared
• Alert: Indication that is 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.
Metric thresholds are boundary values against which monitored metric values are compared.
Some thresholds are predefined by Oracle; others are not.
When a threshold is reached, an alert is generated to indicate that a particular condition was
encountered. An alert is triggered when one of the following conditions is true:
• A threshold is reached.
• An alert was cleared.
• The availability of a monitored service changes.
• A specific condition occurs. (Example: An alert is triggered when 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, with the automatic execution of a job, and so
on.

Data Guard Metrics
Enterprise Manager provides Data Guard metrics:

Data Guard Metrics

You can use Enterprise Manager to monitor 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 Fast-Start Failover: When fast-start failover is enabled, this metric
generates a critical alert on the new primary database if a fast-start failover occurs.
• Data Guard Fast-Start Failover Observer: This metric displays the current status of
the fast-start failover observer. A down status triggers an alert. The observer is a
separate OCI client-side component that monitors the availability of the primary
database in a fast-start failover configuration. Fast-start failover is discussed in the
lesson titled ―Enabling Fast-Start Failover.‖
• Data Guard Performance: This metric provides alerts for performance that is related to
redo log activity in the configuration.
• Data Guard Status: This metric checks the status of each database in the broker
configuration and triggers a warning or critical alert if necessary.
You can set up Email Services to send you a message if a metric is triggered. See Oracle
Data Guard Broker for detailed information.
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.

Managing Data Guard Metrics

You can specify that an email notification be sent to you when a Data Guard metric is
triggered. 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. Next,
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. Next, view the Oracle Enterprise Manager metrics, including the
metrics for Data Guard.
3. Set or change Data Guard metric thresholds by clicking ―Metric and Policy Settings‖ in
the Related Links section on the All Metrics page to access the ―Metric and Policy
Settings‖ page. On this page, you can set and change the Data Guard Status metric on
the Metrics Thresholds tab.
If a metric condition is triggered or a threshold value is exceeded, an alert is issued. Click
Data Guard Status on the Al Metrics page to view triggered metrics. Click the metric, and
then click a particular database to see details.

Viewing Metric Value History

Viewing Metric Value History

When an alert is triggered, you can view detailed information by clicking the link in the
Message field.

Viewing Data Guard Diagnostic Information
• The Data Guard broker records information in:

– Oracle database alert log files
– Data Guard broker log files
• Database status information is available by issuing the
SHOW DATABASE command.

• Use the following database properties to obtain additional
information:
– StatusReport
– LogXptStatus
– InconsistentProperties
– InconsistentLogXptProps
DGMGRL> SHOW DATABASE 'pc01prmy' 'StatusReport';
Viewing Data Guard Diagnostic Information

The Data Guard broker records activity information in the Oracle database alert log file and in
the Data Guard broker log files. The broker log files are named drc<$ORACLE_SID>.log
and are located in the same directory as the alert log file.
You can obtain information about the health of the database (referred to as the database
status) by issuing the SHOW DATABASE DGMGRL command.
The following monitorable database properties can be used to query the database status:
• StatusReport: Lists all problems detected by the broker during a database health
check
• LogXptStatus: Lists all log transport errors detected on all instances of the primary
database
• InconsistentProperties: Lists all properties that have inconsistent values between
the broker configuration file and the database settings
• InconsistentLogXptProps: Lists all redo transport–related properties of standby
databases that have inconsistent values between the broker configuration file and the
redo transport settings

Using Monitorable Database Properties
to Identify a Failure
1. Check the configuration status:
DGMGRL> SHOW CONFIGURATION;
2. Check the database status:

DGMGRL> SHOW DATABASE 'pc01prmy';
3. Check additional monitorable database properties

DGMGRL> SHOW DATABASE 'pc01prmy'
'InconsistentProperties';
Using Monitorable Database Properties to Identify a Failure

You can use the SHOW CONFIGURATION and SHOW DATABASE commands and the
monitorable database properties to identify and determine an appropriate resolution for a
failure in your Database Guard configuration.
1. Use the SHOW CONFIGURATION command to check the status of the configuration.
The status is an aggregated status of all databases and instances in the broker
configuration. If everything is working properly in the configuration, the output of this
command with respect to status is "SUCCESS." If there is a problem in the configuration,
you receive an error message and it will indicate which databases are in warning or
error states.
2. If you receive an error message when you execute the SHOW CONFIGURATION
command, execute the SHOW DATABASE command for each database to view a partial
list of the warnings and errors for the database. For Oracle Database 11g Release 2
(11.2), the SHOW DATABASE command now includes the output from the previous
'SHOW DATABASE <name> StatusReport' command.
3. After viewing the StatusReport output, you can view the other monitorable database
properties: InconsistentProperties, LogXptStatus,
InconsistentLogXptProps.

Using the SHOW CONFIGURATION DGMGRL
Command to Monitor the Configuration

Use the SHOW CONFIGURATION command to display a brief
description of the configuration status:
DGMGRL> show configuration

Databases:
pc01sby1 - Snapshot standby database
pc01sby3 - Logical standby database
SUCCESS
Using the SHOW CONFIGURATION DGMGRL Command to Monitor the

Configuration
The SHOW CONFIGURATION DGMGRL command provides a brief description of the
configuration, including the state of the configuration, the protection mode, and the state of
fast-start failover. The display also lists the databases that are part of the configurati on.
In addition, the current status of the configuration is provided; if there is a problem with the
configuration, a warning message appears. You can investigate the problem as described on
the following slides.

Using the SHOW DATABASE DGMGRL Command
to Monitor the Configuration

Use the SHOW DATABASE command to display a brief summary
of the database:
Database - pc01sby1

Instance(s):
pc01sby1
Database Status:
SUCCESS
Using the SHOW DATABASE DGMGRL Command to Monitor the Configuration

Use the SHOW DATABASE VERBOSE DGMGRL command to view a brief summary of the
specified database in the broker configuration.

Using the SHOW DATABASE VERBOSE DGMGRL
Command to Monitor the Configuration

Use the SHOW DATABASE VERBOSE command to display all
property values for a database:
DGMGRL> show database verbose pc01sby1
Database - pc01sby1

Instance(s):
pc01sby1
Properties:
DGConnectIdentifier = 'pc01sby1'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
…
Using the SHOW DATABASE VERBOSE DGMGRL Command to Monitor the

Configuration
Use the SHOW DATABASE VERBOSE DGMGRL command to view a brief summary and the
properties of the specified database.

in V$LOGFILE
SQL> SELECT group#, member
2 FROM v$logfile
3 WHERE type = 'STANDBY';
GROUP# STATUS MEMBER

------ ------ ----------------------------------
4 +DATA/pc01prmy/onlinelog/group_4.278.711989145

Viewing Standby Redo Log Information in V$LOGFILE

Obtain information about the standby redo log by querying V$LOGFILE. The STATUS column
contains the following possible values:
• INVALID: The file is inaccessible.
• STALE: The file contents are incomplete.
• DELETED: The file is no longer used.
• Null: The file is in use.

in V$STANDBY_LOG
SQL> SELECT group#, dbid, archived, status
2 FROM v$standby_log;
GROUP# DBID ARC STATUS

---------- -------------- --- ----------
4 UNASSIGNED NO UNASSIGNED

5 3303427449 YES ACTIVE
6 UNASSIGNED YES UNASSIGNED
7 UNASSIGNED YES UNASSIGNED
Viewing Standby Redo Log Information in V$STANDBY_LOG

Query V$STANDBY_LOG to obtain information about the standby redo log. Columns of interest
include:
• GROUP# : Log group number.
• DBID: Database ID of the primary database to which the standby redo log file is
assigned. If the standby redo log file is unassigned, the value UNASSIGNED is displayed.
• ARCHIVED: Contains a value of YES or NO. See STATUS for additional information.
• STATUS: Contains a value of UNASSIGNED or ACTIVE.
- UNASSIGNED: If the value of ARCHIVED is NO, the standby redo log was archived
and is again available. If the value of ARCHIVED is YES, the standby redo log was
never used and is available.
- ACTIVE: If the value of ARCHIVED is NO, the standby redo log is complete and
waiting to be archived. If the value of ARCHIVED is YES, the standby redo log is
currently being written to and is not ready to be archived.

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 ALL_LOGFILES ALL_ROLES YES
2 STANDBY_LOGFILE STANDBY_ROLE WRONG VALID_TYPE

3 ONLINE_LOGFILE STANDBY_ROLE WRONG VALID_ROLE
4 ALL_LOGFILES ALL_ROLES UNKNOWN
…
31 ALL_LOGFILES ALL_ROLES YES
31 rows selected.
Identifying Destination Settings

The VALID_NOW column in V$ARCHIVE_DEST indicates whether the archive log destination
is used. The column contains the following values:
• YES: The archive log destination is appropriately defined for the current database role.
• WRONG VALID_TYPE: 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 an implemented standby redo log.
• WRONG VALID_ROLE: 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 : The archive log destination is not defined.
The VALID_TYPE and VALID_ROLE columns are the values from the VALID_FOR attribute
that is specified for each archive log destination.

Setting the LOG_ARCHIVE_TRACE
Initialization Parameter
• LOG_ARCHIVE_TRACE is optional and is used for
diagnostic purposes.
• Set this parameter to an integer value to see the
progression of redo log archiving to the standby system.
– On the primary database, processes write an audit trail of the

archived logs sent to the standby system into a trace file.
– On the standby database, processes write an audit trail of
the archived logs received from the primary database into a
trace file.
• Trace files are written to the Automatic Diagnostic
Repository, the location of which is specified by the
DIAGNOSTIC_DEST initialization parameter.
Setting the LOG_ARCHIVE_TRACE Initialization Parameter

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,
issue the 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.
See Oracle Data Guard Concepts and Administration for additional information.

Setting the LOG_ARCHIVE_TRACE Initialization Parameter (continued)
The integer values for the LOG_ARCHIVE_TRACE parameter represent levels of tracing data. In
general, a higher level indicates more detailed 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
8192 Tracks Redo Apply activity (media recovery or physical
standby)

Monitoring Redo Apply
by Querying V$MANAGED_STANDBY
SQL> SELECT process, status, group#, thread#, sequence#
2 FROM v$managed_standby
3 order by process, group#, thread#, sequence#;
PROCESS STATUS GROUP# THREAD# SEQUENCE#

--------- ------------ ---------- ---------- ----------

ARCH CLOSING 4 1 142
MRP0 APPLYING_LOG N/A 1 149
RFS IDLE 2 1 149
RFS IDLE N/A 0 0
RFS IDLE N/A 0 0
Monitoring Redo Apply by Querying V$MANAGED_STANDBY

Query V$MANAGED_STANDBY to view information about Redo Apply and redo transport status
on a physical standby database. See the Oracle Database Reference for detailed information
about the values in each column.

Evaluating Redo Data
by Querying V$DATAGUARD_STATS
SQL> SELECT name, value, time_computed
2 FROM v$dataguard_stats;
NAME VALUE TIME_COMPUTED

------------------------- --------------- --------------
apply finish time +00 00:00:00.0 13-FEB-2010

02:44:21
apply lag +00 00:00:00 13-FEB-2010
02:44:21
estimated startup time 12 13-FEB-2010
02:44:21
standby has been open N 13-FEB-2010
02:44:21
transport lag +00 00:00:00 13-FEB-2010
02:44:21
Evaluating Redo Data by Querying V$DATAGUARD_STATS

Query V$DATAGUARD_STATS to evaluate each standby database in terms of the currency of
the data in the standby database and the time it takes to perform a role transition if all
available redo data is applied to the standby database.
V$DATAGUARD_STATS displays the amount of redo data generated by the primary database
that is not yet available on the standby database. This information enables you to determine
how much redo data would be lost if the primary database were to crash when you queried
this view.
See the Oracle Database Reference for detailed information about column values.

Viewing Data Guard Status Information
by Querying V$DATAGUARD_STATUS
SQL> SELECT timestamp, facility, dest_id, message_num,
2 error_code, message
3 FROM v$dataguard_status
4 ORDER by timestamp;
TIMESTAMP FACILITY DEST_ID MESSAGE_NUM ERROR_CODE
--------- --------------- ------- ----------- ----------

MESSAGE
--------------------------------------------------------
13-FEB-10 Log Apply Servi 0 562 0
Media Recovery Waiting for thread 1 sequence 151
13-FEB-10 Remote File Ser 0 563 0
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
RFS[25]: Successfully opened standby log 5:
'/u01/app/oracle/oradata/pc00sby1/srl02.log'
Viewing Data Guard Status Information by Querying V$DATAGUARD_STATUS

Query V$DATAGUARD_STATUS to view messages that were recently written to the alert log or
server process trace files that concern physical standby databases or redo transport services
for all standby database types.
See the Oracle Database Reference for detailed information about column values.

Viewing V$LOGSTDBY_TRANSACTION
Query V$LOGSTDBY_TRANSACTION to view information

about all transactions that are actively being processed
by SQL Apply:
SQL> SELECT primary_xid, type,
2 mining_status, apply_status

3 FROM v$logstdby_transaction;
Viewing V$LOGSTDBY_TRANSACTION
Query V$LOGSTDBY_TRANSACTION to view information about the transactions that are
actively being processed by SQL Apply. The transaction identifiers shown in this view
correspond to transaction identifiers assigned at the primary database and do not correspond
to the transactions that are active at the logical standby database. Query the
V$TRANSACTION view on the logical standby database for information about transactions that
are active in the logical standby database, including those that were created as part of SQL
Apply.

Quiz
You can click the Data Guard performance charts that show
real-time data in Oracle Enterprise Manager to view historical
data.
a. True
b. False

Answer: a

Quiz
The LOG_ARCHIVE_TRACE initialization parameter is valid only

on the primary database to display diagnostic information
regarding sending of redo data.
a. True
b. False

Answer: b

Summary

• Use Enterprise Manager Grid Control to monitor the
configuration
• Use DGMGRL to view the configuration status



• Verifying the broker configuration
• Viewing log file details
• Checking the configuration status
• Checking the database status



Optimizing a Data Guard Configuration

Objectives

• Monitor configuration performance
• Optimize redo transport for best performance
• Optimize SQL Apply


Monitoring Configuration Performance
by Using Enterprise Manager Grid Control

Review detailed performance statistics on the Performance
Overview page.

Monitoring Configuration Performance by Using Enterprise Manager Grid Control

Graphical charts on the Performance Overview page:
• Redo Generation Rate: Shows the redo generation rate (in KB per second) on the
primary database.
• Apply Rate: Shows the apply rate (in KB per second) on the standby database. The
―Apply Rate When Active‖ statistic indicates the actual apply rate averaged over the last
three log files.
• Lag Time: Shows the transport lag and apply lag. Transport lag is the approximate
amount of redo (in seconds) that is not yet available on the standby database. Apply lag
is the approximate number of seconds by which the standby database is behind the
primary database.
On the Performance Overview page, you can invoke a test application to generate a workload
on the primary database. This provides a way to view performance metrics when the primary
database is operating under a load.

Optimizing Redo Transport Services
Optimize redo transport with the following techniques:

• Optimizing asynchronous redo transmission by using
multiple archiver processes
• Compressing redo data

Optimizing Redo Transport Services

Information about these techniques is provided in the following slides.

Setting the ReopenSecs Database Property
• This property specifies the minimum number of seconds

before the archiver process tries to access a previously
failed destination.
• Broker default: 300
• Set for the standby database.

• Setting is propagated to the REOPEN attribute of the
LOG_ARCHIVE_DEST_n initialization parameter of the
primary database.
DGMGRL> EDIT DATABASE 'pc01sby1'
> SET PROPERTY 'ReopenSecs'=600;
Setting the ReopenSecs Database Property

When you specify a value for the ReopenSecs database property, it is propagated to the
REOPEN attribute of the LOG_ARCHIVE_DEST_n initialization parameter for your primary
database. The REOPEN attribute of the LOG_ARCHIVE_DEST_n parameter specifies the
minimum number of seconds before the process that is shipping the redo should try again to
access a previously failed destination.
REOPEN applies to all errors and not only connection failures. These errors include (but are
not limited to) network failures, disk errors, and quota exceptions.

Setting the NetTimeout Database Property
• This property specifies the number of seconds that the log

writer process (LGWR) waits for Oracle Net Services to
respond to a request.
• Setting is propagated to the NET_TIMEOUT attribute of the

primary database.

> SET PROPERTY 'NetTimeout'=20;
Setting the NetTimeout Database Property

When you specify a value for the NetTimeout database property, it is propagated to the
NET_TIMEOUT attribute of the LOG_ARCHIVE_DEST_n initialization parameter for your
primary database. The NET_TIMEOUT attribute enables you to bypass the default network
timeout interval that was established for the system on which the primary database resides.
Without the NET_TIMEOUT attribute, 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: Remember to specify a reasonable value when running in maximum protection mode.
False network failure detection may cause the primary instance to shut down if there are no
other standby databases in the correct mode that can be contacted by the primary database
instance.

Optimizing Redo Transmission by Setting
MaxConnections
Primary
database MRP or
transactions LSP Standby
database
LGWR LNSn
RFS
Oracle Net

Online
redo Backup
logs
Reports
ARC0
ARC1
ARC2

logs logs
Optimizing Redo Transmission by Setting MaxConnections

The redo transport mechanism uses all available bandwidth by allowing a single large redo
log file to be transferred in parallel by multiple archiver processes. This behavior is controlled
by the MaxConnections database property.
This architecture increases the redo transfer rate and enables faster redo transmission to
standby databases for bulk batch updates on the primary database. As a result of the
improvement in transfer rates, there is an increased availability of data at the standby
database site.

Setting the MaxConnections Database Property
• This property specifies the number of archiver processes

that are used to transmit redo data from a single archived
redo log on the primary database to the archived redo log
at the remote site for gap resolution.

• Setting is propagated to the MAX_CONNECTIONS attribute
of the LOG_ARCHIVE_DEST_n initialization parameter of

> SET PROPERTY 'MaxConnections'=5;
Setting the MaxConnections Database Property

When you specify a value for the MaxConnections database property, it is propagated to
the MAX_CONNECTIONS attribute of the LOG_ARCHIVE_DEST_n initialization parameter for
your primary database. The MAX_CONNECTIONS attribute of LOG_ARCHIVE_DEST_n is used
to set the number of parallel connections that are used for transmitting archived redo log files
to a remote destination. The MAX_CONNECTIONS attribute defaults to 1, indicating that a
single connection is established for the communication and transfer of data. The maximum
value for MAX_CONNECTIONS is 5.
Note: You must set the LOG_ARCHIVE_MAX_PROCESSES initialization parameter to be
greater than or equal to the value of MAX_CONNECTIONS to achieve the desired number of
parallel connections. If the value of the MAX_CONNECTIONS attribute exceeds the value of
LOG_ARCHIVE_MAX_PROCESSES, Data Guard uses the available archiver processes.

Compressing Redo Data
by Setting the RedoCompression Property

• This can be enabled for all redo transport methods (AYNC
and SYNC).
• Setting is propagated to the COMPRESSION attribute of the
LOG_ARCHIVE_DEST_n initialization parameter.
• Determine whether redo compression is enabled by

querying the COMPRESSION column of the
V$ARCHIVE_DEST view.
• Enable by using DGMGRL:
> SET PROPERTY 'RedoCompression'='ENABLE';
• Enable by using SQL:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3 =
> 'SERVICE=denver SYNC COMPRESSION=ENABLE';
Compressing Redo Data

When the communication network to remote databases is a high-latency, low-bandwidth WAN
link and the redo data that is transferred to standby databases is substantial, you want to
make the most effective use of network bandwidth. Redo transport compression can be
enabled on any remote destination for all redo transport methods to reduce network
bandwidth usage.
Redo compression can be enabled or disabled by setting the Oracle Data Guard broker’s
RedoCompression property. The setting is propagated to the COMPRESSION attribute of the
LOG_ARCHIVE_DEST_n initialization parameter. Redo compression is disabled by default. All
databases in a Data Guard configuration must use Oracle Database 11g to enable redo
transport compression.
When you add a database to the Data Guard configuration, the Data Guard broker
automatically detects whether network compression is enabled or disabled for the standby
database being added. The property is set accordingly.
Note: Use of this feature requires the Oracle Advanced Compression option.

Delaying the Application of Redo
Delaying the application of redo helps 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 and 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 the
change in the standby database.
When operating in maximum protection or maximum availability mode, Data Guard ensures
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.
Note: You can use Flashback Database as an alternative to the Apply Delay configuration
option. Flashback database is an Oracle best practice. See the lesson titled ―Using Flashback
Database in a Data Guard Configuration‖ for additional information.

Setting the DelayMins Database Property
to Delay the Application of Redo

• This property specifies the number of minutes that log
apply services must wait before applying redo data to the
standby database.
• Broker default: 0 (meaning that apply services applies redo
data as soon as possible)

• Setting is propagated to the DELAY attribute of the
primary database.

> SET PROPERTY 'DelayMins'=5;
Setting the DelayMins Database Property to Delay the Application of Redo

Use the DelayMins configurable database property to specify the number of minutes that log
apply services must wait before applying redo data to the standby database. This setting is
propagated to the DELAY attribute of the LOG_ARCHIVE_DEST_n initialization parameter.

to Delay the Application of Redo

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

1. On the Data Guard page, select your standby database and click Edit.
2. On the Edit Standby Database Properties page, click Standby Role Properties.
3. In the Apply Delay field, enter the delay value (in minutes).
4. Click Apply.

Optimizing SQL Apply
• Adjust the number of processes allocated to SQL Apply.

– APPLIER processes
– PREPARER processes
• Modify SQL Apply parameters to control the number of
processes allocated to SQL Apply.

– APPLY_SERVERS: Number of APPLIER processes that are
used to apply changes
– MAX_SERVERS: Number of processes that SQL Apply uses
to read and apply redo
– PREPARE_SERVERS: Number of PREPARER processes that
are used to prepare changes
• Set SQL Apply parameters by using the DBMS_LOGSTDBY
package.
Optimizing SQL Apply

The MAX_SERVERS, APPLY_SERVERS, and PREPARE_SERVERS parameters can be modified
to control the number of processes that are allocated to SQL Apply. Because SQL Apply
allocates one process for the READER, BUILDER, and ANALYZER roles, the following
relationship between the three parameters is required:
APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS – 3
Use the DBMS_LOGSTDBY.APPLY_SET procedure to change the APPLY_SERVERS,
MAX_SERVERS, and PREPARE_SERVERS parameters.
Query DBA_LOGSTDBY_PARAMETERS to view the SQL Apply parameter settings.
Note: See the Oracle Database PL/SQL Packages and Types Reference for detailed
information about the DBMS_LOGSTDBY.APPLY_SET procedure. Also consult the "SQL Apply
Best Practices: Oracle Data Guard 11g Release 1" whitepaper found at:
http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11gr1_sqlapplybestpractices.pdf

Adjusting the Number of APPLIER Processes
• Determine whether adjusting the number of APPLIER

processes achieves greater throughput.
– Determine if APPLIER processes are busy:
SQL> SELECT COUNT(*) AS IDLE_APPLIER
2 FROM V$LOGSTDBY_PROCESS
3 WHERE TYPE = 'APPLIER' and status_code = 16166;

– Determine if there is enough work available for additional
APPLIER processes:
2 WHERE NAME LIKE 'transactions%';
• Adjust the MAX_SERVERS parameter (if necessary).

• Adjust the APPLY_SERVERS parameter to increase the
number of APPLIER processes.
Adjusting the Number of APPLIER Processes

Before changing the number of APPLIER processes, perform the following steps to determine
whether adjusting the number of APPLIER processes will help you achieve greater
throughput:
1. Determine if APPLIER processes are busy by issuing the following query:
SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'APPLIER' and status_code = 16166;
2. After ensuring that there are no idle APPLIER processes, determine if there is enough
work available for additional APPLIER processes by issuing the following query:
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE 'transactions%';
The second query returns two statistics that provide a cumulative total: the number of
transactions that are ready to be applied by the APPLIER processes and the number of
transactions that have already been applied. If the difference between "transactions mined"
and "transactions applied" is higher than twice the number of available APPLIER processes,
an improvement in throughput is possible if you increase the number of APPLIER processes.
Before you increase the number of APPLIER processes, consider the following requirement:
Adjusting the Number of PREPARER Processes
• Determine whether adjusting the number of PREPARER

processes is required.
– Determine if all PREPARER processes are busy:
SQL> SELECT COUNT(*) AS IDLE_PREPARER
3 WHERE TYPE = 'PREPARER' and status_code = 16166;

– Determine if the number of transactions ready to be applied
is less than the number of available APPLIER processes:
2 WHERE NAME LIKE 'transactions%';
SQL> SELECT COUNT(*) AS APPLIER_COUNT
2 FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';

On rare occasions, you may need to adjust the number of PREPARER processes. Before
increasing the number of PREPARER processes, verify that the following conditions are true:
• All PREPARER processes are busy.
• The number of transactions ready to be applied is less than the number of available
APPLIER processes.
• There are idle APPLIER processes.
Perform the following queries to verify the preceding conditions:
1. Determine if all PREPARER processes are busy:
SELECT COUNT(*) AS IDLE_PREPARER
FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'PREPARER' and status_code = 16166;
2. Determine if the number of transactions ready to be applied is less than the number of
APPLIER processes:
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE 'transactions%';
SELECT COUNT(*) AS APPLIER_COUNT
FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';

– Determine if there are idle APPLIER processes:

SQL> SELECT COUNT(*) AS IDLE_APPLIER
3 WHERE TYPE = 'APPLIER' and status_code = 16166;
• Adjust the MAX_SERVERS parameter if necessary.

• Adjust the PREPARE_SERVERS parameter to increase the
number of PREPARER processes.
Adjusting the Number of PREPARER Processes (continued)

3. Determine if there are idle APPLIER processes:
SELECT COUNT(*) AS IDLE_APPLIER
FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'APPLIER' and status_code = 16166;
Before you increase the number of PREPARER processes, consider the requirement:
You may need to increase the value of MAX_SERVERS before increasing the value of
PREPARE_SERVERS.
Use the DBMS_LOGSTDBY.APPLY_SET procedure to increase the values of MAX_SERVERS
and PREPARE_SERVERS, as shown in the following example:
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 26);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 3);

Quiz
Enabling Data Guard network redo compression requires the

Oracle database Advanced Compression option.
a. True
b. False

Answer: a

Quiz
The Data Guard MAX_SERVERS, APPLY_SERVERS, and

PREPARE_SERVERS parameters can be adjusted with the
database initialization parameter file.
a. True
b. False

Answer: b

Summary

• Monitor configuration performance
• Optimize redo transport for best performance
• Optimize SQL Apply


This practice covers configuring network compression of redo

data.


D52161GC30 SG New PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

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

D52161GC30 SG New PDF

Hochgeladen von

Copyright:

Verfügbare Formate

HESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBIT ED

unarski inzenjering d.o.o use only

Mark Fuller Disclaimer

1 Introduction to Oracle Data Guard

Oracle University and Digit racunarski inzenjering d.o.o use only

2 Creating a Physical Standby Database by Using SQL and RMAN Commands

Combinations for VALID_FOR 2-17

Oracle University and Digit racunarski inzenjering d.o.o use only

3 Oracle Data Guard Broker: Overview

Benefits of Using Enterprise Manager 3-16

4 Creating a Data Guard Broker Configuration

Oracle University and Digit racunarski inzenjering d.o.o use only

5 Creating a Physical Standby Database by Using Enterprise Manager Grid

Oracle University and Digit racunarski inzenjering d.o.o use only

6 Creating a Logical Standby Database

Oracle University and Digit racunarski inzenjering d.o.o use only

7 Creating and Managing a Snapshot Standby Database

8 Using Oracle Active Data Guard

Setting STANDBY_MAX_DATA_DELAY by Using an AFTER LOGON Trigger 8-14

Oracle University and Digit racunarski inzenjering d.o.o use only

9 Configuring Data Protection Modes

10 Performing Role Transitions

Oracle University and Digit racunarski inzenjering d.o.o use only

11 Using Flashback Database in a Data Guard Configuration

12 Enabling Fast-Start Failover

Configuring the Primary Database to Shut Down Automatical y 12-13

Oracle University and Digit racunarski inzenjering d.o.o use only

13 Managing Client Connectivity

Creating the AFTER STARTUP Trigger 13-14

Oracle University and Digit racunarski inzenjering d.o.o use only

14 Backup and Recovery Considerations in an Oracle Data Guard Configuration

15 Patching and Upgrading Databases in a Data Guard Configuration

Oracle University and Digit racunarski inzenjering d.o.o use only

16 Monitoring a Data Guard Broker Configuration

Viewing Standby Redo Log Information in V$LOGFILE 16-16

Oracle University and Digit racunarski inzenjering d.o.o use only

17 Optimizing a Data Guard Configuration

Oracle University and Digit racunarski inzenjering d.o.o use only

Oracle University and Digit racunarski inzenjering d.o.o use only

Oracle University and Digit racunarski inzenjering d.o.o use only

Title Part Number

unarski inzenjering d.o.o use only

words that appear within regular text or within code samples.

1. Typographic Conventions for Words Within Regular Text

Oracle University and Digit racunarski inzenjering d.o.o use only

Initial cap Triggers; Assign a When-Validate-Item trigger to

Italic Titles of For more information on the subject see

Quotation marks Lesson or module This subject is covered in Lesson 3,

2. Typographic Conventions for Words Within Code Samples

Oracle University and Digit racunarski inzenjering d.o.o use only

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

Oracle University and Digit racunarski inzenjering d.o.o use only

After completing this lesson, you should be able to:

Oracle University and Digit racunarski inzenjering d.o.o use only

Oracle Database 11g: Data Guard Administration 1-2

Oracle University and Digit racunarski inzenjering d.o.o use only

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

What Is Oracle Data Guard?

Oracle Database 11g: Data Guard Administration 1-3

• Physical standby database:

Oracle University and Digit racunarski inzenjering d.o.o use only

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.